Save file whilst docked at something other than a station?

[elite]

This has probably been asked before.

Would it be a good idea to be able to save a game whilst docked at a rock hermit, pi-42 station, etc...

Is this available in newer versions of the game? I have 1.65.

[Disembodied]

This has probably been asked before.

Would it be a good idea to be able to save a game whilst docked at a rock hermit, pi-42 station, etc...

Is this available in newer versions of the game? I have 1.65.

I think there are technical reasons why this can't be done. There's no way for the program to store what kind of entity you are docked in, or where it is in the system (or, say, in deep space, if you happen to have a misjump and then dock with a Leviathan). As I understand, all the game records is the name of the system. The only place you can save the game is in the main station, therefore anyone starting a saved game in e.g. the Laribebe system must be in the station, and not in an unspecified Rock Hermit, pi-42, Dredger, etc. etc. I suspect that this is one of those changes which could be made -- if the whole game were stripped down and rebuilt. Technically possible, but immensely unlikely!

[elite]

Ah right, I thought it would be a major job to do else it would have been implemented by now.

I thought maybe that the game saved information about what type of station you was docked at and where it was, so that's why I thought it would have been a similar situation if you docked at some other non-moving object like a rock hermit or pi-42 station.

Big ships that you can dock with would also probably be the same but of course to be realistic, ships move so it wouldn't seem 'real' to dock with a dreadger then play the game again a week later only to be in the same place.

Anyway just a thought.

[Commander McLane]

ships move so it wouldn't seem 'real' to dock with a dreadger then play the game again a week later only to be in the same place.

That's not a valid reason against saving on a mothership. Game time doesn't advance with real time as long as you don't play. So even if you reload your commander years after saving him, he wouldn't have aged a single minute (as opposed to you). Also the ship or station he has docked with wouldn't have moved a single inch.

Anyway, being able to save at other places is on many peoples' wishlist. But for the reason Disembodied gave (not only the save-location, but the complete current state of the system you're in is not saved; so if you reload the game, chances are that the rock hermit or dredger you have saved on, doesn't exist and, worse, never has existed) we are not very likely to see it implemented.

[nijineko]

i suppose that short of adding a save state feature to the game that saves at least the type of object, it's location and trajectory, and a selected number of important objects... it would not happen. now i could see it saving the id and location of every rock hermit and dockable object, as well as sun and planet and so forth - "important" objects.

thus the major aspects of a system would stay the same, but the minor ones would be subject to change / erasure. this could be a step towards network play if implemented. each system in which a player exists / enters generates a small data packet of the above mentioned important information which get's sent to connected computers.

[Commander McLane]

I put also this one in the FAQ.

[Micha]

Sorry for resurrecting an old thread, but better than starting a new one.

I've had some thoughts on this.

Basically the issue is that unless the save-game suddenly stores all the info about 'important' objects in the current system, there's no way to re-generate the system on reload.

However, all the systems primary aspects (planet, sun, tech-level, etc) are generated from a system seed. If (and it's a big if) anything dockable is also generated using the same system seed, then the problem would go away - as long as you don't remove any OXPs, the system would get regenerated with all the same dockables every time.

Furthermore, I'm guessing the dockables use a random-number generator to determine a location in the system; again if the RNG is initialised with a known seed, all dockables would always appear at the same starting location in a particular system. Movable dockables could continue to have a random starting location as you can assume that it moved while you were docked...

Now all the save-file needs to store is -which- dockable a player saved at, the rest gets regenerated based on the system seed.

The only downside is that it removes a certain amount of dynamism from the Oolite universe.

Thoughts?

[Lestradae]

Hi Micha,

kindly have a look here:

https://bb.oolite.space/viewtopic.php?t=5095

Problem solved?

Cheers,

L

[Micha]

Well, yes, I saw that.. and while it's a great piece of creative scripting it's still a kludge. I was trying to think up a way it could be done 'properly' and added to the game code.

Honestly not trying to belittle the scripting ingenuity and it is a great stop-gap, but all that mucking about with buying equipment and being auto-launched and docked and whatnot is not really game immersing, imho.

[Lestradae]

Yeah ... see what you mean, would also like to have this in the core game, you have to petition Ahruman or another_commander for that, as those are the guys who decide what goes into the game at the end of the day.

[Micha]

My understanding from reading past posts is that most people think a save-anywhere is a Good Idea, and that it's mostly a technical hurdle with the random creation of things.

Hence my suggestion to take the randomness out of it somewhat. Still random, but predictably so.

[LittleBear]

Would the Core Game have to save the location of everything? Woudn't it just need to save in the save file the type and position of the thing you are docked at? OXPs populate on launching (first doing a check for ships: my_object, number found 0, add my_object). This is necessary, because when you save at a Main Station, the game does not save the position of objects and the system is populated afreash. If you save and launch again, everything is still there. This is so even if you dock and launch from a non-main station dockable. However if you exit after saving and restart Oolite to reload whatever was in the system is lost. Eg if you save, exit and reload at an Anachy with Random Hits installed, the game does not remember that there is a Space Bar there. Its only as the OXP does a check and launching and puts it back that the Space Bar is still ton be found.

So wound't just altering the code to store the type and position of the object you were docked at when you saved do the trick?

[Eric Walch]

However, all the systems primary aspects (planet, sun, tech-level, etc) are generated from a system seed. If (and it's a big if) anything dockable is also generated using the same system seed, then the problem would go away - as long as you don't remove any OXPs, the system would get regenerated with all the same dockables every time.

This is currently already possible in legacy script were you have a random number based on the system seed. But almost none of the oxp's use this. The only one I know of, is anarchies.oxp that ads its stations with this system seed based random number. Here the stations are always in the same system. 1.72 will also give this random number in JS.
One problem will be multiple stations with the same role. Here you never know what station will be added. In this case the station should be added by its unique name. (the ship_key itself)

And who decides what objects around a station are important? BuoyRepair.oxp always adds a buoy with a station. OK, buoys are probably important, but rocks? In most cases they are placed random, but I can imagine an oxp that places them at fixed positions around the station. e.g. a concealed rock hermit with rocks in front of the port to hide the docking port.

OXPs populate on launching (first doing a check for ships: my_object, number found 0, add my_object).

Not always true anymore. The check is not necessary with JS. You only need adding stations on the first launch. With JS you can skip the check if you set first-launch in startup/reset. With the new buoy repair I even moved the first populate from launch to the startup/reset handler. This way the system is already populated before first-launch. So when the core is adding an oxp station, there is a risk that the oxp itself will also add his version.

[Frame]

Furthermore, I'm guessing the dockables use a random-number generator to determine a location in the system; again if the RNG is initialised with a known seed, all dockables would always appear at the same starting location in a particular system. Movable dockables could continue to have a random starting location as you can assume that it moved while you were docked...

Now all the save-file needs to store is -which- dockable a player saved at, the rest gets regenerated based on the system seed.

The only downside is that it removes a certain amount of dynamism from the Oolite universe.

Thoughts?

regarding that all dockable objects spawn initialised from a known seed...

They dont... i have tested this plenty of times to know, that they do not...

Rock-Hermits... etc are random spawned each time you enter a system, just like normal ships... which is why in incorperated the save surroundings function in save anywhere OXP... furthermore i developed this more to support the solar system OXP that i am going to be writing, when i pick up the pace on that one again...

[Micha]

Now all the save-file needs to store is -which- dockable a player saved at, the rest gets regenerated based on the system seed.

regarding that all dockable objects spawn initialised from a known seed...

They dont... i have tested this plenty of times to know, that they do not...
[/quote]

I know they don't.

I was suggesting that maybe they should. Not only whether they get created in a particular system but also where (unless they are inherently movable such as the hOopy Casino's)

Obviously this would require a lot of coordination between all OXP writers as well as a standardised procedure for doing so.

If there's a better idea which doesn't require saving the entire system state in the savegame and ideally not requiring any (major) modifications to the OXPs I'm sure everybody would be very keen on implementing this.

If you can deterministically re-generate a system purely from the system seed (and possibly current game-time) then all you have to do is store the system seed and station id of the station you're docked at in.

If you've got a station (or OXP) which has certain 'important' elements (such as the rocks hiding the docking port in one example above) then it would be responsible for regenerating those. If those important elements can be destroyed or modified then I guess we'd need a way for the game to query the OXP in order to save (a subset of) the OXP state as well. Presumably this already exists as some OXPs already store data in the savegame.