Oolite Bulletins

Question for the devs- why is saving only available in-station and not in space? I always assumed that is done for technical reasons.

Massively Locked wrote: ↑Sat Aug 13, 2022 7:15 pm

Question for the devs...

Dumb pilot here! The simple answer is probably because that's how the original Elite did it (which almost certainly was for technical reasons).

That would explain it. Never having played Elite, I often forget Oolite's roots.

Massively Locked wrote: ↑Sat Aug 13, 2022 7:15 pm

Question for the devs- why is saving only available in-station and not in space? I always assumed that is done for technical reasons.

Oolite needs exact, fixed coordinates to save a game, so a moving object is out of the question, Some OXP stations will not offer a save, simply of the way they were added. At stations moving slow, you might find yourself at the main-station after loading because either your original location moved more than tolerated or was destroyed.

In the original game one could only save at the Main Orbital Station. Save Anywhere was the first attempt to expand beyond this, allowing saves at OXP stations.

Cholmondely wrote: ↑Mon Aug 15, 2022 12:09 pm

In the original game one could only save at the Main Orbital Station. Save Anywhere was the first attempt to expand beyond this, allowing saves at OXP stations.

Absolutely correct, the main-station can't be destroyed, at least not without an OXP, and is always at the same location.

montana05 wrote: ↑Mon Aug 15, 2022 12:13 pm

... and is always at the same location.

Which is true of rock hermits too... yes?

Cody wrote: ↑Mon Aug 15, 2022 12:39 pm

montana05 wrote: ↑Mon Aug 15, 2022 12:13 pm

... and is always at the same location.

Which is true of rock hermits too... yes?

True, difference is that RH could be destroyed,

Also true - but that's the chance one takes if saving at a RH.

Cody wrote: ↑Mon Aug 15, 2022 12:43 pm

Also true - but that's the chance one takes if saving at a RH.

Correct, same like with some OXP stations, you might find yourself at the main-station or simply get ejected. The core-game needs fixed coordinates, a RH would provide it, once again, without OXP's, however, the only object in the core-game indestructible is the main-station.

montana05 wrote: ↑Mon Aug 15, 2022 8:05 am

...you might find yourself at the main-station after loading because either your original location moved more than tolerated or was destroyed.

I had recently saved at a con store then started tinkering with YAH. I pulled my installed ad sets and added a new one. When I restarted, I found that I magically disappeared the con store & teleported to the main station. An obvious sign of the necromantic arts... in Spaaaaacccccceee

Being destructible isn't a problem - the station obviously isn't going to be destroyed between saving and reloading - but the game does require some assurances that it's likely to be in the same place after reload, which Rock Hermits and some OXP secondary stations have.


The main technical reason beyond "this is how it's always been done" is that currently the game doesn't save things like the identities and positions of other ships in the system, their AI state, etc. to the save file. Instead, when you reload the game, it asks the core and OXP scripts to regenerate the system afresh. This isn't particularly obvious if you're docked at a station (at least, one which *is* going to be regenerated in the same place as it was when you saved) but would be really obvious (and rather exploitable) if you saved in the middle of a fight, reloaded, and the fight was replaced by a trade convoy going about its business 15km away.

Serialising the entire system entity and script state to a save file to allow full save/load would be a very large piece of work, and would likely make it somewhere between much harder and impossible to add/upgrade/remove OXPs once a pilot had been started.

cim wrote: ↑Tue Aug 16, 2022 1:17 pm

Being destructible isn't a problem - the station obviously isn't going to be destroyed between saving and reloading - but the game does require some assurances that it's likely to be in the same place after reload, which Rock Hermits and some OXP secondary stations have.


The main technical reason beyond "this is how it's always been done" is that currently the game doesn't save things like the identities and positions of other ships in the system, their AI state, etc. to the save file. Instead, when you reload the game, it asks the core and OXP scripts to regenerate the system afresh. This isn't particularly obvious if you're docked at a station (at least, one which *is* going to be regenerated in the same place as it was when you saved) but would be really obvious (and rather exploitable) if you saved in the middle of a fight, reloaded, and the fight was replaced by a trade convoy going about its business 15km away.

Serialising the entire system entity and script state to a save file to allow full save/load would be a very large piece of work, and would likely make it somewhere between much harder and impossible to add/upgrade/remove OXPs once a pilot had been started.

But it didn't have to save the state of all the entities in the whole system to avoid that exploit... it could be just the entities (or certain types of entities, wreckage and sparks could be ignored) within a certain range of the player ship: a multiple of the scanner range, or the ones near enough to be visible... at worst, there could be a set of conditions to be met so the player can save, like: not docked in a non-deterministic station (I think that one would be mandatory), or no other entities in scanner range to simplify the state saving.

I fail to see how much different it would be adding/upgrading/removing OXPs as compared to a save with the player docked on an OXP station (that could be removed with the OXP...). Granted, weird things could happen, like whole planets/moons disappearing, but such things can already happen: installed equipment already can magically disappear, the player can be teleported to the main station, the whole system configuration (planets/moons/station existence, distance between them and the sun, sky appearance, market values and content, etc.) already can change between a save and a reload.

The main thing I think would be needed is an extra event to be called after startupComplete for OXPs to initialize their in-flight player ship state... it could be a brand new one (OXPs would HAVE to be updated to deal with it), or it could perhaps be shipExitedWitchspace (any OXP that starts timers, frame callbacks, etc., should already be using that...).

Just brainstorming, but It would be nice to be able to quit the game at any time without loosing too much context, sometimes it takes too long to reach the nearest deterministic station and leaving the game running paused is not always an option...

dybal wrote: ↑Tue Aug 16, 2022 4:05 pm

The main thing I think would be needed is an extra event to be called after startupComplete for OXPs to initialize their in-flight player ship state... it could be a brand new one (OXPs would HAVE to be updated to deal with it)

Doesn't need a new event - startUpComplete is already fine for this - but certainly a lot of OXPs would need updating for it.
- anything which adds ships or entities without using the system populator framework would need to make sure it could tell the difference between a normal startUp (initialise those entities as the system is "clean") and a save-anywhere startUp (don't initialise them again, the core game will be loading the ones from last time)
- world and ship scripts would need to cope with the possibility that they've been upgraded since the game was saved, and therefore the values the game is deserialising onto them belong to an (arbitrary!) previous version. At the moment, OXPs have to choose to serialise data to missionVariables, and it can be quite a small set. In a lot of cases on upgrade, you'd therefore want to rename worldscripts to have the version number in them, with all your previous version worldscripts still in place but simply having compatibility code in case the game deserialises data onto them. Messy to handle.
- knowing what you did and didn't need to serialise (and what the core game was and wasn't responsible for serialising, which would itself be a controversial discussion) would be a big increase in complexity for OXP authors and expose them to a lot of details of Oolite internals they don't normally need to know about (and then that makes core game development harder by meaning that changes to those internals can not only break OXPs but also save-games)
It's just too much updating and extra work to retrofit that feature now, I would think.

If you're restricting saving to "no entities on scanner" situations then an updated version of Save Anywhere is probably sufficient as an OXP hack:
- spawn a basic deterministic station way out in the middle of nowhere
- on activation of "Save Anywhere", store the player's position and orientation to the save file, teleport them to the no-services station, let them save
- on reload, auto-launch the player and teleport them instantly back to the saved position, removing all entities which generated within the scanner radius this time round.

dybal wrote: ↑Tue Aug 16, 2022 4:05 pm

the whole system configuration (planets/moons/station existence, distance between them and the sun, sky appearance, market values and content, etc.) already can change between a save and a reload.

Sure, it can, but being docked to a station (which failsafes to moving the player to the main station) avoids a lot of potential issues with that and makes a lot of the rest much less noticeable.

cim wrote: ↑Wed Aug 17, 2022 7:43 am

dybal wrote: ↑Tue Aug 16, 2022 4:05 pm

The main thing I think would be needed is an extra event to be called after startupComplete for OXPs to initialize their in-flight player ship state... it could be a brand new one (OXPs would HAVE to be updated to deal with it)

Doesn't need a new event - startUpComplete is already fine for this - but certainly a lot of OXPs would need updating for it.
- anything which adds ships or entities without using the system populator framework would need to make sure it could tell the difference between a normal startUp (initialise those entities as the system is "clean") and a save-anywhere startUp (don't initialise them again, the core game will be loading the ones from last time)
- world and ship scripts would need to cope with the possibility that they've been upgraded since the game was saved, and therefore the values the game is deserialising onto them belong to an (arbitrary!) previous version. At the moment, OXPs have to choose to serialise data to missionVariables, and it can be quite a small set. In a lot of cases on upgrade, you'd therefore want to rename worldscripts to have the version number in them, with all your previous version worldscripts still in place but simply having compatibility code in case the game deserialises data onto them. Messy to handle.
- knowing what you did and didn't need to serialise (and what the core game was and wasn't responsible for serialising, which would itself be a controversial discussion) would be a big increase in complexity for OXP authors and expose them to a lot of details of Oolite internals they don't normally need to know about (and then that makes core game development harder by meaning that changes to those internals can not only break OXPs but also save-games)
It's just too much updating and extra work to retrofit that feature now, I would think.

I agree!

If you're restricting saving to "no entities on scanner" situations then an updated version of Save Anywhere is probably sufficient as an OXP hack:
- spawn a basic deterministic station way out in the middle of nowhere
- on activation of "Save Anywhere", store the player's position and orientation to the save file, teleport them to the no-services station, let them save
- on reload, auto-launch the player and teleport them instantly back to the saved position, removing all entities which generated within the scanner radius this time round.

I think that would be "good enough for government work"
Unless in the middle of combat, the player can run away from the NPCs in scanner range even without injectors (if in combat the player might be pursued... though some of those hunters and police are really stubborn about scanning the player time and time again and it might be difficult to shake them with a slow ship) and then save.

Are there ways to hide the "Station at the End of the Universe"? (since it would have to be deterministic, created at populator time, there will have to be one at any system the player is in, during the whole system lifetime)

The only method I found to save the game from a script is player.endScenario, but there is the problem of finding the required scenario key...

EDIT: finally noticed that Save Anywhere is an existing OXP. Looked into it... the idea would be to create the "Station at The End of Universe" and a primeable "save" equipment that when activated, in the right conditions, "teleports" the playership to the station and there the only things the player can do is Save, Quit, or Launch (which gets he back to the place the activated the "save" equipment)... right?