Saving

[minoas]

I do not know if this has been discussed, but I feel it would be great if the game let us save while traveling in space (instead of just when docked). Sometimes it takes too long to reach a station so and you have to stop playing for a reason. Would be nice to continue from previous position.

[Disembodied]

Hi, minoas, welcome to the boards! Although it is now possible to save when you're docked in stations other than the main one, I'm not sure if being able to save during flight has been discussed before ... I don't know what technical issues there are, but there are some good gameplay reasons why this might not be a great idea: players could travel a bit, save; travel a bit, save; travel a bit, save; and so on. Part of the thrill of the game is fighting your way through a hostile system to the safety of a station, and giving players the ability to continuously save their progress after each encounter might diminish this. Then again, it's a single-player game, so it's not really "cheating" in any meaningful sense ...

[Wildeblood]

A long while ago I created an OXP called Save and Jump that let you save at the moment of making a witchspace jump from one system to another. Unfortunately, the only copy of the finished version was lost in the Great HDD Reformat. I still think that's a logical point to allow saving.

[Norby]

Hi minoas, welcome here!

it would be great if the game let us save while traveling in space

It isn't impossible technically. Your savegame will be big which is not a problem but there is another reason: Oolite is a modular game so I don't think this will be in the core due to the dev team keep it near the original gameplay until you haven't any extensions and this is far more than a little change.

Extensions called to OXPs can do much more, even tricks which seems like if you can save in the space (improving further the teleport effect of [wiki]Save_Anywhere[/wiki], respawning all ships etc.). With a bit more than a year of experinece in OXP making I guess I can make it, just too much work to start it right now.

Sometimes it takes too long to reach a station

Much easier to solve this problem: buy  Injectors, maybe [wiki]ILS[/wiki] too, and you can dock in a few minutes. Not counting fight times which is not boring.

let you save at the moment of making a witchspace jump

This is a good idea imho, a big improvement against the 15sec countdowns. Even the core should make another autosave if devs do it.

the only copy of the finished version was lost

Can you use the source of [wiki]Save_Anywhere[/wiki] to remake it faster?

[cim]

It isn't impossible technically.

No, but the compromises necessary to make it work might not be pleasant.

Saving in space means serialising the state of all relevant game objects to the save game, then restoring them on load. The problem here - matters of programming all the serialisers and reference resolvers aside - is that a JS script is a relevant game object, so the current variables in all ship and world scripts must be saved. So, what happens in the following scenario?
1) Player saves the game
2) Player upgrades an OXP
3) Player loads the game
At the moment it's fine - the game picks up the new OXP, reinitialises the world script, and calls its startUp method to wake it up and let it do any further initialisation.

If we serialised all the values to the save game, then what happens is the OXP update gets overwritten by the values in the save. That includes the values of variables like this.shipWillExitWitchspace because we have no [1] way to determine which values in an OXP script the author is treating as constant and which they are treating as variables. Worse, if the player removes the OXP, its scripts still exist in the save game and still potentially get reloaded (or perhaps don't get reloaded ... either could cause a hard-to-diagnose in-flight bug).

Being able to keep the same savegame from release to release, and being able to add and remove OXPs freely without risk to the savegame (beyond a bit of bloat to your mission variables section) requires keeping the information stored in the savegame to a relatively abstract level. Allowing the player to only save in situations where changes beyond the abstract level are mostly unnoticeable is the easiest way to do that.

I can't think of an example of a game which successfully solves this problem - they all do at least one of:
- have short enough game lives that "restart to upgrade or change expansions" is acceptable
- risk irrepairable save corruption if you do change expansions mid-game
- don't allow expansions (or put extremely strict limits on what they can do)
- limit where you can save

I still think {witchspace jumps are} a logical point to allow saving.

More practical, certainly, but still extremely difficult. The main difficulty is that it would be a significant shock to OXPs which may be assuming at various levels that the game will load with the player docked. A lot of OXPs, especially older ones, use "first launch from station" as a trigger for various events, and there are probably a range of obvious and subtle assumptions about how game startup works elsewhere too.

Just allowing saving at non-main stations caused some difficulties, and this would be quite a bit bigger. e.g. what happens in the situation where you pursue a mission ship into witchspace, die, the game reloads ... and runs the startUp event in the new system from the save? How many copies of the mission ship end up in the new system, and what configuration do they have? There may still be the serialisation issues above associated with ships sharing the player's wormhole - I'm not sure.

[ffutures]

I'm really not keen on this - one of the things that makes Elite/Oolite interesting is the need to dock to save. Without it anyone could take on hugely long journeys, refuelling in stars and saving before each jump, then reloading if e.g. there are pirates or Thargoids waiting, or the ship misjumps and gets stranded in interstellar space. As things are, if your ship is destroyed you're back where you last saved, and that's an incentive to dock a lot more often.