Oolite Bulletins

I just uploaded an improved version of Commander Wombats classical Thargoid Wars to the Wiki.

Who needs it:
It is a must for everybody that is using a version 4.0 or earlier. Version 4.1 has added code for compatibility with other mission OXP's.

This version improves execution speed. It just takes 5 to 10% of the original speed. Will you notice this?: NO!. Oolite executes the old script already so fast you couldn't notice. But when you have a lot of mission code installed, and all have similar improvements, you will notice the difference. A lot of the old missions have no optimised code, including the native missions.
This version also removes a bug that could stop the Station Attacks.

v.4.2 - (January, 2008) Speed update. The original flat structure of the mission script is partitioned into logical parts for speed optimisation during "In flight" conditions. In the old situation on update-time with "in flight" situations, a minimum of 110 were conditions checked when there was nothing to be done. This improved version can already after 5 checked conditions conclude that there is nothing to be done with "in flight" situations. That is just 5.5% of the original evaluation time. No functional changes.

Removed one bug where a commander who launches during a station-attack offer, without answering the offer, would never get the offer again. Also added code that restarts this mission with old save-files that contain this bugged data.

Removed a bug in the forced launch after a station-attack were the program tried to reset the legal status to that before the jump. (In case the player had illegal cargo on board he should not get punished) Because of the wrong use of "expandable text" it was not saving the content of the variable but the name of the variable.
(Changes by Commander Eric Walch)

Go to download page: Thargoid Wars v.4.2

I updated Thargoids War to version 4.3 after a rapport the other day at this board about a conflict with an other oxp.
Go to download page: Thargoid Wars v.4.3

I have it almost always installed and never had problems with it so clashes were already rare, but this should even cover the last exception. (I hope)

Technical stuff:
I added a test for missionChoice_string undefined. Without this additional check it was still possible that you made a choice on an other mission screen and Thargoids War made his offers before the first oxp could read out the choice that was made.

I switched the order of two commands: into first launching the player and only than clearing the choices. When first clearing the choices it is possible that an JS script reacts on this clearing by presenting its own screen and Thargoid Wars in the next command launches the player. When the choices are cleared after launch the JS script should see it is not docked anymore and postpone its own offer.

Good Job Eric !!!!!!!!!!
It is very nice that someone look after those clasic oxps

One small question: I have noticed that in the new version you have replaced the thargoid_decoyAI.plist with dumbAI.plist. Is that intentional ?

Ark wrote:

One small question: I have noticed that in the new version you have replaced the thargoid_decoyAI.plist with dumbAI.plist. Is that intentional ?

well spotted! Yes I removed the original one, but I already changed that in version update 4.2. When you compare thargoid_decoyAI.plist with the internal dumbAI.plist you will see that they are identical. In that case I prefer not to use a new defined plist but use the one supplied by Oolite. That internal one is even a little updated in 1.72

Thargoid wars is now translated into Java Script.

Version 4.4 was already put on the wiki half year ago. With the release of Oolite 1.74, you should switch to the new Thargoid Wars 4.5

New in 4.4 was
- When docking after a station attack there was now an actual count for all thargoids around the station.
- 1.73- only

New in 4.5 is
- the new mission screen handling.
- You don't any longer get points, just for the fact that thargoids were added to the system, but only for the thargoids you killed yourselves.
- 1.74+ only

As long as the wiki is read only you can access it through my signature below.

Hello Eric, I've got a question:
When the Space Station is under attack and I launched to defend it, I usually destroy one or two Thargoid warship before the alarm cease. Should I expect some kind of message like "mission accoplished"?
Also, when I will be rewarded for my efforts?

Thanks

Dave McRoss wrote:

When the Space Station is under attack and I launched to defend it, I usually destroy one or two Thargoid warship before the alarm cease. Should I expect some kind of message like "mission accoplished"?
Also, when I will be rewarded for my efforts?

Thanks

There never has been a message for doing the job. In the original version the oxp only counted how many thargoids were added during a station attack. Than, on docking you only got a message for every multiple of five added ships. In legacy there was no way to tell if you actually killed a thargoid, of immediately re-docked as a coward.

In this version you only get points for thargoids you killed yourselves. Not for the tharglets or optional thargoid escorts. But you still only get the update message for every fifth kill. Not getting a message is good as on docking there is a scan for thargoids in scanner range of the station. When there still is one around, even an active tharglet, one kill is removed from your thargoid kill-count and you get a message that there are still thargoids around.

A "mission accomplished" message would have been possible but I wanted to change as little as possible to the original.

Ok, understand. Thanks

May as well bump this thread to keep everything pertinent together

I seem to be having a weird problem with the Station Attacks in TWs, they keep getting stuck in a loop. So the alarm sounds, I scramble, thargoids get killed, I redock (in the same station to finish off whatever I was up to in there), then the alarm sounds again (for a "fresh" attack, not the mid-fight docking message), repeat ad nauseum. I wonder if this is only affecting my setup for some reason as I haven't seen anyone else mentioning this problem and the current version of the OXP has been out there for 6 months now.

I managed to sneak a save in between 2 of these looping attacks just now, and it is showing that mission_thargoidwars_station_attack is set to "POSSIBLE". This has left me wondering if the code in lines 171-175 of thargoidWars.js is completely right, but as I am an innocent in the ways of JavaScript and no-one else seems to have mentioned the problem I'd take this diagnosis with a pinch of salt.

Info that may be relevant: using insta-docking (shift-C) after fight due to the long queue, happened with 2 different ships (Llama & Caddy Alpha), with and without UK_Eliter's Extra Thargoids being installed (wondered about the Poet Frigate).

I vaguely recall having something like this happen to me a while ago, but not recently...

Makara wrote:

I managed to sneak a save in between 2 of these looping attacks just now, and it is showing that mission_thargoidwars_station_attack is set to "POSSIBLE". This has left me wondering if the code in lines 171-175 of thargoidWars.js is completely right, but as I am an innocent in the ways of JavaScript and no-one else seems to have mentioned the problem I'd take this diagnosis with a pinch of salt.

Well, I've commented out the from line 174 of thargoidWars.js and it seems to work as intended now. Wonder if my tweak will throw up some new oddities...

I get the same thing - nothing obvious wrong in the JS to me. But what seems odd is the presence of the legacy script.plist along with the JS version.....

Capt. Murphy wrote:

I get the same thing - nothing obvious wrong in the JS to me. But what seems odd is the presence of the legacy script.plist along with the JS version.....

I can't see any reported bug actually. The sometimes looping of the mission is fully intentionally. This happened in the originally legacy version and this is scripted in the current js code.

The presence of the old legacy script is just to keep it working when used on the old oolite 1.65. There was no deed to make it incompatible with this oolite version.

The looping can sometime be continual though.

I think I know why and it's a result of other OXP's firing their mission screen, or the report screen being shown whilst the delay timer is running.

If station_attack is POSSIBLE when this.missionScreenOpportunity fires it's changed to ATTACKED and the delay timer starts. However if the report screen or another OXP shows it's mission screen, this.missionScreenOpportunity fires again when that mission screen is finished and you get the Station Attack mission screen before the delay timer has fired. You launch, station attack is changed to IN_PROGRESS, but then the timer fires and irrespective of whether the player is in flight or not line 174 changes station attack back to POSSIBLE - hence the loop. If the other OXP happens to fire it's mission screen every time you dock you are in a continual loop until you take the cowards way out or wait 60 seconds on the Station Attack screen before choosing an option to ensure the Timer has fired. And you never get rewarded for Thargoid kills made when stuck in the loop, and if you do dock with Thargoids still in the vicinity you get the new attack message rather than the intended message.

edit - scrub the suggestion below.

I think lines 173 and 174 should be

Code: Select all

if (player.ship.docked) {
this.missionScreenOpportunity(); // force a delayed evaluation.
    missionVariables.thargoidwars_station_attack = "POSSIBLE";}

or the timer should be stopped on launching.

Hmmm - I was getting the loop even without another mission screen firing (at least not visibly firing - do they fire without actually putting anything on screen?).
Either way, just deleting/commenting out that line 174 seems to give the intended behaviour (can confirm this, just had a 2nd singular station attack incident since changing that code so I don't seem to have borked it), even if it isn't true to the originally scripted behaviour If multiple station attacks were intended, why test on this.shipExitedWitchspace rather than just on docking?