Re: [Flightgear-devel] poll (more complex than at first appears?)
On Friday 10 Jun 2005 22:41, Andy Ross wrote: theoreticle wrote: Let's say someone comes up with a model for the old Pan Am Clipper, that wants to land fully loaded with passengers and half loaded with fuel. The actual aircraft will sink it's fuselage as far as 5 feet into the water, perhaps more if landing in 'seas'. There absolutely must be some code to support sea planes landing in the water. The water interaction really isn't so difficult (it's just like landing gear compression, but with an extra term for drag due to water flow). The harder part is hacking the scenery subsystem to understand which polygons are water and propagate this information out through the groundcache to the FDMs. That will likely require touching a ton of code all over the simulator; it's always the data modelling issues that cause the problems. Algorithms are easy. Andy One problem with using YASim for sea planes is that the fuselage mustn't contact the surface as this equates to a crash. While I was experimenting with the SR45 I found that I had to omit the lower fuselage deck to achieve this, which must then affect the flying accuracy. I sort of got around it by using a non-retractable gear, which at least added some drag back. one of the last things I tried was to link the brakes of this gear to the gear compression so that the braking effect reduced or increased as the hull rose or sank into the water. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
Le samedi 11 juin 2005 10:20 +0100, Lee Elliott a crit : On Friday 10 Jun 2005 22:41, Andy Ross wrote: theoreticle wrote: Let's say someone comes up with a model for the old Pan Am Clipper, that wants to land fully loaded with passengers and half loaded with fuel. The actual aircraft will sink it's fuselage as far as 5 feet into the water, perhaps more if landing in 'seas'. There absolutely must be some code to support sea planes landing in the water. The water interaction really isn't so difficult (it's just like landing gear compression, but with an extra term for drag due to water flow). The harder part is hacking the scenery subsystem to understand which polygons are water and propagate this information out through the groundcache to the FDMs. That will likely require touching a ton of code all over the simulator; it's always the data modelling issues that cause the problems. Algorithms are easy. Andy One problem with using YASim for sea planes is that the fuselage mustn't contact the surface as this equates to a crash. While I was experimenting with the SR45 I found that I had to omit the lower fuselage deck to achieve this, which must then affect the flying accuracy. I sort of got around it by using a non-retractable gear, which at least added some drag back. one of the last things I tried was to link the brakes of this gear to the gear compression so that the braking effect reduced or increased as the hull rose or sank into the water. LeeE Oh you met exactly what i got when i tried (for the fun) to model an helicopter with floats (SeaStallion) . I could not use JSB (no rotor FDM) and with the use of Yasim it has been very difficult to find the right way which make that model to stand correctly on water with gear-up. To answer that, JSBSim gives a better flexibility. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
Dave Culp wrote: This is a poll. Does anyone really want the FDM to allow flying under the terrain, or was that a misunderstanding by me? No, this is not a misunderstanding. Probably your conclusion of we need to avoid such a situation is different from mine. I would not want to let aircraft fly below terrain surface but i would not want FG to automagically initiate a reset as well. A crash demonstration as Melchior did it for the BO-105 is probably the 'best' solution. Aside from that flying below a bridge or taxiing into a hangar is a desired feature. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] timer help
5. Re: timer help (Josh Babcock) are there any references to use time delay in functions. i am trying to delay speedbrake for 1.5 scnds everytime activated or deactivated in larcsim . i tried to use sleep() functions in msvc71 but makes the whole sim sleep:) i am looking for example time delays in fg source and would be happy if anyonepoints... You could easily do it in NASAL using settimer(). Josh i am totaly lost. i ve tried different declarations of delay functions but they starts infinite loops. i tihnk nasal expalined only for xml usage but i didnt find a source to declare settimer() in a source code . I need a reference... _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG-JSB Carrier Landing Patch
On Donnerstag 09 Juni 2005 15:29, Gerard ROBIN wrote: I have ( for my personal use ), rebuild a Patch which can be applied to the last release (today 12 GMT) of /FlightGear/source/src/FDM/JSBSim. If Jon, Mathias, JSB development team, FG development team agree with, and if anybody interested on I can deliver it. Feel free to do so. Thanks! Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] timer help
On Saturday 11 June 2005 13:44, eagle monart wrote:
i am totaly lost. i ve tried different declarations of delay functions but
they starts infinite loops. i tihnk nasal expalined only for xml usage
but i didnt find a source to declare settimer() in a source code . I need
a reference...
settimer(foo(...), time)
where foo(...) is the function to call and time is the delay in seconds. This
will call foo(...) in time seconds from when settimer() is called.
Here is a function that repeats, or calls itself every 5 seconds.
foo = func
{
# Do something really neat
settimer(foo(), 5.0);
}
This is of course an infinite loop. If you want to stop the loop you have to
check for some condition and simply not call the settimer function:
foo = func
{
# Do something really neat
if (stopTheLoop)
{
# Do nothing
}
else
{
settimer(foo(), 5.0);
}
}
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] timer help
On Saturday 11 June 2005 14:15, Roy Vegard Ovesen wrote:
settimer(foo(...), time)
where foo(...) is the function to call and time is the delay in seconds.
This will call foo(...) in time seconds from when settimer() is called.
Here is a function that repeats, or calls itself every 5 seconds.
foo = func
{
# Do something really neat
settimer(foo(), 5.0);
}
This is of course an infinite loop. If you want to stop the loop you have
to check for some condition and simply not call the settimer function:
foo = func
{
# Do something really neat
if (stopTheLoop)
{
# Do nothing
}
else
{
settimer(foo(), 5.0);
}
}
Whoops!
Replace foo(*) with foo wherever it appears above.
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] After crash , Restart ?
Ampere K. Hardraade wrote: On June 9, 2005 05:28 pm, Martin Spott wrote: I'm curious if it is possible to 'simply' define the whole model as a contact point and let the OpenGL subsystem detect terrain collision. This would require some return channel from the OpenGL system back to the application and I have no idea if this is achievable, If it is achievable, how will that work for aircrafts that use seperated models, such as the A380? No idea, I didn't know there are aircraft with 'separated' models. I thought all these models would consist of several objects that are logically grouped together into a single model, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New developer
Hi All! I would like to contribute to flightgear project... I'm interested in converting italian scenery from MSFS (I already know that it is not possible to distribute stuff that it isn't GPL compatible) and creating an MD-82 model for flightgear... 1) Does someone is already working on that? 2) I work on a WinXp sistem is it a problem? 3) I need a little help because I can't understand what is the documentation that I have to read in order to do the job... Thanks in advance, Andrea ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
Lee Elliott wrote: One problem with using YASim for sea planes is that the fuselage mustn't contact the surface as this equates to a crash. While I was experimenting with the SR45 I found that I had to omit the lower fuselage deck to achieve this, which must then affect the flying accuracy. I suspect the real problem is that there weren't enough gear objects. On a seaplane, anything that contacts the water is a landing gear. Something with a realistic gear compression should be touching the surface before the automatically generated fuselage contact point does; this requirement isn't any different from any other aircraft. FWIW, adding special behavior for contact points when they touch water (relaxed crash distance and spring constant, I guess) wouldn't be hard, provided the hard part is done: telling the FDM when the intersection point is with water. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
Gerard Robin wrote: I could not use JSB (no rotor FDM) and with the use of Yasim it has been very difficult to find the right way which make that model to stand correctly on water with gear-up. To answer that, JSBSim gives a better flexibility. Both JSBSim and YASim use manually placed gear objects. There is no meaningful difference in the way they are configured. Getting the c.g. correct and making aircraft stand up straight is just hard. :) Note that there is no water yet. Making an aircraft stand correctly on water is no different from making it stand correctly on the runway. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] timer help
eagle monart wrote: i am totaly lost. i ve tried different declarations of delay functions but they starts infinite loops. i tihnk nasal expalined only for xml usage but i didnt find a source to declare settimer() in a source code . I need a reference... The documentation for the function is at http://plausible.org/nasal/flightgear.html (at the bottom of the file). It explains how to write Nasal in XML files as well as how to write stand-alone files. The settimer() function is a C++ extension function, it is defined in src/Scripting/NasalSys.cxx in the source code. And of course you can look at the existing Nasal code, all of which uses settimer() extensively. You can grep through all the existing nasal files with something like: cd $FG_ROOT find . -name '*.nas' | xargs fgrep settimer And, as always, posting the code you are having trouble with is much more useful than simply announcing that different versions start infinite loops. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
Le samedi 11 juin 2005 08:39 -0700, Andy Ross a crit : Gerard Robin wrote: I could not use JSB (no rotor FDM) and with the use of Yasim it has been very difficult to find the right way which make that model to stand correctly on water with gear-up. To answer that, JSBSim gives a better flexibility. Both JSBSim and YASim use manually placed gear objects. There is no meaningful difference in the way they are configured. Getting the c.g. correct and making aircraft stand up straight is just hard. :) Note that there is no water yet. Making an aircraft stand correctly on water is no different from making it stand correctly on the runway. Andy NO The big difference is, a seaplane can have 2 types of contact points one which is the usual gears on ground, which is retractable and well defined on both FDM. the second which is part of the fuse and auxiliary floats, with JSBSim we have not any difficulties to define it ( i have a seaplane modelled with 12 contact points) and makes the aircraft standing correctly. with Yasim we must find a medium way to get the same effect. About retractable gears no problems, about contact points on the fuse big problems . -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] joystick subsystem changes
The joystick subsystem does now work differently. Notable changes are: (0) There's no need to list all joystick config files in $FG_ROOT/Input/Joysticks. They are loaded automatically. (1) /input/joysticks/ does only contain nodes for active joysticks -- that's only one single js[0] in most setups! Before we had 28 configs and a couple of empty nodes. And one couldn't say which of these was actually used. (No, it was almost never js[0], as one would assume.) (2) These active js[] contain extra information: id ... the js hardware id that was searched in all the named config files (this does *not* indicate the used driver! Take the name nodes and source for that! source ... the path to the used config file This will probably be useful for user support. Just tell them to look into /input/joysticks/js[0] and see if their js was actually found. This could be hard to do on MICROS~1 via --log-level=info 21|awk ... (3) The default joystick is a normal js config file with namedefault/name (and possibly more names). (4) js[] entries can be preset and won't get overwritten by named js configs. (5) js[] entries aren't shared any more. If you have 10 Saitek-Cyborg-Gold attached, you'll get 10 copies of that js. This allows to tweak them independently, and to store additional values in the node on a per joystick basis. (6) All nasalscript.../script/nasal blocks are executed at initialization time. (See an example for (5) and (6) in the upcoming Saitek/Cyborg-Gold config.) User customization: --- Most people who want to modify the js config, do probably edit the files in $FG_ROOT directly, or copy their preferred config over Defaults/joystick.xml. Both of which is ugly and evil. The correct way is: (a) either load your favorite named js config from your local config file (add --config=/my/personal/config.xml) into a js-named node: input js-named include=Micro-Thrust-Gold-Foobar.xml/ /input This will then automatically get picked up and used if the name contents match the hw id/search string. Such a preset js-named config takes precedence over the official js config for that id. This will (b) include your personal config directly at a specific node: input js n=1 include=Jumbo-Pedals.xml/ /input This entry won't get overwritten by a named js config. It's taken as is. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
Gerard Robin wrote: with Yasim we must find a medium way to get the same effect. About retractable gears no problems, about contact points on the fuse big problems . I'm not understanding this at all; JSBSim and YASim have all but identical* gear systems. Can you please post the YASim configuration you are having trouble with? I suspect you are just misunderstanding something. Are you trying to make the aircraft sit on the automatic contact points? That won't work, they have very high spring constants and are designed to detect crashes. You need to define gear objects with non-tiny compression distances. I think the confusion here might be the assumption that you can only have one set of gear and that they must all retract when /controls/gear-down is set to false. That has never been true with YASim. Andy * Differences of which I am aware: JSBSim uses manual contact points, whereas YASim generates them automatically. JSBSim uses a single set of retractable gear, whereas YASim allows different gear object to retract independently. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: poll (more complex than at first appears?)
* Andy Ross -- Saturday 11 June 2005 17:35: FWIW, adding special behavior for contact points when they touch water (relaxed crash distance and spring constant, I guess) wouldn't be hard, provided the hard part is done: telling the FDM when the intersection point is with water. The hard part *is* done already. See in groundcache.cxx: bool FGGroundCache::get_agl(double t, const double dpt[3], double contact[3], double normal[3], double vel[3], int *type, double *loadCapacity, double *frictionFactor, double *agl) type and frictionFactor! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: poll (more complex than at first appears?)
* Melchior FRANZ -- Saturday 11 June 2005 18:14: * Andy Ross -- Saturday 11 June 2005 17:35: wouldn't be hard, provided the hard part is done: telling the FDM when the intersection point is with water. The hard part *is* done already. See in groundcache.cxx: [...] type and frictionFactor! Umm ... I take the frictionFactor back. That's just a placeholder for now and always returns 1.0. But the type should work. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: poll (more complex than at first appears?)
Melchior FRANZ wrote: * Andy Ross -- Saturday 11 June 2005 17:35: FWIW, adding special behavior for contact points when they touch water (relaxed crash distance and spring constant, I guess) wouldn't be hard, provided the hard part is done: telling the FDM when the intersection point is with water. The hard part *is* done already. See in groundcache.cxx: bool FGGroundCache::get_agl(double t, const double dpt[3], double contact[3], double normal[3], double vel[3], int *type, double *loadCapacity, double *frictionFactor, double *agl) type and frictionFactor! It's actually one of the first things I asked for when Mathias started to implement the groundcache code ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: poll (more complex than at first appears?)
Melchior FRANZ wrote: Umm ... I take the frictionFactor back. That's just a placeholder for now and always returns 1.0. But the type should work. :-) (rolling)-friction and bumpiness could be read from materials.xml in the future. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] poll (more complex than at first appears?)
Andy wrote: whereas YASim allows different gear object to retract independently. !!! ... now there's a thought. Hmmm. I feel a feature request coming for JSBSim. :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [Fwd: Re: [Jsbsim-devel] crash handling options for JSBSim in FlightGear]
Message transfr De: Gerard Robin [EMAIL PROTECTED] Rpondre : [EMAIL PROTECTED] : [EMAIL PROTECTED] Objet: Re: [Jsbsim-devel] crash handling options for JSBSim in FlightGear Date: Sat, 11 Jun 2005 18:39:41 +0200 Le vendredi 10 juin 2005 14:59 -0500, Dave Culp a crit : It seems like I misunderstood someone's complaint about JSBSim crash handling. Nobody wants subterranean flying. This will make the crash handling much cleaner. We can make pause the default behavior and reset the optional behavior, based on a property reset-on-crash. Everyone agreed on this? Dave Ah Ah Ah..WAS IT SO DIFFICULT to leave the facilities to manage by ourself the crash handling, now with the PAUSE we cannot do anything. I tried to explain that we can manage with specific animations that crash, Now nothing working ! You may keep the automatic reset on request, no problem. PLEASE...PLEASE...PLEASE don't reduce the JBS facilites. ___ -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
Le samedi 11 juin 2005 09:24 -0700, Andy Ross a crit : Gerard Robin wrote: with Yasim we must find a medium way to get the same effect. About retractable gears no problems, about contact points on the fuse big problems . I'm not understanding this at all; JSBSim and YASim have all but identical* gear systems. Can you please post the YASim configuration you are having trouble with? I suspect you are just misunderstanding something. Are you trying to make the aircraft sit on the automatic contact points? That won't work, they have very high spring constants and are designed to detect crashes. You need to define gear objects with non-tiny compression distances. I think the confusion here might be the assumption that you can only have one set of gear and that they must all retract when /controls/gear-down is set to false. That has never been true with YASim. Andy * Differences of which I am aware: JSBSim uses manual contact points, whereas YASim generates them automatically. JSBSim uses a single set of retractable gear, whereas YASim allows different gear object to retract independently. OK i'll try to find my old project or to rebuild it , because many many water as passed under the Avignon Bridge since ... -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
On Saturday 11 Jun 2005 16:35, Andy Ross wrote: Lee Elliott wrote: One problem with using YASim for sea planes is that the fuselage mustn't contact the surface as this equates to a crash. While I was experimenting with the SR45 I found that I had to omit the lower fuselage deck to achieve this, which must then affect the flying accuracy. I suspect the real problem is that there weren't enough gear objects. On a seaplane, anything that contacts the water is a landing gear. Something with a realistic gear compression should be touching the surface before the automatically generated fuselage contact point does; this requirement isn't any different from any other aircraft. FWIW, adding special behavior for contact points when they touch water (relaxed crash distance and spring constant, I guess) wouldn't be hard, provided the hard part is done: telling the FDM when the intersection point is with water. Andy Hello Andy, I didn't really have a problem with the number of gear objects - I used a soft sprung tandem layout for the main gear with firm sprung out-riggers for the floats, which were retractable. It actually seemed to work quite well, with the a/c leaning a little to one side on the float that was in the water. As the a/c accelerated for take-off it rose up out of the 'water' quite nicely:) The main problem was that one of the fuselage entries had to be omitted - I originally tried to use three entries as this matched the SR45 fuselage well. As to how much difference this made to what was largely a guess-work fdm is anyone's guess. I figured that it should be possible to model a set of wash waves and spray that could be linked to the compression too. Lot of work though. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Fwd: Re: [Fwd: Re: [Flightgear-devel] [Fwd: Re: [Jsbsim-devel] crash]
Message transfr De: Martin Spott [EMAIL PROTECTED] Rpondre : FlightGear developers discussions flightgear- [EMAIL PROTECTED] : flightgear-devel@flightgear.org Objet: Re: [Fwd: Re: [Flightgear-devel] [Fwd: Re: [Jsbsim-devel] crash Date: Sat, 11 Jun 2005 19:53:19 + (UTC) Newsgroups: list.flightgear-devel Gerard Robin wrote: Message transfr De: Martin Spott [EMAIL PROTECTED] Ah Ah Ah..WAS IT SO DIFFICULT to leave the facilities to manage by ourself the crash handling, now with the PAUSE we cannot do anything. Sure, you can override the default, Happy to learn , How ? This was explained in the CVS respective changelog entry, Martin. Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, I have got only on information coming from Dave: We can make pause the default behavior and reset the optional behavior, based on a property reset-on-crash. Don't mind, it is several weeks ago i started to patch my own CVS release, i'll continu in that way. I worry it, because more and more i will not be able to help by testing, the official release. I started with FG from one of the last 8 version (don't remember which). It took delay for me to join the mailing development because of a lack of low cost internet equipment in my country (partly mountain). I spent that period to look at every pieces of FG programs. Experimenting it on many aircrafts in specific configurations. So.. don't mind, i can do without. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] timer help
eagle monart wrote
And, as always, posting the code you are having trouble with is much
more useful than simply announcing that different versions start
infinite loops. :)
Andy
i wrote different functions here is few examples. by the way i am writing
these to the larcsim c172aero also added time.h under msvc7.1.
i am tryng to add a delay in seconds before activation/ deactivation of
cockpit functions. my aim is to declare specific drag according to time
within component cycle time. i am trying to add an example decleration for
that purposebut function goes too..infinite!!! or
totaly frezes sim .
my first try
// travel time speedbrake drag coeff=1 after travel comp drag=1 // itt
logic checker to break loop
if( Speedbrk) { if (itt==0)
start_time = clock();
while((clock() - start_time) 3 *
CLOCKS_PER_SEC)
{ speedd=1 ;itt=1;
} }
speeddd=1.7; }
another try
double delwait ( double seconds )
{
double checker1,result1 ;
checker1= clock () +seconds * CLK_TCK ;
result1= checker1-clock();
return (result1);
}
if( Speedbrk) { if ( itt==0 ) {ni=delwait(2);
while (ni0) { speedd=1; itt=1; }
}
else { speedd=1.7 ;}
}
another try but frezes whole sim
wait ( int seconds )
{
clock_t endwait;
endwait = clock () + seconds * CLK_TCK ;
return(endwait-clock())
}
if( Speedbrk) { if ( itt==0 ) { while ( wait (2)=0) { speedd=1;
itt=1 }}
speedd= 1.7 ;}
You will find an example of a time delay function in
~/Aircraft/Spitfire/models/spitfire.nas. Look for the code following
# Coffman starter stuff ==
This particular fragment was written by Melchior Franz.
Regards,
Vivian
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Jsbsim-devel] crash]
On Saturday 11 Jun 2005 21:28, Gerard Robin wrote: Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, You can subscribe to the flightgear-cvslogs mailing list or check the archive here; http://baron.flightgear.org/pipermail/flightgear-cvslogs/ Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Jsbsim-devel] crash]
Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, You can subscribe to the flightgear-cvslogs mailing list or check the archive here; http://baron.flightgear.org/pipermail/flightgear-cvslogs/ This one may interest you : http://baron.flightgear.org/pipermail/flightgear-cvslogs/2005-June/010209.html -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Jsbsim-devel] crash]
Le samedi 11 juin 2005 21:40 +0100, AJ MacLeod (email lists) a crit : On Saturday 11 Jun 2005 21:28, Gerard Robin wrote: Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, You can subscribe to the flightgear-cvslogs mailing list or check the archive here; http://baron.flightgear.org/pipermail/flightgear-cvslogs/ Cheers, AJ OK Thanks, I missed something :) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Fwd: Re: [Fwd: Re: [Flightgear-devel] [Fwd: Re: [Jsbsim-devel] crash]
Message transfr De: Martin Spott [EMAIL PROTECTED] De: Martin Spott [EMAIL PROTECTED] This was explained in the CVS respective changelog entry, Martin. Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, I have got only on information coming from Dave: We can make pause the default behavior and reset the optional behavior, based on a property reset-on-crash. I confirm only reset-on-crash true or false nothing else, Have you tried ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
On June 11, 2005 06:07 pm, Oliver C. wrote: I agree with the terrain. But i think that airplanes need to be able to sink after they crash. :) So the best way would be to make the terrain and watersurfaces independent from each other. This would also have some positive side effects because it would allow us to animate waves of the sea and make the sea transparent, especially at the coastlines. For this, it would also be a good idea to display the ground under the sea and merge the terrain with the ground under the sea instead of with the sea level. This would also allows us to include submarines, like someone above in this thread said. Best Regards, Oliver C. I like that idea. It would be nice to fly along the coast of a tropical island, look down and be able to see the white sand under the water... or flying above a coral reef and see the corals on the sea floor. =) Seperating land and water will also allow tidal effects to be modelled. As for underwater exploration, I for one wouldn't mind taking the UFO down and see some underwater landmarks such as the Titanic. hehe. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Fwd: Re: [Fwd: Re: [Flightgear-devel] [Fwd: Re: [Jsbsim-devel] crash]
Gerard Robin wrote: Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, http://baron.flightgear.org/pipermail/flightgear-cvslogs/ Look at the recent changes made by Erik, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New developer
On June 11, 2005 03:06 pm, [EMAIL PROTECTED] wrote: Hi All! I would like to contribute to flightgear project... I'm interested in converting italian scenery from MSFS (I already know that it is not possible to distribute stuff that it isn't GPL compatible) and creating an MD-82 model for flightgear... 1) Does someone is already working on that? I believe someone had been working on the Boeing 717/MD-82, but the author of that aircraft has some real life issues to take care of, and gave(?) the model to someone else to continue. There is no word regarding that particular aircraft ever since. As for scenery, we seem to be lacking developers in that area. ;-) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] t-38
hi all; i am looking for detailed info and measurements of t-38 . some guys told mei can even find accurate scalar tables in roskam books series. i am planning to buy one from amazon but dont know which one contains t-38 datas. anyone knows?? Tom__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
Ampere K. Hardraade wrote: I like that idea. It would be nice to fly along the coast of a tropical island, look down and be able to see the white sand under the water... I think we could already get this by exploring the shallow water attribute in the VMAP data well, I could be wrong, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Fwd: Re: [Flightgear-devel] crash handling options for JSBSim in FlightGear
Le samedi 11 juin 2005 22:07 +, Martin Spott a crit : Gerard Robin wrote: Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, http://baron.flightgear.org/pipermail/flightgear-cvslogs/ Look at the recent changes made by Erik, Martin. Because the shorter Jokes are the best we will stop now . The game is OVER. Starting: Wed Jun 1 22:01:09 CDT 2005 Ending: Sat Jun 11 10:26:34 CDT 2005 are the dates of the last cvslogs. It was saidin an other message /sim/pause-on-crash to true, then the sim will pause on crash, which is the same behavior Yasim has, so this should be the default for FlightGear. If the user sets the property /sim/reset-on-crash to true, then the sim will reset on crash. that does not give any good result on my side. did you try ??? Good Night Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] timer help
eagle monart wrote: i am tryng to add a delay in seconds before activation/ deactivation of cockpit functions. my aim is to declare specific drag according to time within component cycle time. i am trying to add an example decleration for that purposebut function goes too..infinite!!! or totaly frezes sim . Well, first, we seem to be talking about different things. I thought the question was about how to use settimer() in a Nasal script, whereas these are modifications to the C code in LaRCsim. Second, as a more general suggestion: please get your whitespace under control. Different programmers have different ideas about where braces go, how many spaces to use for indentations, whether tabs are legal, whether whitespace should be used around parentheses, etc... But no one should be forced to read stuff like you posted. I honestly had to read through your (non-code) text several times just to be sure it wasn't a joke. :) Third, the clock() function you are calling is not what you think it is. It does not wall clock time, but CPU time used by your current process. These aren't likely to be well synchronized. And finally, trying to wait like this is never going to work well. FlightGear has a main loop that it needs to execute every frame. When you block waiting on something to happen, you are blocking the entire simulator. The proper way to implement this kind of feature is to poll for changes every frame, and set some kind of state to know what to do each update. Honestly, my suggestion is to leave the C/C++ code alone, study the existing aircraft to learn how they are configured using XML and Nasal, and try to implement your feature at that level. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
