runScreen not always firing when expected to

[PhantorGorth]

I am writing some mission screen code.

I have in this.guiScreenChanged:

Code: Select all

if ((this.suspendLottery == false) && ((player.ship.dockedStation.isMainStation == true) || (player.ship.dockedStation.GalCop_Rewards_inScheme == true)) && (player.ship.docked == true) && ((from != "GUI_SCREEN_MAIN") && (to != "GUI_SCREEN_MAIN") && (from != "GUI_SCREEN_REPORT") && (to != "GUI_SCREEN_REPORT") && (from != "GUI_SCREEN_MISSION") && (to != "GUI_SCREEN_MISSION") && (to != "GUI_SCREEN_GAMEOPTIONS") &&  (to != "GUI_SCREEN_LOAD") && (to != "GUI_SCREEN_SAVE") && (to != "GUI_SCREEN_SAVE_OVERWRITE")))
		{
			this.processInterval("Docked");
		}

The processInterval() function eventually calls GRChooseVoucherScreen() which includes this code:

Code: Select all

log(this.name + " guiScreen=" + guiScreen);
mission.runScreen({titleKey: "GalCop_Rewards_Choose_Screen_Title", messageKey: "GalCop_Rewards_Choose_Screen_Intro", choicesKey: Choice_Key}, this.callbackGRChooseVoucherScreen);

This mostly works but sometimes the log(this.name + " guiScreen=" + guiScreen) shows "GUI_SCREEN_STATUS" but the runScreen line fails to work (no mission screen appears).

If it was GUI_SCREEN_MISSION I would understood as it says that you can't use runScreen if you are in a mission screen in the wiki but as that log line say I am not in GUI_SCREEN_MISSION I am confused to why it fails.

Any explanation and any work around I would be extremely grateful.

Info:
Oolite Version: 1.75.3
OXPs (mostly my own half done ones):
Debug.oxp
Free_Slaves.oxp
PlanetFall 1.12.oxp
TestVisa1.oxp
TestVisa2.oxp
Visas.oxp
Safe_Docking.oxp
TripleF5.oxp
GalCop_Rewards.oxp (the one with the issue)

Regards

Phantor Gorth

[Eric Walch]

I don't see how this can happen.

I do see another bug with missionscreens overwriting each other. The only place you can safely use runScreen is inside a missionscreenOpportunity event. On every other place the scripter is responsible for checking there is not already a missionscreen on display. Outside the opportunity you must always check: "guiScreen != GUI_SCREEN_MISSION". That check is currently missing in your code.

And I also think you can skip the following checks: (to != "GUI_SCREEN_MISSION") && (to != "GUI_SCREEN_LOAD") && (to != "GUI_SCREEN_SAVE") && (to != "GUI_SCREEN_SAVE_OVERWRITE").
The this.guiScreenChanged handler will not fire for those pages because there is nothing a script should do on those pages.

[Micha]

Also, why are you still using 1.75.3 for OXP development instead of 1.76?

[Thargoid]

Also you seem to check if the player is docked after you've checked two examples of what the docked station will be? Either the check for player.ship.docked is superfluous, or one of the preceding two will fail badly as dockedStation won't have any properties (as you won't be docked). The order would be better with the dock check first (and in an if statement you don't need ==true, just player.ship.docked is sufficient, the check for true is implicit).

Also when the trigger doesn't occur, you're logging which screen you end up in, but not which one you came from. If you're testing a misbehaving if statement, you need to log everything that the statement checks. You can even do this with a separate little OXP just to do the logging (use this.guiScreenChanged to log to and from).

Lastly player.ship.dockedStation.GalCop_Rewards_inScheme looks suspicious as well. It would either be an ownProperty, or a reference to the station's script perhaps?

[PhantorGorth]

I don't see how this can happen.

I do see another bug with missionscreens overwriting each other. The only place you can safely use runScreen is inside a missionscreenOpportunity event. On every other place the scripter is responsible for checking there is not already a missionscreen on display. Outside the opportunity you must always check: "guiScreen != GUI_SCREEN_MISSION". That check is currently missing in your code.

That is what was confusing me. I hadn't put the guiScreen check in as I had a from/to != "GUI_SCREEN_MISSION" higher up in the code chain. Though technically that isn't a check on the current screen it should have cover it. Yes there is another mission screens from my WIP Visas OXP on the triple-F5 which is the only mission screen that could interfere, given my OXP list. I was rotating through single, double and my triple F5 screens to test the code; waiting for the 1 minute interval to be crossed and my GalCop_Rewards mission screen to appear. Unfortunately given the line above the runScreen call is a log showing the value of guiScreen which showed that the value was "GUI_SCREEN_STATUS" (I was thinking that it could have been "GUI_SCREEN_MISSION") means that that the other mission screen must have launched between the two lines. As I got this a few times not just a one off I would find that explanation extremely unlikely.

I will do more testing.

And I also think you can skip the following checks: (to != "GUI_SCREEN_MISSION") && (to != "GUI_SCREEN_LOAD") && (to != "GUI_SCREEN_SAVE") && (to != "GUI_SCREEN_SAVE_OVERWRITE").
The this.guiScreenChanged handler will not fire for those pages because there is nothing a script should do on those pages.

That is useful to know.

[PhantorGorth]

Also, why are you still using 1.75.3 for OXP development instead of 1.76?

Because I haven't got round to upgrading yet. Anyway I was going to test my OXP against 1.75.3 and then upgrade and test again against 1.76 so I can say that is works in both.

[PhantorGorth]

Also you seem to check if the player is docked after you've checked two examples of what the docked station will be? Either the check for player.ship.docked is superfluous, or one of the preceding two will fail badly as dockedStation won't have any properties (as you won't be docked). The order would be better with the dock check first (and in an if statement you don't need ==true, just player.ship.docked is sufficient, the check for true is implicit).

It is likely superfluous. I will check the possible circumstances and adjust accordingly. I have made significant changes to the code over time so it is likely hangover from previous versions. The ==true is to make my reading of the code easier. Though I am likely not to be consistent about that.

Also when the trigger doesn't occur, you're logging which screen you end up in, but not which one you came from. If you're testing a misbehaving if statement, you need to log everything that the statement checks. You can even do this with a separate little OXP just to do the logging (use this.guiScreenChanged to log to and from).

I have that logging code in my Visas OXP so I didn't need to add that.

Lastly player.ship.dockedStation.GalCop_Rewards_inScheme looks suspicious as well. It would either be an ownProperty, or a reference to the station's script perhaps?

GalCop_Rewards_inScheme is an ownProperty if my understanding of that term is correct. It's there for other OXP developers to specify that a station, other than a main station, is participating this reward scheme.

[Kaks]

Also, why are you still using 1.75.3 for OXP development instead of 1.76?

Because I haven't got round to upgrading yet. Anyway I was going to test my OXP against 1.75.3 and then upgrade and test again against 1.76 so I can say that is works in both.

Some screen switching events weren't firing up properly in 1.75.3, and were fixed for 1.76; chances are that if you were to use 1.76 you might not have these problems.

Since no-one else has got your WIP OXPs it can be a bit tricky for us to try and exactly replicate your problem.
Of course, we're more than happy to fix 1.76 bugs.

About works in both: 1.75.x was the beta for 1.76, I don't really think many players would be too worried if your oxp didn't work with a beta version of Oolite...

[Eric Walch]

That is what was confusing me. I hadn't put the guiScreen check in as I had a from/to != "GUI_SCREEN_MISSION" higher up in the code chain. Though technically that isn't a check on the current screen it should have cover it.

The 'to' in guiScreenChanged() is often a bit of useless in my opinion. In most cases you don't want to know were the original code changed to, but you want to know the page you are currently viewing. As all oxp get the guiScreenChanged() trigger, some other oxps could already have changed the current screen before the handler fires for your oxp.
its a general bug as I also witnessed it in the wip version of XepatlsSword.oxp (fixed in the released one) and in CoyotesRun.oxp (not fixed as far as I am aware).

About the guiScreenChanged() not firing for some screens: I think it should go to the wiki for which screens it triggers. (The list was published somewhere on this forum when the handler was added, but nobody can expect that we still know how to find this list. )

[PhantorGorth]

Some screen switching events weren't firing up properly in 1.75.3, and were fixed for 1.76; chances are that if you were to use 1.76 you might not have these problems.

Ok I will upgrade and try again.

[PhantorGorth]

The 'to' in guiScreenChanged() is often a bit of useless in my opinion. In most cases you don't want to know were the original code changed to, but you want to know the page you are currently viewing.

It isn't useless if you are launching a mission screen when you go from one particular screen to another particular screen. This is done for my Triple-F5 screen I use in my Visas WIP.

As all oxp get the guiScreenChanged() trigger, some other oxps could already have changed the current screen before the handler fires for your oxp.

I have already ruled that out as otherwise the log line, the line before the runScreen line, would have shown "GUI_SCREEN_MISSION". It didn't, it showed "GUI_SCREEN_STATUS" instead. Though there is a possibility that the mission screen was shown but got overwritten by the Triple-F5 screen (which shows on going from GUI_SCREEN_MANIFEST to GUI_SCREEN_STATUS). I will look into this.

About the guiScreenChanged() not firing for some screens: I think it should go to the wiki for which screens it triggers. (The list was published somewhere on this forum when the handler was added, but nobody can expect that we still know how to find this list. )

Good idea.

[PhantorGorth]

It is looking like I have fixed the issue. It was Visas OXP's Triple-F5 mission screen overwriting the GalCop_Rewards one. I added a check for "GUI_SCREEN_MISSION" in the guiScreenChanged event in Visas and the problem seemed to go away.

I may still need to do immediate checks at the point of calling runScreen in both OXPs though.

[Kaks]

Good to know! Looking forward to seeing the finished oxps!

[Switeck]

This message thread has already improved my simple WIP to make a special short-ranged cargo contract offer "mission" to the player. It's supposed to be another Cargo Contracts screen, accessible via pressing F8 3x's in a row.

Code: Select all

this.guiScreenChanged = function(to, from)
{
	if (guiScreen == "GUI_SCREEN_MISSION" || guiScreen == "GUI_SCREEN_REPORT" || galaxyNumber != 0 || system.ID==129) return; 
	if(guiScreen == "GUI_SCREEN_MARKET" && from == "GUI_SCREEN_CONTRACTS") {
		mission.runScreen({titleKey: "srcargo_title", messageKey: "srcargo_brief", model: "dodecahedron"});
	}
}

My main problem is I have yet to figure out how to offer mission choices. I'll be studying a few mission OXPs to figure it out.

[PhantorGorth]

This message thread has already improved my simple WIP to make a special short-ranged cargo contract offer "mission" to the player. It's supposed to be another Cargo Contracts screen, accessible via pressing F8 3x's in a row.

Code: Select all

this.guiScreenChanged = function(to, from)
{
	if (guiScreen == "GUI_SCREEN_MISSION" || guiScreen == "GUI_SCREEN_REPORT" || galaxyNumber != 0 || system.ID==129) return; 
	if(guiScreen == "GUI_SCREEN_MARKET" && from == "GUI_SCREEN_CONTRACTS") {
		mission.runScreen({titleKey: "srcargo_title", messageKey: "srcargo_brief", model: "dodecahedron"});
	}
}

My main problem is I have yet to figure out how to offer mission choices. I'll be studying a few mission OXPs to figure it out.

Not really the place to discuss this. Start a new thread in the appropriate forum section and we can discuss it there.