RE: [Flightgear-devel] how to find remaining fuel
Hi Jon Hope this is concise enough. There is no total fuel onboard property as far as I am aware. In other words there is nothing that adds the contents of each tank to give a total fuel property. All that is needed is something that adds the total of all the tanks and outputs it as a property.Now I dont know if this has to be done as a nasal script or can just be done as a property. Jon Berndt writes I have been using the c172 aircraft. Is it controlled by jsbsim or ysim? Thanks, Seamus I vaguely recall hearing that there is a C-172 for each of those two FDMs. If you are refrring to the default c172, that's _probably_ the JSBSim one. I haven't been following this thread very closely. Can someone concisely recap what is wanted, here? It's most likely a very simple addition for us if it's something we don't now model. Jon Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: fgfs animation module for Blender
* Arnt Karlsen -- Friday 04 February 2005 03:34: On Thu, 3 Feb 2005 19:44:54 +0100, Melchior wrote in message I'll continue to improve and extend this script as I see need. If someone has ideas for useful functions, please tell me. Fowler flaps etc with combined translations and rotations? Sounds interesting, especially since it's a pain to do manually. But I don't know enough about how these are to be animated. Their translation and rotation speed is probably not linear, so it would need a lot of additional input. You'd need to select several vertices -- at least 3 for the retracted, and 3 for the extended flap. The script, however, only gets a list of selected vertices and has no clue about which of them belong together. Changing the script to some kind of 'wizard' might help. I'll think about it but I will probably leave the coding to someone who actually is about to animate such flaps. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: fgfs animation module for Blender
* Melchior FRANZ -- Friday 04 February 2005 10:02: The script, however, only gets a list of selected vertices and has no clue about which of them belong together. Bull. That's how it works now, but, of course, the script gets a list of all objects, faces, edges, vertices. So it would be possible to make copies of the flap and put them into the retracted, the extended, and (time-wise) evenly spaced positions in between, and let the script calculate one translate and one rotate animation both with interpolation table. The additional object would best be kept in place (different Blender scene or later removed by a script like my ac3d-sort sript). Worth a try. Sounds like a lot of fun at least. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] how to find remaining fuel
Jon S. Berndt wrote: I haven't been following this thread very closely. Can someone concisely recap what is wanted, here? It's most likely a very simple addition for us if it's something we don't now model. Actually, YASim uses a Nasal-based fuel system that was designed to be FDM-independent. It doesn't handle the stuff internally at all. Instead, each engine sets an /engine/engines[n]/fuel-consumed-lbs property. Each iteration, it adds its newly consumed fuel (that is, just flow rate * timestep) to this property. The Nasal script then comes around in a polling loop, sucks this stuff out and subtracts it from the tanks according to the fuel selector properties. YASim then just uses each tanks level-lbs property as a pure input property to set weights on the tank objects. This is good for YASim. However, the Nasal approach won't apply for other applications which use JSBSim, and JSBSim also needs its own fuel management for batch runs (standalone operation) outside of FlightGear. The downside to that requirement is that somehow we have to all learn to play nice together in a sensible way. This has been kind of an irritatant to me, that there are probably going to be items in our (JSBSim) configuration spec which are ignored or overwritten by FlightGear, which leads to user confusion and debugging headaches (I'm referring to fuel quantities and weight and balance issues). FWIW, another cool thing this dialog gets you is automatic weight management. You can assign named weight objects in your -set.xml file and use sliders to control their sizes at runtime. Not many of the YASim aircraft are doing this yet (I did the pa28-161 and a4, I know). It's a much cleaner interface than having separate FDM configurations for each aircraft loadout. This points out a headache for FlightGear, too: how to manage different capabilities in different FDMs and not leave users scratching their heads: why can I do this with this aircraft and not that one? Some of the features can be added to the various FDMs without much trouble, I'm guessing, and made more common through the FGInterface class. With JSBSim, though, we have to be careful and make sure new features don't break other people's apps and continue to work with standalone operation. Anyhow, we support specification of named mass objects in the configuration file. There are static once defined. We might consider writing up a list of common features that we'd like to see supported by all FDMs, so the user has a more homogenous experience with the various aircraft. Innis has written that all that is really needed from us it to provide a total fuel property. That's very simple to do. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: how to find remaining fuel
* Andy Ross -- Friday 04 February 2005 03:32: FWIW, another cool thing this dialog gets you is automatic weight management. You can assign named weight objects in your -set.xml file and use sliders to control their sizes at runtime. Not many of the YASim aircraft are doing this yet (I did the pa28-161 and a4, I know). Don't forget the bo105! You can make the bo105 heavy beyond max. takeoff weight, for example by making the patient extremely fat ... :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: fgfs animation module for Blender
On Fri, 4 Feb 2005 10:02:22 +0100, Melchior wrote in message [EMAIL PROTECTED]: * Arnt Karlsen -- Friday 04 February 2005 03:34: On Thu, 3 Feb 2005 19:44:54 +0100, Melchior wrote in message I'll continue to improve and extend this script as I see need. If someone has ideas for useful functions, please tell me. Fowler flaps etc with combined translations and rotations? Sounds interesting, especially since it's a pain to do manually. But I don't know enough about how these are to be animated. Their translation and rotation speed is probably not linear, so it would need a lot of additional input. ..a virtual 2D example: a wee railway wagon rolling down a track that has a straight section (to add wing area), then turns gradually sharper (to add lift first, then drag). -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to find remaining fuel
Jon S. Berndt wrote: This is good for YASim. However, the Nasal approach won't apply for other applications which use JSBSim, and JSBSim also needs its own fuel management for batch runs (standalone operation) outside of FlightGear. Well, it's certainly fgfs-specific, although there's really not much YASim-ness in there. Basically, we want things like fuel state to be settable by the user using the property system. That's really not an escapable requirement if we want the users to configure this subsystem at runtime. IMHO, the easiest way to implement that is to disengage the FDM's internal fuel management code (I actually deleted YASim's) and simply make it take the property stuff as input. The weights work the same way: the YASim configuration simply associates a property name (e.g. /sim/weight[0]/weight-lb) with a specific location on the airframe. Then the GUI code reads the metadata under /sim/weight[n] to pop up a dialog with sliders for each named weight. With JSBSim, you could write a property interface manager for these guys that replaces the internal internal fuel/weight managers you have right now. If you wanted, you could actually write property listeners to override the current property nodes and wire their get/set operations directly into your internal get/set calls. But that seems like more work, IMHO. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] STL help requested
Hi folks, I've run into a tricky problem when using stl map, and am hoping someone might be able to point me on the right direction. I have a map of airports, indexed by string, which is the ICAO code: mapstring, ARP* apt_map; Now, I want to emulate the 'search ahead' function of GPS code entry, so that, for instance, entering KC will cause KCAD to be displayed - the first airport in the database starting with KC. To do this I use the lower_bound function, for both KC and KD. If the returned iterators don't match, then there is a valid match for KC. mapstring, ARP*::iterator it1, it2; it1 = apt_map.lower_bound(KC); it2 = apt_map.lower_bound(KD); return(it1 == it2 ? NULL : it1-second); So far, so good. Now, the problem is that the KLN89 (and probably most/all GPS units) regards A-Z as coming before 0-9, whereas the standard string compare function regards 0-9 as coming before A-Z. So in this instance I might get KC52 displayed instead of KCAD (there isn't really a KC52, but there are many examples outside the US where this bites). Now, I can get round this by using a comparison of lower_bound tests for KC, KCA and KD, and it works. Unfortunately I then have to check for non-alpha chars down to the end of the returned string, and re-test any with 'A' substituted in place. It's effective, but really ugly! I had to think quite hard about code I only wrote a week ago to compose the last sentence, and that's always a bad sign. What I'm sure I ought to be able to do is to define a custom comparison operator that performs a string comparison where numbers are considered to come after letters, and for good measure to do a case-insensitive match on the letters. I want to be able to do something like: it1 = apt_map.lower_bound(KC, gps_less); with all the ugly bits tucked away in gps_less which I can get working and them forget about. Unfortunately, I can't find any good example in any of my books to do this, nor on the internet, and everything I try is giving me swathes of typical gruesome-to-mentally-parse stl error messages. If anyone has an example of how to do this, or any pointers to one, I'd be most grateful. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] STL help requested
David Luff wrote: Hi folks, I've run into a tricky problem when using stl map, and am hoping someone might be able to point me on the right direction. I have a map of airports, indexed by string, which is the ICAO code: mapstring, ARP* apt_map; Now, I want to emulate the 'search ahead' function of GPS code entry, so that, for instance, entering KC will cause KCAD to be displayed - the first airport in the database starting with KC. To do this I use the lower_bound function, for both KC and KD. If the returned iterators don't match, then there is a valid match for KC. mapstring, ARP*::iterator it1, it2; it1 = apt_map.lower_bound(KC); it2 = apt_map.lower_bound(KD); return(it1 == it2 ? NULL : it1-second); So far, so good. Now, the problem is that the KLN89 (and probably most/all GPS units) regards A-Z as coming before 0-9, whereas the standard string compare function regards 0-9 as coming before A-Z. So in this instance I might get KC52 displayed instead of KCAD (there isn't really a KC52, but there are many examples outside the US where this bites). You could use qsort to sort the map just prior to using it: http://www.cplusplus.com/ref/cstdlib/qsort.html It requires a function that returns 0, 0 or 0 for every sort operation, so you can define the sorting algorithm yourself. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] STL help requested
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Luff schrieb:
Hi folks,
I've run into a tricky problem when using stl map, and am hoping someone
might be able to point me on the right direction.
I have a map of airports, indexed by string, which is the ICAO code:
mapstring, ARP* apt_map;
Now, I want to emulate the 'search ahead' function of GPS code entry, so
that, for instance, entering KC will cause KCAD to be displayed - the
first airport in the database starting with KC. To do this I use the
lower_bound function, for both KC and KD. If the returned iterators
don't match, then there is a valid match for KC.
mapstring, ARP*::iterator it1, it2;
it1 = apt_map.lower_bound(KC);
it2 = apt_map.lower_bound(KD);
return(it1 == it2 ? NULL : it1-second);
So far, so good. Now, the problem is that the KLN89 (and probably most/all
GPS units) regards A-Z as coming before 0-9, whereas the standard string
compare function regards 0-9 as coming before A-Z. So in this instance I
might get KC52 displayed instead of KCAD (there isn't really a KC52, but
there are many examples outside the US where this bites).
Now, I can get round this by using a comparison of lower_bound tests for
KC, KCA and KD, and it works. Unfortunately I then have to check for
non-alpha chars down to the end of the returned string, and re-test any with
'A' substituted in place. It's effective, but really ugly! I had to think
quite hard about code I only wrote a week ago to compose the last sentence,
and that's always a bad sign. What I'm sure I ought to be able to do is to
define a custom comparison operator that performs a string comparison where
numbers are considered to come after letters, and for good measure to do a
case-insensitive match on the letters. I want to be able to do something
like:
it1 = apt_map.lower_bound(KC, gps_less);
with all the ugly bits tucked away in gps_less which I can get working and
them forget about. Unfortunately, I can't find any good example in any of my
books to do this, nor on the internet, and everything I try is giving me
swathes of typical gruesome-to-mentally-parse stl error messages. If anyone
has an example of how to do this, or any pointers to one, I'd be most
grateful.
The C++ Programming language 3rd ed. tells me:
Basically you've got 2 options:
1 - create a class with the operator
class IACOcode
{
string the_code;
}
bool operator( const IACOcode a, const IACOcode b )
{
return your ordering;
}
mapIACOcode, ARP* apt_map;
2 - create a custom sort order
class IACOcode_compare
{
public:
bool operator()( const string x, const string y) const
{
return your ordering;
}
}
mapstring, ARP*, IACOcode_compare apt_map;
Then you'll automatically get the desired result with your described lookup.
CU,
Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCBAAwlhWtxOxWNFcRAvoUAKCQmu/HJmzAQ6OZCLwCPJXoNLalPQCfSKB3
TBEVeGwmDCjOwegYbvbj8AQ=
=mohP
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] how to find remaining fuel
With JSBSim, you could write a property interface manager for these guys that replaces the internal internal fuel/weight managers you have right now. If you wanted, you could actually write property listeners to override the current property nodes and wire their get/set operations directly into your internal get/set calls. But that seems like more work, IMHO. Andy I'll have to figure something out, that's for sure. But, our backlog is growing faster than our frontlog. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to find remaining fuel
I found time this afternoon to refresh my memory about how the fuel stuff works. The FDM reads these properties to determine the amount of fuel in each tank. YASim uses this only for computing the inertia tensor and total aircraft mass, it doesn't care about fuel per se. /consumables/fuel/tank[n]/level-lbs The FDM reads the following boolean property to determine whether to kill an engine: /engines/engine[n]/out-of-fuel The FDM *adds* to this property to contain a running total of fuel consumed for each engine. If it currently has a value of 7, and this timestep 4.2 lbs of fuel were consumed by this engine, then it should be set to 11.2. /engines/engine[n]/fuel-consumed-lbs And that's it. Everything else related to fuel, including user-configurability of tank selection and/or filling, is handled by the nasal script/gui for you. IMHO, it's really about as simple for the FDM as is possible. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
