Trunk...a new crash when scooping splinters

[Screet]

the crash I get from OSE hardpirates. Turns out only to happen on 64bit

The OSE hardpirates crash only happens on 64bit systems?

That's bad then, I can't hope to find the problem then. Not havin' a 64bit OS an' all

And the development tools also do not work in 64bit, thus I can't debug there

It's really that way: Within around 10 minutes, I get a crash with hardpirates enabled. In the debugger on XP32 there's no crash

Could that be the timer thing that Eric did mention? Vista64 crashes with the timer crash oxp while xp32 does not!

Eric: I'm sorry...I'm simply too stupid when I try to do multiple things at once. I did replace the JS, but not the shipdata from OP (it's integrated in OSE thus I replace things in there). After I updated the OSE shipdata file, everything was fine!

Screet

[Screet]

Most timer issues were with timers in ship scripts because the script that contained the timer disappeared when the ship was removed. With this ore processor I made sure the timer was created in the worldscript itself. The splinters only call a worldscript function that start the timer within the worldscript. Or even better. The timer is only created on startup. After that I use only the start/stop option for that timer.

Do I understand this properly? There is a bug in Oolite that after removal the timers still do exist and try to call a js that has been removed?

If so, what is required to make ships like behemoth-carrier safe? I'm talking about 2.5.1 here - the script says that it's from you and there's a script with a timer for it that is called via shipdata.plist

Then there's militaryfiasco, which has subentities for ships and these subentities run a script with a timer (smshipsubent.js).

Finally there's buzzer-wowbagger-insult.js in OSE.

Aside from that all timers I found appear to be in worldscripts (might still be too early in the morning). Thus, maybe, all these are already safe - I just want to understand this...I must admit that I was in the hope that the OSE hardpirates would give an explanation why they cause my vista machine to crash (which has problems with the timer-crash-test), but the only hardpirates with possible timers appear to be behemoths.

EDIT: Could that be the cause of my crash? The behemoth shipscript does create and use a timer, but it's not always asking wether the timer exists. It does call this.cloakingTimer.stop() for example without checking for it's existence.

The buzzer-wowbagger and smshipsubent (from military fiasco) do not stop their timer - can this be a problem?

Screet

[Eric Walch]

Do I understand this properly? There is a bug in Oolite that after removal the timers still do exist and try to call a js that has been removed?

If so, what is required to make ships like behemoth-carrier safe? I'm talking about 2.5.1 here - the script says that it's from you and there's a script with a timer for it that is called via shipdata.plist

Then there's militaryfiasco, which has subentities for ships and these subentities run a script with a timer (smshipsubent.js)......


The buzzer-wowbagger and smshipsubent (from military fiasco) do not stop their timer - can this be a problem?

Screet

For the behemoth this timer only is created when the player cloaks while attacking the behemoth. So there is a sure link with attacking a behemoth while cloaked if it would lead to crashes. In future version 2.5.2 I added extra code that deletes the timer when the ship dies or the player hyper jumps out. 2.5.2 it not yet uploaded.

In military fiasco the problem is less as it is a once only timer. That will delete itself. For both oxp's I never experienced a timer related crash.

[Screet]

For the behemoth this timer only is created when the player cloaks while attacking the behemoth. So there is a sure link with attacking a behemoth while cloaked if it would lead to crashes. In future version 2.5.2 I added extra code that deletes the timer when the ship dies or the player hyper jumps out. 2.5.2 it not yet uploaded.

In military fiasco the problem is less as it is a once only timer. That will delete itself. For both oxp's I never experienced a timer related crash.

I did not attack any behemoth during my crash experiences, but I did fly around cloaked. The thing is, that the bt from my crash is exactly looking the same way as that for the timer test oxp.

OSE does add behemoths with the same script as hardpirates. If I add hardpirates, things crash, even if I only fly around cloaked doing nothing (leaving the machine alone).

At least in the trunk version, pirates can and will become hostile to cloaked ships, as cloaked ships always become shortly visible (and targetable) and then vanish again. Thus they cause permanent switching between condition yellow and red.

Could this be enough for the current behemoth script to cause problems? Could also cloaked NPC ships do the same with that script?

I'd really like to resolve this, as it seems to be the only crash left when I play oolite.

The timer crash does require data execution prevention to be enabled, BTW.

Screet

[Commander McLane]

The personalities ships give out commsMessages through a timer. I noticed a lot of JS-errors of the type "this.ship has no properties" when one of them jumped out and I followed in its wormhole. In the new system the old ship is of course no longer there, but its timer still tried to send commsMessages. Obviously the old timer is not deleted together with the ship, and the re-spawned ship gets a new timer.

The solution is easy: In the script delete the timer on both witchjumping out and shipDied.

I only had JS error messages though, no crashes. (Mac)

[Eric Walch]

The solution is easy: In the script delete the timer on both witchjumping out and shipDied.

I only had JS error messages though, no crashes. (Mac)

Yes, that is also the solution I had prepared for the behemoth. The only ship removal a script can't detect is when the player loads a new game.

Version 2.5.0 was already tested against timers and the way it was programmed I could not crash it on my mac. But 2.5.2 will completely delete the timer on death. But this was all because it tried to access properties of a non existing script. Screet seems to get already problems while the script is still there.
Will upload 2.5.2 this evening to see if this changes things for Screets machine.

[Kaks]

He's found the reason for his crashes, and hopefully corrected it already. It's a window 'security' setting, which most games need to override anyway.

[Eric Walch]

He's found the reason for his crashes, and hopefully corrected it already. It's a window 'security' setting, which most games need to override anyway.

I read it. It has nothing to do with the older issue of timers calling properties of removed scripts. This leading to crashes was fixed with 1.73. Nevertheless I already wanted to update the behemoth script already a long time because it is cleaner to explicit delete the timer while I can.

[Screet]

He's found the reason for his crashes, and hopefully corrected it already. It's a window 'security' setting, which most games need to override anyway.

Not really, even broodwar seems to have been fixed, although it's so very old. Currently, Oolite is the only exception I have in that list

I did have my own program in there a few months ago, too. Came from a problem with multithreading and cleanly exiting the application while another thread was running.

Screet

[Kaks]

Really? I've got EU Rome & civ4 in that list, which were the only games I'd installed on that dev computer - it depends on what type of thinking games you have used in the past, I suppose.

Running js timers doesn't involve multithreading, it would be interesting to see a code change that avoids that...

edit: But I stand corrected. I should have said 'some other games' instead.

[Screet]

Sounds familiar. I also scooped up things and suddenly my scoop icon became red because of a full hold. It contained 160 ton of food!
That was not from this oxp but from my cargo Wreck modification. Or my translation into the new method has a bug or there is a bug lurking in oolite.

Hmmm. I did now get that problem when I scooped containers - without CW it seems to be gone. However, I did have the latest version from the wiki.

Strange.

Screet

[JensAyton]

Running js timers does involve multithreading, it would be interesting to see a code change that avoids that...

Um, what? There’s no multithreading involved in anything JS-related. Timers are dispatched using the same synchronous event handling as the simulation.

[Kaks]

Oops, did I really write that?? Corrected now!