Shouldn't we read last 4 bytes from the UDP messages?

[wortelus]

Hi, wortelus here again

I ended up in a situation, where this line of code incorrectly read '0,0' on line 545 of
value = unpack('<f', rrefdata[9:13])[0]
the line is not always 13 bytes long.

The messages are either 13, 21 or 29 bytes long as far as I have seen. Is there something in the protocol I am missing?

Sometimes, the udp communication starts and receives only 13 byte messages, but I am seeing sometimes the 21/29 byte ones
and it breaks the program. Restarting it usually solves the problem, but sometimes it appears again.

Example:
The received message is here 21 bytes long. And as you can see in the watches, the solution of
unpack('<f', rrefdata[-4:])[0] displays the correct position of the knob (5.0) in the sim

Using X-Plane 11.51

[wortelus]

It seems to happen and then never stop until relaunch. For some reason during normal operation it doesn't happen that much, but if I actually run this using debugger it seems to increase its chances to switch to the 21/29 messages. Maybe some kind of buffer overloading?

It could almost seem like the messages send more datarefs per message, although the [-4:] fix magically reads the correct values, even though it is most probably a coincidence.

[wortelus]

This behaviour is caused by X-Plane's choice of sending multiple datarefs in the same packet: https://xppython3.readthedocs.io/en/latest/development/udp/rref.html#multiple-results-in-same-packet

I shall get to fix this in the upcoming times. Until then, I at least link the cause from the xppython3 docs.

wortelus