Open vranki opened 4 years ago
As far as I understand the UDP interface does accommodate updates and commands, does it?
Btw, congratulations on such a nice job!
UDP interface can't do everything that can be done with plugin API but it's quite powerful: http://www.nuclearprojects.com/xplane/xplaneref.html
In my case I use ExtPlane primarily for controlling LED's and switches. Since UDP is an unreliable protocol, I would have to constantly send the position of all switches, and that feels as a waste of bandwidth. Furthermore, I don't know how efficient X-Plane handles setting stuff to the same value, so I prefer to set only on change. For controlling the Zibo I need to access its custom datarefs and commands anyway, so the standard X-Plane UDP is not sufficient for me anyway.
I wouldn't worry about UDP's bandwidth or reliability. Today's gigabit switches are so fast that you can resend everything at fast refresh rate. Let's say 10-20Hz for lights and switches should be enough. For "realtime" instruments like artificial horizon you want to send at 60Hz. Normally networks shouldn't have any packet loss but you can send changed values several times to be sure.
UDP interface can't do everything that can be done with plugin API but it's quite powerful: http://www.nuclearprojects.com/xplane/xplaneref.html
This is pretty outdated. The most recent information can be found in the X-Plane directory under 'Instructions/X-Plane SPECS from Austin/Exchanging Data with X-Plane.rtfd/TXT.rtf'
X-Planes' native UDP interface is quite powerful in terms of performance and resources but lacks some very important functionalities: commands can only be called "once" which means all three phases (begin, run, end) are called right after another and strings (char arrays) can only be send with one character per message, which are always 509 byte long. I use the interface to connect to my External Visuals, as the build-in X-Plane function (based on RakNet) does client-side extrapolation which isn't really usable in a projection setup with overlapping images: two instances never extrapolate to the same position so that the images doesn't fit in the blending zone. I send VEHX commands to update the position and additional datarefs like time-of-day and weather to keep the other visual features in sync. I am just about to put the position updates in a separate thread in order to do server side extrapolation to avoid stutter. To send the commands I use my own fork of the libXPlane-UDP-Client.
Currently I seem to be practically the only developer for ExtPlane. It's still a popular piece of software, but I don't have time for developing it.
I'm currently employed as a professional simulator developer doing X-Plane stuff for work so there is very little motivation to do the same on my free time. Also X-Plane 11 UDP interface is often better solution than ExtPlane for accessing datarefs.
If you use ExtPlane and are a c++ developer, don't be afraid to check the existing issues and try to fix them. Github write access will be given quite easily.