[Split]: Saving on stations

[Smivs]

Just a quick question (to save me hours of trawling through the BB) regarding game saves. Can we now (1.79 on) save elsewhere other than at main stations, and if so, is there a way to prevent a player saving at a specified non-main station?

[Cody]

Can we now (1.79 on) save elsewhere other than at main stations...

I can answer that one - yes!

[spara]

Just a quick question (to save me hours of trawling through the BB) regarding game saves. Can we now (1.79 on) save elsewhere other than at main stations, and if so, is there a way to prevent a player saving at a specified non-main station?

Station has to be spawned in the populator, has to be spawned to the same place and has to be enabled per station by using deterministic flag in the populator. In the core you can save at the hermits' in addition to the main stations. Of the oxp stations I have enabled saving at Rescue Stations and Space Bars.

[Smivs]

Thanks. So if I understand correctly saving is not possible at an OXP station unless you make it so, is that correct?

[spara]

Thanks. So if I understand correctly saving is not possible at an OXP station unless you make it so, is that correct?

Yes. You need to set the deterministic flag in populator to true. By default, it's false.

[Smivs]

OK. Thanks very much

[cim]

One other minor point: even if a station is added deterministically in the populator, it still won't allow saving if:
- you added it deterministically but to non-fixed coordinates (i.e. not using either "COORDINATES" or locationSeed to add it); or
- it has a max flight speed >0 so where it was added and where it is now might be two different things; or
- you're in interstellar space
Basically it'll only allow saving if it has reasonable grounds to believe the station will still be there when the game is loaded again.

[Smivs]

Basically it'll only allow saving if it has reasonable grounds to believe the station will still be there when the game is loaded again.

This is more complicated than I thought!
I'm asking as I am taking the opportunity to tidy up a couple of details in Giant Space Pizza prior to conversion to OXZ.
The script ensures that the Pizza and the Visitor centre are still present in-system (spawned again) if a player saves and re-launches (from the main station as it stands), so I was checking what might happen if they potentially saved at the Visitor Centre. Particularly, would another Visitor Centre be spawned after such a launch. Hence my desire that they cannot save at the VC.
This does mean however that the station will be there (again rather than still) when the game is re-loaded and the player launches. Will this be a problem?
Help and advice would be very welcome.

[another_commander]

Saving on stations discussion split out of Progress thread.

[spara]

If you want to use the saving feature and the new populator, then you need to rethink the whole spawning business. No more spawning on launch and stuff, you need to use the new populator. Look  here for details. Core's oolite-populator.js is worth to check too.

[Smivs]

you need to rethink the whole spawning business. No more spawning on launch and stuff, you need to use the new populator.

<Groans> I haven't even started to look at that yet! Ho-hum...
<Decides maybe this will have to wait for a while...>

[cim]

Summary: if you do nothing and keep the pre-1.79 way of addition, you will not be able to save at the OXP station under any circumstances, and things will just keep working as they were. Unless for mission purposes you really don't want the player to be able to save there, though, I'd recommend doing it the new way which allows saving at OXP stations to be added safely., when you get a bit of time to make the change.

This is more complicated than I thought!

I hope once you've got your head round it you'll see the opportunities for simplification of the current way of doing things in the long-term, but yes, it's a bit different to what was there before, and a little bit more code to do the initial set up.

At the moment, you're presumably adding the pizza + centre using system.addShips in shipWillExitWitchspace and/or other suitable event handlers. Oolite has no way to tell from this that you are adding objects that you intend to add the next time the system is visited / reloaded, and rates the chances of their reappearance as low. Therefore, you can't save at them.

What you could do instead is add both the pizza + centre to the populator information during the new systemWillPopulate event handler. This still uses system.addShips eventually, but it has three advantages:

1) There is exactly one event handler used to populate the system, rather than saying "shipWillExitWitchspace ... oh, but then it won't appear if the player starts in the system, so shipWillLaunchFromStation as well ... but what happens if they launch twice, etc?". I've seen enough bugs end up in OXPs that way: pretty much every OXP of mine that added ships in shipWillExitWitchspace had to have a bugfix release for "except for in interstellar space" (and then most of them also separately "except in nova systems").

2) You can tell Oolite that the stations are likely to come back in the same place as they were before, by setting the "deterministic" flag in the populator options, and providing suitable non-random coordinates.
If you do this, load/save will then be possible at the visitor centre - but there's no chance of a second one being added, because the system population is always run exactly once per system regardless of how the player enters the system.

3) OXPs, especially mission OXPs, can manage potential conflicts more easily. A lot of the populator design was done while thinking of the conversation a while back about the subtle conflict between Xeptatl's Sword and Commies: if the new populator had somehow been around in the really old days, XS could have easily said "this system is currently being used for a mission, and Commies - and other OXPs - should not touch it" for the crucial bit - but with Commies able to add the high-tech factory freely at other times.


So, for an example of use:

Code: Select all

this.systemWillPopulate = function() 
{
  if (this.isASystemWithAPizza()) {
    system.setPopulator("smivs_giantspacepizza",
    {
// a position closer to the sun than the planet is to the sun, but not too close
      location: "INNER_SYSTEM_OFFPLANE", 
// fix the position to be the same one every time, rather than random
      locationSeed: 621863,
// these will always appear the same so long as this OXP is installed
      deterministic: true,
// and this is what adds them. It gets given a 'pos' parameter, which is the result of
// Oolite translating location "INNER_SYSTEM_OFFPLANE: 621863" into real coordinates
      callback: function(pos) {
        system.addShips("smivs-visitor-centre",1,pos,0); // add the visitor centre to the coordinates specified
        system.addShips("smivs-giant-pizza",1,pos.add([15E3,0,0]),0); // add the pizza nearby
      }
    });
  }
}

There are lots of alternative location codes that can be used - "INNER_SYSTEM_OFFPLANE" is a good one for things which should be reasonably quick to reach by torus but have no reason to be near the main spacelanes. There are lots of other options on the page which spara linked to above.

621863 I picked by hitting the numpad at random a few times. It won't be anywhere near 621862 except by sheer coincidence. The idea is to let people place lots of items through different OXPs in different places in the same region (e.g. planetary orbit) without needing to explicitly worry about which other OXPs are doing the same thing - and also not having everything be in exactly the same relative positions in every single system: 621863 will be in a different place relative to the sun, planet and witchpoint in Lave than in Leesti.

Please ask if there's any more I can clarify.

[Smivs]

Ha, yes, lots to take in, indeed. I can see what you are saying though, and the new populator does seem the way to go - ultimately it will be simpler and more straightforward, so I have some studying to do. As you hinted, Xeptatl's Sword would benefit from this as part of its proposed overhaul as well.
The code example above looks very useful - thanks.
So, back to the drawing board on this one