Mission offering

[LittleBear]

True, in the Assassins "Text Adventure" it would be possible for another mission in interupt, but only if sombody set their mission brief to appear literaly at every docking!!!! The text adventure will only be displayed if you are docked at the "Rebel Outpost". This station will not exist unless you are doing this mission, so it is impossible to meet this condition except in this mission. The oneof: will not work here, as I need the "pages" of the FF sytle book to be read immedatley. But no mission so far uses this. If you set a brief to be displayed at the Main Station and / or specific station name then they'll be no conflict. In any event A for Assassins script trumps all others by virtute of alpahetical order, so even if you set your mission in such a way that it could give a briefing at the Rebel Outpost, it still would be shown after the player had solved the text adventure as Oolite would have to read the Assassins's script before it looked at another OXP. As long as the name for the OXP you add is alphabeticly after Assassins, there should be no conflict.

As Thargoid Wars will only launch you if you are docked at the MAIN station, the multi-paged (22 odd!) text adventure will not clash, at least with this OXP.

[TGHC]

You guys rock! I don't really understand much of this, but I guess it's outcome will be to improve Oolite even more so rock on!

[Commander McLane]

In any event A for Assassins script trumps all others by virtute of alpahetical order, so even if you set your mission in such a way that it could give a briefing at the Rebel Outpost, it still would be shown after the player had solved the text adventure as Oolite would have to read the Assassins's script before it looked at another OXP. As long as the name for the OXP you add is alphabeticly after Assassins, there should be no conflict.

That's not correct, as our lead programmer told us two pages ago:

@ Ahruman: One more question: Are the scripts executed in alphabetical order?

There are no guarantees regarding the order of script execution.

[LittleBear]

Opps, missed that! Strange though as on my set up Assassins is being read first as in testing (and I've tested a lot with this OXP and other OXPs that give potential clash briefs) on over 100 test runs I always get the Assassins brief first. Then Military then Thargoid Wars. The Commander I'm usesing is edited so the variables in the save file are tweaked to ensure all conditions are met to make each one of these three OXPs give a brief as soon as Oolite reads its script. It could be a Windows only thing though. But my main point is as along as people don't add a condition that is just "docked" and instead use either docked at main station or docked at Station name (or oneof:) then the text adventure in assassins shouldn't clash with anything else as it is limited to an OXP station that only exists for the duration of the mission.

[LittleBear]

Put a code fixed version of Thargoid Wars on the Wiki and updated the links on the OXP page and mission pages to link to this one. This one has Eric's code fix added, so won't clash with other missions.

Wiki Page is here:-

http://wiki.alioth.net/index.php/Thargoid_Wars

[Eric Walch]

Little Bear wrote:

The text adventure will only be displayed if you are docked at the "Rebel Outpost". This station will not exist unless you are doing this mission,

OK, you are right. The dungeon-like part of the assassin script doesn't run the risk of multiple offerings as it is not played at the main station. But I took this part just as an example of an multiple screen message. In my opinion you must always be aware that there could exist badly written scripts that only check for just being docked rather than docked at the main station. Therefor just make the check for status_screen at the first offering condition to be sure.

But another example would be "military fiasco". It starts with a five page briefing. This briefing however keeps missionChoice_sting set. An other mission offer with choices won't interrupt this. Just a briefing will however.
Military fiasco as I have it, has still two small bugs. On one place it resets the missionChoices in the "conditions" part rather than the "do" part. And the choices of the last message are never reset. He thought: "I'm ready", not thinking at possible other scripts that could wait for this variable to be free again.

I always wondered in what order the scripts were run. I had the feeling that they were run alphabetically, but starting from Z. I am at the moment playing assassins and at the same time play-testing my new UPS-script. Together with a test-script. The UPS mostly comes sooner than the test script and I have seen assassins coming after another script-screen. (I work on a mac OS version).

That your test produced consequently the same appearing order of messages is probably because you always started from the same tweaked save-file. I noticed that if you start from a saved file, the first random choice is always the same. Probably because the seed-value is taken from the save-file. If you manipulate an other save-file, the outcome could be different. In any case: don't rely on a predictable order in OXP executions.

The same counts for scripts started by ships or pilots. After ships are created by a script, the system doesn't keep track witch script created them. Why should it? Consequence is that if you use "setMissionDescription" in a death_action of a ship, the system does not know witch missiondescription is meant and it just chooses one at random. If you want that a death_action changes the description, you must set a variable and check for that variable during a status_in_flight condition within the actual script.

I also noticed that on docking a script of a scripted pilot is run first. As this script is only run once it makes no sense to check the missionscreen. Normal scripts are not executed if the script displays a message on the missionscreen. If you press space the system then checks for other pilots. These pilots are displays together with the award. (I do not know what happens if this does not fit the page.) After pressing space again, the normal scripts are executed at regular intervals while docked.

Eric Walch

[LittleBear]

Sure you're right Eric. In testing I have to admit that I hit enter pretty quick when the Military brief came up, so I didn't give Oolite the chance to scan the scripts. Guess if I'd waited 10 seconds Thargoid Wars might have "interputed" and launched me between the pages of the military brief. Doh!

However, I think your code fix is still good.

The bug would only happen if the player happened to hit 1,000 kills at exactly the same moment that Thargoid Wars chose to send the player out to defend the station! The chances of both events happening at the same time must be "1 in 10 to the power of my overdraft!" (to quote Zaphod Beadlebrox)!. Its like pocket 2s beating pocket Aces!!!

Your code fix should prevent a mission briefing clash 99.99% of the time and its a major contribution to the game!

<Mitigation Mode>

Bear in mind that I'm a criminal lawyer not a programmer! As a kid I messed about with BASIC on the Beeb twenty years ago, but thats it as far as my programming skills go! Any observations I have are based on purely empirical methods rather than knowing what I'm doing! All code for my OXPs was also figured out in this way!

</Mitigation Mode>

[davcefai]

Bear in mind that I'm a criminal lawyer

I think you're the first lawyer to admit it though

If Oolite were multi-player I suspect that LB would be targeting 4 hardhead missiles at me.

[LittleBear]

Added a version of Military OXP, with Eric's code fix added. Do use this one, as it won't conflict with any other OXP putting up mission briefs. It's all Murgh's work (I've just C&Ped the code fix into the script and whilst I was at it I changed the condition "docked" to docked at main station to avoid the problem Eric pointed out above). Added a Wiki page and updated all this links on the Wiki to point to this version.

Grab it here:-

http://wiki.alioth.net/index.php/Military_Fiasco

[Eric Walch]

I also want to make the scriptwriters aware that the missions offered by pilots need special attention. Starting with version 1.65 you can introduce characters. See the conhunt mission were a pilot is introduced. If you put a pilot (character) in a ship and the ship explodes, an escape-capsule is created with your character. (You can also put the pilot directly into an escape-capsule.) This character can contain a script. If you have scooped such a character, he will disembark at the first docking like other scooped pilots. But on disembarking it runs the containing script. In most cases it will contain a missiontext. As this script only runs once, you must put your text to the missionscreen, even if it is in use. A missionscreen will only be present if there is more than one special pilots. Very unlikely, but someone might write a script with many characters. If you use the formulation listed below, it will open a missionscreen if there was none, but will just add a empty line and than the new text below the existing if there was already one present.

<array>
<dict>
<key>conditions</key>
<array>
<string>gui_screen_string equal GUI_SCREEN_MISSION</string>
</array>
<key>do</key>
<array>
<string>addMissionText: empty_line</string>
</array>
<key>else</key>
<array>
<string>setMissionImage: none</string>
<string>setGuiToMissionScreen</string>
</array>
</dict>
<string>addMissionText: your_texts</string>
</array>

I have tested this script with tree pilots on board and is works well if none of the texts is very long. The first pilot opens the empty missionscreen and puts his test at the top. Every following pilot adds an empty line (or other separator as defined in your missiontext.plis) and then his own text. Scripting this way allows for several special pilots to be present if someone wants to write a very special mission.

[Eric Walch]

I finaly uploaded my Mission Offering Text to the Elite Wiki. It is some documentation how to make save offerings that don't clash with other missions as described earlier in this topic.

It also includes a OXP that puts up a brieffing on every docking so you can test if your OXP handles simultanious offered briefings well.

You can download it directly: Mission Offering Protocol

[Commander McLane]

A link to the wiki page would be helpful.

[Eric Walch]

A link to the wiki page would be helpful.

One thing at a time. De previous link will download it now directly. I first wait for comments on it. When it's ok it should get an entry from within the Wiki from its own page. I have to look were it can be placed.

[Commander McLane]

Downloaded it, but I was looking for the compilation of your information. Because it's handier to have it on one wiki-page than throughout one or even a couple of threads here.

Then I found it in the OXP.

Therefore please allow me one remark here: It is generally not advisable to put anything anyone should read (like a readme, documentation etc.) inside an OXP. For us Mac-people (don't know about other OS) an OXP is not a folder you can easily open and look inside, but a package that looks like one single file. I guess an overwhelming majority of players will never right-click on it, hit the "show content" and have a look at its content. So information which shall be meaningful for them has to be outside the package, next to it in the containing folder. Or else the information will never be delivered and is useless.

[Eric Walch]

Downloaded it, but I was looking for the compilation of your information. Because it's handier to have it on one wiki-page than throughout one or even a couple of threads here.

I put it for direct reading on a wiki page now: Mission Offering

Putting most stuff inside the OXP was deliberate as it is only to be used by programmers and those know how to look inside the OXP. (Right-clicking under Windows and ctrl-clicking on a Mac) I also included a small readme file outside the OXP stating most stuff is inside the OXP.