Swarm OXP

[Richard-H]

Thargoid,

after the installation of the swarm oxp i found that it was not possible to scoop up cargo pods or other things
the fulelscopes seems to be not working the are in my equipment list and in my save file but they are not working
there were no errors in my logging
after removing the oxp its works again

my current version is Updated to revision 4736 (1.76.1 )

[Thargoid]

Ok, that's a new one! Add a ship OXP and break trunk equipment.

I haven't yet tried trunk 1.76.1 so I can't comment yet. I'll grab a copy and see what I can see.

But to ask the obvious question first - can you confirm that in the game where you had Swarm installed, that the fuel scoops were purchased and undamaged? I know you said that after uninstalling the OXP you could scoop again, but was that a continuous game (ie you saved with Swarm installed and not being able to scoop, then with the OXP removed the scooping works again with the same save game).

The OXP doesn't touch anything at all with regard to fuel scoops. There's no way it could stop you scooping, other than a tangle with one of the ships causing your scoops to get damaged in the normal fashion for damage.

[Thargoid]

OK, just tried Windows 1.77 trunk rev 4738 (the current nightly build) with just Swarm.oxp and Vortex.oxp installed (using my normal test commander) and I can scoop cargo without any problem.

One other addendum to the above question - are you sure your cargo hold wasn't full at the time?

[Richard-H]

OK, just tried Windows 1.77 trunk rev 4738 (the current nightly build) with just Swarm.oxp and Vortex.oxp installed (using my normal test commander) and I can scoop cargo without any problem.

One other addendum to the above question - are you sure your cargo hold wasn't full at the time?

Thargoid,

sorry that i did not check my own set up firs
after a upgrade of my graphics card linux driver and a reboot the effect was gone
thanks for all the help

[maik]

After the installation of the swarm oxp i found that it was not possible to scoop up cargo pods or other things

after a upgrade of my graphics card linux driver and a reboot the effect was gone

[Richard-H]

After the installation of the swarm oxp i found that it was not possible to scoop up cargo pods or other things

after a upgrade of my graphics card linux driver and a reboot the effect was gone

maik,
Cant explain it probably the reboot did the trick my machine was up for 6 months so you never know

[Thargoid]

Glad it's fixed...

[Switeck]

For whatever the reason, this.xOffset and this.yOffset seems to have undefined/NaN values at the time of the check. I do not know why, but I don't think OXPs are to blame.

Also, once this happens...I often cannot scoop cargo or use wormholes either. It's almost always the case after I use LongRangeScanner OXP to get near one of the NaN distance ships.

If I had to guess, this problem may be like the Random Hits bounty bug...where (if I recall) shooting the Space Bar gave a gigantic bounty because the variable was treated as a string instead of an integer number.

[Thargoid]

If I had to guess it's the Math.sin segment of the calculation of the variables generating the NaN, along the lines that you say relating to decimal places and rounding. Specifically the variables are defined as

Code: Select all

	this.xOffset = (this.ship.speed/this.ship.maxSpeed) * this.weaveX * Math.sin(clock.absoluteSeconds - this.weaveTime);
	this.yOffset = (this.ship.speed/this.ship.maxSpeed) * this.weaveY * Math.sin(this.phase + clock.absoluteSeconds - this.weaveTime);

this.weaveX and this.weaveY are both equal to 2 (as a scaling tweak factor) and this.weaveTime is set to clock.absoluteSeconds when the weave starts (when the ship goes into AIState "ATTACK_SHIP").

My guess is that the values in the time subtraction in the brackets are ending up causing the NaN, hence the whole thing is going NaN. That looks like it would more likely be something odd in the underlying SpiderMonkey, exacerbated perhaps by how the code deals with interstellar space.

Anyway what I'm going to do I think is to add a isNaN check into the script when I do the update for 1.76.1 when that is released (to overcome the issue with the missile scanclass requirement). That way we can see if anyone else experiences/reports such a problem - as I said I can't reproduce your findings on a similar machine set-up (although I don't of course have your OXP list).[/color]

[Switeck]

What about when the time is adjusting? (as a result of a just-finished hyperspace jump)
Could that throw off the calculation somehow?

[Thargoid]

What about when the time is adjusting? (as a result of a just-finished hyperspace jump)
Could that throw off the calculation somehow?

I also thought that, but I tried it (setting the clock to advance via the console whilst sampling the variables by logging) and it made no difference at all.

In any case the weave only triggers when the ship goes into ATTACK_SHIP, which it wouldn't do normally when the clock is advancing.

[JensAyton]

My guess is that the values in the time subtraction in the brackets are ending up causing the NaN, hence the whole thing is going NaN.

For that to happen, this.weaveTime must be NaN or actually not a number (undefined, an object, or whatever).

[Thargoid]

For that to happen, this.weaveTime must be NaN or actually not a number (undefined, an object, or whatever).

It's defined in the function which starts the callback - see here where I posted the wider code (or just look in the OXP).

This is where I'm struggling, as it's about the only thing in there that could trigger a NaN I would say (it's not complex code). Plus as I said I also can't reproduce it on my machine, which is making it even more difficult to fix.

As I said I can put in NaN checks and if so set the variable to something suitable (a small random number probably) but I don't really want to do that prematurely if this is showing up something more fundamentally wrong either in the OXP or somewhere deeper.

[JensAyton]

Another possible source of NaNs would be if both this.ship.speed and this.ship.maxSpeed were 0. I can’t see any reason why they would be when you’ve already checked that the ship is valid, but it’s a conceivable Oolite bug. It would be helpful if Switek would log these values too.

Obligatory irrelevant style critique:

• Since xOffset and yOffset are only used in one function and are not persistent, they should be local variables (var xOffset = …).
• In stopWeave, you’re calling isValidFrameCallback(). As per the documentation, this function isn’t intended to be used in live code. It’s really only there for one of Oolite’s validation tests. If this.callbackID is defined, you should assume it’s valid and delete it when removing the callback.

[Switeck]

In any case the weave only triggers when the ship goes into ATTACK_SHIP, which it wouldn't do normally when the clock is advancing.

The longer the hyperspace jump, the longer the clock is "stuck" advancing. As a result of my wormhole chain-jumping, (done too quickly for the clock to catch up) more than 100 hours can pass.
...And these Thargoids attack immediately.

Ahruman said:
"Another possible source of NaNs would be if both this.ship.speed and this.ship.maxSpeed were 0."

Ok, I added this line:
log(this.xOffset,this.yOffset,this.ship.position,this.ship.speed,this.ship.maxSpeed,clock.absoluteSeconds,this.weaveTime,this.phase, Math.sin(clock.absoluteSeconds - this.weaveTime),Math.sin(this.phase + clock.absoluteSeconds - this.weaveTime)); // ADDED to hopefully figure out these NaN bugs!

The first instance of NaN in the log appears to be this:
11:01:12.500 [NaN]: NaN, (1.#QNAN, 1.#QNAN, -1130.27), 0, 500, 177.3475000075996, 177.3475000075996, 4.6607371108851785, 0, -0.9986663387361366
11:01:12.500 [NaN]: NaN, (1.#QNAN, 1.#QNAN, -9523.83), 0, 500, 177.3475000075996, 177.3475000075996, 2.485774253107807, 0, 0.6098080700624203

I do not know what to make of those values.