q-bomb + shipTakingDamage = freeze (rev 4514)

[Commander McLane]

While testing the following code I noticed a behavioural change in rev 4514 compared to rev 4496:

Code: Select all

this.shipTakingDamage = function(amount, whom, type)
{
    if(type === "cascade weapon" || amount === 1000)
        this.ship.energy = this.ship.maxEnergy;
}

In rev 4496 this worked, making the ship immune to q-bombs.

However, in 4514 Oolite freezes shortly after the cascade reaches the ship. The log file gets flooded with entity dumps, each of which begins with

Code: Select all

10:51:43.765 [universe.addEntity.failed]: ***** Universe cannot addEntity:<OOQuiriumCascadeEntity 0x118bf0350>{0.000000 seconds passed of 20.000000} -- Universe is full (2047 entities out of 2048)

So it seems that manipulating the calling ship's energy during a shipTakingDamage event is doing something nasty which it didn't do before, if called during a cascade (where it is called once per frame, I guess). It works if called during an energy bomb explosion (where it is a one-shot event, I guess).

[JensAyton]

Bug #18054

[Commander McLane]

I'm more puzzled.

I just did some more tests, giving the object-to-immunize much more energy, setting its energy recharge to 0, then restoring the original values.

In every single case it worked without freezing. I don't think that I changed anything else. So whatever causes the freeze doesn't hit all the time.

[Kaks]

Aha! Methinks this is exactly the same problem reported here:

https://bb.oolite.space/viewtopic.php?p=154221#p154221

When there were enough entities to start with, the universe would fill up with explosion debris very, very quickly, Oolite would freeze, and eventually crash.

Not anymore!

[Eric Walch]

Aha! Methinks this is exactly the same problem reported here:

Not quite the same problem. Even without reaching the max entities, the oxp freezes oolite. I just tested and created a fix

What is happening: Every update, the energy of the ship is lowered as long as it touches the blast. The amount depends on the framerate so that the amount per second is constant. Every frame the handler in maclanes example triggers. On testing I got a typical amount per frame of about 900. (at least with a TAF == 1 and a normal high frame rate) When the ships energy was higher, the ship never died and the handler just restored its energy to max. With dropping framerate, the energy damage per frame rose, until a level that is was enough to kill the ship.

And only when the energy was enough to kill the ship, a new cascade entity was initiated. But after that creation the energy was restored and the ship did not die. The next frame the energy damage was enough to kill and another energy blast was created. This cycle becomes a loop and completely freezes the game. The max entity limit is reached and while the logging is less severe than before the recent changes, the loop will never break.

The most complex fix would be to create the blast after the shipTakingDamage handler has fired. An easier fix that I now tested was just to remember that the ship initiated a new energy blast and reset the energy to zero after the handler. That guarantees that the ship dies on a q-mine when energy drops below. A script can only safe the ship when making sure the energy never can drop below zero. Anyhow, the fix will prevent a freeze on a q-mine for such an energy restoring script.

In rev 4496 this worked, making the ship immune to q-bombs.

I think this was just coincidence. When the damage per frame was less than the ships energy there never was a problem. The loop only was created when the damage in one frame was bigger than the ships energy. I think McLane hit the second situation in his later testing.

[Eric Walch]

While looking at that code, I notice the line in cascadeIfAppropriateWithDamageAmount:

Code: Select all

if (energy < amount && energy > 10 && [self countsAsKill])

That means a ship with energy lower than 10 will not cascade. That means that when in the previous frame the energy was lowered to a value between 0 and 10, the ship would not cascade but just die. Seeing the values, this will only happen in a few percent of the cases and and is probably no big deal. Testing for maxEnergy is probably better but I am not sure if that might introduce a bug elsewhere and we better leave it this way.