This is good, Bonk, should we start logging this stuff to text so we can examine WHY this is as stable as it is?
Logging to text would add load and perhaps destabilise it as the logfile grows. I dont think that logging would tell us anything we don't already know.
This is the EXACT same setup is SGO5 with the exception of the Map, shiplist...
I noticed. You forgot to remove the TigerHeart from the playable races.
Should not affect things though and cannot be changed now.
...and ONE tweak of the GF files (I increase the maximun nuber of AIs removed automaticly)
Good call. What did ya increase it to?
I'm not going to cleanthe DB until it starts getting unstable, I want to see how long we can got with this setup before it all goes to hell
I've been watching the db size, its been hovering around 900KB for the last two days. I'll take another peek tomorrow, we may find we do not need to clean it until too many AI accumulate from disconnected missions. <cough *firewalls* cough>
Best not to push it too far, though cuz if the database goes wonky we'll lose the webmap. But I wouldn't bother cleaning it until the db grows to maybe 1.5MB, if it ever does...
The shiplist is also very far from being "error free."
It is entirely possible that this does not have the adverse effect I expected, the validate code does handle it and spits out the error about "0 failed the vaildate..." I've just never been sure if AI are created without ships... (which would be bad). I suppose I can test that relatively easily on an SQL db to find out. My philosophy has always been to eliminate as many errors as possible when running a server, it can only help.
I'm reasonably sure that it is relatively stable because of not disabling AI production. Castrin had established this ages ago. I suspect that default mission matching parameters may play a role as well.
As Dizzy suggests, a smaller shiplist can only be easier on the kit (within reasonable limits of course).
Glad things are going well thus far.
/Me <crosses fingers so as not to jinx it>