Re: [Flightgear-devel] system.fgfsrc
On Monday 10 December 2001 1:19 am, you wrote: I use to be able to startup with the just the HUD showing --prop:/sim/panel/visibility=false --prop:/sim/hud/visibility=true Now both the HUD and the Panel are displayed ? It probably has something to do with a change Curt made at my request to allow the aircraft file to be specified in preferences.xml. For now edit the relevant aircraft file in Aircraft. What's the trick to start with the engines running ?? --prop:/engines/engine0/magnetos/switch-position=3 --prop:/engines/engine0/running=true Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Peeking into the commercial scene
Cameron wrote: I know reporting anything related to MSFS around here will get mixed reviews, but I like seeing what other people are doing if for no other reason that to give me ideas. :-) Anyway...AVSim.com has a pretty thorough review[1] of MS FS2002 up. There are many screenshots of their 3D cockpits which may be useful for helping some of you modellers. Check it out if you like. [1] http://www.avsim.com/pages/1201/fs2002_part1/fs2002_part1.html Anyone with a Windows box would do better to download the Battle of Britain demo (and source code) if the main interest is in the virtual cockpit simulation. The FS202 virtual 3D cockpit looks strangely flat (!) by comparison. BoB source is at: http://www.combatsim.com/pages/Downloads/Source_Code/ Presumably the demo is on the same site somewhere. (The quality of the BoB source code has already been discussed here or in fightgear-model - check the archives). Mally ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Unable to select '--fdm=larcsim'
On Mon, 2001-12-10 at 00:40, Curtis L. Olson wrote: Ross Golder writes: It just produces exactly the same output as it does without this switch (including JSBSim output). As I am pinned to the ground with latest JSBSim (flightgear CVS fresh today), I wanted to revert to LarcSIM to get some airtime in, but I can't. Any suggestions? Ross, Hmmm, we might need to think a bit more about option parsing, but what does --aircraft=c172-larcsim do for you? It gives me an error about SimGear not being able to find a file, but the pathname is quite long so it scrolls off the right of the screen, so I presume it meant's the c172-larcsim.xml file. However, despite the lack of a panel, I can 'Ctrl-U' it up a couple of grand and glide around for a bit quite happily (as a hang-glider pilot, sometimes I can't be bothered with engines and props ! :) ) I can't currently do this with JSBSim, which rather that going up 1000ft, seems to bump the craft to the right a few feet. I'll try copying in latest JSBSim CVS stuff and trying again. Also, if option parsing has changed, shouldn't this have been reflected in 'fgfs --help' in parallel. Sometimes, I need to use '--help', my memory being what it is! -- Ross ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Unable to select '--fdm=larcsim'
Ross Golder wrote: lack of a panel, I can 'Ctrl-U' it up a couple of grand and glide around for a bit quite happily (as a hang-glider pilot, sometimes I can't be bothered with engines and props ! :) ) I can't currently do this with JSBSim, which rather that going up 1000ft, seems to bump the craft to the right a few feet. I'll try copying in latest JSBSim CVS stuff and trying again. This won't work at the moment. I _think_ it has something to do with the trim code. When trying to jump up using the property manager it has the same result (sometimes I even get smashed back on the ground then). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Unable to select '--fdm=larcsim'
Ross wrote: (as a hang-glider pilot, sometimes I can't be bothered with engines and props ! :) Hehehe :-). Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim 0.1.3 Review
Here's a quick review of YASim -- I've been following the first few releases, and 0.1.3 (not yet in FlightGear CVS) is the first that seems stable enough to use. I tried the YASim C172, since that's the plane we've had for the longest in FlightGear, in both JSBSim and LaRCsim versions. The YASim C172 flies fairly well. Take-off works, and p-factor is about the same as in the FLY! C172 -- i.e. you need a lot of right rudder to keep the nose straight during a power climb. Levelling off at 3000' ASL, however, I had trouble establishing a cruise above 100kt at about 85% throttle -- I'd expect 110kt - 125kt, depending on the engine. Where YASim differed most was the stall. I cut the throttle at 3000' then held altitude with the elevators while the plane bled speed. Stall was *very* different than in any of the other simulated C172's I've tried (LaRCsim, JSBSim, FLY!, and MSFS) -- instead of the nose falling until I picked up speed again, the left wing suddenly dropped out from under me and the ground started spinning towards me at an alarming rate. I didn't recover until 1000' ASL (about 600'AGL), which was a little too close for comfort. Is that right for a C172 with neutral rudder and aileron? It was quite dramatic, in any case. Given that YASim models airflow over surfaces, I expected a more fluid feel to the controls (i.e. more like a boat than a car), but it felt much the same as the JSBSim C172 -- the plane responds instantaneously to all control inputs, as if it had virtual tires firmly in the air. I'd like to hear from the pilots on the list about how real C172s feel in the air -- is there a tiny, fraction-of-a-second lag between control input and response and air pressure builds up on the control surfaces? YASim's gear code, like JSBSim's, has trouble handing wind while on the ground. While sitting on the ground with a 20kt crosswind and full brakes, YASim will still weathervane into the wind, while JSBSim will bounce around with the nose hitting the runway. I didn't land the C172 during this review, so I do not know whether YASim supports ground effect yet. The greatest weakness in YASim right now is the powerplant. Unlike JSBSim, LaRCsim, and FLY!, YASim does not allow you to start the engine, does not allow you to lean it in flight to get extra power (leaning just cuts the RPM proportionally to the mixture), and doesn't give a useful EGT or fuel-flow display. That shouldn't be taken as a major criticism -- YASim's lifespan in FlightGear is still measurable in days, and it's astounding how fast it has caught up with the other FDM's in many areas. Adding better powerplant support won't be hard, and hopefully, others will volunteer to help Andy with it. 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] Unable to select '--fdm=larcsim'
That works (since I updated fgfsbase this morning). -- Ross On Mon, 2001-12-10 at 00:40, Curtis L. Olson wrote: Ross Golder writes: It just produces exactly the same output as it does without this switch (including JSBSim output). As I am pinned to the ground with latest JSBSim (flightgear CVS fresh today), I wanted to revert to LarcSIM to get some airtime in, but I can't. Any suggestions? Ross, Hmmm, we might need to think a bit more about option parsing, but what does --aircraft=c172-larcsim do for you? Curt. -- Curtis Olson Intelligent Vehicles Lab 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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim 0.1.3 Review
Andy Ross wrote: What would be best, of course, is finding a POH that lists exact power settings at some reasonable cruise. I didn't do this (does anyone have an online source for POH performance numbers?), and instead copied a bunch of numbers in from different sources. So, in fact, you get about 110 KIAS with full throttle at 3000 feet. Google works great: http://greencastle-aeroclub.com/cessna_172_poh.htm and maybe http://www.aopa.org/asf/publications/cessna_skyhawk.pdf Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] base package access with rsync?
Erik Hofman writes: I have some problems with the local copy of the base package and it seems i have to remove the directory completely and recheck the base package again to get ir right. Specifically, what kind of error messages are you seeing? I'm able to use it just fine. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Unable to select '--fdm=larcsim'
Norman Vine wrote: G.. One of those variables that only lives in the 'ether world' A VERY GOOD REASON for these things to live in a real 'C' variable .. I think you misunderstood. It *does* live in a real C variable (FGInterface::Tank1Fuel). That variable never got initialized, and isn't set by the FDMs, so it contains garbage. In this case, the pure property manager was bypassed by tying the value to an actual memory location. That's the bug -- had this been an actual property, the value would have been zero. The core points here are: 1. Not every FDM or every aircraft model will set all properties. 2. There is no way for clients of the information to know, a priori, whether or not a value is valid or not (starting up a generic jet panel on the 172, etc...). 3. Reading information that the FDM hasn't set shouldn't cause a crash. That's very hard to guarantee in C space, as this bug evidences. With a soft-coded property system, you get it for free. There's also a tangential advantage, which is that it makes evolution of the interface much easier. If I decide that I *really* want to export, say, /yasim/consumables/gun[0]/rounds, I can Just Do It. No need to coordinate an update with Jon, Tony and David. I just set the property, and get someone to write panel code to display an ammunition counter. Running that against the JSB X-15 will just show zero instead of blowing up or failing to compile. Now, at some point we'll want to canonize this property and move it out of the /yasim tree and into the core. But now, that can happen _after_ the development has been done, instead of having to be designed-in beforehand. 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] RFC: FGInterface radical surgery
I think the problem with that though is what about the stand alone version. I also have visions of a standalone version communicating to flightgear via network sockets. The nice thing about that is you can have stable version 1.0 that is known to work and you can have development version 1.1 with all sorts of goofy not-fleshed-out stuff and flip between them ... perhaps even without stoping the main display process ... just kill one and restart the other and no need to restart the graphics part. I do like having a layer of glue between FlightGear and the FDM ... really you will still need this layer, you are just shuffling it around. Regards, Curt. Tony Peden writes: Jon will go ballistic on this ... but I think it makes good sense to have JSBSim publish directly to properties, that way the FDM-FGInterface copy can be skipped. On Mon, 2001-12-10 at 15:36, David Megginson wrote: I'd like to rip out most of the FGInterface (src/FDM/flight.hxx) methods and strip it down to the bare essentials: basically just the init/bind/unbind/update methods. There's a lot of kruft in there that nobody uses, and it's far too brittle for our fast-growning flight models: note that JSBSim.cxx already bypasses it for recent changes (going directly to the property manager) and YASim was designed to use the property manager from the ground up; no one is bothering to extend FGInterface for the new features that are appearing. The adapters for the various FDMs currently work like this: 1. Copy state from FGInterface into the internal FDM model. 2. Cruch a bunch of numbers. 3. Copy state from the internal FDM model back to FGInterface. That means that there's no performance advantage to holding the values in FGInterface -- they have to be copied anyway. The new approach would be 1. Copy state from the property manager into the internal FDM model. 2. Cruch a bunch of numbers. 3. Copy state from the internal FDM model back to FGInterface. The difference is that the FDMs would have much more freedom in choosing what state information to copy in and out: an F16 model might want to publish the state of its leading-edge slats, for example, and a water bomber might want to let us know how much is left in its water tank. I'll have to do this incrementally because there's so much there, but I think it will be a big win for FlightGear -- dead code means bugs (like uninitialized variables), and it's also a barrier-to-entry for new coders trying to learn their way around. Comments? I'll record Norm's vigorous objections in advance. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson Intelligent Vehicles Lab 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] RFC: FGInterface radical surgery
David, I think I will support this proposal under a couple of conditions. 1) We need to be able to have multiple instances of various FDM's running concurrenty (and with your proposed changes, accessible through the property manager interface.) I'm thinking of things like random 'traffic' that would get created and deleted. For instance we have fdm[0], fdm[1], fdm[2], fdm[3] and then we delete fdm[1] because it flew out of range, but now another aircraft flies into view so we need to create fdm[4], etc. Also probably sooner rather than later, John is going to want to be able to air drop his X-15 from our Cessna 310. :-) 2) As you know, accessing property manager values via static propertynode pointers is more efficient because you only have to do the expensive string name hash lookup once the first time the routine runs. It would be nice to have a set of static property node accessors set up that any code could use, rather than having each routine duplicate the static propertynode element it needs. Perhaps it would make sense to put all these static accessors into FGInterface and creat accessor functions for them? stepping back out of swinging distance :-) 3) And we'll need three very large folks to sit on Norman and hold him down while we do this. :-) :-) :-) 4) Norman sent me a raft of changes for Mingwin that might conflict or at least make different changes in some of the same areas as you are looking at. I didn't get a chance to work my way through them all today, but I should probably do that and apply as much of that as makes sense in light of your proposal, while trying to avoid the changes that might potentially conflict. Curt. David Megginson writes: I'd like to rip out most of the FGInterface (src/FDM/flight.hxx) methods and strip it down to the bare essentials: basically just the init/bind/unbind/update methods. There's a lot of kruft in there that nobody uses, and it's far too brittle for our fast-growning flight models: note that JSBSim.cxx already bypasses it for recent changes (going directly to the property manager) and YASim was designed to use the property manager from the ground up; no one is bothering to extend FGInterface for the new features that are appearing. The adapters for the various FDMs currently work like this: 1. Copy state from FGInterface into the internal FDM model. 2. Cruch a bunch of numbers. 3. Copy state from the internal FDM model back to FGInterface. That means that there's no performance advantage to holding the values in FGInterface -- they have to be copied anyway. The new approach would be 1. Copy state from the property manager into the internal FDM model. 2. Cruch a bunch of numbers. 3. Copy state from the internal FDM model back to FGInterface. The difference is that the FDMs would have much more freedom in choosing what state information to copy in and out: an F16 model might want to publish the state of its leading-edge slats, for example, and a water bomber might want to let us know how much is left in its water tank. I'll have to do this incrementally because there's so much there, but I think it will be a big win for FlightGear -- dead code means bugs (like uninitialized variables), and it's also a barrier-to-entry for new coders trying to learn their way around. Comments? I'll record Norm's vigorous objections in advance. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson Intelligent Vehicles Lab 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] Unable to select '--fdm=larcsim'
Andy Ross writes: Norman Vine wrote: G.. One of those variables that only lives in the 'ether world' A VERY GOOD REASON for these things to live in a real 'C' variable .. I think you misunderstood. It *does* live in a real C variable (FGInterface::Tank1Fuel). Ackk.. you are right I only grepped the 'C source The core points here are: 1. Not every FDM or every aircraft model will set all properties. Easy enough to just set everything to 0 or its equivalent in the class constructor ! 2. There is no way for clients of the information to know, a priori, whether or not a value is valid or not (starting up a generic jet panel on the 172, etc...). 3. Reading information that the FDM hasn't set shouldn't cause a crash. Agreed, but... Programming under Linux is much more forgiving then some other enviroments and I realize it is hard for those who only develop for it. That's very hard to guarantee in C space, as this bug evidences. With a soft-coded property system, you get it for free. No the problem is that everyone is trying to make a scripting language out of XML, something that it wasn't really designed to do and so we end up we all of these global settors in 'C' filling up the property tree that don't match up 'name wise' with their 'C' variable name hence making these kind of ommisions invariable. Now if we had an automated tool to parse the C Classes and automatically create teh property tree that would be another story... There's also a tangential advantage, which is that it makes evolution of the interface much easier. As I often say I am all for high level language but ... Now, at some point we'll want to canonize this property and move it out of the /yasim tree and into the core. But now, that can happen _after_ the development has been done, instead of having to be designed-in beforehand. The way I see things developing this is leading to chaos. All global functors with anything able to call anything else with a bit of XML and no easy way to get at things from 'C There isn't even much similarity between the 'C Object tree and the 'property tree' .. UCK Anyway . I have a feeling there is 'code fork' coming FYI I have temporarily placed a MingW32 compiled version of todays CVS files at http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz This is completely unsupported but should just work on any Win32 platform as is with todays BASE CVS files 1.26 meg This has Andy's latest changes (YASim 1.3) and the Fuel Tanks are initialized empty so make sure you top her off before takeoff Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: FGInterface radical surgery
need to create fdm[4], etc. Also probably sooner rather than later, John is going to want to be able to air drop his X-15 from our Cessna 310. :-) Yes, there are some things in work that should *really* be nice that involve multiple instances of JSBSim. I am not against what David (or even what Tony proposed) if it for the most part leaves JSBSim operable under standalone mode. It sounds to me like David's approach is closer to that realm, but I am not sure. I've been heads down in the FDM so long I don't know nuthin' about properties. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: FGInterface radical surgery
Curtis L. Olson writes: 3) And we'll need three very large folks to sit on Norman and hold him down while we do this. :-) :-) :-) No reason to sit on me, As you know I have been resisting forking a different way of doing things for a long time and this will be the little shove that makes it happen. 4) Norman sent me a raft of changes for Mingwin that might conflict or at least make different changes in some of the same areas as you are looking at. Nothing I sent should really have any effect on how the properties are used The biggest change was moving the many cached nodes for the current FDM's latitude, longitude and altitude into the globals and propagating this. ie Now globals-get_latitude() globals-get_longitude() globals-get_altitude() is all that is needed to access these once glut takes over This will be just two pointer dereferences and should be faster then accessing the node though a static variable which is almost gauranteed to miss the 'processor cache' on some memory layouts. The globals data is still small enough to where there is a real good chance of it staying in the 'fast' memory Oh and I included a much cleaner slightly faster Point In Triangle( sgdVec3 point, sgdVec3 tri[3] ) for the hitlist intersection that I was working on for PLib, that someone might actually be able to understand :-) Other then that it was mostly more instrumentation for the #ifdef DEBUG 'printf style' of tracing program flow. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: FGInterface radical surgery
Curtis L. Olson writes: 2) As you know, accessing property manager values via static propertynode pointers is more efficient because you only have to do the expensive string name hash lookup once the first time the routine runs. It would be nice to have a set of static property node accessors set up that any code could use, rather than having each routine duplicate the static propertynode element it needs. Perhaps it would make sense to put all these static accessors into FGInterface and creat accessor functions for them? stepping back out of swinging distance :-) I thought of having protected convenience variables at the FGInterface level holding SGPropertyNodes for the information that every FDM absolutely *must* publish -- the three-member position, angular, velocity, and angular-velocity vectors. On the other hand, that introduces opacity; having *all* of the property nodes in the derived class mades the code easier to understand and maintain. 3) And we'll need three very large folks to sit on Norman and hold him down while we do this. :-) :-) :-) Send me a couple of good chocolate cake recipes -- I'm almost there. 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] RFC: FGInterface radical surgery
On Monday 10 December 2001 9:18 pm, you wrote: David, I think I will support this proposal under a couple of conditions. 1) We need to be able to have multiple instances of various FDM's running concurrenty (and with your proposed changes, accessible through the property manager interface.) I'm thinking of things like random 'traffic' that would get created and deleted. For instance we have fdm[0], fdm[1], fdm[2], fdm[3] and then we delete fdm[1] because it flew out of range, but now another aircraft flies into view so we need to create fdm[4], etc. Also probably sooner rather than later, John is going to want to be able to air drop his X-15 from our Cessna 310. :-) Or fly a 747 with a space shuttle strapped on top. :D ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Unable to select '--fdm=larcsim'
Norman Vine writes: Now, at some point we'll want to canonize this property and move it out of the /yasim tree and into the core. But now, that can happen _after_ the development has been done, instead of having to be designed-in beforehand. The way I see things developing this is leading to chaos. All global functors with anything able to call anything else with a bit of XML and no easy way to get at things from 'C I understand your concern, but judge the tree by its fruits -- the property tree is far from perfectly organized right now, but it has evolved much more order than most of the C++ interfaces, which are showing strong signs of entropy. 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] RFC: FGInterface radical surgery
Andy Ross writes:
This is true, but I think the expense of the string lookup step is
wildly overestimated. Compared to the cost of rendering a single
frame, it's noise. YASim doesn't even bother with the node stuff yet;
it does sprintf/fgSet for every property every frame, and I haven't
noticed any performance issues.
Clearly there are limitations, and for some things efficiency *does*
matter. But those are the exceptions, not the common case.
Right -- it comes down to programming common sense. This isn't going
to bite you:
double altitude = fgGetDouble(/position/altitude);
but this is
for (int i = 0; i bigNumber; i++) {
for (int j = 0; j otherBigNumber; j++) {
double altitude = fgGetDouble(/position/altitude);
// etc.
}
}
Nevertheless, the hashing will add up eventually, so the pre-looked-up
nodes are useful inside the main loop.
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] Unable to select '--fdm=larcsim'
Jim Wilson wrote: Andy Ross writes: 3. Reading information that the FDM hasn't set shouldn't cause a crash. Same with reverse?...seems like the problem with JSBsim and using threads has to do with shared memory, one thread reading before or while the other writes. Eeep, no. Not what I meant. :) I was talking high level: If component XXX isn't prepared to exporting feature YYY, the simulator should still work, and not crash. This can be done in both C++ and properties, but with properties you get it for free; no chance of human error. What you describe is called a race condition, and that's a bug. Always was, always will be. Sometimes it's an unavoidable (or very hard to avoid) bug, in which case you say Just Don't Do That and mark your code as non-threadable. Which brings up a really good point: is the property library threadsafe? I'm guessing not, which means we need to write up a spec for how to do mutex access, or else punt and say you can only use it from the main() thread. Probably not a big deal. 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] RFC: FGInterface radical surgery
I think the problem with that though is what about the stand alone version. I also have visions of a standalone version communicating to flightgear via network sockets. I do like having a layer of glue between FlightGear and the FDM ... really you will still need this layer, you are just shuffling it around. Not sure how I feel or if it even matters, Now that Opengc has an interface with FG via the network sockets using the class structure to express the spec for the interface and inheriting the FGInterface class is nice. I suppose the properties approach would work but I still wind up with a class for the UDP packet and I presume that would still require some mechnaism and a little more work to build it and gather up and pack the data. While this is an open source project, perhaps going a little slower from time to time is not all bad. And if it requires a little more coordination and thought all the better. Maybe a little glue is a better way to hold things together. seems the properties approach tends toward decentralized control. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] About last cvs changes
This is the cvs log message I want to refer to: --- Log Message: Small tweaks to initialization sequence and logic so we can default to a top level aircraft def file (c172-set.xml) preferences.xml or --aircraft= or any other property setting mechanism can be used to set the property /sim/aircraft. After all options and config files are parsed, the contents of /sim/aircraft is expanded into a *-set.xml file and loaded. I synced to the last CVS Flightgear source and base. Then I changed the value of the tag aircraft to c310, so to load for defect the cessna 310 instead of the 172. Then, run fgfs --fdm=jsb (my favourite flight model. I also noticed that the default flight model has setted back to larcsim) But, the change in the aircraft tag value doesn't take effect. The c172 is loaded instead. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] About last cvs changes
Martin Olveyra writes: This is the cvs log message I want to refer to: --- Log Message: Small tweaks to initialization sequence and logic so we can default to a top level aircraft def file (c172-set.xml) preferences.xml or --aircraft= or any other property setting mechanism can be used to set the property /sim/aircraft. After all options and config files are parsed, the contents of /sim/aircraft is expanded into a *-set.xml file and loaded. I synced to the last CVS Flightgear source and base. Then I changed the value of the tag aircraft to c310, so to load for defect the cessna 310 instead of the 172. Then, run fgfs --fdm=jsb (my favourite flight model. I also noticed that the default flight model has setted back to larcsim) But, the change in the aircraft tag value doesn't take effect. The c172 is loaded instead. We made a couple changes in quick succession (hopefully learning from our, well my mistakes, as I went along.) The /sim/aircraft property has been eliminated. preferences.xml include's the default aircraft (c172-set.xml). If you specify --aircraft=xyz, the corresponding config file is loaded and the properties it refers to are set immediately. So any subsequent command line options will override what came out of the aircraft config file. So for instance if you want to run the YASim c310 with no panel but the hud activated (the config file might specify the panel active, but no hud) you can run fgfs --aircraft=c310-yasim --disable-panel --enable-hud Sorry for the confusion on this, as I said, we were figuring it out as we went along. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] About last cvs changes
On 2001.12.11 02:17 Curtis L. Olson wrote: Martin Olveyra writes: This is the cvs log message I want to refer to: --- Log Message: Small tweaks to initialization sequence and logic so we can default to a top level aircraft def file (c172-set.xml) preferences.xml or --aircraft= or any other property setting mechanism can be used to set the property /sim/aircraft. After all options and config files are parsed, the contents of /sim/aircraft is expanded into a *-set.xml file and loaded. I synced to the last CVS Flightgear source and base. Then I changed the value of the tag aircraft to c310, so to load for defect the cessna 310 instead of the 172. Then, run fgfs --fdm=jsb (my favourite flight model. I also noticed that the default flight model has setted back to larcsim) But, the change in the aircraft tag value doesn't take effect. The c172 is loaded instead. We made a couple changes in quick succession (hopefully learning from our, well my mistakes, as I went along.) The /sim/aircraft property has been eliminated. preferences.xml include's the default aircraft (c172-set.xml). If you specify --aircraft=xyz, the corresponding config file is loaded and the properties it refers to are set immediately. So any subsequent command line options will override what came out of the aircraft config file. I understand know the origin of the problem. So, the /sim/aircraft property has been eliminated but the aircraft tag in the cvs version of preferences.xml is still there, with the value c172. Also, in the same file I see the tag sim include=Aircraft/c172-yasim-set.xml, and not c172-set.xml, as you say. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] About last cvs changes
On 2001.12.11 02:32 Curtis L. Olson wrote: Andy Ross writes: Martin Olveyra wrote: Then, run fgfs --fdm=jsb (my favourite flight model. I also noticed that the default flight model has setted back to larcsim) But, the change in the aircraft tag value doesn't take effect. The c172 is loaded instead. I just picked up this change, too. :) The fix is simple. In all the xxx-set.xml files in your Aircraft directory, remove the sim/sim tags that enclose the rest of the data. This placement is done automatically by the loader now. I assume these changes are already in the queue for the base package. I believe these changes were committed this morning. No, they don't. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] compass problem?
I dont know if it is a realistic effect, but, since some cvs versions ago, the compass is stalled most of the time, so it is impossible to know the real magnetic heading. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] About last cvs changes
On Tuesday 11 December 2001 12:06 am, you wrote: This is the cvs log message I want to refer to: --- Log Message: Small tweaks to initialization sequence and logic so we can default to a top level aircraft def file (c172-set.xml) preferences.xml or --aircraft= or any other property setting mechanism can be used to set the property /sim/aircraft. After all options and config files are parsed, the contents of /sim/aircraft is expanded into a *-set.xml file and loaded. I synced to the last CVS Flightgear source and base. Then I changed the value of the tag aircraft to c310, so to load for defect the cessna 310 instead of the 172. Then, run fgfs --fdm=jsb (my favourite flight model. I also noticed that the default flight model has setted back to larcsim) But, the change in the aircraft tag value doesn't take effect. The c172 is loaded instead. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Sync again, the aircrasft files were missing the sim tag ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] About last cvs changes
On Tuesday 11 December 2001 12:29 am, you wrote: Martin Olveyra wrote: Then, run fgfs --fdm=jsb (my favourite flight model. I also noticed that the default flight model has setted back to larcsim) But, the change in the aircraft tag value doesn't take effect. The c172 is loaded instead. I just picked up this change, too. :) The fix is simple. In all the xxx-set.xml files in your Aircraft directory, remove the sim/sim tags that enclose the rest of the data. This placement is done automatically by the loader now. but. but. I assume these changes are already in the queue for the base package. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] About last cvs changes
On 2001.12.11 03:05 Martin Olveyra wrote: On 2001.12.11 02:17 Curtis L. Olson wrote: Martin Olveyra writes: This is the cvs log message I want to refer to: --- Log Message: Small tweaks to initialization sequence and logic so we can default to a top level aircraft def file (c172-set.xml) preferences.xml or --aircraft= or any other property setting mechanism can be used to set the property /sim/aircraft. After all options and config files are parsed, the contents of /sim/aircraft is expanded into a *-set.xml file and loaded. I synced to the last CVS Flightgear source and base. Then I changed the value of the tag aircraft to c310, so to load for defect the cessna 310 instead of the 172. Then, run fgfs --fdm=jsb (my favourite flight model. I also noticed that the default flight model has setted back to larcsim) But, the change in the aircraft tag value doesn't take effect. The c172 is loaded instead. We made a couple changes in quick succession (hopefully learning from our, well my mistakes, as I went along.) The /sim/aircraft property has been eliminated. preferences.xml include's the default aircraft (c172-set.xml). If you specify --aircraft=xyz, the corresponding config file is loaded and the properties it refers to are set immediately. So any subsequent command line options will override what came out of the aircraft config file. I understand know the origin of the problem. So, the /sim/aircraft property has been eliminated but the aircraft tag in the cvs version of preferences.xml is still there, with the value c172. Also, in the same file I see the tag sim include=Aircraft/c172-yasim-set.xml, and not c172-set.xml, as you say. Also, it is really a good idea to delete the tag panel in preferences.xml, because the panel is setted via xxx-set.xml files (and preferences.xml has precedence) With all theese changes, I finally was able to run fgfs without command line parameters and start with the desired aircraft (and its right settings) by changing only the include tag in preferences.xml ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] About last cvs changes
On 2001.12.11 04:00 John Check wrote: On Tuesday 11 December 2001 12:06 am, you wrote: This is the cvs log message I want to refer to: --- Log Message: Small tweaks to initialization sequence and logic so we can default to a top level aircraft def file (c172-set.xml) preferences.xml or --aircraft= or any other property setting mechanism can be used to set the property /sim/aircraft. After all options and config files are parsed, the contents of /sim/aircraft is expanded into a *-set.xml file and loaded. I synced to the last CVS Flightgear source and base. Then I changed the value of the tag aircraft to c310, so to load for defect the cessna 310 instead of the 172. Then, run fgfs --fdm=jsb (my favourite flight model. I also noticed that the default flight model has setted back to larcsim) But, the change in the aircraft tag value doesn't take effect. The c172 is loaded instead. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Sync again, the aircrasft files were missing the sim tag Don't! The right way is without the sim!! What a day!! :-P ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] About last cvs changes
John Check wrote: Andy Ross wrote: I assume these changes are already in the queue for the base package. but. but. Sorry, my fault. I had a sticky date tag in my base package. No, I can't for the life of me remember why. Of all of CVS's quirks, this is the worst; doing a cvs update in a directory with non-branch tags REALLY should generate a warning that you're not doing what you thought you were doing. Maybe I should get off my butt and fix that... 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
