RFC: revised mission screens for JavaScript

[Commander McLane]

@ Ahruman: Good to know. And I would indeed ask for an expandMissionText(), because it would get more complicated if I had to put parts of my missiontext in descriptions.plist.

One more thing, however: addMessageTextKey() is also used by the native Constrictor Hunt mission (see its script) to put additional text to the systeminfo screen. How would that translate into the new mission system?

[Kaks]

err... text=expandMissionText() ?

[Eric Walch]

One more thing, however: addMessageTextKey() is also used by the native Constrictor Hunt mission (see its script) to put additional text to the systeminfo screen. How would that translate into the new mission system?

I assume that this function can stay. It does not overwrite anything but only puts text below existing text.

[Kaks]

By the same token, addMessageText should stay too. Personally I'd find it a more 'natural' thing if we just had a mission.addMessageText() function, without using addMessageTextKey at all.

We could still do the equivalent of addMessageTextKey:

Code: Select all

mission.addMessageText(expandMissionText('old-style-mission-message'));

and we'd have the possibility to write something a lot more flexible:

Code: Select all

var mo=missionVariables.mySpecialMissionObjectives;
mission.addMessageText('You seem to have reached ' + mo +' of the mission objectives' + (mo>3 ? '\nCongratulations, Commander!' : '\nWe had hoped for more.'));

[Commander McLane]

err... text=expandMissionText() ?

And where do you put the "text" in? The Constrictor Hunt mission script contains no equivalent of mission.newMissionScreen() or mission.runMissionScreen(), because it doesn't run a mission screen, but amends the F7 screen.

Therefore it makes no sense to use a method which first clears the screen and then switches it to something that has written "Mission information" on top of it.

[Kaks]

Fair enough! Hence mission.addMessageText as mentioned 2 posts ago!

[Svengali]

There’s actually one problem here, which is that expandDescription() reads from descriptions.plist instead of missiontext.plist, but that’s trivially fixed by adding an expandMissionText().

Thanks Ahruman, this was exactly my headache with my posted example and opens new possibilities to check things before :-)

One thing that slightly bothers me is that ship models are displayed behind the mission's background image. I think we could do with a way to specify which one we want to see in the foreground, the model, or the image.

If this would be static this would then mean to change a lot of artwork and shaders in my oxps. Would it be possible to let a script choose this order? Or would it mean to frickle around with a lot of OpenGL code?

[JensAyton]

By the same token, addMessageText should stay too. Personally I'd find it a more 'natural' thing if we just had a mission.addMessageText() function, without using addMessageTextKey at all.

Originally, I intended to only have addMessageText() and let all message text be specified inline, but this was criticised, validly, as bad practice. Separating data, behaviour and presentation is a good thing! On the other hand, with expandMessageText() in place it’s natural to implement addMessageTextKey() as a prefix convenience wrapper for expandMessageText() and addMessageText().

[Eric Walch]

I noticed that Kaks has been very busy with implementing all the new mission stuff in the current trunk version.

As far as I can see it now does work as intended. However, it means that trunk now logs large amounts of deprecation messages for old scripts so I started to convert some scripts to the new method. For who is interested:

Military Fiasco (for trunk only)

UPS-Courier (for trunk only)

Thargoid Wars 4.5b(for trunk only)

Hoopy Casino 1.2 (for trunk only)

Asteroid Storm 3.54b (for trunk only)


Use at your own risk, it won't run with current Oolite 1.73.x. But starting with translating and using the new scripts helps polishing the new method before a final release. When 1.74 gets released, I'll replace these with final versions.

[Eric Walch]

Just for your info:
Kaks removed this weak a bug from trunk that affected Asteroid Storm and Thargoid Wars. Both oxps should now run okay again with current trunk builds.

[Eric Walch]

Random Hits is now 99% translated to JS for future Oolite 1.74. Currently I see no further bug I left in. (Most likely errors left, are wrong text displays. Please report them back.) The new mission screen method made translating the legacy version into JS much easier. And the way it is set up now, it should be not to difficult to add the extra missions LB had in mind for a 1.4 release.

When trunk users already want to test it further to remove the last bugs before the final 1.74 gets released, they can already download Random Hits 1.3.8 beta (It needs trunk to run)

To save me some bandwidth I removed the Texture and the Models folder. The resulting file is now just 700 kB large. To make it playable again, you must add both folders from an older RH version into this test version. This should be no problem for trunk users.

It behaves the same like the old one. Main difference should be a performance increase. Specially in a system that contains a seedy bar.

And during translation I discovered that 1.74 will break the old legacy version because of the new missile handling. The auto miners around a seedy bar shoot rocks to the Hopper that collects them. It uses the missile function for that. Not mend as hostile projectiles but 1.74 will replace a small part by random missiles. In this case real missiles could be fired at the hopper. That problem is in this version also solved.

[Thargoid]

All of my OXPs which require update for 1.74 are now done and in beta-version at the link below.

A few notes and caveats:

• I'm still playing around with the scripting in all of them and adding bits, so don't take any of them as a final release version (that will come when 1.74 itself is released).
• If I update them, I will increment the letter at the end of the version number of the zip file (but not the OXP folder inside).
• There is a bug in the mission screen callback at the moment in trunk, which is breaking some of these (and others) OXPs which use the callback function for mission screens.
• Target Autolock OXP now has a new feature - your current target appears as a blue/cyan stick on the scanner, so you can keep track of it.
• Armoury OXP is a meta-OXP of AMS, Captured Thargons, Drones, Probe and Missile Rack, plus a few other goodies. It supercedes all the aforementioned OXPs, which will no longer be supported after 1.74.
• The Armoury version of the Captured Thargons now allows reprogramming of scooped Thargons for use with the system for only 500cr (at tech 11+ locations).

As before (and as with trunk itself) use at your own risk, but if you to see glitches please report them to me.[/color]

[PhantorGorth]

I thought it would also be useful if to the runScreen parameters:

Code: Select all

title: String (pure text)
titleKey: String (Key in missiontext.plist)
music: String (filename of a music file)
overlay: String (filename of a picture used as overlay)
background: String (filename of a picture used as background)
model: String (Role of a ship that will be shown as rotating ship)
message: String (pure text)
messageKey: String (Key in missiontext.plist)
choicesKey: string (Key in missiontext.plist)

an additional "name: String" parameter was added for the purpose of naming the screen and then having it exposed to JS as a property (e.g. currentMissionScreenName) of the mission object. This way JS scripting, particularly mission based events, can determine what mission screen it is responding to.

[Kaks]

Err... PG, you'll have to specify a scenario that could cause the type of problem you're trying to avoid...

Using the new mission.runScreen({options},handlerFunction) no event is triggered until the handler function has finished running, and even then the only event that's triggered is to announce a new mission screen opportunity.

I can't think of a single situation where the new style mission screens would get their wires crossed (as opposed to the very cross-wires-prone old style ones) , but I'm happy to be proved wrong!

[PhantorGorth]

Missed that you are using a callback function. But it would be useful for future developments such as keypress intercepts that would benefit from knowing what screen was up at the time. (not just some generic GUI_SCREEN_MISSION.)