local planetinfo overrides

[Wildeblood]

Generally, how to amend information on the F7 screen, but prevent Oolite from storing the amendments in the local_planetinfo_overrides section of the player's saved game?

Specifically, for Explorers' Club, how to check the system displayed on the F7 screen against the array of visited systems, and append either "You have visited this system before." or "You have never visited this system." to the displayed systeminfo description, without that change being permanently added to local planetinfo overrides?

Any suggestions would be much appreciated.

[Capt. Murphy]

Wildeblood - I have an untested idea as to how this could be achieved. The check could be done as the player enters the f7 screen, the text added if appropriate, and then removed again as the player exits the screen.

[Kaks]

If you use the same methods the native Oolite missions use you won't be too far wrong: mission.addMessageText() & mission.addMessageTextKey() were created specifically to add on-the-fly info to gui screens...

Have a look inside oolite-constrictor-hunt-mission.js, inside the .guiScreenChanged event handler to see the TextKey variant 'in action' on the system data screen!

[Wildeblood]

If you use the same methods the native Oolite missions use you won't be too far wrong: mission.addMessageText() & mission.addMessageTextKey() were created specifically to add on-the-fly info to gui screens...

I assumed they only worked on the manifest screen, that's where everyone seems to use them. But look here, it's a bit gawdy on the system data screen, it changes the text colour from green to yellow.



I think backing up the description to some obviously named variable like this.system_description_backup on entering the F7 screen, then restoring it as you leave that screen would be a bit swisher.

Now, back to the subject of local planetinfo overrides, where can I read the documentation? I seem to have broken it.

I have saved games with lots of stuff in there, but it doesn't show up in game. I assumed a misplaced pointy bracket, so when I loaded and re-saved one I expected to see the local_planetinfo_overrides section flushed. But no, it's all still in there. So I'm thinking there's a limit to how much can be stored in there, and I've gone over the limit so the game is just ignoring it all?

[Capt. Murphy]

If you use the same methods the native Oolite missions use you won't be too far wrong: mission.addMessageText() & mission.addMessageTextKey() were created specifically to add on-the-fly info to gui screens...

Have a look inside oolite-constrictor-hunt-mission.js, inside the .guiScreenChanged event handler to see the TextKey variant 'in action' on the system data screen!

Just a note that mission.addMessageText() needs to be documented on the wiki...

[Eric Walch]

Just a note that mission.addMessageText() needs to be documented on the wiki...

You probably mean mission.addMessageTextKey() from Kaks remark? But there he was mixing things up as that method does not exists. mission.addMessageText() can be found on the Mission page.
But, I now added a comment that it works on non-missionscreens as well.

[Kaks]

Nope, mission.addMessageTextKey() does exist, and can be tested using the js console. However, it's defined inside oolite-global-prefix.js rather than next to .addMessageText() (not exactly sure why, but the big A might be able to tell us).
Maybe we should have an extra comment inside OOJSMission.m as a quick reminder...

[JensAyton]

Nope, mission.addMessageTextKey() does exist, and can be tested using the js console. However, it's defined inside oolite-global-prefix.js rather than next to .addMessageText() (not exactly sure why, but the big A might be able to tell us).

Because native callbacks are fiddly, error-prone and hard to maintain, and there’s no significant disadvantage to implementing it in the prefix. This is the motivation for the various other convenience wrappers defined there, too.

(My basic position is/was that anything that can be implemented in JS without a significant performance hit should be. For example, I evaluated implementing all vector and quaternion operations in JS, but it turned out that building JS vector objects from C using slots for the fields was significantly more expensive than sticking a malloced struct in the private field, and doing maths in JS using the private-field approach was significantly more expensive than using slots. This could of course change with future versions of SpiderMonkey.)

[Kaks]

Aha, I knew there was a reason!

Thanks, Ahruman!

[Kaks]

Now, back to the subject of local planetinfo overrides, where can I read the documentation? I seem to have broken it.

I have saved games with lots of stuff in there, but it doesn't show up in game. I assumed a misplaced pointy bracket, so when I loaded and re-saved one I expected to see the local_planetinfo_overrides section flushed. But no, it's all still in there. So I'm thinking there's a limit to how much can be stored in there, and I've gone over the limit so the game is just ignoring it all?

 Here!

When loading a savegame, the overrides inside the savegame are superimposed to all the overrides in all planetinfo.plists.
When changing a system's value - via javascript or legacy scripting - the overrides are updated immediately.

When retrieving any system data Oolite does the following:

• it generates the pseudo-random data
• it looks for all possible overrides, and uses the overridden data if present.

There's no limit to the override data that can be stored inside either planetinfo.plist, or the savegame. If you want, you could PM me the savegame(s) in question, and I can try & figure out what's going on...