Black Phoenix
New member
In my view the X-Plane flight simulator has a great potential to become a true aerospace simulator: it already calculates physics (not talking about their realism though) for arbitrary aircraft at subsonic and supersonic speeds, but it had some issues with space flight.
For example the integration was not correct, and the error grew as you would travel faster and faster (for orbital velocity the error was as high as 1 m/s error in velocity per 1 revolution around planet). Plus it was lacking some graphical and misc physics points.
Anyway, what does this have to do with Orbiter? X-Plane networking is very lacking, only works in LAN (and not very well), and of course the networking falls apart in orbit. I'm creating a plugin for X-Plane which fixes all those physics problems, graphics issues, and also adds networking support to X-Plane, including networking while on orbit.
So I found out that Orbiter API is pretty allowing, and already made this plugin (core parts of it) start up under Orbiter. The goal here - provide networking for low-speed and high-speed flight (orbital flight). As a bonus it also gives compatibility with X-Plane.
It's still a WIP, but so far it does synchronize the low-speed part (more details below).
Features (only ones making sense for the Orbiter version):
Specifics (some things work in an unusual way):
A bit of information on how it works:
The server generates a fixed amount of "frames" per second. During each frame it sends entire world state, delta-compressed, to clients (simple words: it sends to clients only bits that have changed).
Each vessel has a "state vector", out of which a limited number of variables is synchronized at the same time. State variables are:
CXCYCZ are double precision, all other variables are single precision.
During initial minute or so client will synchronize their internal clock with server (typically to precision of about 10-50 msec).
During low-speed flight the state is synchronized as described before, when client receives new frame the state vector is extrapolated (based on known timestamp of this state vector), and then weighted-averaged with "visible" state vector (the one that's used to draw objects).
During high-speed flight the physics are switched over to server. The server calculates physics for all vessels, and positions of all other vessels are synchronized relatively to client (at least for the vessels in close range).
During this mode clients send a "log" of all forces which have acted on the vessel, along with timestamps (server will apply this forces in correct order, and with correct duration, BUT it does not correct for lag when doing so. The forces are presumed to be very small, from some sort of vernier RCS).
That's the general idea right now. The low-speed part is implemented (in X-Plane version, what's left to Orbiter see below), and parts of high-speed flight are implemented (it can integrate vessels on orbit, but it just ignores this data since no force "log" is yet sent).
Assumptions:
The project is open-source (I did not upload the source for newer thing yet though, I'll just post link here when I do). Problems that are left to be solved for orbiter version of the plugin: making meshes and drawing them, reading/writing list of vessels (it only does it for focused vessel right now), GUI (uses X-Plane GUI API, but is not very hard to remake interface to Windows API), reading vessel scripts somehow (or generating scripts based on thruster groups or whatever is used in Orbiter).
For example the integration was not correct, and the error grew as you would travel faster and faster (for orbital velocity the error was as high as 1 m/s error in velocity per 1 revolution around planet). Plus it was lacking some graphical and misc physics points.
Anyway, what does this have to do with Orbiter? X-Plane networking is very lacking, only works in LAN (and not very well), and of course the networking falls apart in orbit. I'm creating a plugin for X-Plane which fixes all those physics problems, graphics issues, and also adds networking support to X-Plane, including networking while on orbit.
So I found out that Orbiter API is pretty allowing, and already made this plugin (core parts of it) start up under Orbiter. The goal here - provide networking for low-speed and high-speed flight (orbital flight). As a bonus it also gives compatibility with X-Plane.
It's still a WIP, but so far it does synchronize the low-speed part (more details below).
Features (only ones making sense for the Orbiter version):
- Precision low-speed flight (precision in other aircraft coordinates is a priority over their trajectories)
- Adequate high-speed flight (other aircraft/spacecraft positions are visually correct, but not precise anymore)
- Support for 30 vessels in orbit (planned to be extended to 500 in later versions. This number comes from CPU limit, not bandwidth)
- Support for joined vessels (two vessels which are mechanically tied together, for example docked or simply rocket stages still attached)
- Optional write protection (requires an unique key/hash for every spacecraft that will be recorded on server)
- Models (meshes) are stored server-side, and are downloaded to all clients
Specifics (some things work in an unusual way):
- In early versions flight is limited to low Earth orbit (X-Plane limitation, there's no way to go further away)
- Uses custom physics engine (in some cases) which kinda ignores Orbiter physics settings right now
- Synchronizes all vessels which are not "networked". If every player loads scenario with an ISS, assuming that ISS has a networked model defined, there will be several ISS's in the orbit (one for each player).
- Uses UDP for networking
- Simulation only runs in realtime
- Time is driven by server
A bit of information on how it works:
The server generates a fixed amount of "frames" per second. During each frame it sends entire world state, delta-compressed, to clients (simple words: it sends to clients only bits that have changed).
Each vessel has a "state vector", out of which a limited number of variables is synchronized at the same time. State variables are:
- X, Y, Z (coordinates in non-inertial coordinate system, relative to
Earthnearest celestial body, but for now only Earth, also relative to CX, CY, CZ) - VX, VY, VZ (non-inertial velocity in same coordinate system)
- AX, AY, AZ (non-inertial acceleration)
- q (quaternion defining orientation)
- P, Q, R (angular velocities)
- CX, CY, CZ (relative offset for X, Y, Z coordinates)
- Custom variables (defined by spacecraft)
- Timestamp for this state vector
CXCYCZ are double precision, all other variables are single precision.
During initial minute or so client will synchronize their internal clock with server (typically to precision of about 10-50 msec).
During low-speed flight the state is synchronized as described before, when client receives new frame the state vector is extrapolated (based on known timestamp of this state vector), and then weighted-averaged with "visible" state vector (the one that's used to draw objects).
During high-speed flight the physics are switched over to server. The server calculates physics for all vessels, and positions of all other vessels are synchronized relatively to client (at least for the vessels in close range).
During this mode clients send a "log" of all forces which have acted on the vessel, along with timestamps (server will apply this forces in correct order, and with correct duration, BUT it does not correct for lag when doing so. The forces are presumed to be very small, from some sort of vernier RCS).
That's the general idea right now. The low-speed part is implemented (in X-Plane version, what's left to Orbiter see below), and parts of high-speed flight are implemented (it can integrate vessels on orbit, but it just ignores this data since no force "log" is yet sent).
Assumptions:
- When two vessels are close, there are only long-term forces (gravity) and short-term forces (RCS) acting on them
- Desired precision in position during high-speed approach (aka docking) is +- 0 meters
- Desired precision in velocity is +-0.1 m/sec (would be better to talk about acceleration though)
- Velocity change (linear, angular) from short-term forces is less or equal to desired precision in velocity
- During high-speed flight the trajectory is weakly influenced by aerodynamics (not a correct assumption, but will have to do for now)
The project is open-source (I did not upload the source for newer thing yet though, I'll just post link here when I do). Problems that are left to be solved for orbiter version of the plugin: making meshes and drawing them, reading/writing list of vessels (it only does it for focused vessel right now), GUI (uses X-Plane GUI API, but is not very hard to remake interface to Windows API), reading vessel scripts somehow (or generating scripts based on thruster groups or whatever is used in Orbiter).
