Re: [Flightgear-devel] multiplayer generic properties
Hi Melchior, Melchior FRANZ schrieb am 10.12.2007 19:32: > Note that loops/listeners that were started in have > to be stopped/removed in ! Otherwise they will keep > running (which is a feature), and you might accumulate them over > time. The bo105 does that correctly, the v22 does not! :-) > > Thanks for reporting. I sent a patch to Emmanuel. Should be in cvs, soon. Maik - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Melchior FRANZ -- Sunday 09 December 2007: > * Melchior FRANZ -- Sunday 09 December 2007: > > BTW: in my tests yesterday I noticed that the part was > > never called, and so the loop is never stopped. > > Just for the record: yes, that's not done ATM. Will fix tomorrow. Which is now done. It may not look pretty, but it's the sanest approach for now (IMHO), and it won't be necessary for fg/osg at all. and are now called per model instance. Note that loops/listeners that were started in have to be stopped/removed in ! Otherwise they will keep running (which is a feature), and you might accumulate them over time. The bo105 does that correctly, the v22 does not! :-) Please test in MP and report any problems. It worked in a local network so far. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Melchior FRANZ -- Sunday 09 December 2007: > BTW: in my tests yesterday I noticed that the part was > never called, and so the loop is never stopped. Just for the record: yes, that's not done ATM. Will fix tomorrow. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Maik Justus -- Sunday 09 December 2007: > With this trick I should be able to transfer the wing-fold > and engine-tilt animation of the v22 over the MP-protocol. Yeah, that's a typical case for properties where standardization wouldn't make much sense, and generic ones are therefore preferable. Though you wouldn't need the embedded Nasal at all, if you just change the property names to the generic ones everywhere. That's just not an option in the bo105, as I have to post-process the transmitted strings and to load the variant XML file. BTW: in my tests yesterday I noticed that the part was never called, and so the loop is never stopped. This can lead to collisions when the same aircraft type joins in a second time. This worked when I wrote the Nasal embedding code. Has the MP code been changed to never release once loaded models?! m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
Hi Melchior,
Melchior FRANZ schrieb am 08.12.2007 17:08:
> * Melchior FRANZ -- Saturday 08 December 2007:
>
>> it was time to add some generic properties for "internal communication".
>>
>
> It's probably also time to remind people again of the possibility to
> add Nasal code to model (animation) XML files. This is then only
> run when the model is used as as a static scenery model or an MP
> model, but not for the instance that you are actively flying on your
> machine. Such code can evaluate generic properties and modify them,
> and/or move them where they belong. In the MP case, cmdarg() can be
> used to access the model's node under /ai/models/. Example:
>
>
> print("I was just loaded under ", cmdarg().getPath())
> print("Good Bye says ", cmdarg().getPath())
>
>
>
Ah, very good! With this trick I should be able to transfer the
wing-fold and engine-tilt animation of the v22 over the MP-protocol.
Thank You!
Maik
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Anders Gidenstam -- Saturday 08 December 2007: > Though my dual control version of the c172p already uses more > than 10 extra float properties.. :) I have no problem with adding more, now that I know that they have no effect if they aren't used. And if you are using some others, anyway, then we can as well have additional generic ones. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
On Sat, 8 Dec 2007, gerard robin wrote: > Nasal animation Probably valuable for YASim but with JSBsim their is an other > way easier. But those properties are not sent over MP - which is the whole point of the /sim/multiplay/generic/* properties. While I agree that JSBSim allows many useful transformations of properties to be specified directly in the FDM config, this is one thing it cannot do. Many thanks to Melchior for adding these properties. (Though my dual control version of the c172p already uses more than 10 extra float properties.. :) Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* gerard robin -- Saturday 08 December 2007: > but don't forget that we can within JSBSim avoid most of the Nasal code > everything done in the FDM. Again: this doesn't even *work* for what you fear it could be (ab)used. The bit of Nasal code in bo105.xml is simply ignored if you fly the bo105. It's only run for bo105 that appear as multiplayer objects, or such that you place as scenery decoration. There are only two uses for embedded Nasal: - static objects (e.g. animated hangar doors), where it's useful that the Nasal module is created when the object comes "into sight" (if you have good eyes ;-), and is removed again when you leave the area - MP objects, which need to run code that knows where in the property tree its parameters reside, and which have to move or modify properties there. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
On sam 8 décembre 2007, Melchior FRANZ wrote:
> * Melchior FRANZ -- Saturday 08 December 2007:
> > it was time to add some generic properties for "internal communication".
>
> It's probably also time to remind people again of the possibility to
> add Nasal code to model (animation) XML files. This is then only
> run when the model is used as as a static scenery model or an MP
> model, but not for the instance that you are actively flying on your
> machine. Such code can evaluate generic properties and modify them,
> and/or move them where they belong. In the MP case, cmdarg() can be
> used to access the model's node under /ai/models/. Example:
>
>
> print("I was just loaded under ", cmdarg().getPath())
> print("Good Bye says ", cmdarg().getPath())
>
>
> See $FG_ROOT/Aircraft/Models/bo105.xml for a real world example.
>
> m.
>
Which is right,
but don't forget that we can within JSBSim avoid most of the Nasal code
everything done in the FDM.
For instance, i do use it to get the right (factor) animation with propellers,
the brake chute animated under conditions, and so on everything done
without Nasal.
Nasal animation Probably valuable for YASim but with JSBsim their is an other
way easier.
Regards
--
Gérard
http://pagesperso-orange.fr/GRTux/
<< Less i work, better i go >>
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Melchior FRANZ -- Saturday 08 December 2007: > $FG_ROOT/Aircraft/Models/bo105.xml Bah ... $FG_ROOT/Aircraft/bo105/Models/bo105.xml m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Melchior FRANZ -- Saturday 08 December 2007:
> it was time to add some generic properties for "internal communication".
It's probably also time to remind people again of the possibility to
add Nasal code to model (animation) XML files. This is then only
run when the model is used as as a static scenery model or an MP
model, but not for the instance that you are actively flying on your
machine. Such code can evaluate generic properties and modify them,
and/or move them where they belong. In the MP case, cmdarg() can be
used to access the model's node under /ai/models/. Example:
print("I was just loaded under ", cmdarg().getPath())
print("Good Bye says ", cmdarg().getPath())
See $FG_ROOT/Aircraft/Models/bo105.xml for a real world example.
m.
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* gerard robin -- Saturday 08 December 2007: > I worry that way /sim/multiplay/generic/.. because i thought > that the best way, regarding every surface position was to > include it into the "/surface-positions/foo" property You miss the point, as maybe some others do as well. The generic properties are not meant to be used for standard functions, but for properties that can't be standardized in a meaningful way. The bo105, for example, has an emblem property for the Red Cross symbol. There's no chance that we'll ever have a hard-coded /sim/model/red-cross-emblem property. We'd have to add thousands of such specific, non-standard properties. And for *such* cases we have now a set of generic properties. Standardized properties should still be transmitted under their specific node path. And if some are missing, then we'll add them. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
AnMaster > Sent: 08 December 2007 14:02 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] multiplayer generic properties > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Vivian Meazza wrote: > > Anders has a really neat bit-mask utility which allows the > > transmission of up to 32 bools in one int property - much > neater for > > light switches and the like. > > > > Vivian > > > > P.S. - by tradition we bottom-post on the devel list > > However for those aircrafts that I considered for lights they > were not on/off but had birghtness setting too, check the > A-10 and A-6E for example. > Even better - for that there's nice slow signal interface using TDM - needs a pair of properties, preferably int. Panel light, nav lights, etc etc. In theory unlimited, but about 8 is practical. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
On sam 8 décembre 2007, Vivian Meazza wrote: > AnMaster > > > Sent: 08 December 2007 11:55 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] multiplayer generic properties > > SNIP > > > > Melchior FRANZ wrote: > > > After Maik has clued me up about multiplayer properties -- > > > > that only > > > > > those are transmitted, which actually exist at init time > > > > (which is why > > > > > they need to be defined in the *-set.xml file), it was time to add > > > some generic properties for "internal communication". That is: > > > properties which aren't dedicated to a particular function, > > > > but can be > > > > > used by an aircraft to send data to its mirror instances over MP. > > > > > > There are for now: > > > /sim/multiplay/generic/string[0-9] > > > /sim/multiplay/generic/float[0-9] > > > /sim/multiplay/generic/int[0-9] > > > > > > Of course, this should be used sparingly. If you need to transmit a > > > path, don't transmit the full path, but only the parts that > > > > are really > > SNIP > > transmit these > > > > > "single-shot" properties in every package (, I hope :-). > > > > > > m. > > Anders has a really neat bit-mask utility which allows the transmission of > up to 32 bools in one int property - much neater for light switches and the > like. > > Vivian > > P.S. - by tradition we bottom-post on the devel list > I worry that way /sim/multiplay/generic/.. because i thought that the best way, regarding every surface position was to include it into the "/surface-positions/foo" property ( i had talk some time ago with anmaster on IRC with it ). I should have talked about that feature HERE before every decision. This would have saved time with modifications. Regards -- Gérard http://pagesperso-orange.fr/GRTux/ << Less i work, better i go >> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Vivian Meazza wrote: > Anders has a really neat bit-mask utility which allows the transmission of > up to 32 bools in one int property - much neater for light switches and the > like. > > Vivian > > P.S. - by tradition we bottom-post on the devel list However for those aircrafts that I considered for lights they were not on/off but had birghtness setting too, check the A-10 and A-6E for example. /AnMaster -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWqPaWmK6ng/aMNkRCgkgAJ9sf1F5wLdOkZBk6y6oGvnk5tm3ugCcCx/O fEWQlFrmcLy/OMV1dwuMiP8= =tQJE -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
AnMaster > Sent: 08 December 2007 11:55 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] multiplayer generic properties > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Yes, I already made a patch (see "[Flightgear-devel] Patch > for Harrier: making it's thrust vector work over mp") for the > harrier that makes use of this :) > > And I can think of several other aircrafts that could make > use of this. For example position lights/anti-collision > lights of some aircrafts. Would make formation flying in the > dark over mp simpler. > > Regards, > > Arvid Norlander > > Melchior FRANZ wrote: > > After Maik has clued me up about multiplayer properties -- > that only > > those are transmitted, which actually exist at init time > (which is why > > they need to be defined in the *-set.xml file), it was time to add > > some generic properties for "internal communication". That is: > > properties which aren't dedicated to a particular function, > but can be > > used by an aircraft to send data to its mirror instances over MP. > > > > There are for now: > > /sim/multiplay/generic/string[0-9] > > /sim/multiplay/generic/float[0-9] > > /sim/multiplay/generic/int[0-9] > > > > Of course, this should be used sparingly. If you need to transmit a > > path, don't transmit the full path, but only the parts that > are really > > necessary. For example, the bo105 will only transmit "foo", when it > > actually means "Aircraft/bo105/Models/Variants/foo.xml". > > The prefix and the ".xml" postfix will be stripped. There's > still the > > possibility to transmit "../../foo" if for some reason I > want to refer > > to a file elsewhere. (I didn't add double/long/bool, as > they would be > > transmitted as float/int/int, anyway.) > > > > In one of the next protocol revisions, we won't have to > transmit these > > "single-shot" properties in every package (, I hope :-). > > > > m. Anders has a really neat bit-mask utility which allows the transmission of up to 32 bools in one int property - much neater for light switches and the like. Vivian P.S. - by tradition we bottom-post on the devel list - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* AnMaster -- Saturday 08 December 2007: > Yes, I already made a patch (see "[Flightgear-devel] Patch for > Harrier: making it's thrust vector work over mp") for the harrier > that makes use of this :) Yes, you are quick. This will have to be reviewed and OK'ed by the harrier model maintainer. > And I can think of several other aircrafts that could make use of this. > For example position lights/anti-collision lights of some aircrafts. These are "standard properties", and should therefore not really use the generic ones, though we may yet have to add them. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Yes, I already made a patch (see "[Flightgear-devel] Patch for Harrier: making it's thrust vector work over mp") for the harrier that makes use of this :) And I can think of several other aircrafts that could make use of this. For example position lights/anti-collision lights of some aircrafts. Would make formation flying in the dark over mp simpler. Regards, Arvid Norlander Melchior FRANZ wrote: > After Maik has clued me up about multiplayer properties -- that > only those are transmitted, which actually exist at init time > (which is why they need to be defined in the *-set.xml file), > it was time to add some generic properties for "internal communication". > That is: properties which aren't dedicated to a particular > function, but can be used by an aircraft to send data to its > mirror instances over MP. > > There are for now: > /sim/multiplay/generic/string[0-9] > /sim/multiplay/generic/float[0-9] > /sim/multiplay/generic/int[0-9] > > Of course, this should be used sparingly. If you need to transmit > a path, don't transmit the full path, but only the parts that are > really necessary. For example, the bo105 will only transmit "foo", > when it actually means "Aircraft/bo105/Models/Variants/foo.xml". > The prefix and the ".xml" postfix will be stripped. There's still > the possibility to transmit "../../foo" if for some reason I want > to refer to a file elsewhere. (I didn't add double/long/bool, as > they would be transmitted as float/int/int, anyway.) > > In one of the next protocol revisions, we won't have to transmit > these "single-shot" properties in every package (, I hope :-). > > m. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWoYUWmK6ng/aMNkRChvvAJ4gtFn5qiH9R+AcaL3Uvq/vcxWgRwCfVUNk +n/CrUzFWf2Puqz6mY9ibgI= =yodC -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] multiplayer generic properties
After Maik has clued me up about multiplayer properties -- that only those are transmitted, which actually exist at init time (which is why they need to be defined in the *-set.xml file), it was time to add some generic properties for "internal communication". That is: properties which aren't dedicated to a particular function, but can be used by an aircraft to send data to its mirror instances over MP. There are for now: /sim/multiplay/generic/string[0-9] /sim/multiplay/generic/float[0-9] /sim/multiplay/generic/int[0-9] Of course, this should be used sparingly. If you need to transmit a path, don't transmit the full path, but only the parts that are really necessary. For example, the bo105 will only transmit "foo", when it actually means "Aircraft/bo105/Models/Variants/foo.xml". The prefix and the ".xml" postfix will be stripped. There's still the possibility to transmit "../../foo" if for some reason I want to refer to a file elsewhere. (I didn't add double/long/bool, as they would be transmitted as float/int/int, anyway.) In one of the next protocol revisions, we won't have to transmit these "single-shot" properties in every package (, I hope :-). m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
