Oolite Bulletins

Thanks for the update. Works well so far. Debug messages were turned on in tweak 0.97. I turned them off in my install.

I got a missjump with Interstellar Tweak, I targeted a Witchspace cloud, waited till the Thargoids turned up and then cleared up. I then headed to the cloud since it was going to where I wanted to go and just flew straight through it! I couldn't target it again, so I couldn't take an entity dump.

Fatleaf

Thanks for the report. However, that is a known Oolite problem; it's not caused by my OXP (which is still in rather protracted final development). And I don't know how to solve the problem, I am afraid.

Exception: ReferenceError: RETURN is not defined
Active script: Interstellar tweaks - main script 1
IST_MAIN-SCRIPT.js, line 489:
RETURN;

It should be a lower case return;

UK_Eliter wrote:

Fatleaf

Thanks for the report. However, that is a known Oolite problem; it's not caused by my OXP (which is still in rather protracted final development). And I don't know how to solve the problem, I am afraid.

If you guys have a reliable way to create intangile witchclouds, I'll give a go at fixing the problem...

Dear all

The really-very-nearly-there-this-works-right? version of InterstellarTweaks is available here: http://www.box.com/shared/moreq536ht. As I say on the 'Test Pilots' thread, I'm keen for people with systems different to mine to test it. That means: anything save Windows XP SP3 (which is what I've got), i.e. Mac, Linux/Unix, Windows Vista, Windows 7.

Cheers!

Looking forward to this one. I've been running 0.97 for a few weeks now. I am using Windows 7.

This tweak is not compatible with the Thargoid Witchspace Drive OXP. I experience the drive melt down error and explode while in transit through the wormhole misjump chain created by the Thargoid device.

Hi UK_Eliter,

It looks like you've renamed some of your worldScript references in the latest release which breaks your compatibilities. For mine I've spotted.

Line 470 - if (worldScripts["murphy-thargoid-drive"] && worldScripts["murphy-thargoid-drive"].jumping){return;}
should (and used to) be if (worldScripts["murphy-thargoid-drive.js"] && worldScripts["murphy-thargoid-drive.js"].jumping){return;}

Similarly Line 270 if (worldScripts["escapePodLocator"]) {worldScripts["escapePodLocator"].ecl_interstellarSpaceRange = 2;}
should (and used to) be if (worldScripts["escapePodLocator.js"]) {worldScripts["escapePodLocator.js"].ecl_interstellarSpaceRange = 2;}

I think there are a quite a few more looking at some of the names you've used to reference other scripts.

Also the new meltdown code needs a if (worldScripts["murphy-thargoid-drive.js"] && worldScripts["murphy-thargoid-drive.js"].jumping){return;} early in this.shipExitedWitchspace = function() (line 1187).

One other bug spotted in the script.

Line 1257 - Currently reads if (this.nearMeltdown = true) which isn't a valid check. I'd suggest a simple if (this.nearMeltdown)

This is one inventive OXP though - there are a lot of ways to die....

Solonar, Murphy

Thanks for this. Indeed, thanks especially to Murphy, who put some work in!

My script seems to work now with the new jump drive. However, I haven't entirely removed the chance of my script killing you when you use it. Rather, I add 0.0006 to the chance of your getting witchspace sickness with every jump the drive makes. (I hope that is OK with you! Note that each time one launches from a station one starts with that chance at 0.008. When using the normal witchdrive, that chance gets increased by 0.01 every time - after the second time - that one jumps from interstellar space to interstellar space.) Your drive makes a lot of jumps, even for relatively short distances - and should perhaps come with an epilepsy warning! Is it really meant to make that many jumps - some 50 or so to go some 50 light years? Perhaps it makes many small jumps to decrease the amount of 'Oolite' time taken. (I haven't looked closely at your code.)

Also, I get a load of the following errors in the log - though I am not sure the Thargoid drive (or that in conjunction with my script?) caused them:

Hi UK_Eliter,

The many, many misjumps (with a check for a shorter route after each misjump) are indeed the way it can (sometimes) beat the fastest route available by Normal Jumps. I honestly think it would be better to bypass your sudden death code if the drive is active.

The timer errors are possibly from InterStellar Tweak - because the Jump Drive is exiting the interstellar space again before your timers have fired they lose their reference when they are created again and eventually get garbage collected.

Thargorn Witchspace Battle had the same problem, but Eric has updated it now by adding a check for to see if the timer already exists before recreating it. The code snippet below is what I suggested to him.

if (this.thargoidTimer && this.thargoidTimer.isRunning){this.thargoidTimer.stop();}
this.thargoidTimer = new Timer(this, this.addThargoids, 10+Math.random()*50);

It could be from another OXP entirely though that sets one shot timers on arrival in interstellar space, and doesn't check to see if they've fired when the player jumps again.

Hi Murphy

I think I may have indeed have a timer problem. I'll check (again!). Something is causing my OXP sometimes to crash after many misjumps. I don't know what it is. It could be one of the recent changes I've made (changes to do with recognising, and interacting with, other OXPs). I've put up version 0.99b (together with new versions of two of my other OXPs - for their handling of other OXPs wasn't right). But probably it still contains the aforementioned bug. Yours a bit frazzled . .

Hi, just downloaded 99c.

No crashes for me, but I'm using a 1.76.1 maintenance build, which has some timer crasher bugs in the source code fixed.

I had a quick look through the shipScripts and the timer handling looks OK at first glance in those. In the worldScript there are a couple that result in unrooted timers if the player misjumps again very quickly, which are probably the cause of the unrooted Timers getting garbage collected (and possibly your crashes?). Try adding a check to see if they already exist and are still running before creating them along the lines of the code snippet I posted above.

The ones I spotted are

this.militaryInterstellarTimer = new Timer(this, this.addMil3GSquadToFuturePosition, 3 + ( Math.ceil(Math.random()*30) ) ); and
if (Math.random() <= this.threeG_HelpChanceForOnlyBugs) {this.militaryInterstellarTimer = new Timer(this, this.addMil3GSquadToOldPosition, 4 +( Math.random() )*100);}

Interesting side effect of not bypassing your code with the Thargoid Drive - I didn't get sick, but your code manages to move the ship before it get sucked into it's new wormhole about 1 time in 10. As far as the player is concerned they have had a jump chain failure and are stuck in the middle of some interesting Interstellar Tweak scenario. But it happens with almost every use of the Thargoid Drive. I still think the easiest solution is to bypass your code when the drive is in use (players with both OXPs will still have lots of fun with Interstellar Tweaks as they have to go there (more than a few times) to get a drive in the first place, and will normally need to replace the drive by further visits to interstellar space at some point).

Murphy: thanks again!

I've added the checks you suggest and totally bypassed my code for your drive. Moreover, I'm dealing with what may be the real problem, namely this: stuff being triggered by shipWillExitWitchspace, and stuff triggered by shipExitedWitchspace, ending up running concurrently. If this doesn't fix the problem, I'll see if trunk does.

I'm not sure what you need to do but one approach is to use a single repeat timer and some sort of flag/counter.

E.g on shipWillExitWitchspace set up a repeat Timer; Timer function does stuff. At some point all of the shipWillExitWitchSpace stuff is done. The timer carries on running, but does nothing else unless a flag has been set by the shipExitedWitchspace handler, at which point the timer function does the rest of the stuff, before ending itself. The shipWillExitWitchspace handler includes a check to see if the timer is still running and ends it if it is.