New sort of crash!(?)

[Lestradae]

I sadly have to report a new sort of crash under the "1.74" trunk.

The old crashes are gone, they simply happened after some time. The new crashes always seem to happen during fighting, I observed that as I am doing an Assassins mission atm. And now I noticed that the last entries in the log, though never stating a direct crash reason, always look similar to this here:

[jstest.alert]: Player alert condition changed to yellow (mass locked)
[jstest.alert]: Player alert condition changed to green (clear)
[jstest.alert]: Player alert condition changed to yellow (mass locked)
[jstest.alert]: Player alert condition changed to red (mass locked, hostiles present)

The alert condition changing as crash source, is that possible? I am forced to test it again anyways as I now lost the mission to this crash several times

/report

L

[Screet]

The alert condition changing as crash source, is that possible? I am forced to test it again anyways as I now lost the mission to this crash several times

Hmmm. Did you update the fuel collector script to make it crash-proof? That, however, was always writing a 301 as last log entry before the crash on my system.

Since then I did not have a single crash within many hours, but I was still running the reduced OSE script instead of the js WIP.

Once, when I tried to look for the stations with the js WIP I did have a crash during a short fight, too...but that would indicate that the js script does add some sort of ship which would cause a crash.

Maybe I simply was lucky not to have any crashes though...gotta update to the new JS and give it a try.

Screet

[Lestradae]

There will soon be an OSE V0.7+ for testing - that should have the fuel collector crash repaired (I altered the script following suggestions from Kaks & Cmdr Cheyd) - and I am already playing with OSE V0.7, so that will not have been the reason for the crash.

Will keep my eyes open if it happens again, with the same log entries ...

[Screet]

There will soon be an OSE V0.7+ for testing - that should have the fuel collector crash repaired (I altered the script following suggestions from Kaks & Cmdr Cheyd) - and I am already playing with OSE V0.7, so that will not have been the reason for the crash.

Will keep my eyes open if it happens again, with the same log entries ...

Hmm. Maybe I should increase logging like you did. With OSE.js in I just got a crash during combat...without OSE.js and my minimal ose-xml.plist it all was fine.

I guess it's a specific ship that's causing the problem. Maybe it's time to consider to use the js version and comment out all but one addition and then test...until there's an hint of what addition it requires to crash.

Screet

[Lestradae]

And again, end of log before/during crash:

[jstest.alert]: Player alert condition changed to yellow (mass locked)
[jstest.alert]: Player alert condition changed to red (mass locked, hostiles present)
[jstest.alert]: Player alert condition changed to yellow (mass locked)
[jstest.alert]: Player alert condition changed to red (mass locked, hostiles present)
[jstest.alert]: Player alert condition changed to yellow (mass locked)
[jstest.alert]: Player alert condition changed to red (mass locked, hostiles present)
[jstest.alert]: Player alert condition changed to yellow (mass locked)
[jstest.alert]: Player alert condition changed to red (mass locked, hostiles present)
[jstest.alert]: Player alert condition changed to yellow (mass locked)
[jstest.alert]: Player alert condition changed to green (clear)
[jstest.alert]: Player alert condition changed to yellow (mass locked)

[Svengali]

Unfortunately this doesn't tell us anything. It's just a few messages from a_c's jstest. Start adding logs to ALL your own files to determine which script causes the problem.

[Screet]

Unfortunately this doesn't tell us anything. It's just a few messages from a_c's jstest. Start adding logs to ALL your own files to determine which script causes the problem.

Since I don't have these crashes without ose.js, I strongly recommend to begin by disabling everything but one of what ose.js adds to the ooniverse. If it does not crash, add another one...until the crash is back. That should make it easier to locate the problem?!?

Screet

[Kaks]

Screet, couldn't agree more. A faster version of that idea was mentioned by Thargoid not too long ago: comment out half of the code that adds new ships: if there's no crash, the buggy ship is in the other half. Then try one quarter, one, eighth etc... You can eliminate many 'suspects' very quickly that way...

[zevans]

Screet, couldn't agree more. A faster version of that idea was mentioned by Thargoid not too long ago: comment out half of the code that adds new ships: if there's no crash, the buggy ship is in the other half. Then try one quarter, one, eighth etc... You can eliminate many 'suspects' very quickly that way...

Or, you know what you've changed recently, start by disabling the ones you've changed. If you had no crash, and you changed something, and then it crashes, it's not hard to point the finger.

[Screet]

*GRRR*

It's something that comes with the JS that adds additional ships. I fail to understand it. Previously, it only crashed during combat.

This time I was returning from a navy station to the normal station and was writing on the board...when I did look at the screen, I did fly much too far. Turned around and instantly when I hit the key to enable torus drive, oolite did crash.

How can that come from the JS? Or was it luck that I could play over 10 hours without the JS not having a single crash?

Screet

[Lestradae]

Screet, are we talking the newest OSE.js that is published over there at the OSE thread?

And why are you so sure it is this specific script?

My potential bugs list is growing again, first the navy lemmings (Super Tiger ) and now this ...

L

[Screet]

Screet, are we talking the newest OSE.js that is published over there at the OSE thread?

And why are you so sure it is this specific script?

I'm using the modified one you asked me to test and which I modified further and then sent back to you yesterday.

Without that JS, I did not have a single crash! However, all I can see that it does is to add ships when a player enters a system...?!?

Ohh...and you can (again) add the behemoth-fighter script to that bug list. The fix which I did send you doesn't work on all occasions.

I'm currently testing with this:

Code: Select all

this.shipLostTarget = function(whom)
{
   if(whom == this.attacker) {
	this.ship.reactToAIMessage("TARGET_LOST")
   } else if(this.attacker && this.ship.AIState != "FLYING_ESCORT")
    {
        this.ship.target = this.attacker
        this.ship.reactToAIMessage("HURRY_UP")
    }
}

As it appears that this.attacker is not always usable. Might be me missing something else due to misunderstanding, though

Screet

[Kaks]

As it appears that this.attacker is not always usable.

Correct, if a ship isn't actually being attacked, then this.attacker is undefined.
You might want to add an extra condition:

Code: Select all

if (!this.attacker) {
 // I want you to do this other thing...
}

[Screet]

As it appears that this.attacker is not always usable.

Correct, if a ship isn't actually being attacked, then this.attacker is undefined.
You might want to add an extra condition:

Code: Select all

if (!this.attacker) {
 // I want you to do this other thing...
}

Uh...but there WAS an if(this.attacker...) in there, but somehow it did not work. I guessed that this.attacker was equal to this.whom during the lost message and that's why I then did add the check for (whom == this.attacker) now.

Screet

[Kaks]

Screet, you're assuming that the target that was lost was the same ship that was attacking your ship.

That isn't always the case. If your ship is fighting 2 other ships, this.attacker is the last one that actually hit your ship.

Usually both players & NPCs tend to focus on just one of the attackers in order to maximise their chances of actually destroying one of them.

In other words, this.target doesn't switch in sync with this.attacker, contrary to what seems to be the underlying assumption for the code above...

As to 'somehow it didn't work', well I think you need to cater for all possible cases.
The code above doesn't do that, and the code before it didn't either. Sure, you changed the cases you test for, but if there are 3 possibilties and you only test for 2, you're still going to miss one of them...