Proposal for 1.82: planetinfo.plist changes
Posted: Tue Oct 07, 2014 9:05 pm
At the moment, the majority of properties which can be recorded in
This has a number of disadvantages:
The basic idea
The obvious solution is to statically code all of the initial values of the properties into the core game's
So, the plan is to add a "layer" property to
There would be four layers available, numbered 0 to 3, but OXPers would only need to care about 1, 2 and 3.
Setting in JS using
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
Seeded random generation is currently the only source for where the systems are. There would be a
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
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)
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.
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
};
- 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.
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.
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)