Chris

And obviously @cgspeck has created another application for this feature which he explained in the first post of this ticket. @bcoconni incorrect. Using this protocol for multi-compute Flightgear preceeds my interest in the matter. Why don't you just use the custom protocol definition feature? With next you can specify the path to them on startup. That way you don't need to make any further changes to Flightgear nor external JSBSim, and you can lock down the protocol that you need.

Tests pass, thank you for accepting my PR :-) You can mark this ticket as Done.

Hi, thanks for the reminder! It's almost midnight where I am, I can check this tomorrow and get back to you.

About the generic protocol, we do need a seperate discussion (on the developer list), but I would observe that it will only improve if you (or someone like you) steps up to do the work: there is no magical development team that would jump in and work on that. So I'd suggest, if you care about this kind of multi-compute (and I'd also want a discusison about different styles of multi-compute, since this one is the most complex/awkward to support...), then it's on you to decide what protocol(s) you...

I understand the slippery slope argument but it does not apply in this case because this change is about fixing already present broken behaviour. Native FDM already transmits fuel information, but not in a way that is usable by recieving Flight Gear instances as demonstrated. I don't understand why you think using the generic protocol would be brittle or difficult A couple problems with it, from an outsider's perspective: a) it is difficult to determine which nodes should be transmitted - some appear...

Hi James, This is not about adding properties to the Native FDM protocol but rather fixing what's already there. The protocol already transmits "level-gal_us" however this is not sufficient to transmit fuel state to a secondary instance or satisfy the use cases here: http://wiki.flightgear.org/Howto:Multi-computing_FlightGear http://wiki.flightgear.org/Slaving_for_Dummies https://www.inkdrop.net/dave/multimon.pdf My attempt in May to have this addressed by the aircraft model failed and eventually...

Hi James, This is not about adding properties to the Native FDM protocol but rather fixing what's already there. The protocol already transmits "level-gal_us" however this is not sufficient to transmit fuel state to a secondary instance or satisfy the use cases here: http://wiki.flightgear.org/Howto:Multi-computing_FlightGear http://wiki.flightgear.org/Slaving_for_Dummies https://www.inkdrop.net/dave/multimon.pdf My attempt in May to have this addressed by the aircraft model failed and eventually...

Related ticket