missionScreenEnded does not work in trunk 1.75.0.4324

[Okti]

Hi,

One of the OXP's I wrote was handling missionScreenEnded in 1.74.2 and it worked fine. But the trunk version 1.75.0.4324 seems not to raise the event.

Any Idea?


Okti

[Okti]

Bug is confirmed by gizmo as well in Expansions packs

[gizmo]

To save the programmers / debuggers some searching:
relevant post: https://bb.oolite.space/viewtopic.php?p=129697#p129697
trunk version: 4341 (Linux)

Edited to add:
I'll try again with trunk version 4351.

[gizmo]

Same problem with build 4351

[Kaks]

The mission screen handling introduced in 1.74 doesn't require manually untangling different mission screens using missionScreenEnded.

I believe there was a 'warning: deprecated' attached to that event at some point, but somehow that warning doesn't seem to have made it to the wiki documentation yet...

[JensAyton]

The mission screen handling introduced in 1.74 doesn't require manually untangling different mission screens using missionScreenEnded.

We’ve been through this elsewhere. :-)

Turns out somebody implemented a complete replacement for missionScreenEnded() in all the cases it used to be relevant, then added new situations where the replacements aren’t useful…

[Kaks]

Tsk!
I suppose missionScreenEnded (& maybe a mission.screenRunning bool) might still prove useful to those reckless enough to want to program mission screens while in flight...

About the docked situation: unfortunately, it's still perfectly possible to overlap mission screens while docked by totally ignoring missionScreenOpportunity, and putting mission.runScreen()s inside shipSdockedWithStation instead...

[Commander McLane]

About the docked situation: unfortunately, it's still perfectly possible to overlap mission screens while docked by totally ignoring missionScreenOpportunity, and putting mission.runScreen()s inside shipSdockedWithStation instead...

...which is especially true for old, not-yet-updated OXPs. *peers over his spectacles at the person in the mirror*

[JensAyton]

I suppose missionScreenEnded (& maybe a mission.screenRunning bool)

guiScreen === "GUI_SCREEN_MISSION"

[Kaks]

Problem solved!

By the way, I'm under the impression it was perfectly feasible to run mission screens while in flight for both 1.73 & 1.72 - the only 'minor annoyance' there would be that the player couldn't select any options...

[Okti]

Thanks Kaks,


Being one of the reckless, trying to use mission screens during flight for cheating purposes, I think some of the OXP writers can find it usefull to give commands to their squadron or many clever things can be done.

Priming an equipment, is realy good in version 1.75. But I believe if it is supported by mission screens with choices this option can be used cleverly.

Okti

[Kaks]

I would have thought you could run mission screens with primed equipment:

Code: Select all

mission.runScreen(parameters, callback);

is just another way of saying: run the function called 'callback' when the mission screen is ended (either by the player making a choice, or pressing F1, for example)

[Okti]

This Method Works Fine.

[Svengali]

Specially in fighting situations missionscreens (or when should group members get commands?) are bad and if I get this right exactly that's why Ramirez isn't using it. I'm playing with different approaches for a while now and screens are the worst option.

I think using a clever structure with primable EQs only is the way to go.

[Kaks]

True, Ramirez temporary missiles/instruction icons seems the best option yet for battle situations, though that does make that equipment only available if the player has at least X missile pylons in total...