this.guiScreenChanged not firing when opening mission screen

[Thargoid]

Just noticed that the this.guiScreenChanged doesn't trigger when docked and a mission screen is triggered.

For example if I trigger a mission screen under GUI_SCREEN_STATUS and then exit the mission screen to GUI_SCREEN_MARKET, I only get the trigger from exiting the mission screen to the market place (from = GUI_SCREEN_MISSION and to = GUI_SCREEN_MARKET).

Can this be fixed please so it also triggers on leaving a GUI screen and going into a mission screen?

[cim]

I'm fairly sure this is intentional - at least, it's as documented that it doesn't fire on entering mission screens (or indeed some of the other GUI screens).

I presume this is because the only script that should be doing anything when entering a mission screen is the script that created the mission screen, and that script knows it's happening already. Letting other scripts intervene at that point could be messy.

[Thargoid]

It somewhat screws up the new functionality of setting the exit screen for the mission screen though. For example if I want to intercept entry into the marketplace with a mission screen before passing it back to the marketplace, I need to set a flag so that when I leave my mission screen and go into the market place I don't loop around and go back into the mission screen.

What I was then going to do is use the departure from the marketplace screen to reset the flag again. However if another OXP calls a mission screen (for example Thargoid Wars did it during my test) then I have no way to reset the mission flag as the gui screen changed function doesn't fire - hence I'm effectively sneaking out of the marketplace screen and so not resetting the flag.

I know it's a very specific case, but it's breaking somewhat the functionality you put in place. It also seems rather odd that it features it happily appears as the "from" parameter when you leave a mission screen into a normal GUI screen.

[cim]

What I was then going to do is use the departure from the marketplace screen to reset the flag again.

Is there a reason you can't do that on the guiScreenChanged call going in to the marketplace?

It also seems rather odd that it features it happily appears as the "from" parameter when you leave a mission screen into a normal GUI screen.

That's mainly just an implementation detail (and you can't break things with "from", either, so there's no need to filter it out)

[Thargoid]

This part I can do in the to step (I'm going to code that today - flip-flop the flag on alternate entries into the marketplace screen) but the problem is I'm going to be making some temporary changes to the marketplace setting which I want to revert immediately afterwards. I was also going to do that when I left the marketplace screen. But I can't do that, as I can sneak out of the screen without an event firing to trigger it.

I can see where you're coming from about not messing with a mission screen as the to, but the problem is I really want to clean up based on the from and as the event isn't firing then I'm losing that opportunity too as a consequence.

It's about the screen you're leaving as well as the screen you're going into with this event, which may have been overlooked here.

[cim]

Right, got it. I'll have a look at that when I get a moment, then.

[Wildeblood]

This part I can do in the to step (I'm going to code that today - flip-flop the flag on alternate entries into the marketplace screen) but the problem is I'm going to be making some temporary changes to the marketplace setting which I want to revert immediately afterwards. I was also going to do that when I left the marketplace screen. But I can't do that, as I can sneak out of the screen without an event firing to trigger it.

I can see where you're coming from about not messing with a mission screen as the to, but the problem is I really want to clean up based on the from and as the event isn't firing then I'm losing that opportunity too as a consequence.

It's about the screen you're leaving as well as the screen you're going into with this event, which may have been overlooked here.

You don't need an event callback. Start a frame callback while you're on the screen and use that to detect as soon as guiScreen changes. See Trading Assistant or Market Aide for examples.

[Thargoid]

Thanks - I already thought of that. A frame callback isn't needed - a simple timer would do well enough.

However on principle I prefer not to write my own events to patch where existing ones aren't working as they arguably should. I'd rather request a problem fix than monkey-patch it myself each and every time I may need to.

We've had to do something like that before (the approaching planetary vicinity function was broken in one of the release versions around 1.72 or so - a bit like it is currently in trunk) and it's a less than ideal way of getting around such glitches. Then we had to as the code was released, but here we perhaps have the opportunity to change things before release.

[Commander McLane]

I've stumbled across the same issue when running a mission screen in the playerBoughtEquipment handler:

Code: Select all

this.playerBoughtEquipment = function(equipment)
{
    if(equipment === "EQ_NAVAL_ENERGY_UNIT")
    {
        mission.runScreen(
        {
            // adding some additional process to the purchase of the equipment
        });        
    }
}

In the transition from the equipment screen to this mission screen also guiScreenChanged doesn't fire.

[cim]

As of r5442, guiScreenChanged should be firing on all mission screen entries.

[Thargoid]

Yes, it's working fine for the application I wanted it for. I'm just polishing that up for a beta launch sometime next week.

I just hope it doesn't break any existing OXPs which may be silently relying on the original non-firing, as of course if you are using a mission screen to do the intercept, you now get two firings (one going into the original screen, then the second one going from it to the mission screen). Nothing that can't easily be worked around in the script with a flag setting, but of course it needs to be done.

[cim]

I just hope it doesn't break any existing OXPs which may be silently relying on the original non-firing, as of course if you are using a mission screen to do the intercept, you now get two firings (one going into the original screen, then the second one going from it to the mission screen). Nothing that can't easily be worked around in the script with a flag setting, but of course it needs to be done.[/color]

Well, if you're using guiScreenChanged to trigger a mission screen, you're presumably already checking the "to" screen, so it should be okay.