#164 Making MP a true subsystem broke surface position updates

[Anonymous]

Originally created by: zakalawe@mac.com
Originally owned by: zakalawe@mac.com

(from jano)

from commit d39841d in flightgear, the surface positions are not sent anymore.
the properties in ai/models/multiplayer[i]/surface-positions/ have a  value of : "(none).
that still works  with players using older fg version. if you want to quickly test this just use 127.0.0.1 as  output server address, you will see yourself and the mp-you in the same time.

[Anonymous]

Originally posted by: zakalawe@mac.com

There's a work-around to make the props explicit in the -set.xml file, but that clearly sucks. I'll work on making the MP code independent of startup order.

[Anonymous]

Originally posted by: zakalawe@mac.com

Here's the named commit: http://gitorious.org/fg/flightgear/commit/d39841d2dfdf82e1d590ab331888e3a392d199c6

jano, are you sure it wasn't the following commit that broke this? I.e
http://gitorious.org/fg/flightgear/commit/0c342308eb73079724befab0a9e93bcdf7b06244

[Anonymous]

Originally posted by: zakalawe@mac.com

Analysis: this is horrible.

Deeper analysis: this is occurring because the actual dependency is between the aircraft *model* code and the MP protocol implementation. The FDM can't be involved, since it's not created until much later. Ideally the FDM shell would initialise the standard properties earlier, but that's a high risk change since the FDMs subclass FGInterface, and we can't safely init/bind them early.

What has been happening, I believe, is that we've been initialising the aircraft model before the MP protocol, and hence creating lots of 'output' properties at that time - for surface position and so on. Naturally there's a good correspondence between properties the MP layer sends, and properties the model code might use.

[Anonymous]

Originally posted by: jean.pellotier@wanadoo.fr

just to confirm that was d39841d the fist commit to introduce the bug, but i think you saw it yourself.

jano

[Anonymous]

Originally posted by: zakalawe@mac.com

Should be fixed by: http://gitorious.org/fg/flightgear/commit/6251814604a2395d66dc28fbe0cde8ce99e7be2c

I've changed the strategy completely, to use a property-listener to watch for properties being created, and re-scan the MPproperty list in that case. (Before anyone worries about the performance impact, we re-scan lazily right before doing the actual send)

This seems to work great for me, and the MP system is a bit more independent from others - yay! This approach is finding quite a few properties the old logic was missing - so this may fix some long-standing issues with some MP props not being sent. (I'm not sure if we have bugs like that)

Jano and others, please update and let me know if this fixes things for you, or breaks anything else. As always with MP, the wider the testing the better.

Cc: and...@gidenstam.org
Status: Fixed

[Anonymous]

Originally posted by: jean.pellotier@wanadoo.fr

the surfaces positions works now with the c172p, but it's seems the position itself is not as precise as before, the mp model and the original used to be perfectly in sync when parked, (using 127.0.0.1 as server address) and now they have a little difference in position, something like float/double ?

jano

[Anonymous]

Originally posted by: zakalawe@mac.com

Just to be clear, is this 'visually' different or 'numerically' different? There's probably a one frame latency, because the MP 'receive' code is run before the protocol 'send' code, but the only case this would matter is your loopback test, I think.

(I'll verify the update() ordering of the pieces, but I am pretty sure this is what the answer will be)

[Anonymous]

Originally posted by: jean.pellotier@wanadoo.fr

forget that, it was the same before the fix, i think i noticed this because i started in CYCP (canada) this time, with a longitude of -119, instead of the 5 i have in france when i start fg usually.

btw that's not a frame question, as the plane is parked and the position properties don't change.

to conclude, the fix is good to me, surface positions are working nice, thanks.

jano

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

(No comment was entered for this change.)

Status: Temp

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

(No comment was entered for this change.)

Status: Fixed