Re: [Flightgear-devel] SimGear warning cleanup patch
Petru Paler wrote: Attached. It's basically a couple unused variables, an explicit cast, some unused functions removed or commented out, and a whole bunch of pragmas removed. About the pragmas: Are you sure thay don'r mean anything on other platforms? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ATC
Now that 0.7.9 is released I've got round to looking at the subject of ATC again. This is probably going to be a long post so make sure you've all had your coffee :-) I basically hacked the ATIS support into Flightgear, on the grounds that is was the simplest possible part of ATC to implement, and could be done by that kind of thuggery. As the ATC gets extended though this approach won't be good enough, so after some thought I've come up with a proposed ATC architecture within Flightgear. I'm not an experienced programmer as far as architecture goes though (this is the only large scale C++ code that I contribute to) so I'd like to throw it out to the rest of you for consideration. At the moment I've modelled the comm/ATIS interaction on how the nav/VOR adf/ADF works in FGRadioStack. The FGRadioStack::Search() function searches for valid stations and flags hits. The FGRadioStack::Update() function processes the results of valid hits, updating the vor/adf/ils needles, and managing and updating the atis transmission. This works fine for vor/nav/adf etc since the pilot is only concerned with his/her own instruments, and it is a fairly well bounded problem. It's going to fall down with ATC since potentially the system must display messages from/to other aircraft, and the problem is much larger in scope and will thoroughly mess up radiostack.cxx. Hence I propose that all FGRadioStack does is to either just supply the selected comm frequencies to an ATC manager, or possibly do the station lookup in the Search() function and then flags hits to relevant stations to the ATC manager. The latter has the advantage that any work done by the navaid people to better model the limits of reception may be used by the comm stuff. The former has the advantage that the ATC manager will probably have to have the capability to do station/frequency lookups anyway for the AI traffic. For the ATC itself, I propose that the overall ATC is handled by one global FGATCMgr. This will accept input from several sources; the radiostack of the current aircraft (as discussed above), the position of the current aircraft, the AI traffic module, and an input module to parse input from the user of the current airplane. It will output to one global FGATCDisplay module (as the hack does at the moment) for rendering of the ATC output, either to screen or voice or both, and also directly to the AI traffic module. It will maintain instances of FGATIS, FGTower, FGEnRoute, FGGround etc as needed, possibly more than one instance of each if required. These sub-modules will do the actual work of generating the transmission contents. Its possible that it might be necessary to write an FGFlightPlan module as well - can someone tell me whether real life ATC actually knows whats in a flightplan after its been filed or is it simply a case of the pilot just requests what's on his/her flightplan? ATC potentially requires large amounts of data - airways, sid/stars, frequencies for all the types of ATC, etc etc. For now I will carry on with the STL map approach that the airport data and atis uses, but try to compartmentalise the reading of the data such that it will be easy to just change the data access functions if we want to move to a database or whatever in the future. None of this is going to appear very quickly (unless someone else is already working on it or planning to!) since I am very time pressed, but I will start implementing this, so get comments on the architecture in now if you think I'm going wrong please. If anyone else is working on aspects of ATC/AI traffic modelling please give me a shout since I've no desire to duplicate work. I'm sure someone mentioned on this list once that they were working on canned voice ATC, or was I imagining it? Due to the natural physical splitting of ATC into ground/tower/approach/departure etc in real life its also a prime candidate for a collaborative approach if anyone who wants to contribute to Flightgear but doesn't know where to get started fancies pitching in... Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] plane banks to left side
On Sat 23. February 2002 04:12, you wrote: Please start with some yasim aircraft and apply parking break. Look at skid ball. I thought that it should be in the middle of tube, when sitting on runway. but it isn't. Is your runway flat ? I started on KSFO. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen writes: Working from a single thread is obviously the easiest solution, where possible. However, in the case of our property system, potentially any part of the code may want to access those properties. We'd have to assign one thread as the property manager, and do all property access via the/an inter-thread messaging system. Not very nice, IMHO. I think it would be better for the main thread to read the information from the property manager and then pass it to an object that the other thread can access. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson writes: Threading is *really* scarey in a program of this magnitude. Even the current threaded tile manager is a big time bomb waiting to happen. We are getting away with doing stuff that's not guaranteed to work. We've taken a lot of steps to try to minimize the potential problems, but as the scenery and modeling gets more complex this problem is only going to get worse. Threading is relatively safe if each thread is forced to play in a sandbox. A subsystem running in a separate thread must *not* touch any other subsystem (including the property manager), and must send and receive all information through a single, tightly-controlled interface. That implies that a subsystem in a separate thread should not even include other FlightGear header files, much less access FGGlobals, FGInterface, the property manager, or anything else directly. The best candidates for separate threads are processes that have relatively little input or output but require a lot of computation. For example, if some day we have an incredibly sophisticated weather simulator that actually models air currents over different terrain types, we might actually let it do its computations in a low-priority background thread and report back every minute or so. I don't think that threads are a panacea for whatever ails us. Another good candidate for a separate thread would be auto-generated, smoothly-transitioning terrain textures. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
Andy Ross writes: The effect is happening because the aircraft isn't consuming fuel. If you take off at full tanks, you never get any lighter. A real aircraft would have burned off a big chunk of its fuel store in the climb, and would have an easier time of it. As a workaround, try starting /sim/fuelfraction at 0.5 or so, to simulate an early-to-mid-flight cruise condition. It should climb much better. Fuel consumption in YASim will get done RSN, I promise. That's a good point. I remember reading an article where the author sat in an A340 cockpit on a London-Vancouver flight; it wasn't until around Greenland that the plane had burned enough fuel that it could climb to full cruising altitude. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
On Sat 23. February 2002 01:06, you wrote: The flightgear side really only knows the current ground elevation for a specific lon/lat. FlightGear has no way to know the dimensions of a specific aircraft or the relative placement of the gear. It would seem like the best thing FlightGear can do is provide the elevation of the ground for the starting lon/lat, and then it should be up to the FDM to do the rest. BTW How you can get altitude of specific lat,lon position, please? What about scheme, when FDM or other SubSystem store lat,lon position structures on some heap and after frame render get it back with filled altitude. The FDM passes back the location of the aircraft's CG, and this combined with knowledge of the aircraft orientation and pilot view offset relative to the CG allows FlightGear to properly render the scene. I don't know the details of how it works know, but it seems like the FDM would need to find a suitable starting point for the CG given the information FlightGear can provide (which is the ground elevation.) This is a tricky area though so if there's something I'm missing feel free to point it out. :-) Curt. Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
--- Martin Dressler [EMAIL PROTECTED] wrote: On Sat 23. February 2002 01:06, you wrote: The flightgear side really only knows the current ground elevation for a specific lon/lat. FlightGear has no way to know the dimensions of a specific aircraft or the relative placement of the gear. It would seem like the best thing FlightGear can do is provide the elevation of the ground for the starting lon/lat, and then it should be up to the FDM to do the rest. BTW How you can get altitude of specific lat,lon position, please? What about scheme, when FDM or other SubSystem store lat,lon position structures on some heap and after frame render get it back with filled altitude. The scheme used to pass the data back and forth is not the problem. It's farther upstream than that. The FDM passes back the location of the aircraft's CG, and this combined with knowledge of the aircraft orientation and pilot view offset relative to the CG allows FlightGear to properly render the scene. I don't know the details of how it works know, but it seems like the FDM would need to find a suitable starting point for the CG given the information FlightGear can provide (which is the ground elevation.) This is a tricky area though so if there's something I'm missing feel free to point it out. :-) Curt. Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Temperature and air pressure
On Fri 22. February 2002 23:41, you wrote: I've added two new properties tied to the FGEnvironment class (you'll see these only if you compile with --with-new-environment): /environment/temperature-sea-level-degc /environment/pressure-sea-level-inhg I'm sticking with sea-level-equivalent values for now, because I know that the FDM people are pretty possessive of their atmosphere models. Later I might add properties and methods for the values at current altitude as well. I'd very much like to figure out how to hook these up to the FDMs, so that we can have sluggish climb behaviour on hot, muggy days, etc. We might also need a relative-humidity property. What units should we use? Do the FDMs care about humidity? All the best, David Is Humidity important? Why not report just air density and viscosity. IMHO viscosity is importanat for count of Reynolds number. Maybe Re don't play big role in currents FDMs but is really important for RC modeling. OT: What are necessary values for FDM. air pressure air density viscosity temperature wind vector gravitation vector, Forgot I something? Reagrds, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tower view
Someone needs to rewrite the viewer code to allow viewpoints to be added at runtime; then, we can define a tower position for specific airports and allow you to switch to the nearest tower. And as usual, I don't have the time (much less the programming prowess) to take on such a task. I have in my mind this Idea, which doesn't need locations of Towers. Maybe it is from Flight Unlimited II. When you switch to tower view( or better ground view) your view point initialize at some specified (in cofig file) distance before and left of aircraft at specified altitude above ground. And stay here until you switch to another view mode. I look for one moth that I write it, but I still can't get enough time to do it. Reagrds, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson writes: Textures: any threading that involves portions of opengl needs to be handled very delicately. No, I wouldn't touch OpenGL. I'm talking about generating textures in-memory; they would then be passed off to the main thread for use by OpenGL. We're a long way from that, though, so there's no need to worry. Anyway, in the back of my head, someday, I want to try to develop a case against the threaded tile pager and maybe figure out a way to to partial per frame model loading and unloading ... not that I don't desparately wish we could do it, it's just that I'm not sure we can do it reliably in the face of all the things the tile loader will need to do in the long term ... (?) What you need to do is isolate the tile manager completely, so that it has (almost) no dependencies on the rest of the program, except for one structure for data exchange. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
David Megginson writes: Anyway, in the back of my head, someday, I want to try to develop a case against the threaded tile pager and maybe figure out a way to to partial per frame model loading and unloading ... not that I don't desparately wish we could do it, it's just that I'm not sure we can do it reliably in the face of all the things the tile loader will need to do in the long term ... (?) What you need to do is isolate the tile manager completely, so that it has (almost) no dependencies on the rest of the program, except for one structure for data exchange. I don't think the solution can be that trivially simple. The render thread has opengl/scene graph dependencies. The tile pager has opengl/scene graph dependencies. That in itself forces you to do a *lot* of horsing around. For instance, you can't directly call a plib model loader in the tile paging thread because that could involve creating textures (which would involve opengl calls) and you'd open yourself up for strange crashes and wierd visual anomalies. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson writes: David Megginson writes: What you need to do is isolate the tile manager completely, so that it has (almost) no dependencies on the rest of the program, except for one structure for data exchange. I don't think the solution can be that trivially simple. The render thread has opengl/scene graph dependencies. The tile pager has opengl/scene graph dependencies. That in itself forces you to do a *lot* of horsing around. For instance, you can't directly call a plib model loader in the tile paging thread because that could involve creating textures (which would involve opengl calls) and you'd open yourself up for strange crashes and wierd visual anomalies. Surely it is possible to do a byte by byte copy of the tile from disk to memory in a separate thread, without *any* Opengl/ssg/plib dependency, such that the main thread need only access memory and not disk? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
D Luff writes: Surely it is possible to do a byte by byte copy of the tile from disk to memory in a separate thread, without *any* Opengl/ssg/plib dependency, such that the main thread need only access memory and not disk? Surely it is possible, but if your goal is to push all time consuming portions of the tile paging process out into a separate thread to avoid rendering pauses, then this doesn't buy you as much as you might hope. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC
On 25 Feb 2002, at 11:00, D Luff wrote: thoroughly mess up radiostack.cxx. Hence I propose that all FGRadioStack does is to either just supply the selected comm frequencies to an ATC manager, or possibly do the station lookup in the Search() function and then flags hits to relevant stations to the ATC manager. The latter has the advantage that any work done by the navaid people to better model the limits of reception may be used by the comm stuff. The former has the advantage that the ATC manager will probably have to have the capability to do station/frequency lookups anyway for the AI traffic. In fact, after looking at it, I think I'll just get the comm frequencies directly into the ATC manager with the bind method and rip all of the comm stuff out of radiostack. Any objections? Also, am I right in thinking that the global ATC manager and ATC display manager should both be derived from FGSubsystem and declared in FGGlobals in order to fit in properly with the future direction of FlightGear? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson writes: D Luff writes: Surely it is possible to do a byte by byte copy of the tile from disk to memory in a separate thread, without *any* Opengl/ssg/plib dependency, such that the main thread need only access memory and not disk? Surely it is possible, but if your goal is to push all time consuming portions of the tile paging process out into a separate thread to avoid rendering pauses, then this doesn't buy you as much as you might hope. Fair enough. I was under the impression that it was the disk access taking the time. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
D Luff writes: Fair enough. I was under the impression that it was the disk access taking the time. Registering new textures with opengl can take a noticable amount of time (especially when they are large.) Freeing memory (and any associated garbage collection) can actually be a *big* hit at times. It actually is a very complicated problem to do tile paging properly in a separate thread. What we have now mostly works but has grown pretty ugly in response to some of the practical difficulties with doing this well. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC
D Luff writes: Also, am I right in thinking that the global ATC manager and ATC display manager should both be derived from FGSubsystem and declared in FGGlobals in order to fit in properly with the future direction of FlightGear? Yes, that would be a good idea. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Temperature and air pressure
Martin Dressler wrote: Is Humidity important? Why not report just air density and viscosity. IMHO viscosity is importanat for count of Reynolds number. Maybe Re don't play big role in currents FDMs but is really important for RC modeling. OT: What are necessary values for FDM. air pressure air density viscosity temperature wind vector gravitation vector, Forgot I something? If you want to provide data you need it first. And there are no weather reports that give me viscosity AFAIK. So any weather system can only provide data that it has and that it can derivate (e.g. denisty from pressure and temperature). If you want viscosity and it's possible to derivate, that's fine. But to 'publish' that data it's important how expensive it's to compute (and to publish) and how many subsystems need it. So it *might* be better if that data isn't provided and the (yet-to-come) ModelSim FDM calculates it itself. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson wrote: D Luff writes: Fair enough. I was under the impression that it was the disk access taking the time. Registering new textures with opengl can take a noticable amount of time (especially when they are large.) Freeing memory (and any associated garbage collection) can actually be a *big* hit at times. It actually is a very complicated problem to do tile paging properly in a separate thread. What we have now mostly works but has grown pretty ugly in response to some of the practical difficulties with doing this well. Well, I don't know the current threading code (well, it won't run under MSVC anyway AFAIK). But I'm under the impression that on my compiles the disk access is quite a problem (noticeable 'jumps' for each tile). That's no surprise. Current disks have an access time of 10 ms. If we need - say - 10 files we'll have 100 ms. (unrealistical guess as there's caching, etc., but that's w/o the work that's done as soon as the files are loaded). 100 ms is 1/10 s and that's very noticeable. Just reading the data in an extra thread into a buffer and doing the rest in the main thread should help a bit. To avoid memory (re)allocation we can recycle that buffer. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
David Megginson [EMAIL PROTECTED] said: Andy Ross writes: The effect is happening because the aircraft isn't consuming fuel. If you take off at full tanks, you never get any lighter. A real aircraft would have burned off a big chunk of its fuel store in the climb, and would have an easier time of it. As a workaround, try starting /sim/fuelfraction at 0.5 or so, to simulate an early-to-mid-flight cruise condition. It should climb much better. Fuel consumption in YASim will get done RSN, I promise. That's a good point. I remember reading an article where the author sat in an A340 cockpit on a London-Vancouver flight; it wasn't until around Greenland that the plane had burned enough fuel that it could climb to full cruising altitude. Yes agreed. And probably with a 747-400 it is only those longer flights like London-Vancouver that get filled to the brim with fuel. Andy, is the aircraft otherwise considered filled to capacity (passenger/cargo) in the fdm? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] UIUC Paper Publication (FlightGear References)
Bipen Sehgal, Robert Deters, and Michael Selig recently published a paper on their smart icing system research, specifically describing their Icing Encounter Flight Simulator. [1] You can view this paper in PDF format here: http://amber.aae.uiuc.edu/~m-selig/apasim/pubs/ It is a very nice paper, it speaks highly of the FlightGear project, and it show cases one category of use that FlightGear is well suited towards. I have linked to it from the FlightGear page describing the UIUC smart icing project: http://www.flightgear.org/Projects/uiuc.html [1] My wife just got done taking a cake decorating class so I have thoughts of rose petals, vines, and leaves, etc. when I see the name of the UIUC sim. :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3D Model Configuration Changes
I've just made some changes to how 3D models are configured. The following properties are no longer used: /sim/model/heading-offset-deg /sim/model/pitch-offset-deg /sim/model/roll-offset-deg /sim/model/x-offset-m /sim/model/y-offset-m /sim/model/z-offset-m Instead, if the /sim/model/path property points to a file ending with .xml, the FGAircraftModel class reads a property file at that location to get information about the 3D model. Initially, the following properties are recognized: /path The path to the model, relative to the XML file (not FG_ROOT). /offsets/heading-deg The heading rotation for the model, in degrees. /offsets/pitch-degThe pitch rotation for the model, in degrees. /offsets/roll-deg The roll rotation for the model, in degrees. /offsets/x-m The x-axis transformation, in meters. /offsets/y-m The y-axis transformation, in meters. /offsets/z-m The z-axis transformation, in meters. Here's an example for my C172 model: ?xml version=1.0? PropertyList pathc172-dpm.ac/path offsets heading-deg270/heading-deg z-m-1/z-m /offsets /PropertyList This uses the file c172-dpm.ac in the same directory as the 3D model, rotates the model 270 degrees around the z-axis (the heading rotates around z=0), and lowers it 1 meter along the z-axis. Very, very soon, the file will also contain information on animating parts of the model (propellers, ailerons, flaps, etc.) based on property values. This will work with *any* 3D format that allows objects inside the 3D model to be named (including ssg, VRML, AC3D, and, I think, MDL formats). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C 172 panel
Hi, I´ve found this panel and it seem to be very cool. What do you think ? http://www.avsim.com/pages/1000/dreamfleet/dffull.jpg All the best. Sergio Roth
Re: [Flightgear-devel] C 172 panel
Sergio Roth [EMAIL PROTECTED] said: Hi, I´ve found this panel and it seem to be very cool. What do you think ? http://www.avsim.com/pages/1000/dreamfleet/dffull.jpg Yes, I saw that one not too long ago. Very nice vinyl texture. And the metal panel area itself is pretty darn near perfect, lots of nice touches including just exactly the right shine. It looks like it'd be an expensive one performance wise. Yeah that sure is a cool panel. It's not a c172r, but given enough effort something like that could be done. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Model Configuration Changes
David Megginson [EMAIL PROTECTED] said: Instead, if the /sim/model/path property points to a file ending with .xml, the FGAircraftModel class reads a property file at that location to get information about the 3D model. Initially, the following properties are recognized: /path The path to the model, relative to the XML file (not FG_ROOT). /offsets/heading-deg The heading rotation for the model, in degrees. /offsets/pitch-degThe pitch rotation for the model, in degrees. /offsets/roll-deg The roll rotation for the model, in degrees. /offsets/x-m The x-axis transformation, in meters. /offsets/y-m The y-axis transformation, in meters. /offsets/z-m The z-axis transformation, in meters. Great improvement! One thing I noticed as soon as the c172 model went in was that the offsets affected every model that didn't have offsets defined in the aircraft-set.xml file, simply because they were included in the c172-set.xml file that always gets processed by default, even if another aircraft is selected. Does this address that issue? If I switch to a different model in my command line will the offsets for the default model go away? Another question that came to mind (and I apologize in advance if it's a stupid one!): Is it possible to eliminate the requirement of offset values with models built for the base package distribution...ie can we convert all the vertices in the *.ac files so that it isn't necessary to use them? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
Jim Wilson wrote: Yes agreed. And probably with a 747-400 it is only those longer flights like London-Vancouver that get filled to the brim with fuel. Andy, is the aircraft otherwise considered filled to capacity (passenger/cargo) in the fdm? Um... I'm not sure. :) The configured empty weight is 400k lbs, but I didn't record where I got that number. I'd assume that this is really the empty weight, not including payload. YASim has a weight tag that can be used to provide software control over payload via the properties system, which would obviously be the right way to do this. I guess I'll assume that I did the right thing... The issue of flat-rating the engines has been nagging me, too. I strongly suspect this is at least part of the effect; does anyone have numbers that would support this? Implementing this would be really easy; analagous to the way the turbocharger waste gate gets handled in the piston engine model. It would also be a spiffy way of handling the supersonic over-speed behavior the engine model has at high speeds (the mach compression of the intake air is modelled, but the losses due to intake geometry are not). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen wrote: Actually it is fairly easy to make the property manager Thread Safetm. All regular r/w locking can happen on a per-node basis, and can be encapsulated transparently. The property manager seems like an ideal candidate for IPC messaging, so if we want, it can be done. This is the Great Myth of multithreading. Threadsafe components are not sufficient to protect against threadsafety violations. The only way to avoid deadlocks and race conditions is for the whole architecture to support them from top to bottom. Making the property manager threadsafe isn't the issue; sure it can be done. The problem is that *using* the property manager (or anything) from multiple threads leaves you open to race conditions that occur due to unsynchronized changes to the property values. For those with Java experience, consider the Vector class. It's threadsafe, right? Right. Now enumerate over it in one thread while modifying it in another. Is *that* threadsafe? :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
On Mon, 25 Feb 2002 08:33:03 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Andy Ross writes: The effect is happening because the aircraft isn't consuming fuel. If you take off at full tanks, you never get any lighter. A real aircraft would have burned off a big chunk of its fuel store in the climb, and would have an easier time of it. As a workaround, try starting /sim/fuelfraction at 0.5 or so, to simulate an early-to-mid-flight cruise condition. It should climb much better. Fuel consumption in YASim will get done RSN, I promise. That's a good point. I remember reading an article where the author sat in an A340 cockpit on a London-Vancouver flight; it wasn't until around Greenland that the plane had burned enough fuel that it could climb to full cruising altitude. ..another point you guys may be aware of, is that some jets (military only?) tank _cold_ (40-50 Centigrades below zero) fuel, this allows burning off fuel as it expands on heating up to tank temperature, so these jets arrive at mission target altitude with still full tanks. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C 172 panel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 26 Feb 2002 05:57, you wrote: Hi, I´ve found this panel and it seem to be very cool. What do you think ? http://www.avsim.com/pages/1000/dreamfleet/dffull.jpg Now that's what we need, but with the yoke removed so all the switches below are accessable. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8eqt5F2H7v0XOYBIRAv/fAKC3yDbns7aHdpdkZgFRWnBgm8c0lACgwMUC kpNx1Bzpb3RVYbCoCXuWhRo= =faTe -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] KFLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.kflog.org/ Check out that for a flight logging program. If only it had flight planning features Anyone know if we could hook it up to FlightGear? Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8erDRF2H7v0XOYBIRAo4ZAJ0dIkGTfoBdDw4x1zSZAWbD4XzDEgCfdhhc OnxY1v8MYWKNFdKtHhS6NyI= =7gqx -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KFLog
David Findlay writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.kflog.org/ Check out that for a flight logging program. If only it had flight planning features Anyone know if we could hook it up to FlightGear? Thanks, Interesting, someone should download this and report back. :-) FlightGear can output nmea strings so it seems like there shouldn't be too much work needed to get the two packages talking to each other. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Base Package Check Failed......????
Hi Help Base package check failed.. Found version [none] Please upgrade to version 0.7.9 The above is what happens when I try to run ./fgfs (from the terminal). I am using Mandrake 8.0. Installed SimGear-0.0.17 (tar version) Installed FlightGear-0.7.9 @ --prefix=/usr/local/FlightGear (tar version) Un-Tarred fgfs-base-0.7.9 @ usr/local/FlightGear. It looks like it's there to me. Version file claims to be 0.7.9. Out of desperation I un-tarred the base package into the below directories: usr/local/lib/FlightGear usr/lib/FlightGear All installations seemed to install happally. I also did a few re-builds, removed config.cache and did the distclean thingy, but same problem. Thanks Jeff Davis P.S. Did not have fg0.7.8 installed on this hard drive, new install, but did try to install a RPM package for fg0.7.9 but the SimGear RPM was not right so I am giving the tar versions a try. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Andy Ross wrote: Curtis L. Olson wrote: Threading is *really* scarey in a program of this magnitude. I'd be adverse to adding additional threading especially if it involves something like the property manager. There might be specific isolated instances where we can do it reliably, but there is way too much that can bite us if we try to do much threading. Amen. The only purpose to doing threading in a C/C++ environment is SMP scalability (in Java, you have to use them for I/O multiplexing too; I consider this a bug, but at least there you have language Well, the main reason for using multi-threading in a single CPU environment is to use the CPU cycles when a program (or thread) is in an IO lock ... BTW. There are thread schedulers which work in a single address space, pth is one example: http://www.gnu.org/software/pth/ This would remove the need for locking (expept for OpenGL I gueass). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Erik Hofman wrote: This would remove the need for locking (expept for OpenGL I gueass). guess, guess, guess. (I'm improving). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: animating 3D models
I've just added the first, small support for animating 3D models. The spinning propeller for the C172 had been hard-coded into the C++, but now, it's defined in a property file; the propellers on the DC-3 also spin. The only type of animation supported right now is spin tied to an rpm property, but I'll be adding rotations, shifts, etc. soon so that we can move control surfaces and even retract gear. I'm interested in suggestions for blinking lights. I'm surprised that this is much easier than I had thought. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 25, 2002 at 12:55:07PM -0800, Andy Ross wrote: Martin van Beilen wrote: Actually it is fairly easy to make the property manager Thread Safetm. All regular r/w locking can happen on a per-node basis, and can be encapsulated transparently. Making the property manager threadsafe isn't the issue; sure it can be done. The problem is that *using* the property manager (or anything) from multiple threads leaves you open to race conditions that occur due to unsynchronized changes to the property values. Hmmm.. I think we have different definitions of threadsafe. For those with Java experience, consider the Vector class. It's threadsafe, right? No, it's not. Imagine what happens when one thread is reading it while another thread is writing to it. :-) Right. Now enumerate over it in one thread while modifying it in another. Is *that* threadsafe? :) Now what did I just say? Pay attention please. ;-) A solution is to subclass a MutexVector that provides transparent locking on member access. Since there is only one mutex involved, deadlocks cannot occur. It is now Thread Safetm for all r/w operations. Of course, this breaks when deleting the vector. Which is what my earlier post was about. Not that it matters, since we're not doing multithreading on properties in the first place. :-) - -- Regards, I RADIS, do you? =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Mon, Feb 25, 2002 at 12:55:07PM -0800 X-S-Issue: [EMAIL PROTECTED] 2002/02/26 00:24:34 0800dc9a27bf18f991a6c1eb2a5bc123 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx6x7kACgkQN880WP6HRIsKIgCdFja4q0wUowN2D5WS4YaaLTp4 7roAoJeRQTRvEmPu//KaNi+MSR54IGm7 =6/c6 -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen wrote: Andy Ross wrote: For those with Java experience, consider the Vector class. It's threadsafe, right? No, it's not. Imagine what happens when one thread is reading it while another thread is writing to it. :-) Right. Now enumerate over it in one thread while modifying it in another. Is *that* threadsafe? :) Now what did I just say? Pay attention please. ;-) You missed my point. First, the Vector class *is* threadsafe; check all the methods, they're synchronized. There is no way, in Java, to corrupt the state of a Vector object by modifying it in multiple threads. Each thread is guaranteed to see a consistent object; there is no way to add two elements at the same index, for example, or to remove an item more than once. The library designers got this part right. Your suggestion about how to add threadsafety to the property system would achieve the same level of functionality. My point was that this buys you *nothing*. You can still write all the race conditions you want by assuming that the object won't be modified from another thread. See my post about the nuclear bomb safety lock; even a perfectly threadsafe property system is susceptible to race conditions. The point, again: *all* multithreaded code is susceptible to race conditions and deadlocks. There is *no* way around this. The only way to avoid them is to be very, very careful with your design. You cannot rely on libraries to save you. You cannot rely on simple techniques to save you. You have only your mind, your experience, and the minds and experience of the yahoo threading cowboys working on the rest of the project to rely on. Now, are you getting the point? :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
On Mon, 25 Feb 2002 16:17:29 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Arnt Karlsen writes: ..another point you guys may be aware of, is that some jets (military only?) tank _cold_ (40-50 Centigrades below zero) fuel, this allows burning off fuel as it expands on heating up to tank temperature, so these jets arrive at mission target altitude with still full tanks. You wouldn't want to do that with civil jets -- imagine a 747's wing tanks exploding because it got stuck in an hour-long line for takeoff and the fuel heated up too soon. ..well, I'm only 99% sure about military only. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Landing gear vibrations: some questions
..on Sat, 23 Feb 2002 15:42:11 +0100, Lorenzo Scaldaferro [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED] in newsgroup: rec.aviation.simulators: ..first, I need to apologize for showing bad form in responding by separate emails too, and for posting this onto the www.flightgear.org developers mailing list. See below for justification: Hello, i'm an italian mechanical engineer student and i'm writing a thesis about landing gear vibration problems. I'm gonna finish it but i still have some doubts and i hope you can help me to clarify. 1. I know how shimmy dampers work but i don't know if they are always used on planes or if they are not, and i'd like to understand what makes deciding that use, after simulations, or always with planes with a certain weight or operational speed. 2. I found a publication about landing gear dynamics called: Landing gear integration in aircraft conceptual design, by Sonny T. Chai and William H. Mason, it's described how to proceed to design gear and choose wheels, dampers, etc. but nothing is written about considering vibrations during design, so i'd like to know why. 3. I saw there is an intense use of F.E.A. for shimmy, brakes vibrations and gear vibrations in general, but i also think i understood that the problem is not fully understand. So what kind of future considerations can we do? Are modern airplanes problem free? What are the new technologies to resolve the problem? Because from what i found the way to proceed is use Moreland and Pacejka theories, made simulations and FEA, test the gear (just in two words) but from what i understand is in use that you can really discover if the plane has shimmy or so and sometimes we prefer to maintain a light shimmy if we discover it after production and there's not an easy way to resolve. I know my questions could result stupid but every discussion, document, link or else would be very appreciate. ..if you, Lorenzo, understand, as I believe, what you have read, you may be able to provide a valuable set of eyes and opinions on the below. Thanks a lot, Lorenzo ..FlightGear 3 different flight dynamics models all share a landing gear problem, if you care to DL the FlightGear source code, you may be able to add another set of engineering eyes. Warning, DL is some 27 MB. ..FlightGear runs on linux, unix, MacOS, and the Microsoft wintendo os'es. It is networking capable, on limited hardware, you can farm out flight dynamics number crunching to another box on your lan, or, you may have a multi pilot environment, and fly several planes. There is also a glass cockpit project, and a moving map project going on, these can plug into Flightgear over a lan, internet, or a cluster of boxes. (No games yet, only the wee beginnings of bomb drop code, games can of course be written on this code base. ;-) ) ..open source code such as Linux, FlightGear and some Unix'es, is _potentially_ FAA Certifiable, just like AN bolts, because anyone, such as any FAA inspector, may legally inspect and reverse-engineer the code, in_excactly_ the same way they torture AN hardware thru failure. ..closed source software licenses, such as Microsoft's, usually makes reverse engineering such as FAA type inspections, a criminal offence, this consequently makes such software un-certifiable for aviation use, where-ever airworthiness is a requirement. ..(and, no, I'm not going to waste anyones time on an os flame war. ;-) ) ..now, FlightGear is still _far_ from airworthy. ;-) But it _is_ moving in a direction that I like a _lot_. :-) [arnt@lana FlightGear]$ ls -GAFl /usr/local/lib/FlightGear/Aircraft total 104 -r--r--r--1 1000 590 Feb 8 13:22 747-uiuc-set.xml -r--r--r--1 1000 1587 Feb 9 04:25 747-yasim-set.xml -r--r--r--1 1000 897 Dec 24 13:44 a4-yasim-set.xml -r--r--r--1 1000 692 Feb 8 13:22 beech99-uiuc-set.xml drwxr-sr-x3 1000 4096 Feb 16 19:05 c172/ -r--r--r--1 1000 1523 Feb 9 04:25 c172-ifr-set.xml -r--r--r--1 1000 1703 Feb 9 04:25 c172-larcsim-set.xml -r--r--r--1 1000 1815 Feb 13 21:03 c172-set.xml -r--r--r--1 1000 670 Feb 8 13:22 c172-uiuc-set.xml -r--r--r--1 1000 1599 Feb 9 04:25 c172-yasim-set.xml drwxr-sr-x3 1000 4096 Feb 16 19:05 c182/ -r--r--r--1 1000 2433 Feb 13 21:03 c182-set.xml drwxr-sr-x2 1000 4096 Feb 16 19:05 c310/ -r--r--r--1 1000 2482 Feb 13 21:03 c310-set.xml -r--r--r--1 1000 702 Feb 8 13:22 c310-uiuc-set.xml -r--r--r--1 1000 978 Dec 24 13:44 c310-yasim-set.xml drwxr-sr-x3 1000 4096 Feb 16 19:05 dc3/ -r--r--r--1 1000
Re: [Flightgear-devel] KFLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 26 Feb 2002 08:26, you wrote: David Findlay writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.kflog.org/ Check out that for a flight logging program. If only it had flight planning features Anyone know if we could hook it up to FlightGear? Thanks, Interesting, someone should download this and report back. :-) FlightGear can output nmea strings so it seems like there shouldn't be too much work needed to get the two packages talking to each other. I've downloaded it, so I'll have a bit of a play with it now. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8eum9F2H7v0XOYBIRAmXKAJ0fyK+c93VD635B7BJ5ucsbi6zfiACgtb+x Lp8R+fsTGbpR8xclvkPhsNc= =niEV -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC
Its possible that it might be necessary to write an FGFlightPlan module as well - can someone tell me whether real life ATC actually knows whats in a flightplan after its been filed or is it simply a case of the pilot just requests what's on his/her flightplan? ..this depends on regulations, ..flight plans may be files on forms, some time ahead of departure, someplaces, and sometimes, filing over radio after takeoff is acceptable. It also varies by country. The rules are only (mostly) standardized for ICAO international IFR flight plans. All other kinds differ everywhere. Depending on the situation, sometimes ATC does know your flightplan and sometimes they don't. It's basically as simple as that (for FGFS). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Broken Code
Hi, On Jan 19 the FGEngInterface and FGGearInterface were removed from the flight.hxx source. It broke a lot of code in the opengc interface as well as internal logic to modulate the display symbols. I have made requests to this group for help in fixing what was broken by this change. I don't mind fixing things even if I didn't break them, (I've managed to get some of it working again with help from Curtis ) but I DO MIND spending my time searching for something that may or may not exist when a simple yes, no, or look here would help especially when queries go unanswered. Seems common courtesy would dictate for that person to at least acknowledge the post and respond to the request. And the proper thing to do is either provide a fix or guidance on how to restore the functionality lost in the change. It's not a big deal and world peace doesn't hang in the balance, but it is frustrating and there are a few who want to use the displays and we owe it to them to keep the projects in sync and running. JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] (Newbee) Problems compiling MetaKit
I am attempting to compile (version 2.4.2-32) MetaKit, which is included in (version 0.0.17) Simgear. (I am utilizing cygwin to create binaries on a PC.) The ../unix/configure command appears to work fine. However, the make command creates the following error message: g++ -c -O2 -I../unix/../include -I/usr/include ../unix/../tcl/mk4tcl.cpp -DDLL_ EXPORT -DPIC In file included from ../unix/../tcl/mk4tcl.cpp:22: ../unix/../tcl/stubtcl.h:3: syntax error before `*' ../unix/../tcl/stubtcl.h:4: syntax error before `*' ../unix/../tcl/stubtcl.h: In function `int MyInitStubs(Tcl_Interp *)': ../unix/../tcl/stubtcl.h:15: syntax error before `*' ../unix/../tcl/stubtcl.h:20: `struct MyInitStubs(Tcl_Interp *)::HeadOfInterp' ha s no member named `stubTable' ../unix/../tcl/stubtcl.h:20: `struct MyInitStubs(Tcl_Interp *)::HeadOfInterp' ha s no member named `stubTable' ../unix/../tcl/stubtcl.h:20: `TCL_STUB_MAGIC' undeclared (first use this functio n) ../unix/../tcl/stubtcl.h:20: (Each undeclared identifier is reported only once ../unix/../tcl/stubtcl.h:20: for each function it appears in.) ../unix/../tcl/stubtcl.h:26: `tclStubsPtr' undeclared (first use this function) ../unix/../tcl/stubtcl.h:26: `struct MyInitStubs(Tcl_Interp *)::HeadOfInterp' ha s no member named `stubTable' ../unix/../tcl/stubtcl.h:34: `tclPlatStubsPtr' undeclared (first use this functi on) ../unix/../tcl/mk4tcl.cpp: In function `struct Tcl_Obj * GetAsObj(const c4_RowRe f , const c4_Property , Tcl_Obj * = 0)': ../unix/../tcl/mk4tcl.cpp:347: implicit declaration of function `int Tcl_SetByte ArrayObj(...)' ../unix/../tcl/mk4tcl.cpp: In function `int SetAsObj(Tcl_Interp *, const c4_RowR ef , const c4_Property , Tcl_Obj *)': ../unix/../tcl/mk4tcl.cpp:401: implicit declaration of function `int Tcl_GetByte ArrayFromObj(...)' ../unix/../tcl/mk4tcl.cpp:401: initialization to `const t4_byte *' from `int' la cks a cast ../unix/../tcl/mk4tcl.cpp: In method `bool TclSelector::MatchOneString(int, cons t char *, const c4_String )': ../unix/../tcl/mk4tcl.cpp:1261: implicit declaration of function `int Tcl_String CaseMatch(...)' ../unix/../tcl/mk4tcl.cpp:1261: warning: cannot pass objects of type `const c4_S tring' through `...' ../unix/../tcl/mk4tcl.cpp: In method `void TclSelector::ExactKeyProps(const c4_R owRef )': ../unix/../tcl/mk4tcl.cpp:1324: conversion to `char *' from `const char *' disca rds qualifiers make: *** [mk4tcl.o] Error 1 Hoyt A. Fleming@HOYT'S_DESKTOP /usr/local/source/simgear/metakit/builds $ Does anyone know what I need to do to avoid the TCL errors? Thank you in advance (from a FlightGear newbee) for your help. Hoyt Fleming attachment: winmail.dat
