Proposal for 1.82: planetinfo.plist changes

[cim]

At the moment, the majority of properties which can be recorded in planetinfo.plist are (without OXPs) dynamically generated based on random seeds, some - like the sun and planet properties - through quite a convoluted process when the player enters the system.

This has a number of disadvantages:

• system.info.[i]property[/i] only has a value if it has been set through planetinfo or JS. Otherwise, it's null even though the game often knows the value of the property.
• System info properties are only readable for the current galaxy. Without doing a lot of your own caching - and hoping no OXP has modified the properties - it's therefore very difficult to do randomly-generated cross-chart missions.
• Certain bits of Oolite's internal code are more complex and slower than they need to be.

So, here's the plan to fix this, which comes with a few other bonus features for OXP developers. Have a read and let us know what you think.

The basic idea

The obvious solution is to statically code all of the initial values of the properties into the core game's planetinfo.plist and stop randomly generating them. However, if we just do this, OXPs can no longer override properties set that way with "universal".

So, the plan is to add a "layer" property to planetinfo.plist

Code: Select all

 "0 7" = {
   "layer" = 2;
   "name" = "Not Lave";
   // ...many more properties
};

There would be four layers available, numbered 0 to 3, but OXPers would only need to care about 1, 2 and 3.

• Layer 0: This would be used to set the values for all systems in the core game's planetinfo
• Layer Universal: This would be the (unchangeable) layer for all universal properties, whether core or OXP. Non-universal properties can not be set to this layer.
• Layer 1: This would be the default layer for a change to planetinfo made by plist
• Layer 2: This would be the default layer for a change to planetinfo made by JS
• Layer 3: This would not be the default layer for anything. It's intended for mission and similar OXPs which absolutely need a particular system to have particular properties.

This gives precedence out of the box identical to Oolite 1.80 - JS overrides OXP planetinfo overrides OXP Universal overrides core Universal overrides core defaults - but with the added benefit that it's easier for OXPs to cooperate with each other if they both use the same system.

Setting in JS using system.info.[i]property[/i] = value; will still work, but there will also be a system.info.setProperty(property,value,layer); method to set at the other layers.

JS persistence

Another problem with the current planetinfo set up is that JS changes are permanent - they persist in the savegame even without the OXP that created them (whereas obviously if you remove an OXP using planetinfo.plist its changes go)

This is not good - OXPs shouldn't have effects on your game if you uninstall them. So, the plan here is that JS changes would be tagged with the manifest ID of the OXP that made them. If that OXP isn't there when you load the save game, it doesn't do it. This does mean that OXPs without manifests can't make persistent changes by script: that I think is an acceptable change given that adding a manifest to an OXP takes about five minutes, and most of the ones which make JS-based changes either already have a manifest or will remake the change anyway if it's not there.

New properties

There would be a few new properties needed.

Certain properties of the system - like the exact positions and types of the star and nebula boards on the starfield background, or the initial glow state of the sun corona - are only practical to generate randomly. There would be a random_seed property added to generate these.

Seeded random generation is currently the only source for where the systems are. There would be a coordinates property to specify this. (OXPs will be able to set this, but almost certainly shouldn't except for  oolite-scenario-only OXPs)

There are some properties which are currently not settable through planetinfo which could be made settable - the witchpoint-planet distance, the planet-station direction vector, and the planet-sun direction vector being three examples. While we're here we might as well make them proper planetinfo properties.

Modified properties

For the most part the intent is to take the systems as generated in 1.80 and just push their current properties into the planetinfo.plist file. There are two exceptions to this where I think replacing the existing properties on generation may be beneficial, both to do with the starfield backdrop.

• The number of stars. The current code generates a random number which is often zero or near-zero. There is a rough estimate of 6,000 stars visible from Earth unaided, so what I'd suggest is that all systems get a random number around 6,000 stars. (The existing limits on star count for low-graphics settings would continue to be applied). OXPs can still override this up or down by setting a universal property.
• The colour of stars. At the moment Oolite picks two entirely random colours, brightens them, and uses those colours and a range "between" them as the star colours. Many of these colours are implausible for stars to begin with, and it's not clear why one system has red and yellow stars while the next has green and purple. So, we'd instead set colours similar to those already used for sun colour generation to get a typical red/yellow/white/blue main-sequence spread.

Not included

While this change would make it significantly easier than it currently is to add extra galaxies or systems per galaxy, this is not going to happen as part of it. This is internally quite a significant change and will need time to settle down before further work in this area is considered. (And even with it, both are still challenging to do properly without allowing massive OXP conflicts)

[cim]

While I'm poking around planetinfo.plist, a few other things have come up...

There are a few parameters currently set in this file - baseline galactic hyperspace behaviour and coordinates for fixed galjump behaviour, hyperspace tunnel colours, shield/energy recharge strategy - which have increasingly less to do with planets. I'd like to separate these out into a separate gamesettings.plist file. I don't think any OXPs are affected by this, though it might affect people's local customisations.

I'd also like to make the docking clearance option default to on in future, and make it a normal per-system option. This makes it easier for beginners who are docking manually to avoid being rammed by launching ships as they creep up to the dock, and is consistent with the tutorial. Now that we have saving at non-main stations - and a guaranteed hermit in every system - it shouldn't be too bad for fugitive players [1], and they can always change it back.

Thoughts?

[1] Oolite doesn't support fugitive players very well in the core game anyway - no way to get equipment beyond basic missiles, joining up with pirate packs is unreliable, etc. If anyone wants to start a different thread to talk about how that could be improved I'll be interested to hear your ideas - especially if there are some which could go into the core game.

[Norby]

make the docking clearance option default to on

An optional auto request for clearance wolud be good to prevent fine after landing, especially for new players. Maybe a game option in F2 which send a request when the player target a non-hostile station, or a js function which send a request if called.

[Disembodied]

I'd also like to make the docking clearance option default to on in future, and make it a normal per-system option.

It might be worth having stations keep an eye out for player ships which look like they're on approach, and have them broadcast a message reminding them to request docking clearance, e.g.

Attention Cobra III: Yourshipnamehere! It is an offence to dock without prior authorisation. Please request clearance through authorised channels or vacate the docking lane immediately! Failure to comply may result in a fine and/or loss of breathing privileges.

[Rustem]

I wanted to write a OXP script for generating the corona parameters based on its description. But when you change the function by System.infoForSystem, the corona flare is written to the save file.

When used set value to null for OXP layer:

Code: Select all

System.infoForSystem(galaxyNumber, system.ID).corona_flare = null;
or
System.infoForSystem(galaxyNumber, system.ID).setProperty(3, "corona_flare", null);

but it is not delete from scripted_planetinfo_overrides and is set equal = 1.0. Is it possible to remove the other way?

Also, if multiple jump to the system, value of corona flare is acummulating. This could have been avoided if possible function to obtain the properties from layer - getProperty from planetinfo.plist (layer 1 or 2).

There is prepared properties solutions through planetinfo.plist, but it not automaticly generating.

Is there a correct generating through JS OXP?

[cim]

When used set value to null for OXP layer

Thanks - there was a bug with setting null for the corona_* properties. This will work as expected in tonight's build.

[Rustem]

This will work as expected in tonight's build.

Yes, it working. Thanks!