Trunk 1.75.4.4621

[Fatleaf]

I have tested this as before and I am still getting 2046 entities!

The Log, http://www.boxcn.net/shared/19kfkjymo11nxutahxqk

Hope it helps.

[another_commander]

Have the scripts of XS OXP been fixed? This is the OXP adding continuously entities due to becomeExplosion sending also a shipDied event. The only way I can think for fixing it in code is to purge entity generation earlier than 2047 and not attempt to write to log, but I am not convinced that this is a good thing.

[Eric Walch]

I have tested this as before and I am still getting 2046 entities!

The Log, http://www.boxcn.net/shared/19kfkjymo11nxutahxqk

Hope it helps.

That you get that number of entities is correct. The oxp is asking for that number of entities. Before the death actions had a bug that prevented the shipDied()from triggering when a 'becomeExplosion' was called by AI. (The JS explode() method did trigger death actions).
becomeExplosion not triggering any death action was broken somewhere around oolite 1.72.

The missile you use spawns a lot of primary entities. Every primaryentity itself also spawns a lot of secondary entities. And those secondary entities spawn a lot of tertiary entities. If you count them up you get those high numbers. It was more a bug that you only got 500 Before the bugfix, only the entities that destroyed themselves by colliding into each other, the death actions triggered so they could continue the chain of debris formation. Now all do.

So its mainly an oxp bug(1). Lucky enough this is only a wip missile and can still be fixed before any release.

To change the code so it works with both Oolites is not just a mater of changing numbers, it needs another concept. e.g. the way McLanes fireworks.oxp handles it. His firework missiles creates also a similar cascade of entities without above problem.

1) bug is maybe the wrong word as oolite the last two years never worked as it should and on testing the oxp did work.

[Fatleaf]

Brilliant. So at least we have a fix for the original bug and we have also tested the fix and found that it works.

So that is good news. Thanks

[Eric Walch]

I just realised that the easiest way to make the behaviour consistent between oolite versions before and after the bugfix is using the 'who' parameter of the event because the AI command 'becomeExplosion' blames nobody for the explosion. e.g. changing

Code: Select all

this.shipDied = function ()
{
        system.addShips("flash1", 40, this.ship.position, 400);
		worldScripts["XeptatlsSword-Main"]["getRidOfThargoids"]();
};

into

Code: Select all

this.shipDied = function (ship)
{
    if (ship)
    {
        system.addShips("flash1", 40, this.ship.position, 400);
        worldScripts["XeptatlsSword-Main"]["getRidOfThargoids"]();
    }
};

will make sure it won't do anything when the explosion is initiated by an AI command.

Transferring a null parameter is mainly because oolite can't blame a ship with 100% certainty. Another ship could have used a "safeScriptActionOnTarget: becomeExplosion". Than is it better to blame nobody, like the JS explode() does.

[Switeck]

I tried something crazy with Trunk 1.75.4.4621 ...I dropped 100's of cargo canisters in a spot and then activated my energy bomb. Game froze, flooded memory, then crashed when it approached 2 GB ram usage.
The log file was over 300 MB in size.

In more regular playing, I was doing large numbers of cargo contracts and passenger contracts at the same time. When I launched from the main station (didn't try any other stations at the time), the game would freeze for >5 seconds -- sometimes close to 20 seconds. I checked Windows Task Manager and it reported oolite.exe as consuming >600 MB ram at one point.

Using Win XP Pro SP3
19:56:54.140 [rendering.opengl.version]: OpenGL renderer version: 3.3.0 ("3.3.0"). Vendor: "NVIDIA Corporation". Renderer: "GeForce GTS 250/PCI/SSE2".

I can post a log for that if necessary, but it'll have to wait a couple days so I can test it again thoroughly if I need to bundle up my savegame/s, log, and minimal OXP list.

[Eric Walch]

I tried something crazy with Trunk 1.75.4.4621 ...I dropped 100's of cargo canisters in a spot and then activated my energy bomb. Game froze, flooded memory, then crashed when it approached 2 GB ram usage.
The log file was over 300 MB in size.

I can not reproduce that. Things of type cargo should not initiate an energy blast themselves (Unless they explicit carry fuel). With 100 cargo pods I just get one energy blast and the entity count does not significantly increase during the blast.

[another_commander]

I can confirm Switeck's findings also on my system. Threw energy bomb amidst 960 cargopods. Memory was consumed totally. The log has some interesting information:

Code: Select all

11:36:29.488 [universe.addEntity.failed]: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x2b161398>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
11:36:29.488 [universe.objectDump]: DEBUG: Entity Dump - [entities count] = 2047,	n_entities = 2047

Investigation of the log indicates that the first 498 cargopods are destroyed by the e-bomb, then the entity overflow happens. The entities spew in the log after the limit is reached indicates a lot of

Code: Select all

11:36:29.488 [universe.objectDump]: Ent:   2  OOFlashEffectEntity position: (-3006.02, 43734.2, -4215.32) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT range: 507.284 (visible: yes)
  11:36:29.488 [universe.objectDump]: Ent:   3  OOBigFragmentBurstEntity ttl: 1.000s range: 507.284 (visible: yes)
  11:36:29.488 [universe.objectDump]: Ent:   4  OOSmallFragmentBurstEntity ttl: 1.500s range: 507.284 (visible: yes)
  11:36:29.488 [universe.objectDump]: Ent:   5  OOSmallFragmentBurstEntity ttl: 1.500s range: 877.768 (visible: yes)
  11:36:29.488 [universe.objectDump]: Ent:   6  OOBigFragmentBurstEntity ttl: 1.000s range: 877.768 (visible: yes)
  11:36:29.488 [universe.objectDump]: Ent:   7  OOFlashEffectEntity position: (-3160.44, 43133.6, -5292.9) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT range: 877.768 (visible: yes)

'Unable to add entity' messages continue arriving until memory has been exhausted. I think we are just toying with the limits of the software/hardware here, expecting a no-crash in this case is the same as filling up a hard drive to maximum and expecting that nothing wrong will happen.

[Gimi]

Suggestion from someone with no knowledge of the inner workings. Griffs alloys and wreckage does nice things with explosions. Could that be the culprit, as I understand it adds additional wreckage that expires after a short while. May be that other OXP,s work in a similar manner.

[Eric Walch]

Investigation of the log indicates that the first 498 cargopods are destroyed by the e-bomb, then the entity overflow happens. The entities spew in the log after the limit is reached indicates a lot of

That number seems expected somehow. Every explosion generates 3 particles: OOBigFragmentBurstEntity, OOSmallFragmentBurstEntity and OOFlashEffectEntity before the entity itself is destroyed. At some point there exist 4 particles for every destroyed one. and 4 x 498 = 1992 that leaves 55 remaining entities in the system until the max of 2047 is reached.

Only the debugging makes that on every failure of adding an entity the whole universe is dumped to the log. (At least that dumping to the log will stop in deployment builds.)

EDIT: I just build a version that did not make the entity dump. Than adding 1000 cargopods and blowing them up. FPS stayed reasonable high and in a few seconds the whole computer was back to normal. The main problem seems to be the quantity of entity dumps to the log.
I now only have

Code: Select all

[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15bab1000>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOFlashEffectEntity 0x11c856e60>{position: (-194714, 48313.6, 512538) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15bab6e00>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOFlashEffectEntity 0x11c856fd0>{position: (-193810, 48251.6, 512561) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15babcc00>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOFlashEffectEntity 0x11adec8b0>{position: (-193937, 48100.2, 512593) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15bac2a00>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOFlashEffectEntity 0x11adeca20>{position: (-194570, 48142, 512624) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15bac8800>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOFlashEffectEntity 0x11c783d50>{position: (-193883, 48311.9, 512626) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15bace600>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOFlashEffectEntity 0x11c783ec0>{position: (-193963, 48232, 512644) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15bad4400>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOFlashEffectEntity 0x11cf1d440>{position: (-193706, 48368.2, 512658) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15bada200>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOFlashEffectEntity 0x11cf1d5b0>{position: (-194054, 48254.8, 512667) scanClass: CLASS_NO_DRAW status: STATUS_EFFECT} -- Universe is full (2047 entities out of 2048)
[universe.addEntity.failed] Universe.m:3701: ***** Universe cannot addEntity:<OOBigFragmentBurstEntity 0x15bae0000>{ttl: 1.000s} -- Universe is full (2047 entities out of 2048)

without the whole universe being dumped after every failure of adding an entity. This info to the log seems enough for me.

[Kaks]

Clearly a case of too much debugging!

One more thing, though! When the universe is almost full alloy/scrap metal producing entities would not produce anything when exploding because of the explosion effects adding to the entity count...

A quick code change later, the situation seems to be a lot better: we do get some alloys/scrap metal from them even when the universe is almost full!

Eric, I'll wait for your commit, then I'll add mine!

[Cody]

I think that this may be music to my ears... many thanks, Devs!

[Switeck]

Should I break my earlier post up as a new topic?
(The bit about "lots of" contracts causing huge memory leaks.)

[another_commander]

Should I break my earlier post up as a new topic?
(The bit about "lots of" contracts causing huge memory leaks.)

You have a savegame you could upload? I wouldn't call 600MB usage a "huge memory leak", as memory utilized by the game may depend on the OXPs running, but the bit about the pauses is of interest.

Edit: Just realized you are referring to the actual application memory, not the total system memory used. In that case, it indeed seems to be wrong having 600MB on the base app. Worth looking at.

[Eric Walch]

Eric, I'll wait for your commit, then I'll add mine!

I just made the commit. I did not fully removed the dumping of the entity list but added a switch in logcontrol.plist. Default will be universe.maxEntitiesDump = no; but if needed, the logging can be switched on easy by editing the plist. (Make sure you update the local copy of logcontrol.plist when you have one like me)

With 1000 cargopods, the FPS rate only dropped to 8 for about a second and than restored to normal values within one or two seconds.