Page 2 of 3
Posted: Fri Nov 20, 2009 10:09 pm
by 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.
Posted: Thu Dec 24, 2009 11:27 am
by 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.
Posted: Mon Mar 01, 2010 9:47 pm
by 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.
Posted: Sat Apr 17, 2010 12:24 pm
by 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]
Posted: Sun May 09, 2010 11:36 pm
by 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.
Posted: Mon May 10, 2010 1:35 am
by 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!
Posted: Mon May 10, 2010 6:47 am
by 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.)
Posted: Mon May 10, 2010 6:29 pm
by Kaks
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!
Posted: Mon May 10, 2010 6:43 pm
by JensAyton
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.