Planetary system renaming bug

[Eric Walch]

I can confirm that on the long range chart, when set in planetinfo.plist the name is changed there too, and works with the find function..

But not when you are changing the name via a Java script or debug console..

When it works with the planetInfo.plist and not with the JS.info, the problem is probably not so severe. I just did another test with the console and claimed my own planet:

Code: Select all

> system.info.name="Ericonia"
Ericonia
> system.ID
67

> system.systemNameForID(67)
Esdi
> system.systemIDForName("Esdi")
-1
> system.systemIDForName("Ericonia")
67

It seems that systemNameForID is also not working and returns the old name, while the opposite method, systemIDForName does not recognise the old name and needs the new name.

I think the overrides in the planetInfo.plist are not stored in the saved file, while the JS changes are definitely stored. (like the old legacy scripting =info= changes that are also stored in the save file)
Tested it and reloaded a save game with the changes brought back the changes with the same limitations as the JS alterations.

[Kaks]

Wow, doesn't time fly!

As it happens, it was a much more evil beast than I first thought, with a lot of small, related bugs!

I'll spare you the horrible details of that bug squashing, but everything should be ok now, including saving & loading games with renamed systems, restarting the game, long range map, and changing another system name using

Code: Select all

system.infoForSystem(0,55).name='Blah';

One potential issue that's still there: if you say rename Leesti to Bleh, the planet description will still say 'the planet Leesti...' etc..

Still, the standard description can always be overridden!

Cheers,

Kaks.

edit: the %H & %I problem is still there, I'll see if I can sort it out _without_ oolite crashing horribly when I've got a bit of time!

[Kaks]

Ok, as of rev.2244 everything should work: %H & %I now use the new scripted name ( %N isn't connected to the system's name ), and standard planetary descriptions use the new system name. In other words

Code: Select all

system.infoForSystem(0,55).name='Blah';

Will automagically generate 'the planet Blah...', all messages anywhere should refer to Blah, etc...

Of course, this also applies to changes inside planetinfo.plist stuff - afaik!
If everything tests out ok, we can then remove the present wiki warning!

What Eric said above still makes a lot of sense, though:

This inconsistency with renaming the system has been in Oolite forever. I don't know if it really was thought through that renaming should be possible. Names are listed everywhere in documentation and a lot of old style scripting has planet names hard-coded in the oxp. e.g. Random Hits or Galactic Navy sends you to a lot of fixed planet names. This would fail when the name changed.

With JS this is less of a problem. Since the last UPS release I also added a few fixed destinations, but I only stored the planet number in my code and ask Oolite for the system name when I need it.

It seemed very sensible to warn others on the wiki that changing names could cause several inconsistencies. Not only between oxp's but even within Oolite itself. And fixing this problem is probably time consuming as it will need fixing on many places in the code.

So anything that can change a system's name will most likely need something like this written next to it:
WARNING: other OXPs - like Random Hits or Galactic Navy - can be adversely affected by planet/system name changes. Any OXP that changes planet names needs to be thoroughly tested for compatibility with other OXPs.

[Eric Walch]

WARNING: other OXPs - like Random Hits or Galactic Navy - can be adversely affected by planet/system name changes. Any OXP that changes planet names needs to be thoroughly tested for compatibility with other OXPs.

Great work Kaks. With this fixed it becomes really possible to use this feature. And I think the current version of Galactic Navy won't suffer from name changes. Originally the names were stored, but I advised Nemoricus for his JS translation to only store ID numbers instead of names so the newest versions (5.0 upwards) won't have this problem and will use any changed names.

[Frame]

On the other hand, changing in system names for cosmetics, as when viewing the planet data screen is nice if your OXP is making use of features that like that to make a feeling of completeness.

For past 1.73 builds I think data on systems, should be in a separate data block, and always read/write.

For example, if you want to call up data, on a planet other than the main Planet (something you can do with JS)

Then there are two things that are fixed..

1 the planets appearance if not textured (if textured you can set a new texture, but not read what the present texture is, if any)

2 the planets diameter: allways locked to the mainPlanets diameter
----------
You can change the name, government, economy etc.. As you wish allready..

Now I'm only referring to the numbers on the data screen: The diameter should of course stay the same, once the planet has been created.. allthough if the diameter was read/write, it would allow for JS dynamic created planets of an OXP determined size...

I'm still working on the Solar OXP, now and then, homing in on something that is workable for all parties (past OXP's and future ones).

[Nemoricus]

Galactic Navy does in fact use the the system ID when it generates the mission system.

system.systemNameForID is used to get the name, so if somebody has changed the name, it should show up correctly.

[Kaks]

Thanks Nemoricus. I'd find it hard to give up on Random Hits, but it's good to know that at least the new Galactic Navy doesn't have problems with renamed systems!:)

For past 1.73 builds I think data on systems, should be in a separate data block, and always read/write.

For example, if you want to call up data, on a planet other than the main Planet (something you can do with JS)

Not quite sure what you mean there. Can you give more concrete examples?

Then there are two things that are fixed..

1 the planets appearance if not textured (if textured you can set a new texture, but not read what the present texture is, if any)

I think we can improve on the present situation. However, that could well mean ditching setTexture() after 1.73: we could have a read/write planet.texture property instead, set to return null if no .png is assigned to a planet, and returning a string with the name of the image if the planet has been texturized already.

Hmmm, while on the subject, there are inconsistencies with retexturing that need to be looked at between now and the release of 1.73. (See the Notes below)

Now I'm only referring to the numbers on the data screen: The diameter should of course stay the same, once the planet has been created.. allthough if the diameter was read/write, it would allow for JS dynamic created planets of an OXP determined size...

Only changing the numbers on the data screen is doable, but I think it would be very confusing, and probably generate a number of bug reports in due course... changing the actual planet size is not that doable: there's a lot of things inside a system that are calculated from the size of the main planet. I don't think that planet radius is going to be modifiable this side of 1.74

I'm still working on the Solar OXP, now and then, homing in on something that is workable for all parties (past OXP's and future ones).

Good to hear that! RL is not letting me play with Oolite atm, but who knows, one day I might just have time to try out Solar OXP!


Notes
At the moment ( edit in trunk ) .setTexture('newSurface.png') retextures a planet immediately, but the change is lost after a hyperspace jump.
All other retexturing methods, however, change a planet texture permanently (there are at least 5 more methods: 2 js, 2 legacy script ones & adding the texture key directly to planetinfo.plist), but changing the current system's main planet texture using the other methods will only take effect after a hyperspace jump.
In addition to that, setTexture() can be used on all moons and secondary planets as well as the main planet (could add a new crater to a moon if a specific event happened, for example), while all the other methods apply to the main planet only.

[Commander McLane]

Just to remind everybody: A mission immediatly springing to mind that uses fixed names is the Constrictor Hunt. So not only OXPs would be affected, but the built-in missions.

And as we know from a lot of ever-popping-up Constrictor threads on these boards, an amazing number of people manage to get lost during that mission even with unchanged names. Now imagine the confusion that would arise if you got the message

“A strange looking ship left here a while back. Looked bound for Arexe.”

but there wasn't even an Arexe.

And since we have localization OXPs, even changing the strings in missiontext.plist to something dynamic wouldn't be trivial.

*****

On the other hand and as a general remark: Personally I would consider any OXP that would attempt to change a major portion of planet names in the Ooniverse not so much an OXP, but a total conversion of Oolite. And other OXPs made for Oolite cannot honestly be expected to work with a total conversion.

[Eric Walch]

And as we know from a lot of ever-popping-up Constrictor threads on these boards, an amazing number of people manage to get lost during that mission even with unchanged names. Now imagine the confusion that would arise if you got the message

“A strange looking ship left here a while back. Looked bound for Arexe.”

but there wasn't even an Arexe.

Is solvable by rewriting that mission completely. However, it would be better to add a trigger for the expandDescription in the text itself e.g. %J76 would lead to replacement by the name of system 76 in the current galaxy. You still need to rewrite that mission but it will be easier as you only need to edit the missiontext. (And in js probably add an expandDescripion). It would even make writing an mission oxp easier as you need those system ID's anyhow. Currently you must always check if you use matching names/ID's

[Nemoricus]

The SpecOps mission does use the planet's name directly, if I remember correctly. I must fix that.

[Kaks]

WARNING Renamed planets need to be thoroughly tested for incompatibility issues: other OXPs - and inbuilt missions - can be adversely affected by planetary system name changes.

Right, rev. 2249!

ExpandDescription (and all related code, including mission description) now replaces %Jxxx (where xxx is a number from 000 to 255) to its corresponding name.

Here's a slightly edited 'log' from the javascript console:

Code: Select all

> system.name
Lave

> system.systemIDForName('lave')
7

> expandDescription('%J007')
Lave

> system.name='Shazam'
Shazam

> expandDescription('%J007')
Shazam

Please note the leading zeroes: if it's not 3 numbers it won't work, as per

Code: Select all

> expandDescription('%J78')
%J78

> expandDescription('%J078')
Soinuste

This was a very quick (i.e. not too thoroughly tested) update. It doesn't crash, and doesn't seem to leak memory, but don't quote me on that!
It's also a drive-by update.. I'm not entirely sure when I'll be back next, but I'll try not to be a stranger!

Hopefully we should now be able avoid the worst problems associated with planetary system renames. Still

It seemed very sensible to warn others on the wiki that changing names could cause several inconsistencies. Not only between oxp's but even within Oolite itself. And fixing this problem is probably time consuming as it will need fixing on many places in the code.

And of course, keep an eye out for the almost inevitable:

'I was looking for the constrictor near Xaddiquwa...'
'There's no planet called Xaddiquwa in the eight galaxies!'
'There is! I'm looking at it!'


Cheers,

Kaks

WARNING Renamed planets need to be thoroughly tested for incompatibility issues: other OXPs - and inbuilt missions - can be adversely affected by planetary system name changes.

[Kaks]

Oops! ex-duplicated post. nothing to see here.

[Frame]

ohh did'nt see that you had a ?

I Mean for past 1.73...

If we want to call up data on any other Globe, other than the main Planet, we need to be able to modify the on screen data...

presently

Diameter and the texture is locked to the main planet...

and of that

Diameter of an NON main planet should me read/write, so you could dynamicly and pseudo randomly set the size of our extra non-main planets, instead of having to have fixed entries in your planetinfo.plist file.

for example
presently i have things like this..

Code: Select all

"MarsType1M" = {
		position = "abs 0 0 50000000";		
		radius = 8970;
		ambient_level = 0.5;
		"polar_color_factor" = 0.0;
        	"rotational_velocity" = 0.001;
        	"percent_cloud" = 25;
        	"percent_land" = 75;        	
        	"clear_sky_color" = "colorRed";
        	"cloud_color" = "colorRed";
        	"polar_clear_sky_color" = "colorRed";
        	"polar_cloud_color" = "colorRed";
        	"land_hsb_color" = "0.84 0.69 0.38";
        	"sea_hsb_color" = "0.84 0.69 0.38";
        	"cloud_alpha" =  89;
        	};
        "MarsType1S" = {
		position = "abs 0 0 50000000";		
		radius = 3397;
		ambient_level = 0.5;
		"polar_color_factor" = 0.0;
        	"rotational_velocity" = 0.001;
        	"percent_cloud" = 25;
        	"percent_land" = 75;        	
        	"clear_sky_color" = "colorRed";
        	"cloud_color" = "colorRed";
        	"polar_clear_sky_color" = "colorRed";
        	"polar_cloud_color" = "colorRed";
        	"land_hsb_color" = "0.84 0.69 0.38";
        	"sea_hsb_color" = "0.84 0.69 0.38";
        	"cloud_alpha" =  89;
        	};
        	
        "MarsType1L" = {
		position = "abs 0 0 50000000";		
		radius = 13397;
		ambient_level = 0.5;
		"polar_color_factor" = 0.0;
        	"rotational_velocity" = 0.001;
        	"percent_cloud" = 25;
        	"percent_land" = 75;        	
        	"clear_sky_color" = "colorRed";
        	"cloud_color" = "colorRed";
        	"polar_clear_sky_color" = "colorRed";
        	"polar_cloud_color" = "colorRed";
        	"land_hsb_color" = "0.84 0.69 0.38";
        	"sea_hsb_color" = "0.84 0.69 0.38";
        	"cloud_alpha" =  89;
        	};

Thats alot of text, for something that differs only in size... which is why, diameter should be read/write for non main planets.

I'm not advocating for a read/write to the main planets diameter, but only for extra generated planets..

The textures of these(the generated ones), can never be shown either.

* in systems where System redux or any other OXP sets a texture for the main planet... we can trick the miniature into showing another texture, when on the system data screen.

* BUT We can never re-set the main planets texture, since we cannot read the texture of the main planet, and therefore we do not know what the texture originally was.

There are a bunch of work arounds for texture thing.. however not for procedual generated planets, which is why I think we need some way
to show the extra planets, in the planet/system data screen...

Pressing F7 twice is presently not used for anything... it would be perfect to use that somehow... like switching through all the extra planets or moons in the system, that have a property set like

Code: Select all

system.planets[n].OXPExtraPlanet = true

when not set to true, these are just uninteresting globes intended for viewing, not any actual use.

[Eric Walch]

Right, rev. 2249!

ExpandDescription (and all related code, including mission description) now replaces %Jxxx (where xxx is a number from 000 to 255) to its corresponding name.

Kaks, as always great work. I just altered Oolite mission descriptions on my computer. Replaced all planetnames by the new replacement code. Visiting one system for the conhunt mission showed that it replaced it correctly. (will add the new missionDescription.plist to my next commit when other agree to this change) So in future all the internal mission texts will follow any renaming.
But even when they are renamed in future I would still advise to not rename known mission systems.

[DaddyHoggy]

Right, rev. 2249!

ExpandDescription (and all related code, including mission description) now replaces %Jxxx (where xxx is a number from 000 to 255) to its corresponding name.

Kaks, as always great work. I just altered Oolite mission descriptions on my computer. Replaced all planetnames by the new replacement code. Visiting one system for the conhunt mission showed that it replaced it correctly. (will add the new missionDescription.plist to my next commit when other agree to this change) So in future all the internal mission texts will follow any renaming.
But even when they are renamed in future I would still advise to not rename known mission systems.

Perhaps "hands off" systems could be marked in the wiki? (or would this negate some of the special features (i.e. secrecy) of the in-built missions?)