News - orbitersoftware Wiki - orbitersoftware

Version 0.8.2 for Orbiter 2016 has been tagged and pushed. This minor version marks the change to Orbiter 2016, animation support and comes with appropriate compatibility changes.

Changes since 0.8.1:

• OMPClient: don’t auto-close interface window on normal clients
• OMPClient: docked objects don’t drift rotate now
• OMPClient: fixed bug with vessels that create things on startup (e.g. Atlantis)
• OMPClient: implemented key “S” empty event sent in order to start status update
• OMPClient: added keyboard handler again including status send ping key “S”
• OMPClient: fix for quick launch in 2016
• OrbiterExtensions: updated to fix 2016 compatibility
• OMPClient: fixed thread-induced jitters with 2016
• OMPClient: fixed fakes after vessel state update
• OrbiterExtensions: updated to fixed record event lib
• OMPClient: removed superfluous animation maps
• OMPClient: removed direct TCP recording transmission
• OMPClient: removed direct UDP event transmission
• OMPClient: send and receive vessel-specific states and animations status
• OMPClient: minor code changes
• OMPClient: fixed tracking duplication
• OMPClient: fixed RK4 algorithm regarding velocity component
• OMPClient: container only show OMPDefault vessels
• VesselHook: fixed CTD with missing HookQueue
• OMPClient: fixed missing offer notification

• Host: disabled automatic zombie kicking for persistence
• User: fixed bug with re-connection STUN clients
• Vessel: implemented double-buffering for vessel-specific state transmission
• Vessel: store and broadcast vessel-specific state information
• Server: removed direct TCP recording transmission
• VisibilityCluster: minor code changes
• Vessel: broadcast vessel states
• Server: removed ORRL info from server configuration templates
• Web: added style settings for web server

• Configuration: change to Azure server address for this release
• Documentation: some more notes
• Packaging: removed ORRL content
• Documentation: updated readme file
• Documentation: added notes on connection issues

Compatibility notes:

• 0.8.2 servers will accept 0.8.x clients and 0.8.2 clients can join 0.8.x servers.
• Despite the server/client compatibility above, be aware that mixing 2010 and 2016 might cause strange visual effects.

With Orbiter 2016 and this release, the docking scenario is now pretty stable. In contrast to the temporary version in the previous post, animation changes are now transmitted on recorder events (e.g. cone, gear, radiator, etc). The new keyboard handler also fixed the missing missile toy key functionality from the previous post, and also adds a new key “S” to transmit out-of-band animation updates. This way, things like RMS in the Shuttle can be propagated to observers, too. So just to remind you, stock key settings are:

• Left Ctrl together with left Alt as modifiers
• “C” to rotate missile target selection
• SPACE to fire missile
• “S” to broadcast vessel states (animation etc.) of the focus vessel

I have patched the Azure server a bit, because that Microsoft cloud apparently ditches open TCP connections after 4 minutes idle time. Now the server-side does a keep-alive every 10 seconds, so it should be no problem anymore. There is also an ISS now on a headless container client.

---

Version 0.8.1 has been tagged and pushed. This minor version is the first step towards persistence, featuring the implementation of the hand-over protocol.

Changes since 0.8:

• OMPClient: getting rid of superfluous oapiGetSimMJD() in get_clock_acceleration
• OMPClient: build up and maintain vessel state snapshots for given MJD
• OMPClient: using snapshots instead of GetStatusEx() and oapiGetSimMJD()
• OMPClient: build up a first snapshot at startup in order to avoid error at server
• OMPClient: update snapshots on default vessel creation
• OMPClient: remove unused struct initialisation
• OMPClient: removed blocking of super structure state vectors
• OMPClient: implemented quick launch feature in preparation for container clients
• OMPClient: implemented quick leave feature in preparation for container clients
• OMPClient: implemented container flag to assign container on startup
• OMPClient: fix MJD syncing to only call Orbiter if acceleration changes
• OMPClient: fixed bug in refactored startup sequence regarding vessel selector
• GroupInformation: removed superfluous target information
• OMPClient: streamlined kill list operation
• OMPClient: implemented acceptance sender reaction
• OMPClient: added infrastructure to move vessel from remote to local domain
• OMPClient: implemented parsing of ACCPT responses in order to move objects

• Server: added container assignment feature
• Server: added offer/accept/hand-over database mechanisms
• Host: don’t send chat messages to containers
• User: re-use removed flag in packet receiver
• User: only send observation group info with offers taken into account
• User: implemented locked local ID guarding
• Map: unroll recursive call in database parsers (no more old clients, anyway)
• Host: don’t allow raw prompts
• Host: made server offer and accept response format deterministic

• Config: reverted earth rotation offset, too
• Settings: using scheme defaults instead of explicit default code
• Settings: added container flag to XML scheme
• Documentation: added TODO list with outlining of hand-over protocol

Compatibility notes:

• 0.8.1 servers will accept 0.8 clients and 0.8.1 clients can join 0.8 servers.
• Be aware that this version also removes the rotation offset of earth, which was a legacy from the days of the non-rotating earth hack. So if you join old servers with your new client (and vice versa), changes are that you are in the wrong position due to that. This is no fundamental incompatibility in the code, though, therefore you can simply change your earth.cfg accordingly.
• The hand-over protocol is mostly server-based, so a new client joining an old server is simply unable to issue the command. However, an old client joining a new server could accept a hand-over offer, which will result in the loss of the object. Similarly, an old client joining a new server offering objects will result in duplication of the object.

In 0.8.1, the state vector transmission based on MJD timestamps introduced in 0.8 was refined by means of a snapshotting mechanism. Instead of getting simulation object states asynchronously in the sending/receiving thread, the system now maintains a synchronized snapshot list, which will be used on transceiving. This should in theory make docking less jumpy, because the consistency of state info wrt. timing info is guaranteed.

In order to get persistence, aka “my vessels stays in orbit while I’m offline”, I’m pursuing the following strategy towards 0.9:

• Administrators could run so called “container” clients, running the OMPClient with a special flag set, so it will react slightly differently to server calls and provides no meaningful user interaction. A good candidate for such a container is orbiter_ng running with no graphics client. It will just be there to run the physics on objects it maintains.
• When clients crash or log-off, the server hands-over the orphaned objects to one or more containers. This way, the object remains in the server’s universe, but maintained by the container instead of the actual client.
• When a client logs in again, the container hands-over the objects again, letting the client continue where he left off.
• With multiple container clients, loss of one container should not result in a total loss of objects.
• With the help of containers, the server can save/load object states, so a server crash or restart should not result in a total loss of objects.

This version comes with 3 flags you can use to alter the behavior of the OMPClient’s startup process: “QuickLaunch”, “QuickLeave” and “Container”, all three of them Boolean. They are optional attributes of the root element in the OMPClient.xml configuration. “QuickLeave” is true by default, reflecting the current behavior of leaving the server (i.e. deleting all objects). In early versions of the software, this was not the case. Instead, you’ve got a dialog giving you the choice of “just” logging-out (and keeping the objects) or leaving completely on shutting down. If you set “QuickLeave” to false, you are back to this behavior. “QuickLaunch” is false by default. If set to true, as soon as the OMPClient module is loaded, a connection is established, the given user is logged-in and a scenario with an OMPDefault vessel right in the sun is loaded. From there you can use the scenario editor and add vessels as usual. “QuickLeave” is forced to true with this, so when you quit the simulation, the system leaves the server and exits Orbiter. While these flags are nice-to-haves, they are probably useless to most users. However, they are stepping stones for the third flag: “Container”. If this flag is set to true (false by default), both “QuickLaunch” and “QuickLeave” are forced, and the system will act as container client instead of a normal client. This flag is implemented, but besides joining the server as declarated container client, nothing else of the above mentioned strategy is implemented ATM. This is where the next versions will expand.

The foundation for the strategy – the hand-over protocol – has been implemented already, and goes like this:

• the sending user issues “\offer ” in the chat-window, with being the global ID of the vessel he wants to offer to , with being the name of the receiving user. Similar to trackings and observations, “\offer” alone will list all running offers and “\offer off” will retract them.
• the receiving user issues “\accept ” in the chat-window, with being the global ID of the vessel which was offered to him, and being the local ID it wants to use. Unfortunately, this later ID is not automated right now, but easily calculated: just count the number of vessels you have currently and use that number. If it fails, add 10. The algorithm re-uses skipped numbers, anyway. Again, similar to trackings and observations, “\accept” alone will list all available acceptable offers.
• once the receiving user accepted the transfer, the remote vessel on his side will be deleted, and a new local vessel with the name and real class of the hand-over object will be created. Afterwards the receiving user can control the vessel as usual.
• the sending user’s vessel will be deleted and replaced by the remote representation of it.

If it pans out, the same protocol will be used in the future to hand-over vessels from crashing/logging-off clients to containers and back again, just server-triggered.