...on for 1/2 second then off for one second. I can do this with one timer, but it involves some kind of modulo arithmetic or somethin'?
I would have though just a boolean switch would have been sufficient: if the timer is on a 0.5 second repeat, flipping the boolean value would allow you to switch the effect on and off.
Yeah, anyway Moving right along...
Could I please get a definitive answer to the (mysterious to me) question of if, and when, one needs to clean up timers in world-scripts?
this.shipDied = this.reset = this.someoneLookedAtMeFunny = function () { /* code to stop and delete timers */ }
Using shipDied() should be sufficient for ship-scripts(?), but in world-scripts this seems to have been subject to changing fashions over the years.
Ignoring the one-liner addons ("This planet has rings"), there are two possibilities for the planet descriptions - the vanilla game goat-soup one and those provided by eg. Famous Planets/The Assassins Guild etc.
Is there any way of a second OXP selecting the display of Goat Soup F7 vs Famous Planets F7 - and then swapping the F7 description later? Or would this really need a rewrite of Famous Planets itself? I understand that the most recent F7 variants are stored in the Jameson save file.
Is there any way of a second OXP selecting the display of Goat Soup F7 vs Famous Planets F7 - and then swapping the F7 description later? Or would this really need a rewrite of Famous Planets itself? I understand that the most recent F7 variants are stored in the Jameson save file.
They are swappable. I made a demo... what was it called?... Wildeblood's Manor. But you claimed it didn't work for you?
They aren't really swappable anonymously/generically - you would have to know the details of the other OXPs you're interacting with. But, there's a lot of unused potential in SystemInfo that has been waiting to be discovered for years. Tell us more of what you have in mind?
Is there any way of a second OXP selecting the display of Goat Soup F7 vs Famous Planets F7 - and then swapping the F7 description later? Or would this really need a rewrite of Famous Planets itself? I understand that the most recent F7 variants are stored in the Jameson save file.
They are swappable. I made a demo... what was it called?... Wildeblood's Manor. But you claimed it didn't work for you?
They aren't really swappable anonymously/generically - you would have to know the details of the other OXPs you're interacting with. But, there's a lot of unused potential in SystemInfo that has been waiting to be discovered for years. Tell us more of what you have in mind?
Wildeblood's Manor did work for me eventually. I apologise for not confessing this to you earlier.
My question is inspired by Murgh's new alpha Mission oxp. It is based on the vanilla goat soup F7 descriptions. The division of economies/political systems/species into exactly eight each. And the descriptions: The world Xequerin is fabled for its weird volcanoes and the Xequerinian mountain lobstoid / Tiraor is a revolting little planet. / The planet Rabedira is well known for its inhabitants' ancient loathing of sit coms but ravaged by dreadful civil war. Why is it all so simplistic and bizarre?
But there are a number of other OXPs which overwrite the goat soup descriptions (Famous Planets, Riredi OXP, The Assassins Guild etc.). I was wondering if might be another way of dealing with that (other than declaring those OXPs as "Conflict OXPs" in his manifest.plist).
What makes sense to Murgh's mission is another matter... but I was dreaming of a piece of equipment (your retro-encabulator, perhaps?) which allows one to toggle between the various F7 descriptions.
Wildeblood's Manor did work for me eventually. I apologise for not confessing this to you earlier.
My question is inspired by Murgh's new alpha Mission oxp. It is based on the vanilla goat soup F7 descriptions. The division of economies/political systems/species into exactly eight each. And the descriptions: The world Xequerin is fabled for its weird volcanoes and the Xequerinian mountain lobstoid / Tiraor is a revolting little planet. / The planet Rabedira is well known for its inhabitants' ancient loathing of sit coms but ravaged by dreadful civil war. Why is it all so simplistic and bizarre?
But there are a number of other OXPs which overwrite the goat soup descriptions (Famous Planets, Riredi OXP, The Assassins Guild etc.). I was wondering if might be another way of dealing with that (other than declaring those OXPs as "Conflict OXPs" in his manifest.plist).
What makes sense to Murgh's mission is another matter... but I was dreaming of a piece of equipment (your retro-encabulator, perhaps?) which allows one to toggle between the various F7 descriptions.
You might be anticipating a problem where there isn't one. SystemInfo data comes in four layers: planetinfo.plist in the Resources folder, planetinfo.plists in OXPs, javascript and priority javascript. Mission OXPs should use the priority layer, only setting it when the mission actually starts,and cleaning up after themselves when they're done.
But, let's say hypothetically, you're so enamoured of the Famous Planets descriptions that you want to toggle back to them even when you're supposedly busy on a mission... then you'd copy the priority description out to a mission variable then delete it from SystemInfo, similar to what Wildeblood's Manor did. But, as I wrote above, there's no general solution: you need to know the OXP identifier you're dealing with to delete another script's priority entries.
Last edited by Wildeblood on Thu Mar 05, 2026 2:15 pm, edited 1 time in total.
Wildeblood's Manor did work for me eventually. I apologise for not confessing this to you earlier.
My question is inspired by Murgh's new alpha Mission oxp. It is based on the vanilla goat soup F7 descriptions. The division of economies/political systems/species into exactly eight each. And the descriptions: The world Xequerin is fabled for its weird volcanoes and the Xequerinian mountain lobstoid / Tiraor is a revolting little planet. / The planet Rabedira is well known for its inhabitants' ancient loathing of sit coms but ravaged by dreadful civil war. Why is it all so simplistic and bizarre?
But there are a number of other OXPs which overwrite the goat soup descriptions (Famous Planets, Riredi OXP, The Assassins Guild etc.). I was wondering if might be another way of dealing with that (other than declaring those OXPs as "Conflict OXPs" in his manifest.plist).
What makes sense to Murgh's mission is another matter... but I was dreaming of a piece of equipment (your retro-encabulator, perhaps?) which allows one to toggle between the various F7 descriptions.
You might be anticipating a problem where there isn't one. SystemInfo data comes in four layers: planetinfo.plist in the Resources folder, planetinfo.plists in OXPs, javascript and priority javascript. Mission OXPs should use the priority layer, only setting it when the mission actually starts,and cleaning up after themselves when they're done.
Thank you for that.
Any chance of an explanation of your comment above? "...there's a lot of unused potential in SystemInfo that has been waiting to be discovered for years" - what sort of thing are you thinking about?
Any chance of an explanation of your comment above? "...there's a lot of unused potential in SystemInfo that has been waiting to be discovered for years" - what sort of thing are you thinking about?
Many things. It's persistent storage that is much better organized than missionVariables. You can store arbitrary data in there, not just the official properties. If you want to add a property like average_house_price for your real estate agent OXP, you can do that. And once created, that data can be used by several OXPs using the layering, which missionVariables doesn't have.
You mentioned the eight government types. Add a government_precise property, then go Dewey decimal in there, specifying in excruciating detail precisely what sub-type of communism Vetitice enjoys.
Ever since this appeared 'I've been [present participle] with [abstract noun]:
-----------------------------
guiSelectedRowChanged
This method was added in Oolite test release 1.91.
The guiSelectedRowChanged handler is called whenever the player has selected a new item from any menu (for instance, by using the up/down arrow keys to select a new item), but before the player has pressed enter on that item. The screens where this will happen are: "GUI_SCREEN_OPTIONS", "GUI_SCREEN_EQUIP_SHIP"(F3), "GUI_SCREEN_SHIPYARD"(F3F3), "GUI_SCREEN_INTERFACES"(F4), "GUI_SCREEN_MARKET", "GUI_SCREEN_GAMEOPTIONS", "GUI_SCREEN_LOAD", "GUI_SCREEN_SAVE", "GUI_SCREEN_SAVE_OVERWRITE", "GUI_SCREEN_STICKMAPPER", "GUI_SCREEN_MISSION". Additionally, screens that can have multiple pages will also generate the event, but only when multiple pages are present. For example, the "GUI_SCREEN_STATUS"(F5) and "GUI_SCREEN_MANIFEST"(F5F5).
The event will fire after the guiScreenWillChange event, but before the guiScreenChanged event. You can query the global property "guiScreen" to determine from which screen the item was selected.
this.guiSelectedRowChanged = function(key : string, row : integer, text : string)
{
// your code here
}
The "key" parameter is the underlying key code for the selected row, based on the screen currently shown. The "row" parameter is the gui screen row index value for the selected row. The "text" parameter is the visible text of the selected row.
-----------------------------
I'm particularly enamoured with the line, "// your code here". It adds such an air of mystery, mixed with optative possibility. What could we do there ("here")? Well, that depends whether this event works the way I imagine it does. Are there any examples of this being used "in the wild" yet? If so, where, please? If not, could we get some exposition of how the developer(s) responsible imaged/intended it might be used?
As I read the above description, this event will fire every time the highlighted line on the screen changes? So, if one enters the market screen, then scrolls down to alien items, this event could fire 18 times in one second? Is that correct?
I'm particularly enamoured with the line, "// your code here". It adds such an air of mystery, mixed with optative possibility. What could we do there ("here")? Well, that depends whether this event works the way I imagine it does.
Or you could just put this code in a world script, run Oolite, and see what turns up in the log.
Are there any examples of this being used "in the wild" yet?
The one example I have that's "in the wild" probably isn't going to be much help to you. It's an accessibility helper, for blind players, which essentially reads out the text on whatever line gets selected. The code itself is just this:
All this is doing is storing the currently selected text for the screen, along with the key, then calling the $annouceSelection() function which reads it out loud. So, yeah, probably not much help.
Or you could just put this code in a world script, run Oolite, and see what turns up in the log.
Ya know, I thought of doing that, and then I remembered that the last time I tried to use Oolite on this machine it ran at a blistering four (4) frames per second.
The one example I have that's "in the wild" probably isn't going to be much help to you. It's an accessibility helper, for blind players, which essentially reads out the text on whatever line gets selected. The code itself is just this:
All this is doing is storing the currently selected text for the screen, along with the key, then calling the $annouceSelection() function which reads it out loud. So, yeah, probably not much help.
That's exactly the sort of thing I hoped to discuss. So, how do you deal with the scrolling problem I alluded to above? Presumably, you don't want every line read out if the player is scrolling quickly? You'd have lots of lines in a buffer, and what was being heard would not pertain to the actual currently highlighted line. So, do you start reading immediately and interrupt partly read messages immediately, resulting in stuttering? Or, do you implement some sort of dwell timing, so you don't start reading until the player has stopped rapid-scrolling and settled on a line?
If you did use a dwell time, did you base it on some academic scholarship or, "A half a second seems about right."?
That's exactly the sort of thing I hoped to discuss. So, how do you deal with the scrolling problem I alluded to above? Presumably, you don't want every line read out if the player is scrolling quickly? You'd have lots of lines in a buffer, and what was being heard would not pertain to the actual currently highlighted line. So, do you start reading immediately and interrupt partly read messages immediately, resulting in stuttering? Or, do you implement some sort of dwell timing, so you don't start reading until the player has stopped rapid-scrolling and settled on a line?
I didn't get far enough in the development to work out the best system. At present, it caches all the lines being selected and will slowly read them out, one line at a time, until it catches up. I was hoping to work on it more with the blind player who initiated the work, but he hasn't shown up in DIscord for a while.
If I was to return to this, I'd probably put some sort of slight delay on reading, and then empty the cache each time the up/down arrows are pressed. You might still get a stutter occasionally, but it would probably be acceptable.
Moving right along... 
