by tdammers » Mon Apr 23, 2018 3:51 pm
Jomo; I just read the thread you linked on thejabberwocky, and I think that the way you think things work is almost, but not quite, correct.
You are right about how models are loaded from whatever is installed on either side: if the MP protocol says I'm flying a "777-200ER", then your FG instance will look at the Aircraft directories on your computer and try to find a model named "777-200ER". So far, so good.
The next important thing here is the "property tree": this is a tree-shaped data structure that reflects the entire state of an aircraft in the simulation - position, speed, type, systems, failures, control surfaces, engine state, everything. The property tree can be inspected (and even modified) inside FG under "Debug > Browse Internal Properties", and also somewhere in the Phi web interface.
Among other things, the property tree is used to position and animate the aircraft model - for example, there may be a property "/surface-positions/elevator", containing a deflection angle in degrees, and the aircraft model might then be rigged to rotate the submodel (aircraft part) called "elevator" by that amount. All this is defined in the aircraft definition, typical somewhere in a file called Models/{aircraft-name}.xml. This system is extremely flexible; it doesn't only rotate submodels, but it can also show/hide aircraft parts, change texts, change texture positions, turn lights on and off, illuminate things, etc. etc.
Landing gear is pretty much always done this way: the current gear position (as calculated by the FDM) is stored somewhere in the property tree (IIRC it's something like "/gear/gear[n]/position" or sth like that), and the model animation picks up that property and changes the position and rotation of the landing gear and landing gear covers.
The DHC-6 nose (blunt or stretched) is done the same way, except that the property is not set by the FDM, but based on the selected livery. If you load up the DHC-6, and change the "/sim/model/blunt-nose" property in the property browser, you will see that the model's nose changes shape on the fly.
Now, the problem with multiplayer is that in order to show an aircraft properly, you need the correct values for all the properties that influence animations; and those properties need to be sent over the network, otherwise you won't know the correct values for someone else's aircraft. Problem is, you can't just send the entire property tree, because that would require way too much network bandwidth. A full property tree can have hundreds, if not thousands, of individual values, and sending them all would require sending several megabytes per frame (!) over the network - with, say, 20 other aircraft in sight, and 30 FPS, that's an entire CD-ROM worth of data to be exchanged every second. That is simply not going to work. But since the system is so flexible, it is impossible to tell in an automated fashion which properties are relevant - there is a handful of them that you always need, like position and velocity, and those are standardized, but everything else is up to the aircraft author. Each aircraft defines a list of additional properties to send over the network, mapping spots in the property tree to spots in the multiplayer protocol message. E.g., you could define that your aircraft puts "current gear extension status" for the 3 sets of gears in properties 5 through 7. As long as those mappings match on both sides, everything works out great: the controlling pilot's FG instance sends the selected properties, and the observer's FG instance reads them, reconstructs the property tree from them, and animates the model.
Trouble starts when this goes wrong: when a needed property doesn't end up in the right spot, the animation won't run, or it will run incorrectly. For example, if the gear extension status property isn't there, then the landing gear will be displayed in the default position, which is typically "retracted"; and if the DHC-6's blunt-nose property isn't there, then no nose will be shown at all (I checked this, it is actually what the aircraft definition says).
But there are several reasons why and how things can go wrong:
- Incompatible aircraft. If the aircraft definitions on both sides use different properties for, say, gear extension status, then the animation will look at the wrong property, not find it, and thus fail to display the landing gear. Or if the property does get sent, but in a different slot of the MP protocol message, then the other end will not read it back out into the right property, and the same thing will happen.
- Buggy aircraft. If the aircraft simply doesn't send the property at all, then there is no way to get it back out. Likewise, if the aircraft definition on the receiving side doesn't define an MP mapping for the property, then it won't be received either.
- Transmission problems. I don't know the specifics here, but AFAIK, it is possible for MP protocol messages to get truncated. This could, in theory at least, lead to some properties at the end of the message not being transmitted. I don't know if this can actually happen though, and if so, under what circumstances.
- Incompatible FG versions. And this, I think is a hot lead (I will explain in a second why I think that). If the FG versions on both sides are different, and the receiving end doesn't fully understand what the sender is sending, then it may not be able to get all the properties that have been transmitted. And we get the same problem again: property missing, aircraft model animations defaulting or doing weird things.
So why do I suspect the FG version? Well, several clues:
1. The way the DHC-6 nose works hasn't been changed in years; I went back in history to 2015, long before the past few FGDATA releases. There have been no changes to how the nose works since, and since I've flown the exact same DHC-6 before without issue (several movies confirm this), a sudden change in the aircraft itself cannot be causing this.
2. The nose showed up fine within the same MP session later, on someone else's computer (I met FlyAndi shortly after departing from EDDF and asked to confirm that my nose was present).
3. I am running a fairly new FG version (2018.2) that I built from source, and IIRC there has been some work on the MP protocol since.
So in order to troubleshoot this, it would be very helpful if we could compare FG versions; then I could dig into the history and see if I can find anything that hints at a change in FG itself that could cause this. Either way, I am pretty convinced that it's *not* an incompatibility between the installed aircraft models.