Info screen clash

[Ark]

When you capture a criminal or you rescue someone from space when you finally reach the station see an info screen telling you that “for rescuing ……” or “for capturing …"

I have noticed that there is a clash of this screen with other mission screens. Recently I was in leesti and a rescue someone in an escape capsule (well rescue him after I pirated him ). I haven’t completed the asteroid mission so the first thing I saw when I entered leesti station was the info screen for asteroid storm but the info screen about my reward for rescuing someone was gone, never saw it. I am wondering if the opposite clash can also happens, to miss a mission info screen for the favor of the info reward for rescuing or capturing someone screen.

[Commander McLane]

Should usually not happen. I think the engine handles the bounty/rescue/unload cargo screen first, before mission screens. So it should not be able to overwrite them. The opposite case does happen, however, and I am not sure whether it can be prevented. Mainly depends on whether the engine handles the bounty/rescue/unload cargo screen as a mission screen or a status screen, which I don't know ATM.

[Eric Walch]

I have noticed that there is a clash of this screen with other mission screens. Recently I was in leesti and a rescue someone in an escape capsule (well rescue him after I pirated him ). I haven’t completed the asteroid mission so the first thing I saw when I entered leesti station was the info screen for asteroid storm but the info screen about my reward for rescuing someone was gone, never saw it.

That is correct. Scripts that only checks for not missionscreen will overwrite any other screen. But as this screen holds no vital information, it is not to big a problem. Alternative the scripts should check for both screens not present.

I think the engine handles the bounty/rescue/unload cargo screen first, before mission screens. So it should not be able to overwrite them.

Normally yes, only the script from a scripted pilot runs earlier. When you let a scripted pilot set up a missionscreen, than that comes first. The system does not overwrite that missionscreen.

[Commander McLane]

The screen is called GUI_SCREEN_REPORT. So scripts could include a check for it and not put up mission screens as long as it is shown.

But it is strange. Just had a look into the Asteroid Storm script. It says:

Code: Select all

	if (!player.ship.dockedStation.isMainStation || guiScreen != "GUI_SCREEN_STATUS") return;

in the shipDockedWithStation event handler. So it shouldn't overwrite the report screen, because guiScreen is GUI_SCREEN_REPORT, not GUI_SCREEN_STATUS.

[Thargoid]

The GUI screen was probably GUI_SCREEN_STATUS when the check was made (by both scripts), but by the time the code then triggered to display the mission screen the display had already been changed to GUI_SCREEN_REPORT by the other script.

If it's scripted to be really robust there needs to be a second check immediately before the mission screen is requested perhaps, or some similar "time of use" checking?

[Eric Walch]

you are using an old version of Kaks. He changed the thing a few times before his final 3.45 release. (My current 3.50 release has not changed this.) Both use:

Code: Select all

if (this.myMissionShown || guiScreen == "GUI_SCREEN_MISSION" || (mission.choice && mission.choice != "")) return;

And that is better. With the code you mention, it will not show the screen, but there is no trigger when the report screen is finished. It will lead to not showing the mission screen at al when there was a report screen. (Unless you start up an additional timer to check this).

[Commander McLane]

Cataclysm also overwrites report screens with its mission screens, as I just checked.

My solution:

Code: Select all

this.missionScreens = function()
{
	if(guiScreen == "GUI_SCREEN_MISSION" || guiScreen == "GUI_SCREEN_REPORT" || !player.ship.docked) return
	// display mission screen
	.
	.
	.
}

and an addition in the guiScreenChanged event handler, in order to run the mission screen display function after the report screen:

Code: Select all

this.guiScreenChanged = function(to, from)
{
	if(from == "GUI_SCREEN_REPORT") this.missionScreens()
}

Works! And another problem squashed.

And I think this covers all cases. As far as I can imagine there are only three screens that could be displayed after docking: The status screen, (another) mission screen, or the report screen. Status screen is a 'go ahead' for my OXP, another mission screen or the report screen are 'STOP' signs, until they are finished.

[Eric Walch]

Code: Select all

this.guiScreenChanged = function(to, from)
{
	if(from == "GUI_SCREEN_REPORT") this.missionScreens()
}

Works! And another problem squashed.

And I think this covers all cases.

Not quite. The GUI_SCREEN_REPORT screen is internal on the list were it is not save to fire a tickle after display. The reason is multiple report screens. When there are more items than fit on one screen, it is followed by a next one when the player pressed space. Though, in this case this.missionScreens() will find another GUI_SCREEN_REPORT screen and do nothing. So it works, but a better solution would be to change the code and make the last GUI_SCREEN_REPORT screen fire a missionScreenEnded handler. (even it is not really a mission screen).

Thinking of it,.. It could be that when both to and from is the same screen, this.guiScreenChanged is never send and you don't have to worry about that.
Checked it with the code: guiScreenChanged is only send when to and from are different. And also will switching to GUI_SCREEN_REPORT screen not generate a guiScreenChanged event. Both reasons that your code will always work well.

For now I add your code also in next UPS release.