F14B, copilot mode, I do not see the thanker

[abassign]

The pilot is making supply, I am co-pilot, but I do not see the thanker. This is a real disappointment, I wanted to take pictures
How fix this problem?

Version FGFS: 3.5
F14B JSBSim back-seater

[Hooray]

if you are talking about the "dual pilot" mode, that is using multiplayer - while the tanker is using the AI system, whose state isn't normally propagated across MP, which is why client-side AI scenarios etc don't show up for other MP users.
It would be possible to work around these restrictions using a bit of Nasal coding - but in general, those features are not designed to work together, which is a common issue among many FlightGear featurees lacking integration.

The easiest way to "fix" this would be running the same tanker scenario locally, while getting rid of any randomness.
The other option would be modifying the tanker.nas script to support a master/slave mode, where one fgfs client provides the control logic for the tanker, while others would merely replicate that state using the data from the master instance.

[abassign]

It seems clear that we must synchronize, through UDP, the tree structure of the property: "/ to / models / tanker," where are the information to support sending via UDP? I noticed that UDP fits the id for the substructures of the tree of the property, this is certainly a problem It would have been better to introduce a compression protocol, such as through a table, which initially provide a temporary id that matching with the dynamic structure of the tree, creating a "dictionary", then, after the master can send values to the slaves ... otherwise we will have just a lot of problems for maintenance ?
For example:
Start UDP Create Dictionary: <0><tree structure><id><value> .... <check-sum>
After UDP send only this prams: <id><value> .... <check-sum>
The <0> id means the UDP protocol send the the create dictionary function, in this way is possible to send all tree values linked to the structure. If the value don't change is possible non send the data to reduce the throughput...
But normally I prefer to create the id through a function md5 (8 bytes?), So that it can build on the client id the right, in this case it is possible to remove the frist phase ... I often used this method to systems data storage hash. The collision probability for md5 8 byte is 1/5,411,658,792 ... Normally, the checksum calculation is done with a short code md5 2 characters for example ... In this case only every 256 errors I can not realize that the individual is not correct, and then I can hold awaiting the next posting.

What do you think of this Client-Server strategy Sync ?

[Hooray]

the "dictionary" approach you mentioned is already being used by the MP protocol, implemented as a lookup table with integers and properties (key/value mapping).
What seems "clear" to you is not necessarily the right/best approach though - while you could do that (as per README.IO and README.protocol) it would make much more sense to use the mp_broadcast.nas mechanism instead, which uses generic properties to encode arbitrary message channels.
However, pub/sub is not currently supported - so would need to be explicitly modeled onto your channel.

If you are interested in working on this, I'd suggest to get in touch with Red Leader to work out the details - but for that, you will undoubtedly want to review existing code using mp_broadcast.nas and look at the module itself. Once you understand how to create your own message channels, you could use those to also propagate certain /ai or /models state explicitly across MP clients, which would also be an interesting feature for the bombable addon.

[abassign]

@hooray, what do you think to use OpenRti ? The information transport by UDP is defined in this library or is an external implemention ?

[Hooray]

There already is an existing RTI/HLA based replacement for the existing fgms-based protocol - however, it hasn't been maintained in years, and it is certainly quite a bit more involved than simply using generic properties and creating "data channels" on top of those - we have existing code doing that, and it would be a working workaround for all people on MP. RTI/HLA however is a different matter, simply because we don't currently have any official RTI-based multiplayer infrastructure at all.
Technically, it would be the "most correct" approach - but it would definitely involve tons of complex topics, and you would inevitably have to touch the C++ code - probably not just in FG, but also in SimGear - and quite possibly in OpenRTI, too.

Like I said, for the time being, HLA/RTI are no even being used for MP purposes - so even if you were to come up with a solid implementation, it would only be of use to people explicitly using your patches.
Which is why I believe it to be much easier to simply patch ai.nas (or tanker.nas) to separate the visualization of the model from position computations, and using the latter to selectively propagate such state to relevant fgfs clients - no matter if those are MP clients, or instances in a master/save setup (think LinuxTag/FSWeekend).

Then again, the whole "dictionary approach" you outlined would be unnecessary with HLA/RTI, because there's even better/more efficient code in place for much more complex requirements