Oolite Bulletins

Micha wrote:

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.

Well, that's exactly how the game engine (what other people refer to as "core game") works (and has always worked), and that's exactly the information that is saved in every save-game since save-games exist. It's the way the system is generated in the first place, after all.

Problem is, that OXPs are expansions of the "core" game, and they can (and have to) do a lot of things not usually done by the "core" game. (Would be kind of boring if they couldn't, well, expand the game, wouldn't it?)

And each scripter is entirely free to do things the way he (or she) wants, even free to do things wrong. A scripter is also free to deliberately make ships and stations appear randomly, unpredictably. For instance, I even think there may be a reason why Giles chose to make Rock Hermits appear randomly, not always in the same systems at the same places.

Thanks to Eric for mentioning Anarchies as an example of placing objects while using the system seed (in scripting-terms read: pseudoFixedD100_number). Although I'd have to add that this is not true for all stationary objects in that OXP. Salvage Gangs, Sentinel and Renegade Stations are spawned that way, and therefore appear reliably in the same system (although notably their location in the system is not detemined by the seed), but Hacker Outposts are not, and deliberately so. Their appearance depends on the player meeting a certain ship, thus making it not too easy to find them. This means that also in the current setting, if you save and reload in an Anarchy-system that had a Hacker Outpost, it won't be there anymore after reloading, until you find the henchman again.

If a "save everywhere" project means all OXPers have to be subjected to spawn station entities in the one-and-only very specific way, it is doomed before it even has started, because we simply can't make all OXPers to follow this rule. They will break it, some deliberately, some of sheer ignorance. What are you going to do about it? You can't do anything.

And even if you could, there is still the issue of all other (non-station) entities in the system.

Bottom line: I don't see a shortcut around storing the relevant data about every relevant entity in the system in the save-file. The only thing debatable is how many and which entities we consider relevant, and which of their data we consider relevant.

Hmm. All reasonable points. Personally I prefer to have certain things like spacestations deterministic but I can see that it's not always desirable. And of course different people have different expectations of the game.

To save everything though requires the save engine to query every OXP for its 'important' entities and what attributes of those entities it needs to save. Then the loading engine has to pass those to the OXP again.

A lot of work for every relevant OXP to implement load/save, and easy to get wrong.

Micha wrote:

To save everything though requires the save engine to query every OXP for its 'important' entities and what attributes of those entities it needs to save. Then the loading engine has to pass those to the OXP again.

I don't think it's quite that bad.

For a start it would be satisfactory to simply save all station-entities. No querying of OXPs needed. Let the save-engine create a list of station-entities in the current system, with their most important data--basically their position and orientation--and put that in an array which gets saved.

On restart the array is read out and the entities are recreated. If the OXP responsible for a certain station-entity has been removed in the meantime, let the engine display a message on the load screen:

Can't spawn station-entity XYZ. Please re-install OXP.

and simply refuse to load the game in question.