Sun_distance_modifier vs government affecting oolite standard populator in an unfortunate way.

[DTHP]

Version 1.84

I finally tracked down an issue of FPS stuttering that suddenly occurred only to vanish "sometimes" a few minutes later in a government 3 system (Dictatorship). As some of you may know, I am making extended star systems with a few bit more planets to visit than the single one we are used too.

Now i set the sun_distance_modifer to 1000.0 and i assume that between the main planet and the sun that there are a lot of rocks and ships spawned because the entities in the system sky-rocketed to 1400 and sometimes something, very likely something with collision detection began to use a lot of resources.

I discovered the reason when i set the government to 6 (Democracy) and sun_distance_modifier to 1000 when it in system "7 144" spawned more than 2000 entities. I think the Oolite began to struggle with that many entities because afaik, the cap is around 2048.

I assume the more secure a government the more ships are spawned. Add to that the "import" of pirates from nearby Anarchy systems.

I fixed it by adding my own "empty" populator via the planetinfo.plist, and the entity list fell to a size of 59. Those new populator functions are empty and do nothing.

It is a pretty easy thing to just add two settings in the planetinfo.plist and "might" trigger this behaviour and I see the fault of it somewhere in how the standard populator is spawning entities rather than just capping the sun_distance_modifer that will be an exercise in itself in finding a fair cap.

As a side note i was surprised to see the main station launch a patrol and a single trader(sometimes with escorts) after undocking with "empty" populators doing nothing. The station is using stationAI.plist, not the new Javascript based one.

[cim--]

This is probably to be expected. The repopulator mechanism periodically adds ships to a system from hyperspace and station launches (the exact frequency dependent on a number of factors, but government and neighbours is a lot of it). The initial population aims to make it appear that the repopulator has been running for a while already. Holding the repopulator rate constant, if the spacelanes are longer then each ship will be present in the system for longer (assuming travel speeds don't change), so the number of ships present will tend to stabilise at a higher value, so the populator adds more to start with to ensure that the spacelanes are generally populated to the appropriate density. If you set a `sun_distance_modifier` 50 times normal, that means approximately 50 times as many ships. Even if the populator didn't do this, the repopulator would mean that the count of ships went increasingly high as more of the ships it added went onto the very long W-S or P-S lanes. I don't think there's anything the standard populator/repopulator combination can really do about this case - having the OXP cancel both of them and substitute its own is probably best. Adjusting the AIs to make ships far less likely to want to head to the sun in the first place would also probably be needed if you kept the 'populator simulates the repopulator' idea. (I would guess that the ships launching from the station may have come from emptying the populator but not the repopulator?)