So I did some more digging, and found that the latest version of the DHC-6 causes FG 2018 to dump warnings to the console:
- Code: Select all
Multiplayer packet truncated prop id: 11990: sim/multiplay/mp-clock-mode
Hmm, curious. So I went in and looked for that message in the codebase. I also tested several Twin Otters to see which one started causing these errors. And here's what I found.
- Up until (and including) FGDATA version 2016.1, the Twin Otter sent a total of 76 properties, 17 of them in the "generic" subtree that also contains the blunt nose one.
- Starting with 2016.2, the total number of properties sent increases to 98, 40 of them "generic".
- There are two versions of the multiplayer protocol in current use, 1.0 and 1.2. The 1.0 version has a hard limit on the maximum packet size, and any properties that you try to send beyond that limit are dropped. The 1.2 version is a backwards-compatible extension; it sends the first packet just like 1.0, but then it puts additional properties into as many additional packets as it needs, tagging those packets with a "magic" value that causes 1.0 clients to ignore the packet, while 1.2 clients will read the additional properties. As a result, clients capable of processing the full 1.2 protocol will receive all the properties, while older clients will only get the properties that fit in the first packet.
- The order of user-defined properties is "strings, floats, integers". Unfortunately, the blunt-nose property is an integer, so it is very likely to end up in the second packet.
So if we put all this together, it is fairly clear what's happening:
- The old (2016.1 and earlier) Twin Otter, as shipped with my old machine's FG installation, works fine across everything, because everything fits into one packet.
- The new (2016.2 and later) Twin Otter works fine as long as both clients support the 1.2 protocol, but if the recipient only supports 1.0, then the second packet, the one that contains the blunt-nose property, will not be seen, and the nose will not appear.
If this is the case, then that would mean that the "Jomo FG" is a version that supports only the 1.0 protocol, while both my machines support 1.2.
We can easily verify this; if you visit EDDF now, my DHC-6 parked at V174 is now the most recent version, but with nearly all custom properties removed from the MP property list. You won't be able to see the chocks, tie-downs, control surface positions, etc., and the doors won't open; but the nose should be there. Happy to hear from anyone how that works out.
This is not a proper fix of course, because we really do want all those things to also work.
The proper fix would be:
1. Upgrade all clients to an FG version that supports the new MP protocol (not sure which one that is though).
2. Fix the DHC-6 model such that when the property is missing, it will default to the blunt nose instead of no nose at all.
I will come up with a commit for #2 on my github repo ASAP, it's not difficult.