Oolite Bulletins

I found the reason: It is a flaw in how Oolite handles the order. When looking more closely, there is no mechanism that offers the opportunity to the last oxp. The list of worldscripts is just always called in the same order from start.

Normally that results in that when script 1 till 10 have nothing to show, script 11 can show a series of screens and scripts lower in the list don't get an opportunity till 11 is ready. That means that scripts higher on the list, keep getting opportunities but normally will ignore it because they already skipped the first opportunity and conditions didn't change.

Anarchies is an exception, in that skips the first opportunity and than later decided that is does want an opportunity, based on the calculation in the guiScreenWillChange handler. Apparently anarchies was higher in the list and on the second opportunity offer, it took the opportunity before my oxp could. This problem can only be fixed inside the source by explicitly remembering the last script. The current handling is not a big problem as long as it happens rarely. No screen will we overwritten, it is just the order that can be mixed up. It could only become a problem when one of the oxp's forces a player launch.

Perhaps a problem with how you scripted the callback?

I didn't use callbacks because there were no options to select from. By generating a missionscreen from within a callback there will be no problem as there is not yes an opportunity given.

Eric Walch wrote:

Anarchies is an exception, in that skips the first opportunity and than later decided that is does want an opportunity, based on the calculation in the guiScreenWillChange handler.

I don't really follow.

The guiScreenWillChange handler only places a line on the manifest screen by using setInstructionsKey, and only if you go to the manifest screen. It doesn't run a mission screen at all.

You probably mean the guiScreenChanged handler? This one does run a mission screen, but only if the player presses F3. So it shouldn't get in the way of two mission screens following each other. It's only when the player visits the equipment store that a certain event may take place. Also, it's secured by using your old method of checking for missionVariables.offering (twice, to be sure). So, if you set this variable during your series, Anarchies won't interfere.

Commander McLane wrote:

I don't really follow.

I didn't really analysed your script, so I was just assuming. Looking better at when the amnesty offer is given, I see it has nothing to do with the changed screen handlers. In the missionscreenOpportunity handler itself there is a random change that it displays the offer. On every opportunity, anarchies is given the option to display his screen first. As long as the amnesty is not offered, the second oxp can show its series of screens until the dice falls correct for anarchies to display its amnesty offer.

I always was in the assumption that Oolite would give the opportunity to the oxp that did the last display, but that is not the case. I think that should change.

Eric Walch wrote:

I always was in the assumption that Oolite would give the opportunity to the oxp that did the last display, but that is not the case. I think that should change.

That's also what I would expect, so I agree that this is an Oolite bug that needs fixing.

Also, I find it conceptually correct that a mission screen can be brought up each time when missionScreenOpportunity is called, not just once, right after docking. It's basically the idea of missionScreenOpportunity that we're not limited to just after docking. If you want your mission screen to only run right after docking or not at all, you should set a variable during the first pass, or use reportScreenEnded.

However, having said that, I actually didn't fully realize the consequences of the fact that missionScreenOpportunity is called several times during your stay at a station. The result is that the chances for the mission to start are too high. I wanted to give a 2%-chance on a non-Anarchy main station. But because the event handler is called more than once, the actual chance is much higher. I have to think about that.

Also, this will of course influence every mission screen in every OXP that is called with a certain chance, as long as all other conditions are met. The fix is to do the chance calculation not in the missionScreenOpportunity-handler, but in the shipWillDockWithStation-handler and put it in a variable. missionScreenOpportunity will then only look at this variable, but not operate with a different value each time when it's called. Alternatively, one can of course use a pseudo fixed random number instead of Math.random().

Commander McLane wrote:

Eric Walch wrote:

I always was in the assumption that Oolite would give the opportunity to the oxp that did the last display, but that is not the case. I think that should change.

That's also what I would expect, so I agree that this is an Oolite bug that needs fixing.

If an OXP wants to call a mission screen to immediately follow on from its previous one, it can do mission.runScreen from the callback, which is guaranteed to be before any calls to missionScreenOpportunity.

Trying to work out which script should be sent missionScreenOpportunity is not entirely straightforward - what if you have a modular set up like New Cargoes where the callback of a mission screen ends up calling functions in other worldscripts, or someone doing something stranger but potentially valid and calling mission.runScreen from something other than a worldscript? The "which script is in charge" question is something Oolite already gets wrong at times. I'd rather "fix" this one by changing the documentation to reflect what actually happens, I think.

Anarchies 2.9:
- converted to OXZ format and uploaded into the expansion manager,
- contain the facelift by spara,
- apply a small fix from Eric,
- use a workaround to check only the first missionScreenOpportunity after docking,
- you can save in the additional stations, except in the Hacker Outpost which is not stationary.

V2.9.1 contain a patch from phkb:
- fixed issues with double Behemoths appearing in system
- fixed issues with the amnesty mission not being triggered when docking at the Behemoth
- fixed javascript "undefined" error relating to "bouy-witchspace".

I extended the [wiki]Anarchies[/wiki] page with the history from readme.

Version‭ ‬2.9.2‭ by phkb:
-‎ ‏updated all subentities to use new style
-‎ ‏updated equipment.plist to OpenStep format.
-‎ ‏updated shipdata.plist to OpenStep format.
-‎ ‏changed‭ ‬’background‭’‬ properties of mission screens to‭ ‬’overlay‭’
-‎ ‏added screen ID to all mission screens.
-‎ ‏updated station market scripts to use new style.
-‎ ‏updated equipment conditions to use a condition script.
-‎ ‏updated shipdata.plist to use a condition script.
-‎ ‏fixed incorrect texture reference in‭ ‬"afl-m-dock‭"‬ definition.

Thanks, Norby!

Thanks for the continued support, Anarchies has some of my favorite content for my combat pilot style!

Here is a random idea: what if some very few anarchist systems had their Coriolis station on fire? Griff has made a very nice model back in 2008 but it seems nobody has used it in any OXP yet, perhaps this would be an idea. See his post here: https://bb.oolite.space/viewtopic.php?t=3460&start=154

gsagostinho wrote: ↑Mon Jul 03, 2017 10:03 pm

Here is a random idea: what if some very few anarchist systems had their Coriolis station on fire? Griff has made a very nice model back in 2008 but it seems nobody has used it in any OXP yet, perhaps this would be an idea. See his post here: https://bb.oolite.space/viewtopic.php?t=3460&start=154

OMG thank you and Griff too!
I'll use this in Diplomacy :p

@Day it's a cool model, isn't it? It would be a pity if it was never used!

Hold on, one can download, only, a whole OXP from that link . .

UK_Eliter wrote:

Hold on, one can download, only, a whole OXP from that link . .

By that link do you mean the link I posted of the burning Coriolis by Griff? If so, the zip file does have an OXP inside but I don't remember if it is working or not, my interest in sharing it was just for the model.