Project Community based station construction and stationkeeping

[Majid]

Download link for latest snapshot:
http://orbiter.world/orbiter.online.zip

Extract in root Orbiter directory, then activate the 3 included modules: clientpersister, serverpersister, mjdcontroller and you should be set.

What's currently supported :

1. Docking
2. Atmospheric flight
3. Persistence
4. Missiles (Combat MFD)

I have added a combat MFD and missiles to help find bugs. Persistence is working well, with the caveat that currently there is no persistent "docking list" so discrepancies can occur. When leaving the sim, undock/redock your vessels.. This is a pain in the ass limitation that'll soon hopefully go away.


Hey guys. I have been working on a multiplayer-like collaborative mission add-on. The goal isn't real-time multiplayer, but rather to provide a persistent world and ways for players to collaborate with one another.

1. Oxygen, propellant and ships are the three primary resources players are concerned about. All players start off in a Deltaglider. They can purchase additional ships with credits, the price of which are computed using a totally arbitrary scheme that relies on the mass, thrust, size, etc to compute the price. The amount of oxygen and propellant a player's ship(s) has is controlled by the server. I would have liked to use Ummu and UCGO for Oxygen modeling but I think that decision will bite me in the ass later on. There is no easy way to integrate with those add-ons, they weren't designed with this in mind.

2. Payload management is done via Kulch's wonderful universal cargo deck add-on, because it handles all the physics for you. Sacrificing realism for playability, the idea here is that you are only constrained by your ship's thrust.

3. I know people have in the past collaboratively built space stations by doing missions and sharing scenarios. A persistent world streamlines this process greatly.

4. Get from point A to B quicker than other person type races.

5. Missions. People will inevitably strand themselves in deep space hopelessly lost. They'd be able to issue SOS calls that can be received and handled by players for credits. Refueling missions, transportation missions, etc. Because the world is persistent, the interface largely facilitates the transaction between players, but it is agnostic of the actual dealings. So for example, orbinauts would be able to negotiate deals like launching a module for either a flat fee or percent stake in all the profits from the station. If a party fails to comply, the other party can open a ticket much like it's done on PayPal/amazon/ebay and the final outcome would be decided by the world's admins/council/etc.

6. Achievements. Tracking the total distance traveled by each ship, the number of missions and complexity of each mission, crossing the 100 km mark for the first time, being supersonic for the first time, etc, with a rank going from newbie to master orbinaut. I plan on having a little link that people can post in their signature in the orbiter-forum that'd display their stats.

7. Mission planning. Even doing LEO/local space stuff requires planning and careful execution. I think in Orbiter things appear to be so easy because we can time accelerate whenever we want and compensate for lack of planning by hitting T and doing another burn with massive engines and endless supply of fuel. Because players can only fly ships they own (unless on a mission) and because they lose the ships they destroy, players will be motivated to use mission planners to plan their missions lest they find themselves in the middle of nowhere. I am guilty of this. If I could, I would bring up my mission planner MFD, plan my mission and have my plan sent over to be looked at/annotated/approved by an expert, and that's precisely what'll happen here.

I am looking for ideas specifically about collaborative station management. Collaboratively building the station is easy. Each person involved launches the module and the persistent world syncs the vessels and their positions across all clients, so no need to share scenarios.

What I need help with is, what to do once the station is built? You can have one person in charge of the oxygen on board and the food (which is consumed according to the number of crew on board, also a server side variable). Since most stations will likely be built as orbital fueling stations, another person could be responsible for making sure that the fuel reservoirs are full. I believe there are regulations about when and how spacecraft can rendezvous and dock with one another, so one person could perhaps be responsible for approving or rejecting docking requests. Since this is all real-time, the request to dock could be transmitted to the "Docking Officer" onboard the station via his/her cell phone via an email notification (opt-in and optional). The docking officer would fire up orbiter and will be presented with the scenario containing the approaching ship. The officer could then based on the situation approve or reject the docking request in game, which will be transmitted to the approaching player.

I am looking for other ideas along this line. I don't know what real astronauts on the ISS do.. I think doing a full blown systems emulation would be totally out of scope. But given the persistent world described here, what could some duties be of the crew of stations? At the time the station is "registered" with the world, the player can do an EVA and indicate specific parts/regions and label them. Given that, we could do some generic damage modeling and maintenance of sub-systems. Implementing it is easy, but the devil (and fun) is in the details.

 

[Face]

How do you plan on dealing with time-acceleration? I know you dropped a "since this is all real-time" in there, but it was never stated explicitly.

AFAIK, all the past station-building community projects were serialized by means of handing over scenario-files from one player to the other. This way, time-acceleration as normal Orbiter game-play was no problem at all.

However, as soon as you allow parallel state-changing actions in a persistent and common universe, you have to think about the time-acceleration problem and how it influences Orbiter game-play if not allowed. If you allow it, you open up a can of worms, as described in these old multiplayer threads.

I don't think that there is a real need for massively parallel operations at the beginning, so I would suggest to operate like the old station building projects at first, just automated and server-managed. In other word:

1. Have a server holding the universe state.
2. Users can announce a mission profile (either via simple posts or more formal server dialogs). This can be in parallel.
3. Either an administrator or an automated server-side process decides what user gets a ticket first. This user can now use the server universe and manipulate it (via mission flying - what to do about cheaters is another story). Once ready, he closes the ticket. Now the universe state has advanced.
4. Again either a person or an algorithm decide what mission profiles in the queue are still valid or need to be redefined (because the state of the universe has changed!). If the queue has still something in it, repeat at 3. In the mean-time, people can always do 2.
5. You could allow users to download scenarios of the current universe state at every point in time, e.g. for practicing purposes, but you can't allow their "results" to be "commited" to the universe.

If we see the above state-changing actions as commits in a version control system, we can also see that a parallel system might be possible, if a sufficient merging-algorithm can be applied. But I think for a first cut this would be too complicated, so better keep it serialized and "branch"-free at first.

 

[Majid]

How do you plan on dealing with time-acceleration? I know you dropped a "since this is all real-time" in there, but it was never stated explicitly.

AFAIK, all the past station-building community projects were serialized by means of handing over scenario-files from one player to the other. This way, time-acceleration as normal Orbiter game-play was no problem at all.

However, as soon as you allow parallel state-changing actions in a persistent and common universe, you have to think about the time-acceleration problem and how it influences Orbiter game-play if not allowed. If you allow it, you open up a can of worms, as described in these old multiplayer threads.

I don't think that there is a real need for massively parallel operations at the beginning, so I would suggest to operate like the old station building projects at first, just automated and server-managed. In other word:

1. Have a server holding the universe state.
2. Users can announce a mission profile (either via simple posts or more formal server dialogs). This can be in parallel.
3. Either an administrator or an automated server-side process decides what user gets a ticket first. This user can now use the server universe and manipulate it (via mission flying - what to do about cheaters is another story). Once ready, he closes the ticket. Now the universe state has advanced.
4. Again either a person or an algorithm decide what mission profiles in the queue are still valid or need to be redefined (because the state of the universe has changed!). If the queue has still something in it, repeat at 3. In the mean-time, people can always do 2.
5. You could allow users to download scenarios of the current universe state at every point in time, e.g. for practicing purposes, but you can't allow their "results" to be "commited" to the universe.

If we see the above state-changing actions as commits in a version control system, we can also see that a parallel system might be possible, if a sufficient merging-algorithm can be applied. But I think for a first cut this would be too complicated, so better keep it serialized and "branch"-free at first.

Thanks for the interesting response. I have actually been busy abusing the orbiter API in unimaginable ways and working on weapons/AI/story mode elements to support the eventual introduction of hyperdrives and jump gates to the world. The poll you created about preferred multiplayer features suggested most people don't care about making such sacrifices to work around time acceleration. I strongly favor 1x constant time acceleration over any implementation that allows time acceleration, and I think well positioned jump gates and hyperdrives constrained by fuel and economics can lead to interesting scenarios and gameplay (blockades?). I want to do that properly, and that means having a small campaign/story mode showcasing the new game elements, and that takes some time. I am borrowing heavily from Elite Dangerous.

In the meantime I was curious about what we can do in a persistent real-time world when constrained to local space because of the lack of time acceleration. Me and my co-workers used to play a game called Diplomacy for example, where we made our moves once a day, usually by using the smartphone. My question is, what type of game elements can we add into Orbiter such that we can have this type of gameplay? ie. Pull out your phone, make decisions and have that affect the real-time persistent world. In World of Warcraft for example, you have the option of controlling certain game elements from your phone via their app.

The idea about building a scenario merging tool is very cool and is certainly something to be explored. But I am more interested in gameplay mechanics that we can add to make the game more fun *without* time acceleration. That means adding something like crew management and systems maintenance simulation, some type of game mechanic that would allow the player to interact with the game world not just by means of using Orbiter to fly somewhere. In Orbiter right now, you can fly to anywhere in the solar system, but that's it. So getting from point A to point B is the primary objective, and there isn't a lot to do besides that. I want to introduce in-game elements that'd require the player to have a more active role in maintaining space stations, for instance.

I think there is a lot we can do just in LEO by adding game elements and activities that'd keep the player engaged. What these activities and in game elements are, I need ideas and help with. Because the world is persistent and real-time, we can be really crazy. For example, we can add things like having to wait in line because too many orbinauts are launching from the same launch complex. We can also borrow from the real space industry and try to implement some of their protocols/procedures in game so players have other things to do and manage. I would love to hear ideas along this line of thought.

Rather than necessitating the use of time acceleration, if we were to use Orbiter as a simulator for local space operations, what activities/in game procedures/protocols can we implement to make the game more fun and possibly even more realistic? Like for example, what operations and activities would we need to do to maintain ISS in Orbit?

 

[Face]

But I am more interested in gameplay mechanics that we can add to make the game more fun *without* time acceleration. That means adding something like crew management and systems maintenance simulation, some type of game mechanic that would allow the player to interact with the game world not just by means of using Orbiter to fly somewhere. In Orbiter right now, you can fly to anywhere in the solar system, but that's it. So getting from point A to point B is the primary objective, and there isn't a lot to do besides that. I want to introduce in-game elements that'd require the player to have a more active role in maintaining space stations, for instance.

I see. Personally, I think that idea won't fly, simply because the audience you are talking to is used to using the simulator with time-acc to get from point A to point B, but not to using it as a station simulator. But that's just my opinion, of course. I wish you luck in your endeavor.

On the subject of things to do on a station that might keep people interested, especially when talking about mobile access, what about space-themed mini-games? Simple game-mechanics to achieve one of the maintenance goals that each "passenger" needs to fulfill in order to keep systems from failing. Let's say you have to:

• repair life-support pipes,
• re-route failed battery/generator wirings,
• fix hull holes,
• train body to counter-act bone-decay,
• do manual star-navigation in order to check on-board instruments,
• ...

Each of them could be worked into a mini-game that you need to win in order to stop the involved system from decaying. If done so in a portable way, it doesn't matter if the user plays it in front of his desktop, laptop or mobile device. I think these "keep-it-alives" would also be necessary in other vessels, not only stations, so you can make it a generic thing. Just the size of the vessel would determine how much work needs to be done in a given time period, so in order to maintain a huge vessel (or station), you will need a certain number of people to lift the work load, just like in real life.


Kind of a space Tamagotchi. :lol:

 

[jedidia]

I think well positioned jump gates and hyperdrives constrained by fuel and economics can lead to interesting scenarios and gameplay

The question here inevitably becomes, why use Orbiter at all? Why not use a simpler engine that would allow easier implementation of game elements?
Because if you put jump-gates and stuff in, it becomes questionable why the whole overhead of a fully realised newtonian solar system is even necessary. Especially if you want to go multiplayer, it would make a lot more sense to instance every "Location" accessible by jumpgate by itself. Way less hassle on the server!

 

[4throck]

Bring the scope down to the core functionality » a persistent universe.
So you start by creating a scenario merger that works of a web-server.

That should keep you busy enough to get something that works.

 

[Urwumpe]

With Dropwizard, he should be able to do this scenario merger in a day - but that's a fat java web service then and as framework a bit overpowered for such a small project. (But it is much slimmer than any Java EE application, by being one server-one application)

From my assessment so far, Dropwizard is a great framework for any browser game project - especially since you can go from monolithic app to micro services while your project grows without too much lava cake slowing you down.

Still - since most players will hardly play longer than two hours everyday, you should include this in your planning of any game. Going from Face suggestion, I would maybe suggest using Action Points, that are refreshed every day, and simply let the player do a number of tasks in the few hours of his evening plus deciding what his "virtual astronaut" does while off-duty. You don't even need to limit this then to space stations. You could also do a Mars Mission that way. There are a lot of creative possibilities in such a concept....

You could maybe also make it possible to have multiple missions in parallel on a single server, but running at different "recharge intervals" - for example one where the AP are refreshed every 6 hours for those who don't have to work hard...

 

[Majid]

Bring the scope down to the core functionality » a persistent universe.
So you start by creating a scenario merger that works of a web-server.

That should keep you busy enough to get something that works.

The persistence is extremely easy to implement in Orbiter and is already done. The way it works is I have an Orbiter instance running that persists/propagates the state vectors of any "offline player". The orbiter instance(s) is simply polling a web service for new vessels to persist. Once the player becomes online, since this is 1x time acceleration, the new state vectors are copied into the player's simulation.

---------- Post added at 01:22 PM ---------- Previous post was at 01:15 PM ----------

With Dropwizard, he should be able to do this scenario merger in a day - but that's a fat java web service then and as framework a bit overpowered for such a small project. (But it is much slimmer than any Java EE application, by being one server-one application)

From my assessment so far, Dropwizard is a great framework for any browser game project - especially since you can go from monolithic app to micro services while your project grows without too much lava cake slowing you down.

Still - since most players will hardly play longer than two hours everyday, you should include this in your planning of any game. Going from Face suggestion, I would maybe suggest using Action Points, that are refreshed every day, and simply let the player do a number of tasks in the few hours of his evening plus deciding what his "virtual astronaut" does while off-duty. You don't even need to limit this then to space stations. You could also do a Mars Mission that way. There are a lot of creative possibilities in such a concept....

You could maybe also make it possible to have multiple missions in parallel on a single server, but running at different "recharge intervals" - for example one where the AP are refreshed every 6 hours for those who don't have to work hard...

I will have to respond to your post in kind later as I am currently at work, but just FYI, I am using node.js for HTTP and curl on the Orbiter side.

 

[Majid]

I see. Personally, I think that idea won't fly, simply because the audience you are talking to is used to using the simulator with time-acc to get from point A to point B, but not to using it as a station simulator. But that's just my opinion, of course. I wish you luck in your endeavor.

On the subject of things to do on a station that might keep people interested, especially when talking about mobile access, what about space-themed mini-games? Simple game-mechanics to achieve one of the maintenance goals that each "passenger" needs to fulfill in order to keep systems from failing. Let's say you have to:

• repair life-support pipes,
• re-route failed battery/generator wirings,
• fix hull holes,
• train body to counter-act bone-decay,
• do manual star-navigation in order to check on-board instruments,
• ...

Each of them could be worked into a mini-game that you need to win in order to stop the involved system from decaying. If done so in a portable way, it doesn't matter if the user plays it in front of his desktop, laptop or mobile device. I think these "keep-it-alives" would also be necessary in other vessels, not only stations, so you can make it a generic thing. Just the size of the vessel would determine how much work needs to be done in a given time period, so in order to maintain a huge vessel (or station), you will need a certain number of people to lift the work load, just like in real life.

Kind of a space Tamagotchi. :lol:

I was thinking of these random mini-game events as well, along with some deterministic elements that the player has to maintain. For instance, making sure food and oxygen is in stock. But what other perishable items/resources do you think the player would need to maintain operation? Currently if the player is running out of oxygen/food, they can either choose to fly the refueling mission themselves or create a service request asking someone else to fly the mission with the goods. Are there other necessary resources
that the player would have to have stocked up?

I would really like to add these sort of elements to the game, and it's not technically challenging but demands a lot of creativity. Pretty much everything is on the table. For most of the repair type items you listed above, I am thinking of allowing the player to simply do an EVA with a couple beacons marking the location of where the player needs to be in relation to the vessel to complete the task.

The question here inevitably becomes, why use Orbiter at all? Why not use a simpler engine that would allow easier implementation of game elements?
Because if you put jump-gates and stuff in, it becomes questionable why the whole overhead of a fully realised newtonian solar system is even necessary. Especially if you want to go multiplayer, it would make a lot more sense to instance every "Location" accessible by jumpgate by itself. Way less hassle on the server!

Why not use Orbiter? Orbiter makes it exceedingly easy to do this sort of stuff. I am not trying to do real-time live multiplayer, so the challenges that orbiter brings in having a moving universe doesn't apply here. The gates will be placed in a way that people will still have to use orbital mechanics to get to, and in real-time as well, so most likely it'll take several hours to make the journey from Earth to Jupiter even with the gates. You don't have to use the gates, you're free to fly to Mars in real-time if that's what you want using realistic/efficient hohmann transfer. You can buy the massively powerful LSS photon ship and do a direct flight to your destination. Rather than doing everything from scratch, I see Orbiter as a perfect platform to play around with this sort of stuff.

Gates are literally just a mechanism for bypassing time acceleration. Time acceleration introduces a lot of conceptual headaches, and the benefits of allowing it aren't enough for me, especially when you can bypass the problem via gates.

With Dropwizard, he should be able to do this scenario merger in a day - but that's a fat java web service then and as framework a bit overpowered for such a small project. (But it is much slimmer than any Java EE application, by being one server-one application)

From my assessment so far, Dropwizard is a great framework for any browser game project - especially since you can go from monolithic app to micro services while your project grows without too much lava cake slowing you down.

I have had a lot of success with node.js. The scenario merger thing that Face described indeed sounds really tempting to do and I was tempted to tackle it over the weekend but I didn't want to get distracted.

I was just thinking of creating a "Missions MFD" that'd:

1. Allow you to create a mission, which is just a string title along with a string description describing the mission.
2. Allow you to see missions created by everyone else. It'd just be a paginated list of missions.
3. Missions would be composed of stages. The MFD would allow you to create a stage by asking for 2 pieces of information:

a) What you did in this current stage.
b) What has to be done in the next stage.
4. Players would be able to look at the mission list, select a stage and fly it. Stages have to be flown serially.
5. The MFD would then present to to the mission creator a list of stages to be approved or rejected, flown by actual orbinauts.
6. When a player is done flying a stage and hits the end stage button, Orbiter would save the scenario and upload it to the server. This scenario can then be used by the mission creator to approve or reject stages flown. I could simply download the scenario from the server to some local folder under scenarios, then launch the scenario under Orbiter using the -s command line flag. The mission creator could then inspects the stage in game and choose to reject/approve it in the MFD.

Can't see any major obstacles, except time. There are always n+1 projects to work on :lol:

Still - since most players will hardly play longer than two hours everyday, you should include this in your planning of any game. Going from Face suggestion, I would maybe suggest using Action Points, that are refreshed every day, and simply let the player do a number of tasks in the few hours of his evening plus deciding what his "virtual astronaut" does while off-duty. You don't even need to limit this then to space stations. You could also do a Mars Mission that way. There are a lot of creative possibilities in such a concept....

You could maybe also make it possible to have multiple missions in parallel on a single server, but running at different "recharge intervals" - for example one where the AP are refreshed every 6 hours for those who don't have to work hard...

Can you elaborate on the action points? I am looking for very specific things to code/implement right now.

 

[Face]

But what other perishable items/resources do you think the player would need to maintain operation?

Duct Tape. :rofl:

The scenario merger thing that Face described indeed sounds really tempting to do and I was tempted to tackle it over the weekend but I didn't want to get distracted.

What I described was not necessarily a scenario merge tool. I described that the state-changing action one does in such a system could be seen as commit to a version control system. Whether this is a simple file like an Orbiter scenario, a complex database entry or in-memory objects was not the point. The point was that once you can see the state-changing action as commit to a VCS, the thought is not so far away to think about branches and merges.

I think it doesn't make much sense to press every aspect of the universe (e.g. every consumable resource, every user data, every hit/action/karma-point) into the scenario file in order to have it merged.

I was just thinking of creating a "Missions MFD" that'd:
<snip>

Why an MFD mode? That sounds like a job for either an external application or a custom dialog.

 

[Urwumpe]

Duct Tape. :rofl:

Lots of it. And WD40. And as German, I of course have to mention the importance of shaving foam for experiment repairs in microgravity. :lol:

About action points: Applies to the mini game concept. Instead of having unlimited attempts at a minigame during a mission, a player should just need to expend a resource called action points. This way cooperation between players is encouraged, if there is more to be done during the mission, than a single player can handle with his AP.

 

[Majid]

So 2 things, and this is all in the context of the persistent real-time world:

1. It seems EVAs will become mandatory to make repairs and such, but AFAIK Ummu is not fully compatible with Orbiter 2016 and crashes when switching to internal view? Are there any known fixes for this? Would it be worth targeting Orbiter 2010 for compatibility reasons? Or would it be better to simply have my own mmu/crew implementation?

2. What do you guys think of breaking down mini-games/failures into categories? So for example a ship could experience things like main engine failure (by using THGROUP_MAIN or selecting the thruster with the greatest ISP) that could only be fixable by an engineer. You'd have to have an engineer on board or have one fly to you. A medical condition on board would have to be treated by a doctor. You'd have to pay these guys a monthly salary.

I think engineer/doctor are the two main classes I can think of right now, let me know if there should be others. What I need help with is coming up with as many failure/mini-game cases as possible.

I am thinking of an MFD/beacons interface to let the player know where to be. The player could have a toolbox with things like duck tape, welding equipment, etc, then the repairs could be composed of commands to the player to go to a certain location and use a certain tool.

Each failure could have a a rate of failure associated to it. So for example in the case of a main engine failure, the power of the main engine could fail progressively over time so that at the start, you have 95% of the total power but over the course of several hours the power gets less and less until a full failure occurs. The user would be able to monitor the status of all of these things on their phone, and they'd be able to arrange for an auto-AI based repair with a chance of failure to repair, which could cost some money. Or they'd be able to have someone else fly to them.

So what I need is:

1. Description of failure. This could be something that has a tangible effect on the operation of the ship like for example failed thrusters. Or it could also be something that's currently not modeled into the game, like failed reactor core or something that has to be fixed in time or the entire ship will blow up.
2. Tools in the toolbox needed to repair it
3. Failure rate, this is the amount of time in seconds it takes for the failure to grow by 1%.
4. A series of steps the player would need to take guided by the MFD to repair the failure. These steps could be "go to the location of the main engine" and use x tool, then use y tool, etc.

So for example, we can have a main engine failure with the 4 things defined as:

1. "Propellant leak is resulting in loss of main engine thrust! Emergency EVA necessary to address the issue."
2. Since this falls in the engineering class of problems, you'd have to have an engineer make the repair.
3. Use the duct tape from the toolbox to seal the leak. Toolbox could be modeled via a toolbox MFD.
4. The repair MFD interface would guide the player to the location of the damaged thruster. In the case of thrusters we can do this by using the orbiter API to get the locations.
5. The player has to use the tools within a set distance from the desired "action box" location.
6. The failure rate could be something like 2600 seconds, which would result in the engines dying completely in just over 3 days.

This would be interesting because it'd allow the user to either do something like a reentry using the partial engines to avoid being stranded in space with no engines.

It'd be awesome if we can come up with a list of such failures. I'd like for this to be scriptable but I think that would come later.

 

[Face]

(emphasis mine)

It'd be awesome if we can come up with a list of such failures.

Who is we? Do you suggest that people here should build up a list of failures before they can get their hands on a working system?

If so, why don't you take 2 or 3 examples and work them into a prototype, so folks can see what you have in mind?

I fear that most people will not invest much time into creating content for yet another multiplayer addon that is still basically vaporware. A working system - even if just a prototype - could spark much more interest IMHO.

 

[Majid]

(emphasis mine)
Who is we? Do you suggest that people here should build up a list of failures before they can get their hands on a working system?

If so, why don't you take 2 or 3 examples and work them into a prototype, so folks can see what you have in mind?

I fear that most people will not invest much time into creating content for yet another multiplayer addon that is still basically vaporware. A working system - even if just a prototype - could spark much more interest IMHO.

Sure, some suggestions would be really nice! I am looking for 2-3 complete examples. Not asking for written scenarios or anything, but maybe a line or two describing a repair or activity that might be interesting. You don't have to look at it as creating content, I am just trying to bounce some ideas and come up with wild enough suggestions that I can generalize somewhat.

I see your point though, there have been too many threads like this without actual work/progress. I'm planning on releasing the persistence stuff specifically soon, maybe coming Tuesday.

 

[jedidia]

And WD40

Honestly, I don't think that's a good idea in zero G... :shifty:

 

[Urwumpe]

Honestly, I don't think that's a good idea in zero G... :shifty:

What protects a Atlas rocket from rust can't be bad. :lol:

 

[Majid]

Hey guys. I just released a barebones persistence module that's going through approval on OrbitHangar.

It comes with 3 modules. Why three you ask? The MJD controller syncs the simulation time up with the server time, and keeps it synced.

The client module takes state vectors from the server and creates them locally in Orbiter.

The server module was never intended to be released to end users, as it's responsible for persisting vessels that are offline and is meant to be run on a server.

Originally the plan was to have very slow updates on the vessels because the goal isn't realtime multiplayer. But as it turns out, you can get decent performance by using Orbiter to propagate the vectors between 1 second updates. In atmospheric flight, this is good enough to result in smooth flight given the vessel isn't maneuvering very sharply. Due to Orbiter's new touchpoint system there is instability on the ground when the spawned DG's gear isn't down. Lowering the gear results in smooth landed vessels. Orbital flight is relatively stable, but on 1 Hz update cycle there are jitters. To compensate for this, update cycle for vessels with a positive periapsis altitude is reduced to once every 60 seconds. This actually makes maneuvers like docking possible. Unless you get unlucky But the jumps are only a few meters, so you'll have to correct for that until the next update. In my minimal local testing, the results are surprisingly good.

Given that this add-on's goal isn't real-time multiplayer, I'm very happy with the results so far.
Once/if the add-on is approved, you can download/extract in Orbiter's root folder, then activate the three modules. The MJD controller will try and sync any scenario to the server time and world. However, don't start a scenario in the future. If it is too far in the future, the amount of time you'll have to wait at 0.1x time acceleration is substantial. Use the included scenario, that's sufficiently close in the past to the server time so that the controller can rapidly advance to the target MJD.

If everything goes well, you will dock with the DG sitting on the runway upon loading. Please undock so that if anyone else decides to join, they too can experience the pleasure. I am so stoked Orbiter 2016 doesn't flip the table when landed vessels dock. The stock scenario comes only with the vessel GL-01. Every other vessel in the simulation is being persisted by the server.

You can persist your own vessels by using shift + P on the MJD controller MJD or press "PER".

The top line is the current sim MJD, the bottom line is the target MJD. I am currently using my laptop to persist the vessels... But I plan on getting a decent Windows VPS soon.

---------- Post added at 04:02 AM ---------- Previous post was at 03:44 AM ----------

This uses http for everything. If you can run orbiter and visit a website, you should be able to run this with the only dependency being the VS 2015 redistributable runtime components.

 

[Face]

Hey guys. I just released a barebones persistence module that's going through approval on OrbitHangar.

It comes with 3 modules. Why three you ask? The MJD controller syncs the simulation time up with the server time, and keeps it synced.

The client module takes state vectors from the server and creates them locally in Orbiter.

The server module was never intended to be released to end users, as it's responsible for persisting vessels that are offline and is meant to be run on a server.

Originally the plan was to have very slow updates on the vessels because the goal isn't realtime multiplayer. But as it turns out, you can get decent performance by using Orbiter to propagate the vectors between 1 second updates. In atmospheric flight, this is good enough to result in smooth flight given the vessel isn't maneuvering very sharply. Due to Orbiter's new touchpoint system there is instability on the ground when the spawned DG's gear isn't down. Lowering the gear results in smooth landed vessels. Orbital flight is relatively stable, but on 1 Hz update cycle there are jitters. To compensate for this, update cycle for vessels with a positive periapsis altitude is reduced to once every 60 seconds. This actually makes maneuvers like docking possible. Unless you get unlucky But the jumps are only a few meters, so you'll have to correct for that until the next update. In my minimal local testing, the results are surprisingly good.

Given that this add-on's goal isn't real-time multiplayer, I'm very happy with the results so far.
Once/if the add-on is approved, you can download/extract in Orbiter's root folder, then activate the three modules. The MJD controller will try and sync any scenario to the server time and world. However, don't start a scenario in the future. If it is too far in the future, the amount of time you'll have to wait at 0.1x time acceleration is substantial. Use the included scenario, that's sufficiently close in the past to the server time so that the controller can rapidly advance to the target MJD.

If everything goes well, you will dock with the DG sitting on the runway upon loading. Please undock so that if anyone else decides to join, they too can experience the pleasure. I am so stoked Orbiter 2016 doesn't flip the table when landed vessels dock. The stock scenario comes only with the vessel GL-01. Every other vessel in the simulation is being persisted by the server.

You can persist your own vessels by using shift + P on the MJD controller MJD or press "PER".

The top line is the current sim MJD, the bottom line is the target MJD. I am currently using my laptop to persist the vessels... But I plan on getting a decent Windows VPS soon.

---------- Post added at 04:02 AM ---------- Previous post was at 03:44 AM ----------

This uses http for everything. If you can run orbiter and visit a website, you should be able to run this with the only dependency being the VS 2015 redistributable runtime components.

Sounds like OMP's state in the beginning, just with TCP lag :thumbup:. Why the regular updates at all, if it is not supposed to be real-time multiplayer, though? I guess the displacement caused by regular updates during docking will be quite annoying to most.
Also, is that local only ATM? Or is there a public server (your laptop?) that is reachable for everybody simultaneously? The later would be necessary to check if the concept works out with more than one or two connections running.

 

[Majid]

Sounds like OMP's state in the beginning, just with TCP lag :thumbup:. Why the regular updates at all, if it is not supposed to be real-time multiplayer, though? I guess the displacement caused by regular updates during docking will be quite annoying to most.
Also, is that local only ATM? Or is there a public server (your laptop?) that is reachable for everybody simultaneously? The later would be necessary to check if the concept works out with more than one or two connections running.

Hey Face.

There is a linux public server, reachable by everyone with a public domain. That is for the orchestration. In this implementation there is the concept of persisters. The linux server persists vessels across a number of persisters.

Because I distributed the server module as well, you can fly around in orbiter.world without my laptop being up at all. The idea is to have a pool of persisters always running in a Windows VPS when I have it. If my laptop is down, people can still log in. Currently, they'll see the positions of ISS/GL/etc frozen in place. In the future logged off vessels will be moved into a different persister. But they'll still be able to persist their position using their own client, and anyone else can do the same, and you can actually have a multiplayer experience that way. If a player logs off, his/her position will remain static to the other players.

I attached a playback. Please note, some of the funkiness is due to Orbiter's playback system. I really did crash the ShuttleA. Note, none of the vessels besides the GL-01 was in the scenario originally, they were all spawned into this scenario.

I start flying the DG at around 1 minute 30 seconds. You be the judge if the effect is worth the cost of 1 second global update cycle. There is also a slow update cycle, which is done every 60 seconds for orbital flights. It's also pretty stable in position from update to the next. A 60 second update cycle ensures that the instrumentation works, the position is actually pretty darn accurate, and you can actually dock this way. We can make this inversely proportional to the distance, for one thing. Also, currently everything is being done in global coordinates. I think I can probably improve the orbital flight experience by using space stations as hubs that are master vessels so that I can use relative coordinates.

 

[Majid]

Also as an FYI, in the above playback, even though my 2 orbiter instances (one persisting the vessels, the other recording everything and receiving telemetry) are on the same machine, that's not an advantage in terms of latency because the state vectors are stored on the publicly reachable server, so in the playback above I am making the same roundtrip that anyone else's client would.