[Solved] The ultimate crash

[Eric Walch]

Found it! SVN patch against current trunk below to fix both my graphics oddities, and the general crashing bugs.

Nice find.

Thargoid's Wild Ships exposes this bug consistently, because it adds three stations each with two timers to many systems, so you don't need (m)any more timers from other sources to make this code path occur when the Kiota timers from the old system are being cleaned up. I guess most previous OXPs didn't involve that many timers that regularly.

Its of cause an oolite bug, but oxp makers were always warned to clean up their own timers. The Kiota station uses two timers, but only one is stopped when the ship dies. None is stopped when the ship is removed because the player jumps to another system.
Specially for timers etc we got a 'entityDestroyed' handler in 1.75 that always fires when an entity is fully deleted. The station should have stopped the running timers there.
Anyhow, it is good to hear that when a script fails to stop them, oolite's engine will handle it now without crashing.

[cim]

Its of cause an oolite bug, but oxp makers were always warned to clean up their own timers.

Not by the JS reference, they weren't. I didn't come in until 1.75.3, so this is the only guidance I've had on timers:

If the this parameter becomes invalid (usually because it’s attached to a ship that’s destroyed, or left behind when the player executes a hyperspace jump), the timer will be stopped and removed automatically.

... which says you should get away with it and don't need to manually intervene. I've tweaked the Wiki now to add the entityDestroyed suggestion.

[JensAyton]

Its of cause an oolite bug, but oxp makers were always warned to clean up their own timers.

The bug is triggered when there have been more than 16 active timers at once and then the count drops to 12. The priority queue used for timer dispatch is supposed to shrink back to 16 slots — 24 - ((24 - 12) * 2 / 3) — but instead shrinks to 8 slots — 24 - (24 - 12 * 2 / 3). This can happen regardless of how fastidiously individual scripts handle their timers.

Ironically, the bug fixed in r4729 caused the right thing to happen, since the new capacity was set to amountToRemove (16) instead of _capacity - amountToRemove (8).

[Bugbear]

Just letting you all know that my XUbuntu vs Oolite issue is no more.

It is with heavy heart that I hand in my Linux geek card. After 12 months of trying to nut out hardware issues with my speccy new laptop, I am admitting defeat.

This means I go crawling despondently back to an installation of Window 7 on the laptop bare metal. Back to the bloat, the intolerable reboots for the simplest of updates, and back to having to use an OS written by people for whom it is not in their interest to make the software as efficient as possible (otherwise how could they force people onto Windows .

It’s my own fault really. I shouldn’t have bought a Dell, rather I should have purchased a machine from a more Linux friendly vendor, so I feel I only have myself to blame here. Next time…

At the very least, though, I’ll still be running Linux via a VM. At least I’ll still be able to take advantage of the huge library of free software, and that’s software that has been designed to get the job done, not have its hand in my wallet. Just a shame that Oolite runs a bit jittery in a VM.

So now I'll be a garden variety Windows + Oolite commander. Oh well, things could be worse...

Thanks everyone for your assistance.