GUI_SCREEN_INVENTORY (not sure what screen that is)
GUI_SCREEN_LOAD (not sure what screen that is)
GUI_SCREEN_MARKET
GUI_SCREEN_REPORT (not sure what screen that is)
GUI_SCREEN_SAVE (not sure what screen that is)
GUI_SCREEN_SAVE_OVERWRITE (not sure what screen that is)
The values I'm not sure about are basically the ones not mentioned in the wiki. I guess LOAD, SAVE and SAVE_OVERWRITE are screens connected to the F2-screen when docked. I don't know which screens INVENTORY and REPORT refer to. At least there are no screens with these headlines.
My list differs from Ahrumans in a couple of points. Why that? I am running Oolite on a Mac in windowed mode. Could windowed be different from full-screen?
Tested the method to destruction by running Assassins Thargoid Wars and Military at the same time! Got the Assassins brief, hit launch before the game had chance to do anything (neither other OXP running). Killed my mark and docked. The Assassins guild thanked me. As soon as I had pressed space the screen flicked to the F5 screen for half a second, but before I could touch the controls. Thagoid Wars scrambled me to defend the station. Shot down a few Thargoids and docked. Now the Military offered me the chance to destroy the Military vessels. As STATUS screen works on both the Mac and Windows, the oneof should work on both. If I'd chosen orginally to remain docked for more then 10 seconds (which most players will) I'd have seen each brief in the same docking with no clash.
OXPS : The Assassins Guild, Asteroid Storm, The Bank of the Black Monks, Random Hits, The Galactic Almanac, Renegade Pirates can be downloaded from the Elite Wiki here.
GUI_SCREEN_INVENTORY is never used; I made a mistake. I’m removing it from the source code.
LOAD/SAVE/OVERWRITE are for loading and saving files, either at startup or from OPTIONS while docked (except under Mac OS X while running in a window).
Confirm that GUI_SCREEN_OPTIONS works while paused but not while docked (scripts should’t be firing at all while paused, they seem to be running on the wrong clock).
GUI_SCREEN_REPORT is when you’ve finished a contract.
The undefineds seem to have been fixed in 1.69 as part of general code cleanup. The new regime will also cause the compiler to generate a warning if a new one is added but not handled in the function that generates the strings for scripts.
Ahh, in removing the INVENTORY thing, I see there is in fact an explicit list of screens on which the script is checked while docked, helpfully labelled “screens from which it's safe to jump to the mission screen”:
I can confirm that the three UNDEFINED in 1.68 are displayed correctly in 1.69.
But my system doesn't seem to like the switching between different versions of Oolite. After restarting 1.68 again the background-picture of my HUD isn't displayed anymore.
I just observed that GUI_SCREEN_MARKET works correctly when in flight (as opposed to when docked).
It will work in any screen while in flight… this may need fixing, but then, you can’t actually buy anything on the market while in flight, so there’s no way for a mission to break something there.
I think (hope) all of us scripters always use a STATUS_DOCKED querying condition or something similar, when bringing up mission screens. So nothing that happens in flight could trigger a status screen.
And that should remain so, because every screen apart from the main screen the player looks at during flight means he flies blind for a shorter or longer time, which is generally not advisable.
You’re right. However, the existing code decides whether to run the script or not, not whether to allow a mission screen or not. It would be easy to stop script execution while the user is looking at the market screen in flight, but for scripts that actually do need to do something while you’re flying around that would be bad, so I won’t change this behaviour.
Looking forward, I want to introduce a new mission screen model for JavaScript, where mission screens are objects that are set up completely and then shown, without “leftovers” from previous mission screens etc. In that model, it should be simple to simply disallow mission screens under certain circumstances without interfering with other script execution. (This could be done now, but would probably break existing scripts which implicitly rely on not running on those screens where scripts are currently disabled.)
Would it be possible/desirable to invoke the 'non-view outside' screens when in flight by holding down the appropriate key, dropping straight back to the ahead view when the key is released...?
...possibly easier for sudden thoughts to check something whilst in flight...
Thinking again, there is however a problem. If the text of the other mission runs over more than one screen, than you get a PRESS SPACE COMMANDER at the end of the first screen. As soon as you press space, gui_screen_string changes to GUI_SCREEN_STATUS for some milliseconds. If the engine runs your condition "gui_screen_string equal GUI_SCREEN_MISSION" at that very moment, the condition will be false, the else-part will be entered and your first mission screen will be shown instead of the second screen of the other mission. And that's why we are going to need the variable on top of this method. So Eric is right.
Im sure you need the extra variable to be foolproof in all occasions. I did a little testing before my first post and even wrote a test OXP for this purpose. I tried to put it in this message, but I see not how this can be done. Anyone?
I am pleased with the reactions about the mission offering conflict. It seems that it was an ongoing problem were many others were struggling with. They however could lay the problem aside by advising to remove other OXP's.
In my case it was more difficult. In the OXP I am writing, there are 3 missions running parallel. And the locations are chosen at random. So I have no direct control in avoiding offering two missions on one docking. I had to deal with the problem and find a solution.
The problem was in short: I saw the offer of one mission, but on answering I noticed that the variables did not change, but those of the other mission that was not visibly offered, were set. Analyzing the problem I saw that this could also occur between different OXP's.
Making an offer if the mission-screen is free lets other missions wait politely on each other. For my OXP- this method was enough. Lets call this method A. I think in 95% of the missions this method is enough. But to make things foolproof you need a common variable between scripts to signal if offering a mission is save.
I propose the variable: "mission_offering". Lets call this method B.
The problem with only method A arises if a script want to show several pages. Take for example the Assassins script. In the OXP there is a walk outside he ship that is build up with a combination of many mission-screens. Of course you don't want that an other OXP makes an offer half way the walk.
Method A makes sure that the screens wait on each other. So halfway you get an other mission in between and after reaction on the offer, the original script will continue when only method A is used. So far the remaining problem is only cosmetic. But, if the second mission it e.g. Cmdr Wombats Targoids Wars that tells the station is under attack, you will be launched and the original mission is interrupted. With introducing a common variable this can be avoided.
On starting the walk assassins uses "set: mission_offering assassains_walk". The other OXP sees mission_offering is defined and politely waits. On some point the walk is ready and the assassins script uses: "reset: mission_offering". At this point the second OXP makes his offer, not sooner.
Before every mission-offer one checks if "mission_offering undefined". On starting a multi screen offer or an offer with a mission-choice one gives mission_offering a unique value. (e.g. the mission name with a number.) After the last page of after a mission-choice is made the variable is reset and will become undefined again.
And to make sure you start with an undefined value, mission_offering must also be reset after launching. (A player can launch during the mission offer, leaving the variable defined).
Only method B will not work with single page offers because you must reset mission_offering after the last page and there only one page. So to tackle al problems one needs method A in combination with method B. So before every mission offer one must check if :
Of cause things will only work seamless if both scripts use these rules. The B method can even be used to make sure that your mission is put first by defining "mission_offering" in space. However, scripters should never do that with the exception of rare occasions, like the nova mission where the nova counter is already running on docking.
-----
Looking at existing script one sees that mission_offering (or another temporary variable) is also needed in missions with a mission-choce. Lets take the Trumble mission as example. At the moment (in my version 1.65) it is wrongly programmed. Because of the bug you can bypass the trumble offer. It is a big mistake to use the mission variable itself to signal if a offer is made. And as lots of scripters copied this method, a lot of other missions have the same bug. I also started that wrong way.
I assume all scripters have looked at Oolite's own missions. Lets see what happens if a player launches during the trumble offer.
When on landing condition = ("mission_trumble equal BUY_ME") than an offer is made and mission_trumble changes into OFFER_MADE. Two other conditions now wait for the moment missionChoices becomes YES or NO. If the player launches at this moment, the condition "mission_trumble equal BUY_ME" will never occur again and the offer will never be made again.
Even worse: Part of the script stays waiting until missionChoises becomes YES. It won't become YES from the trumble mission but an other mission could offer a yes/no question and there is a good chance that the trumble mission is triggered by this answer and making it impossible for the original scrips to react as missionChoices will be reset by the trumble reaction.
So a big advice: never change the mission variable on an offer to just signal that an offer is made. Use a second temporary variable for this occasion. And what would be better than to use the newly proposed mission_offering variable for this purpose. Set this variable on making the offer with a unique value so no other missions will react on it. Reset mission_offering after a answer is given.
One other advise: never use a simple YES or NO as outcome of missionChoices. An other badly programed script could react on this. Better use a unique response like YES or NO in combination with your missionname, (e.g. YES-targoidwars of YES-trumble)
I think that if all scripts use method A and B together they will never become problems with colliding misson-offerings.
-----
Within this list someone asked if this method could handle long text offers that were broken in part with "press space". I have tested it. Long texts are not broke in parts by Oolite. (I tested this with Oolite 1.65). If the text is to long it just runs of the screen. It is up to the programmer give text just the right length. But it can be realized with a combination of both methods.
First give the first page of missiontext and set mission_offering to "page1".
In the next condition wait until the missionscreen is available again and mission_offering equal page 1. Then print page 2 and set mission_offering to "page2".
And so on. After the last page is printed, reset mission_offering again. I have tested t. It works well for multipage briefings.
