The other point to consider is that at least initially (from the log Switeck posted on the first page of this thread), the this.xOffset and this.yOffset seem to be calculated correctly and have numeric proper values, but subsequently the NaN appears.
From the logging above, all the components that make up this.yOffset are logged except this.weaveY, and that's just a fixed tuning value (equal to 2) defined when the ship is spawned. So unless this is somehow becoming undefined part-way through a repeated callback sequence, we're multiplying three things together that look like numbers and ending up with something that .isNaN.
I'll try adding in autojumper and see if I can replicate the problem again (Switeck - I have v0.42 - if I need a newer one can you PM me a link please?) but likewise this one has me confused.com
Well, the speed and maxSpeed values are sane (0/500 is a number). We can also deduce that there’s a bug in GNUstep causing NaNs to be logged as “1.#QNAN” instead of “NaN”.
@Switeck - can you also please test them by either just spawning one somewhere quiet in normal space, or increasing the role weight in shipdata.plist to something huge and then do a single normal mis-jump.
I'd like to confirm if the NaN issue happens without the use of the auto-jumper or not (maybe even temporarily remove that OXP).
@Ahruman - do you want me to log this as a bug on Berlios, as it doesn't seem to be a simple one?
I just tried the autojumper - the version I have doesn't seem to work on 1.76. All I get is a missile appearing which flies a little way then explodes and does some damage. But nothing else...
Nope, in the middle of nowhere with absolutely nothing around me.
Just saw a missile appear, fly a little way and then explode (doing a little damage to my shields).
Is there a current version available anywhere, as I'm not sure mine is up to date (v0.42). The readme in the file seems to contain half information from the misjump inducer for example.
Can you do the normal-space test without the auto-jumper installed and see if the NaN's persist please?
OK, following some extensive testing and collaboration between Switeck and me, we seem to have narrowed down the NaN problem (although I still can't reproduce it).
Anyway I've added script code to remove where we think it happens (and to deal with it if it does), so the OXP is up to v1.02. No real need to update from v1.01 though unless you have the problem too (NaN's reported in the log).
I've continued testing with Swarm v1.01 OXP to determine the underlying causes of the crashes.
I usually have to do 2 back-to-back misjumps before I see Thargoids at NaN location.
If I'm using this.weaveX (local variable) and get a NaN location for a Thargoid, even attempting log(this.weaveX); (or similar command) in the same .js script causes the game to crash to desktop!
In later tests, I'd replaced this.weaveX/Y with just weaveX/Y (making them global variables)...so I thought I'd eliminated its problems, until after a series of wormhole jumps I saw this in Latest.log:
04:06:31.187 [script.javaScript.exception.notDefined]: ***** JavaScript exception (<unidentified script>): ReferenceError: weaveX is not defined
04:06:31.187 [script.javaScript.exception.notDefined]: ../AddOns/Swarm 1.01.oxp/Scripts/swarm_thargoid.js, line 252.
04:06:31.187 [script.javaScript.exception.notDefined]: ***** JavaScript exception (<unidentified script>): ReferenceError: weaveX is not defined
04:06:31.187 [script.javaScript.exception.notDefined]: ../AddOns/Swarm 1.01.oxp/Scripts/swarm_thargoid.js, line 252.
(repeating about 15 times)
From what I can tell...weaveX isn't going undefined (when defined as a global variable) but rather the code that defines weaveX (this.shipSpawned = function() ) doesn't run BEFORE this.performWeave = function() calls weaveX. This may be because the system populator doesn't trigger a typical this.shipSpawned behavior -- ships added by the system populator may be treated like they've always been there.
This may be because the system populator doesn't trigger a typical this.shipSpawned behavior -- ships added by the system populator may be treated like they've always been there.
No. I can confirm that shipSpawned is triggered for all ships. That's what I use for NPC-shields, offender_traders, and randomshipnames.
This may be because the system populator doesn't trigger a typical this.shipSpawned behavior -- ships added by the system populator may be treated like they've always been there.
Commander McLane wrote:
No. I can confirm that shipSpawned is triggered for all ships. That's what I use for NPC-shields, offender_traders, and randomshipnames.
That leaves the other possibility then...that shipSpawned is just firing too slowly, and ends up running after this.performWeave = function() calls weaveX.
It can't be - the callback (which does the weaving) is initiated at the end of shipSpawned after the weaveX/Y variables are defined (or not as the case may be).
Switeck has pointed me in the direction of this problem and provided a link to a slightly modified (extra logging) version 1.01. With it as the only OXP installed I also get NaNs followed rapidly by a crash to Desktop with 1.01. If I misjump on my first jump after loading the game is doesn't seem to happen, but if I've done at least one normal jump and then misjump, or if a normal jump as the populator happens to spawn one of these in normal space I get a crash just as the witchspace tunnel starts.
Some extra logging on top of what Switeck added under the this.shipSpawned handler and the this.spawnedAsEscort handler does reveal it's happening because the frameCallback is starting before this.shipSpawned handler is fired, so this.weaveX and this.weaveY are both undefined.
The wiki says this about this.shipSpawned -
The shipSpawned handler is called for newly added ships. It does not trigger on adding but on the first update after adding. On a witchspace jump it means that first all ships are added to the system, then afterwards all the shipSpawned() events are triggered.
I notice that this.startWeave is called from the AI. I would hypothesis that the AI is loading and managing to send the sendScriptMessage: startWeave before this.shipSpawned() has fired some circumstances. Issues with reproducing this could be to do with different frame rates between machines. This machine I've tested on is running a framerate of 99.
The actual crash appears to happen on attempting to log(this.weaveX) or log (this.weaveY) when they are undefined (within the frameCallback code).
Firstly just to be clear, the current version (1.03) won't suffer from this problem, as this.weaveX and weaveY are removed in that (their values are hard-coded instead).
Also it seems a little odd, as whilst the callback is indeed started via the AI, it has to go through a couple of states first to get into the condition to do so (although it could conceivably do so before an update call if the ship spawns and goes straight into attack). Also logging an undefined value like that definitely shouldn't cause a CTD.
But you may be onto something with why I can't reproduce it, as my machine is lower power and has nowhere near that frame rate (I get max about 50, it's only a netbook). But it may be useful to the dev's for a possible underlying issue that is being highlighted here (and elsewhere).
For reference I've got a bug open on Berlios about this (bug 18485) - can you add your details to that please?
.
![[EliteWiki]](/images/elitewikismall.png){kind=small}
Capt. Murphy's OXPs