On mar 26 août 2008, Melchior FRANZ wrote:
> * gerard robin -- 8/26/2008 2:32 PM:
> > The specific air refueling and or fuel.nas makes problems if the Aircraft
> > has some specific tank management, for instance Crusader has a specific
> > "transfer tank" which feed the others, Blackbird has an other
> > process.... in order to manage the balance and so on.
>
> With the generic interface an aircraft could just refuse to take any fuel,
> based on electrical system, or whatever. The idea again is something like
> this in fuel.nas (with merged in aar.nas):
>
> fuel_interface.setDoubleValue(offered_amount);
> var accepted_amount = fuel_interface.getValue();
> if (!accepted_amount)
> return;
> if (accepted_amount > 0)
> fill_tanks(accepted_amount);
> subtract_from_tanker(abs(accepted_amount));
>
> Normally, no listener is attached to node "fuel_interface", so the value
> will be the same after reading in again, and all that was offered in this
> cycle will be filled into all active tanks, just as it's the case now. But
> an aircraft could attach a listener to that node:
>
> setlistener(fuel_interface, func(n) {
> if (don_t_feel_like_tanking) {
> n.setDoubleValue(0); # no thanks; offer rejected
> } else {
> var amount = n.getValue();
> do_fancy_stuff_with(amount);
> n.setDoubleValue(-amount); # we took *and* distributed it
> }
> });
>
> ... or something.
>
Today i am not the best to evaluate your proposal, many others could say what
they want.
May be coming here, i will complicate things which are, i guess, requested
simple.
Generic is generic :)
> > As, i told before, depending on the FDM we can, more or less, include
> > part of these specific features into the FDM itself, JSBSim is able to
> > take it.
>
> Yeah, I bet one could code Tetris within a JSBSim config file. Whether it
> makes sense is a different matter. ;-)
hmmm Tetris, not sure......... :)
>
> > Regarding the new "type" probe/boom which is defined into into the
> > model.xml with nasal, won't it be possible to define it, into the
> > demo.xml file instead of it ?
>
> The refueling type must be known over MP/AI. It must also work for
> aircraft piloted by a human. The demo XML file is the wrong place for
> that. And then the refueling capacities are properties of the tanker,
> not of a particular scenario. I agree, however, that using one model
> for either refueling type (and "select"-animating the boom/probe model
> based on that) would be a good idea.
>
> m.
>
Oh right i forgot MP.
The other alternative could be to create an other
data/Models/Geometry/KC135/KC135_probe.xml file with the
nasal .setValue("probe"),
We need, too, a other additional demo.xml file.
We save the .ac file which remain the same :)
--
Gérard
http://pagesperso-orange.fr/GRTux/
"J'ai décidé d'être heureux parce que c'est bon pour la santé.
Voltaire "
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
