runScreen not always firing when expected to

[Switeck]

I only offered the code example because for the simple case of showing the mission briefing...it works.

[Capt. Murphy]

Why don't you let this.missionScreenOpportunity deal with potential conflicts? Anywhere you want to runScreen, set a flag, and manually call this.missionScreenOpportunity().

Under the event handler function include a condition check for the flag and if met the appropriate runScreen command. It is easy this way to look after multiple screens, daisy chain screens etc. Take a look at the current Explorers' Club to see how the options and associated screens are set up.

[Eric Walch]

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.

I disagree here. Specially when you use it for showing a missionscreen, or adding text to the current screen it is useless. It is not guaranteed that the 'to' screen is the current screen, so you must test for the current screen instead of the 'to' screen. When no other oxp het interacted during this handler, both screens still will be the same.

The only time when you can use the 'to' is when just setting a few variables on the action and you are not interested in the actual current screen.

[PhantorGorth]

Why don't you let this.missionScreenOpportunity deal with potential conflicts? Anywhere you want to runScreen, set a flag, and manually call this.missionScreenOpportunity().

Under the event handler function include a condition check for the flag and if met the appropriate runScreen command. It is easy this way to look after multiple screens, daisy chain screens etc. Take a look at the current Explorers' Club to see how the options and associated screens are set up.

I am considering this.

[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.

I disagree here. Specially when you use it for showing a missionscreen, or adding text to the current screen it is useless. It is not guaranteed that the 'to' screen is the current screen, so you must test for the current screen instead of the 'to' screen. When no other oxp het interacted during this handler, both screens still will be the same.

The only time when you can use the 'to' is when just setting a few variables on the action and you are not interested in the actual current screen.

The circumstances I am referring to are not about knowing the current screen but about the one you will be going to, to intercept. My Visas' Triple-F5 screen is a mission screen acting as a gui screen to provide information about the Visas you own. It is accessed by pressing F5 on the Manifest screen. Under normal circumstances the screen then displayed is the Status screen but on guiChangeScreen event I use the fact that "from" is GUI_SCREEN_MANIFEST and "to" is GUI_SCREEN_STATUS to launch my mission screen. It doesn't matter which screen the current actually is at that moment just that the screen it's going to is meant to be GUI_SCREEN_STATUS and you are coming from is GUI_SCREEN_MANIFEST. This is purely about navigation of screens, not what is displayed. The only proviso is to make sure that the current screen isn't another mission screen, which caused me a headache for my GalCop_Rewards OXP. When you press space on the Visas' mission screen the screen displayed should be, but doesn't necessarily need to be, the Status screen, but if it is, the navigation looks like I have added a screen to the F5 button cycle which is what I am after.

[Commander McLane]

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).

There should always be a check for player.ship.docked first. It's never superfluous. The reason is that it is possible to immediately re-launch the player by script upon docking. Scripts that check for a property of the docked entity (like isMainStation or another one) will throw an error, because dockedStation is already null and therefore has no properties. I'm just checking this situation of docking and immediate script-induced re-launch, and Snoopers is giving me this error every time:

Code: Select all

22:24:33.331 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (snoopers 2.1): TypeError: player.ship.dockedStation is null

[Thargoid]

I meant where it is in the posted script it's superfluous (either the preceeding checks self-evidently prove that the player is docked, or the script will bomb out with precisely the kind of error you posted and will never get to the dock check anyway).

You are entirely correct though that the first check should always be that the player is docked. I was speaking specifically about this particular example, which indeed should be rearranged into the correct order.

[Svengali]

There should always be a check for player.ship.docked first. It's never superfluous. The reason is that it is possible to immediately re-launch the player by script upon docking. Scripts that check for a property of the docked entity (like isMainStation or another one) will throw an error, because dockedStation is already null and therefore has no properties. I'm just checking this situation of docking and immediate script-induced re-launch, and Snoopers is giving me this error every time:

Code: Select all

22:24:33.331 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (snoopers 2.1): TypeError: player.ship.dockedStation is null

Sure - I'll add a check as it is a valid method and Oolite allows it.

But still - it smells like a problematic approach which might have other side-effects...

[Kaks]

Hmm, there seems to be a few issues centred around scripts spitting out the player while they're docking.

There are some plans to overhaul the way docks work in the near-ish future, and including a way to totally prevent the player from docking might well become part of that overhaul...

[Svengali]

There are some plans to overhaul the way docks work in the near-ish future, and including a way to totally prevent the player from docking might well become part of that overhaul...

OOoo .-)

And muchas gracias CMcL for the pointer .-)

[Commander McLane]

There are some plans to overhaul the way docks work in the near-ish future, and including a way to totally prevent the player from docking might well become part of that overhaul...

That would be nice.

And muchas gracias CMcL for the pointer .-)

You're welcome.