sidestepping mission choice by launching from mission screen

An area for discussing new ideas and additions to Oolite.

Moderators: winston, another_commander

Post Reply
User avatar
Commander McLane
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

sidestepping mission choice by launching from mission screen

Post by Commander McLane » Tue Apr 23, 2013 12:07 pm

This may have been discussed before, but I don't remember a definitive decision.

The problem popped up in conjunction with a specific OXP, but the issue is a general one, so I'm raising it here independent of any specific OXP.

On mission screens, usually the F-keys are blocked. You can't change to the equipment screen or the market screen, but are supposed to press SPACE (or select an option, if there is a choice). However, there is one notable exception: you still can press F1 and launch. This is particularly problematic in case of mission choices, because by pressing F1 none of the choices offered is taken, and the OXP may get stalled.

Therefore my suggestion: block the F1-key as well while on a mission screen. I have never understood why it wasn't blocked in the first place. If there is an unavoidable reason for it, other possibilities should be discussed.


In the meantime, scripts can check for an unexpected launch from a mission screen, at least when options are involved. All you need to do is to use the switch command in the callback function, and include a default (you can reach the same result with if-clauses as well, but this one looks cleaner for the example):

Code: Select all

this.missionScreenOpportunity = function()
{
    var options = {
        "01" : "Option 1",
        "02" : "Option 2"
    };
    mission.runScreen
    (
        {
            message: "Take an option.",
            choices: options
        },
        function(choice)
        {
            switch(choice)
            {
                case "01":
                    log("test", "Option 1");
                    // your code here
                    break;
                
                case "02":
                    log("test", "Option 2");
                    // your code here
                    break;
                
                default:
                    log("test", "No option taken, player launched instead");
                    // your code here
            }
        }
    );
}
In my trials, the default message was written to the log when I launched by pressing F1, and also when I was launched by script. Thus it indeed covers all cases where the options are sidestepped—deliberately or accidentally. So you can use that clause to reset everything that needs to be reset for the options to appear again at the next opportunity. Or you can make it identical to one of the options above, thereby forcing that choice on the player who launches.

This should at least take care of most of the problems with stalled missions.

Post Reply