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:
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.
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.
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.
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]
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.
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!
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.)
To misquote our Supreme Grand Admiral, that might just be a case of premature optimisiation.
Adding keypress intercepts could involve a pretty radical rethink/redesign of OXP/player interaction. Quite a tricky subject, really!
Which is why, afaik, this is one of the 'well past NSR' bits!
Actually, this arose out of a discussion with PhantorGoth on IRC. I can’t see any reason not to have an optional, queryable identifier parameter in the mission screen dict.
