Easy things first: Does this occur if you remove the Hermitage OXP?
Easy answer - no, it doesn`t :) Because starting a new career by selecting an Easy option in Hermitage is the only scenario in which I get this kind of errors. That puts the player into TL13 Rexebe system in G1, other two options work as intended.
serpent_death is referring to the Serpent Cruiser which I`m using. Suppose there is also *_trader and *_pirate as I encountered mentions of them not being found in the log before, but it works OK on my main savegame and I never had "Universe is full" error on it. Never saw it, to be precise, but I generally look into the log first thing after the game crashes.
(edit)
I tried that - starting a new Hermitage on Easy - under my test install, it went fine with no errors. Log is included for comparison, although there`s really nothing fancy in it (at least that I could see)
I also took the savegame created under test install and tried loading it under main. End result was basically the same (black screen and force-exit), but - "universe is full" errors were only being generated by *shotEntity and *effectEntity. My best guess is that the Hermitage itself, or player ship type, is unrelated, but *something* is spawned in this exact system by one of the OXPs that works incorrectly. Please see the log attached.
I think you will need the 1.91 test release to be able to debug this further. You can get 1.91 from either here or here (second one is a monolithic executable containing core+selected OXPs and decompresses in memory when run). You can install it alongside 1.90 and as long as they are in different folders they can coexist peacefully. What 1.91 allows you to do is dump the full list of entities in the universe at any time. Just launch it normally and once you start getting "Universe is full" messages in the log press "p" to pause and then press "0" (zero) to dump the entity list in the log file. Maybe the list of entities present could give a hint of which OXP is responsible.
I also took the savegame created under test install and tried loading it under main. End result was basically the same (black screen and force-exit), but - "universe is full" errors were only being generated by *shotEntity and *effectEntity. My best guess is that the Hermitage itself, or player ship type, is unrelated, but *something* is spawned in this exact system by one of the OXPs that works incorrectly. Please see the log attached.
Just to let you know, I've replicated your OXP set and am getting the same issue - universe is full when loading the Hermitage scenario. I've started working through where the conflicts might be occurring, but it might take me a while.
Just to let you know, I've replicated your OXP set and am getting the same issue - universe is full when loading the Hermitage scenario. I've started working through where the conflicts might be occurring, but it might take me a while.
Good to hear that, maybe something useful will uncover itself in the process :) I`d say cross-referencing it with one used by Cholmondeley could narrow down a potential issue a lot, since he seems to be starting the same career in Rexebe fine.
In the meantime I will produce a test-build log with entity dump.
edit: apparently I won`t, as pressing the zero key produces no result in the log file. These excerpts could be noteworthy:
15:31:41.863 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (Hermitage_Main 0.8.1): TypeError: h is null
15:31:41.863 [script.javaScript.exception.unexpectedType]: Resources/Scripts/oolite-populator.js, line 2062.
No, that should not be relevant. Had a look and there is something else you might try: Open oolite.app/Resources/Config/logcontrol.plist and find this line:
universe.maxEntitiesDump = no; // Dumps all entities when universe is full (Can be quite verbose)
Change the no; to a yes;, restart the game and let it fill up the universe. Entity dump to the log should happen automatically. Make sure you are using the test release version for this.
Entity dump to the log should happen automatically.
That did it, presenting me with a 318MB file with thousands of recursive entity dumps. I took liberty of compiling a (seemingly) relevant information to a separate file, which is attached.
Can you try taking out "Convoys"? I think that one is spawning a lot of extra ships.
That has cleared the issue :)
Right away I saw that Shift+F shows an entity count around 1380, and no abnormalities in the log (let me know if you still want to see it)
(edit)
eager to try out the 0.8.2 with mission generation fixed, if you had a chance to look over it. Basically the only game-breaking issue remaining at this point.
For clarity, I don't think Hermitage is causing Convoys to do anything unexpected. In fact, I think you'd get the same error if you made your way to Rexebe (G1) independently with Convoys in play. I suspect that the high number of interstellar connections (11 in the case of Rexebe) makes the populator add more ships. Convoys takes over some of those roles based on it's role frequencies in it's shipdata file, and then adds a bunch of extra escorts for each. At least, that's the working theory I have at the moment.
Just out of curiosity: how is it performing with this many entities spawned?
Did some quick fly around for observations. In one word - good :)
It takes around 4GB of memory, CPU usage is 15-18% (i7 7800X 6-core @3.5GHz), GPU usage is 25-30% (GTX1080 8Gb), FPS is 55-59 docked (I have set a 60 limit), 43-47 in fly and 33-38 amidst a heated combat (entity count got up to 1500), though CPU and GPU both aren`t receiving considerably more load judging by the graphs.
For clarity, I don't think Hermitage is causing Convoys to do anything unexpected. In fact, I think you'd get the same error if you made your way to Rexebe (G1) independently with Convoys in play.
That was my thinking also, that the system itself is behaving abnormally with one of the OXPs. In fact, I recall being unable to hyperspace to Onrira system (G1 TL14, close to Lave) back in the day, with the game stuttering heavily on witchjump and then always crashing - though I didn`t looked in the log then and it could be also attributed to JS out of memory. Maybe some tune-up to Convoys is in order to limit its fertility for such cases.