Ascension Ultra (Misc) | 2019-10-29 22:27 |
COIClient (1.1.0) | 2019-10-30 23:42 |
UMMUFB (1.0) | 2009-08-18 23:12 |
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:
Compatibility notes:
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:
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:
Compatibility notes:
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:
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:
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.