Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More developers needed! #67

Open
vranki opened this issue Jun 6, 2020 · 5 comments
Open

More developers needed! #67

vranki opened this issue Jun 6, 2020 · 5 comments

Comments

@vranki
Copy link
Owner

vranki commented Jun 6, 2020

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.

@Djeez2
Copy link

Djeez2 commented Jun 6, 2020

As far as I understand the UDP interface does accommodate updates and commands, does it?

Btw, congratulations on such a nice job!

@vranki
Copy link
Owner Author

vranki commented Jun 6, 2020

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

@Djeez2
Copy link

Djeez2 commented Jun 6, 2020

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.

@vranki
Copy link
Owner Author

vranki commented Jun 6, 2020

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.

@HellGL
Copy link

HellGL commented Dec 8, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants