Oolite Bulletins

Some links to the mission pages on the wiki would be great - in fact I've only just seen your Assassins page and that looks really good. I'll have to do one of those at some point, but better finish off the mission first, eh?

I'm just wrapping up some missiontext at the moment - I know what I want to say, but it's a question of how to go about it. It's like being back at school doing short stories in English lessons - except this is taking me ages!

Right, I've been spurred into actually doing something about this OXP! I've finished up all the loose ends so I think it's time to unleash it onto the public. I've been testing things more or less as I've gone along, so with luck things should all work out as intended. However, I expect there may be some little niggles here and there so if anyone runs into problems just leave a post here or PM me - especially if you want to avoid spoilers by going through all the script and mission text.

I've included some instructions on how to continue on from v0.3, and details of any other OXPs that need to be installed.

Note that I'm still open to any suggestions on improvements. I haven't been keeping up with some of the latest scripting discussions so there may well be better ways of doing some things, but there you go. Any views will be appreciated.

Trident Down v0.4 is now available via the link in my signature. Thanks again to all of those who have helped with this. It's been a long journey!

Hi Ramirez

A new mission OXP is always welcome, but I want to ask you one simple (maybe stupid – so forgive me) question

Why in Galaxy 4?
This Galaxy already has a lot of missions (native: Nova, Opxs: Deposed, Lovecats). Also there is already a very nasty conflict of Nova with Deposed

On the other hand Galaxies 6 and 8 are completely empty of missions

The simple answer is that I happened to be in Galaxy 4 when I first started thinking about the mission - once I started it was difficult to transplant somewhere else as the story's quite closely linked in with the politics of that particular Galaxy. If and when I do another mission I will aim to set it in a less busy location!

FYI I have updated Trident Down to v0.5 to fix various bits and pieces as well as to make some small improvements in the way things work. You can get the updated version from the link below.

I found out last night that it also has a dependency on the Executive spaceways OXP as well as the one with the viper 2 I mentioned before. Could you perhaps add a note to this effect on your download page and in the readme in the OXP?

Great Fun playing through it so far

Another month, another update! I've fixed some issues identified in the other threads and have also taken the opportunity to make some other modifications. I've altered the starting conditions from Competent to Dangerous, as I think it needs a little more flight experience to play without any help, and have also modified some of the reward amounts to provide a bit more balance between the different threads.

A major change is a new bit of business to get around some of the awardEquipment issues that people have identified.

I'm still hesitant to go for the v1.0 release simply because I've only just installed Oolite 1.70 and I can't be 100% confident that everything works with it - I'd need to do a complete re-test which could take a long time...

Trident Down v0.6

Hoopy wrote:

I found out last night that it also has a dependency on the Executive spaceways OXP as well as the one with the viper 2 I mentioned before. Could you perhaps add a note to this effect on your download page and in the readme in the OXP?

This raises an interesting point, I think that any OXP, that is dependant on other OXPs should have it prepackaged. Is this possible, or does it raise complications?

The only, but serious, complication that comes to my mind is that usually the OXP author isn't aware of the dependency he just has built in. That's why dependencies tend to show up unexpectedly here.

I'm pleased to announce that I've finally brought Trident Down up date with Oolite v1.71.2. I've implemented some general fixes and improved the overall reliability, as well as adding in the fix that should prevent clashes with other Galaxy 4 missions.

Note that Trident Down v1.0 will not work with earlier versions of Oolite. If you're part way through the mission on v0.6 you can carry on without having to do any changes to your savegame. Although I haven't included all the other dependent OXPs in the Trident Down package itself, I have bundled them together in a separate zip file that you can download in case you don't already have them installed.

The files are available at the link below; also I've updated the Trident Down wiki page.

Hi Ramirez,

I`m playing Trident Down at the moment (at the forced misjump point) and had the problem that I didn`t find my way further through the mission.

After installing version 1.0 (had 0.6 before) the mission objective (follow ship that jumped far by forced misjump) has disappeared from my mission screen (double F5).

Solution for that/idea what could be the problem?



L

Lestradae wrote:

After installing version 1.0 (had 0.6 before) the mission objective (follow ship that jumped far by forced misjump) has disappeared from my mission screen (double F5).

Solution for that/idea what could be the problem?

Ramirez changed casing of the scriptname. Resulting oolite sees it as an other script and does not display the old description. Mission will still work however, despite missing description.

Time to resurrect this old thread. I've been putting it off for ages but now that the 1.74 test release is officially out, and as I have some free time coming up, I'm going to attempt to translate Trident Down into javascript and make some much-needed improvements along the way.

Some questions for the seasoned scripters out there:

TD involves quite a lot of multiple-screen mission briefings, so that's a mission.runScreen followed by a choice evaluation of some kind. The usual practice for dealing with this seems to be to set up all the choice evaluations separately, so for example you have a this.missionScreens function that operates when you dock, which then calls a separate this.choiceEvaluations function that covers any responses.

This is OK where the script is fairly short and simple, but the script for TD is pretty long and convoluted, and I'm a tad concerned that doing a translation using this structure is going to be very difficult to manage. It just means that in the script, as I start to include all the different threads and options, the functions for a mission screen and its corresponding replies are going to be separated by a ton of other stuff.

Is there any way to keep the briefings and choices in-line, in a similar way to legacy? In other words, having the choice evaluations run within this.missionScreens rather than a separate function somewhere else in the script?

In fact, does anyone have any general tips about either translating old scripts or handling mission choices and multi-screen briefings?

Ramirez wrote:

Is there any way to keep the briefings and choices in-line, in a similar way to legacy? In other words, having the choice evaluations run within this.missionScreens rather than a separate function somewhere else in the script?

Yes because for each runScreen you can define a different call-back function like the "stage1" function in the next example: Only you have to define the choices first before creating the mission screen. But appart from that, you can keep largely in sync with your legacy script. Its probably a bit confusing in the start (at least for me it was) but than the bits start to get clear and it even becomes easier to write complex pages.

I just did not do that in my work because the old script already used one big function that handled all pages so it was easier to keep that structure.
The main advantage over the old method is that you don't have to worry about other oxp's. When you end a missionscreen, you can trust on it that you are the only oxp that gets the first opportunity to create a next screen.

Eric Walch wrote:

Code: Select all

{
 function stage1(choice) { if (choice === etc....};
 runScreen({..........}, stage1);
}

In fact, I’d go so far as to recommend the following style: This arrangement has the advantage that the order of the code reflects the actual order in which things happen: first the decision to present the screen, then the set-up, then the details of the mission screen, then the code that runs when it’s done. For most purposes, the fact that the completion handler is a callback that’s invoked later doesn’t matter.

Note that it’s fully supported to call runScreen() again in the completion handler, and if you do your screen is guaranteed to run immediately without any other scripts coming between. However, you must also keep in mind that the player can cancel a mission screen by launching the ship, so it’s important to make sure any state your script sets up is “sane” at the start of each mission screen.

(I don’t tend to write this way myself, mostly because of bad habits from C and old-style Objective-C. If I wrote in Lisp, or even modern Objective-C, it would be natural to me. It’s an idiom that works well with JavaScript, so if you’re just picking it up it’s the approach you should use.)