Extension to Mission Screen Handling

[PhantorGorth]

This is a simple suggestion to describe but looking at the source code slight more difficult to do.

The suggestion is to add two new options to .runScreen parameters. The first parameter would be called something like "anyKeyPress" (which would be boolean). The second would be "anyKeyPressInstructions" (which would be a string). If anyKeyPress is "true" then "choicesKey" and "initialChoicesKey" would be ignored and instead of "Press Space Commander" at the bottom of the mission screen the "anyKeyPressInstructions" string would appear. Now in the mission screen when a key pressed, this is passed as an object parameter (eg. {shift, ctrl, alt, keyCode} ) to the missionScreen callback function as a second parameter. The choice parameter of the callback would be a default "keyPress"

The aim is allow more interesting and useful mission screen behaviour.

I had a look at doing this myself but I don't yet understand the JS engine interface much.

[Commander McLane]

What would that achieve that's not already doable (and is being done hundreds of times each day) by mission choices? Or even by a simple "Press Space"? The player presses either RETURN (in case of a setup with mission choice) or SPACE (in case of the default setup), and "anyKeyPressInstructions" are performed in the script.

There is one really needed improvement to mission screen handling, though: disable the use of F1 to launch in the middle of a mission screen, which regularly results in unsuspecting players getting stuck in the middle of a mission.

[PhantorGorth]

What would that achieve that's not already doable (and is being done hundreds of times each day) by mission choices? Or even by a simple "Press Space"? The player presses either RETURN (in case of a setup with mission choice) or SPACE (in case of the default setup), and "anyKeyPressInstructions" are performed in the script.

There is one really needed improvement to mission screen handling, though: disable the use of F1 to launch in the middle of a mission screen, which regularly results in unsuspecting players getting stuck in the middle of a mission.

That was very dismissive of you CML. There are plenty that this idea would allow you to do that you can't (or rather can't do easily) using the existing interface. You can not create free text entry for a start. Also you could have say a dynamic menu in the middle of the mission screen and use the arrow keys to scroll through the list on screen. (Remember the choices has to be in the missiontext.plist and are therefore not dynamic.) To do this now I have to have options to scroll up and down in the mission choices which means for one direction (say down) I have to use the arrow key to go to it and then press enter which is a two step process which gets tedious. (For an example of this see my GalCop Rewards' mission screen used for selecting a voucher when you win more than one.) Another idea is this could be use to control a 3D model. These ideas are just for starters but basically you would be able to do a lot more than can be done now. Yes for most uses the current way is perfectly fine but more sophisticated ideas it is not flexible enough.

I agree with your point regarding pressing F1 though.

[Svengali]

One way to have dynamic texts in mission choices is to use missionVariables. So it's possible, although a bit inconvenient.
And after adding the initialChoicesKey (in trunk) the devteam has done another step. Muchas gracias

I fully agree that more possibilities for missionscreens are highly welcome, e.g. the step from UI to a GUI would make things even more convenient, specially for more complex scenarios

[Commander McLane]

Sorry, I didn't want to sound dismissive.

There are plenty that this idea would allow you to do that you can't (or rather can't do easily) using the existing interface. You can not create free text entry for a start. Also you could have say a dynamic menu in the middle of the mission screen and use the arrow keys to scroll through the list on screen. (Remember the choices has to be in the missiontext.plist and are therefore not dynamic.)

You can make them dynamic. All you have to do is to put the text in a mission variable, which is how it has been possible forever to display dynamic texts on mission screens. A combination of

Code: Select all

    missionVariables.my_first_choice = "Go up dynamically.";
    missionVariables.my_first_choice = "Go down dynamically.";
    missionVariables.my_first_choice = "Stay where you are dynamically.";

in the script and

Code: Select all

    "my-mission-choices" =     {
        "choice_1" = "[mission_my_first_choice]";
        "choice_2" = "[mission_my_second_choice]";
        "choice_3" = "[mission_my_third_choice]";
    };

in missiontext.plist should be perfectly valid. (EDIT: ninja'd by Svengali on this one.)

To do this now I have to have options to scroll up and down in the mission choices which means for one direction (say down) I have to use the arrow key to go to it and then press enter which is a two step process which gets tedious. (For an example of this see my GalCop Rewards' mission screen used for selecting a voucher when you win more than one.)

Options can also be selected directly by double-clicking, so there's no strict need for keypresses at all. (Or is this a Mac-only feature?)

Another idea is this could be use to control a 3D model.

I'm no expert on this, but wouldn't that require a re-write of how models are displayed on mission screens rather than a new check for keypresses? As far as I know the models are not meant to be controlled anyway. They just spin in front of you. Simple controls (like "increase spin" or "reduce spin") can be implemented as mission choices, but the main point is: does the engine currently allow to apply changes to the spinning models in the first place?

[cim]

I'm no expert on this, but wouldn't that require a re-write of how models are displayed on mission screens rather than a new check for keypresses? As far as I know the models are not meant to be controlled anyway. They just spin in front of you. Simple controls (like "increase spin" or "reduce spin") can be implemented as mission choices, but the main point is: does the engine currently allow to apply changes to the spinning models in the first place?

Yes - the mission.displayModel property will get you a standard Ship reference to the model with modifiable position, orientation, etc. Probably helps to set spinModel to false first, of course.

[Svengali]

Options can also be selected directly by double-clicking, so there's no strict need for keypresses at all. (Or is this a Mac-only feature?)

It's there on all platforms.

I'm no expert on this, but wouldn't that require a re-write of how models are displayed on mission screens rather than a new check for keypresses? As far as I know the models are not meant to be controlled anyway. They just spin in front of you. Simple controls (like "increase spin" or "reduce spin") can be implemented as mission choices, but the main point is: does the engine currently allow to apply changes to the spinning models in the first place?

Via spinModel:false and framecallback you can do a lot of things. The other option was used in Snoopers (up to 2.2.x) to use a helper entity and "safeScriptActionOnTarget: performTumble" to get a random change.

Ninja'd by cim .-)

[PhantorGorth]

Sorry, I didn't want to sound dismissive.

Accepted. This might be a cultural difference here.

There are plenty that this idea would allow you to do that you can't (or rather can't do easily) using the existing interface. You can not create free text entry for a start. Also you could have say a dynamic menu in the middle of the mission screen and use the arrow keys to scroll through the list on screen. (Remember the choices has to be in the missiontext.plist and are therefore not dynamic.)

You can make them dynamic. All you have to do is to put the text in a mission variable, which is how it has been possible forever to display dynamic texts on mission screens. A combination of

Code: Select all

    missionVariables.my_first_choice = "Go up dynamically.";
    missionVariables.my_first_choice = "Go down dynamically.";
    missionVariables.my_first_choice = "Stay where you are dynamically.";

in the script and

Code: Select all

    "my-mission-choices" =     {
        "choice_1" = "[mission_my_first_choice]";
        "choice_2" = "[mission_my_second_choice]";
        "choice_3" = "[mission_my_third_choice]";
    };

in missiontext.plist should be perfectly valid. (EDIT: ninja'd by Svengali on this one.)

I agree this would work under some circumstances but not if the number of entries varies.

To do this now I have to have options to scroll up and down in the mission choices which means for one direction (say down) I have to use the arrow key to go to it and then press enter which is a two step process which gets tedious. (For an example of this see my GalCop Rewards' mission screen used for selecting a voucher when you win more than one.)

Options can also be selected directly by double-clicking, so there's no strict need for keypresses at all. (Or is this a Mac-only feature?)

I vaguely remember that now you've said it. It probably works under all OSs but I tend not to use the mouse when playing Oolite.

Edit. There is. Ninja'd by Svengali.

[cim]

I agree this would work under some circumstances but not if the number of entries varies.

It's the sort of thing you'd want to write an abstraction layer for once and then go through that, but you could vary the number of entries by having one "generic" choice list set up for each list length, selecting the one you needed for this occasion, and populating the mission variables accordingly.

[PhantorGorth]

I agree this would work under some circumstances but not if the number of entries varies.

It's the sort of thing you'd want to write an abstraction layer for once and then go through that, but you could vary the number of entries by having one "generic" choice list set up for each list length, selecting the one you needed for this occasion, and populating the mission variables accordingly.

Oh agreed, but is not that convenient, and you have to be careful your set goes up to the maximum you can ever get from your OXP. (Mind too many choices and you start to have problems fitting it all in one screen.)

[Pleb]

It would help if there were more options for the mission offering screens though. Although for the most part they tend to serve their purpose it would be good if we could use different coloured text or change the size of text. Or the ability to insert more than one image into the screen. I know this can be achieved with Javascript but if there were more defined options in the code it would mean OXPs like Snoopers wouldn't have to require complex coding, and the script files could be radically reduced.

[PhantorGorth]

It would help if there were more options for the mission offering screens though. Although for the most part they tend to serve their purpose it would be good if we could use different coloured text or change the size of text. Or the ability to insert more than one image into the screen. I know this can be achieved with Javascript but if there were more defined options in the code it would mean OXPs like Snoopers wouldn't have to require complex coding, and the script files could be radically reduced.

That's for another request I think. I am keeping it limited here to the key press idea.

[Eric Walch]

I'm no expert on this, but wouldn't that require a re-write of how models are displayed on mission screens rather than a new check for keypresses? As far as I know the models are not meant to be controlled anyway. They just spin in front of you. Simple controls (like "increase spin" or "reduce spin") can be implemented as mission choices, but the main point is: does the engine currently allow to apply changes to the spinning models in the first place?

Via spinModel:false and framecallback you can do a lot of things.

When Griff released his Halloween witch, I played a bit with it to let it fly circles to and from the player on a mission screen with callbacks. So , any animation there is already within the possibilities.