Mission offering

[Hoopy]

maybe it was with buying fuel that it happened. Even half a second might be long enoughfor a commander to press return. It's very easy to see the Aegis symbol and just type 'C', F3, Enter to dock and refuel.

Hmm...

[davcefai]

This may be a silly suggestion but FWIW:

Is it possible to display, say, a red flashing rectangle in a corner of the screen which will indicate that something is about to happen?

[JensAyton]

This may be a silly suggestion but FWIW:

Is it possible to display, say, a red flashing rectangle in a corner of the screen which will indicate that something is about to happen?

Almost certainly not without a lot of redesigning. (This would require everything that “happens” to be delayed, and the game would have to lie to scripts or suspend their execution, which it can’t currently do cleanly.)

[Eric Walch]

Ahruman, in the Wiki with: function resetMissionChoice() you write:

(Open issue: why not just make choice read/write? --ahruman)

You are looking for a reason to make it read/write? There is a very good one. My original proposal to create clash-free offers contained two things that were needed.

1- Always check first if there is already a mission-screen before adding a new one.

2- Introduce a variable to check if a oxp intends to add a next page. (for multipage offerings)

Item 1 is accepted by now and avoids 99% of the clashes. For point 2 I suggested a common variable "mission_offering". But most writers don't want to check for a variable they don't use themselves and is only there for rare events.

But the missionChoice key itself could also be such a variable. This one is more used and already checked by other oxp's. It also gets his own clearing event handler that makes it more useful than my original mission_offering.

I'll make things clear with an example.

When I put up a screen with choices there is no problem for multipage display. Other scripts wait until the screen is cleared and the choices are cleared. But when immediately after clearing the choices a next screen is displayed, there will be no problem, the script gets his second screen.

Problem arises with a screen without choices. When this clears, the first oxp that runs gets an opportunity to display a screen will do it. To claim a second screen in this case could be done by setting mission.choice = "busy". Other scripts see a choice that is not cleared and wait. When the script runs that put up the busy message, it knows it was his choice and he can set up his second screen.

Everything depends on missionclash proof programming but this concept does not depend on the use of the mission.offering and is more likely to be commonly accepted. But we need it only for multi screen offerings with screens that have no choices.

[JensAyton]

I was wondering whether there’s a reason not to make it read/write. There doesn’t seem to be, so it will be in 1.71.

Actually, there is one issue. missionChoiceWasReset() is currently sent to all scripts when resetMissionChoice() (or the legacy script method resetMissionChice) is called. I think I’ll keep that notification for setting the choice to null, but not notify when setting to another value; this reduces the chance of infinite recursion if a script tries to change mission.choice in its missionChoiceWasReset() handler, and I don’t think other changes are as interesting.

Edit: done; mission.choice read/write, mission.resetMissionChoice() deprecated.

[Eric Walch]

Oolite 1.73 will have an reportScreenEnded() eventhandler. With older Oolite you could only detect this by using the guiScreenChanged() handler what was a bit extra work.

On docking there are two screens that are only shown once, that is the "arrival report screen" and the "mission screen". Because the player cant restore this page, missions should not erase the current page when these are shown. With legacy code it is simple: every 10 seconds the script is activated and can check if these pages are free.

JS is event driven so when skipping these pages we need an event to presume our code. This new reportScreenEnded can be used at the same locations as the missionScreenEnded. And when a missionscreen ends and has open choices that not belong to your oxp, you also have to postpone action until the owner of that closed missionpage has processed the choices. Here we need the missionChoiceWasReset to proceed. They all signal the script it can start evaluating its own missionstuff. In code it would look like:

Code: Select all

this.missionScreenEnded = this.reportScreenEnded = this.missionChoiceWasReset = function()
{
   // add your mission stuff here;
}

To test the new reportScreenEnded() it was convenient to have a method to put my own text on that screen instead of scooping a lot of escape pods. So I also added a method for the player (like the commsMessage() and the consoleMessage()): addMessageToArrivalReport(). This adds a message to the arrival report. More info on the scripting pages about player and eventhandlers.