I've just noted an glitch with this.guiScreenChanged. It does not fire when you go from a static gui screen to a flight screen (e.g. when docked pressing F1, or when flying by pressing F1 to F4, both from a GUI screen like the status screen or the marketplace one).
When in-flight if you go to a gui screen it fires correctly (parameters from returned as GUI_SCREEN_MAIN and to returned as GUI_SCREEN_STATUS) but if you then go the other way it doesn't fire (I would expect a trigger with from = GUI_SCREEN_STATUS and to = GUI_SCREEN_MAIN).
Editted to add - this.missionScreenEnded also suffers from the same problem when docked. It doesn't trigger if F1 is used to exit a displayed mission screen. It does however if you use F1 to F4 to leave a mission screen when in-flight when tested using the script below.
Editted to add mk 2 - As a note, if the script is linked to the player ship via shipdata.plist, this.missionScreenEnded does NOT fire when leaving the screen in-flight. However it does if the script is set up as a normal world script.
From a gui screen point of view there's no difference in the code between all the cockpit screens, ie f1-f4. Status to main ? Oopsie!
As for the launch bit, yes, also a bit of an oversight, there being about 57 (ok, might be less! ) other events firing at that particular time...
Mission screen ended is deprecated, and will disappear altogether in future versions of Oolite, in favour of the new, encapsulated mission handling introduced in 1.74.
I've just noted an glitch with this.guiScreenChanged. It does not fire when you go from a static gui screen to a flight screen (e.g. when docked pressing F1, or when flying by pressing F1 to F4, both from a GUI screen like the status screen or the marketplace one).
Its probably not a bug, but a (bad) choice. The wiki does not tell it, but this.guiScreenChanged only fires for selected screen switches that seemed usable for scripting at the time of adding the handler. Maybe this combination was just forgotten to add as usable. Unlike other handlers, this handler must get inserted in the code at dozens of different places in the source were a screen switch occurs.
It thus makes the use of any kind of mission screen whilst in-flight severely limited, as you can't react to coming out of them other than via a choice.
From what I can see (using the test script) it fires for moving between all gui screens except coming out to the flight screen as mentioned.
And as far as I can see aside from a choice selection there is no way to detect leaving a mission screen in the 1.74 mission set-up, so if missionScreenEnded is depreciated (it isn't signalled as such in 1.74.2) then the only alternative is guiScreenChanged, and that doesn't work reliably enough to take over...
I'm not sure I follow what you're saying: I thought that no matter how it happens, when you leave a mission screen the js function specified in runScreen is called anyway (with either a null parameter, or the choice you actually made).
If I display a mission screen in-flight and leave it via F1/F2/F3/F4, this.guiScreenChanged does not fire but this.missionScreenEnded does.
If I display a mission screen whilst docked and leave it via F1, neither this.guiScreenChanged nor this.missionScreenEnded fires.
Hence if this.missionScreenEnded is removed, we cannot detect leaving a mission screen in-flight unless that screen offers a choice and something is selected (and we detect by the firing of the defined callback function). If there is no callback function then you can't detect the ending otherwise.