The problem of running out of memory due to a huge number of ships is well known. Apparently all the information about the ship is stored for each instance, instead of keeping it only on the template. I suppose the AI has a "threat level before buying out ships", which you exceeded. Then it bought all its ships; resulting in a huge memory increase; resulting in huge load time and risk of running out of memory.



I highly recommend to try *eliminating* the AI buyout bonus. This appears to be where people *see* the AI cheating, buying 500 ships the player could never afford.

Since I'll probably not do too much with the game in the near future (mainly because the lack of an automerge-function for fleets annoys me beyond a point where I can enjoy it), I decided to put up what I've started before and finished just now.

Ail wrote:
(mainly because the lack of an automerge-function for fleets annoys me beyond a point where I can enjoy it).

What does "auto-merge" mean in this context? Do you mean rally points? Or are you still seeing AI fleet spam?

Auto merging ships? There would be issues regarding ship class that would almost requre user created filters.

Ctrl clicking the desired ships you wish to put into the fleet and hitting merge is probably the best it's getting :/

Yes, something like Rally-Points.

A way to form fleets from your 600 Command-Points without having to click them together manually.

The AI can do it since 1.0.14. There already is a button to merge fleets but it will only work if the fleets you have selected have <= your max-command-points.

If you don't select anything it should just run the routine that the AI uses to merge their fleets.

Same goes for the Launch button. If you don't select ships manually it should just make fleets automatically.



I think that should be programmable in less than an hour because every method and UI-element already exists. They just need to be brought together.

I guess there are two threads discussing this in the proposals section. I think any rule the game had, would annoy many players with a different rule in mind. Then they would spend more time un-merging and re-merging. Personally, I set each forge planet to build one complete fleet the way I want, and then when it's done I go use it.

I think that any rule is better than no rule at all.

Also in war-times it's not a big problem because then I will launch my fleets regularly.

Problem is longer periods of peace. I will have dozens of ships from different generations and fleet-cap might have changed in the meantime aswell.



I want them simply to leave the hangars with one click and merhe to fleets trying for the fleet-cap if possible.

Ail wrote:
I want them simply to leave the hangars with one click and merhe to fleets trying for the fleet-cap if possible.

So this is a button, on the hangar, which says "merge into orbiting fleets". And when you click it, any random ship merges into any random fleet where it fits, and any random ships left over from the hangar are put into new fleet(s) randomly. Is that sufficient? Or do you need rules of which ship goes into which fleet so you don't have to reorganize them later?

I don't need rules... just the same thing the AI does when it merges fleets would be sufficient. If I wanted special fleets with ships for specific roles than it's okay to manually build them but just to get out all the crap I've built wouldn't require any complicated stuff.

Uploaded a 1.3 ... had pretty bad things happening. The Ai kept making ships during peace-time and at one point it declared war (while having 300+ 22/22 fleets).

During the 2nd turn of the war the game locked up in the transition between turns while constantly allocating more memory. Then it crashed with the "too many heaps" (or so) error after a few minutes and reaching roundabout 1.7 GB Ram-usage.



I don't think the error is directly related to the mod but the game maybe has a problem when it comes to moving around such vast amounts of fleets.

Have you reached the point where decreasing the AI FIDS/buyout bonus makes sense? If the AI is getting better, we should be able to reduce these and still have expert players find it challenging. This will reduce the ship count.

This may become reasonable soon.

I think the ridiculous buyout-bonus shall go/be reduced first.



The problem is not the AI's planet-development or economy anymore. (It actually was not that bad to begin with)

It's mostly about military and ships and to some extent diplomacy.



But what I consider more important is the analysis of the bug I ran into with the latest version of my mod.



It looked like it was related to the many ships the AI built but some things did not make sense in this regard.



It was at turn 330 or so. I had found out how to let them make more ships at around turn 290. So they already "spammed fleets" since 40 turns. They did never buyout them though.



Then at turn 330 the AI declared war on me and attacked some fleets and a system of mine. Most of their fleets were still hovering around their gather-systems. But I saw a massive movement of fleets in their backyard on the way to the front.



I was eager to analyze their attacking behaviour.



But then the game went into a deadlock "Turn is being progressed" for like 5 minutes while the memory-usage of the game constantly rose. At the end it crashed with a heap-overflow-error.



What I consider a possibility is that due to declaring war, they might have decided to buyout ships in addition to all the ones they already produced (I think it was 300-400 fleets of 22 CP at that point). And maybe the progress of buying out is buggy.



Or it has something to do with their attack-algorithm. Maybe the problem occured when they decided to assign targets.



The last theory is that it has to with autosaving between turns. I noticed that the increased amount of ships made loading-times go up a lot. So maybe saving times are similarly affected. But then it would not have happened so suddenly.



So the connection with something that only happens during war seems more likely.

Yeah, that's what happened all the time in 1.2 but should not in 1.2.1 because it would ...

Ok, I know what it is.

It is the race afterall.



Amoeba have affinity for:

Food: 1.0

Dust: 1.2

Horatio have:

Food: 1.4

Dust: 1.0



So that's why in my case they just sticked to food but in your case they wanted to switch and then realized: "nope"

So while I know how to fix it, I'm wondering if I shall not simply use the old solution that would just make food till max-pop. It's so much easier and I consider the benefits of the current solution, even without the cycling as really marginal.



Ok, I changed it as following:



Food: Whenever it wants to but not when the Maxpop is reached.

Industry: Whenever it wants to but not on Planets where it has a Bonus to Science and Money.

Money: Only on Planets with a Bonus for Money.

Science: Only on Planets with a Bonus for Science.

Note that I differentiate between the levels. Which means for Level 1 only Arid has a Bonus for Money and only Barren has a Bonus for Science! So it should make food or Industry on all other types.

Now I just need to test it... This time I take the Amoeba.

I agree on eliminating the ridiculous buyout-bonus. With my "fix" that allows the AI to normally build more ships they will have a lot of ships as well but they don't pop out of nowhere and thus don't seem like a cheat.

At endless they can buyout 10 times as much as you can with the same amount of dust while having more dust in the first place. Also making ind=>dust and using that to buy ships actually is more ind-efficient for them than actually building the ships... I really agree that this has to go.



I don't think that the mere fact of them having all these ships caused the issue.

Loading times got longer, yes. Turn times got longer as well.

Both of that is understandable but it was not a big issue.



But when the crash happened it was not like the turns before. Before it maybe took 10 seconds to process the end of a turn. At a time where the AI already had all those 400 fleets.



Considering it took roundabout 5 minutes of "Turn is in progress" before the game was shut down, that would mean more than 30 times that amount of fleets. And even with their 3.5 M and high buyout-boni I don't see the how they have bought 60,000 ships.



The bug looks like an endless (or almost endless) loop where it allocates memory for something. So existing ships cannot really be the problem because the memory they use already must've been allocated before.



Unfortunately I cannot find out whats going on by jailbreaking since obviously whatever they do that causes the problem won't happen when I take them over.



So I suspect the routine where the AI does buyout. But I have no evidence. Just a theory.



Also for the savegames I'm pretty sure that not each instance of a ship is stored there because I've not seen them grow in a noticable manner during the buildup of the ships. But how it is saved in the save-files and how the game actually handles it can certainly differ a lot.



I don't know if the devs know what "Coverity" is. It is an extremely powerful code-analyser. It takes a lot of time to process code but it will find memory leaks and other stuff like that.



I'd like to know if something like that was used on the ES-Code. Because it would drastically limit the likelyness of memory-leaks.

I know coverity well. I am not sure what they described is a "leak" as much as inefficient design. There is "a little" information mixed in with random commentary here:



http://forums.amplitude-studios.com/showthread.php?5500-Optimizations-status&highlight=status

Did you have the save game? I am interested in this kind of "Out of memory" which seams related to something defined...

Did I need the mod to make the game crash?



For the memory analysis tools, we try some other ones. Coverity seams more "Java" to me, but I can miss read their website...

But the problem is that our game is based on Unity and we don't have access to their code base. And as our code is in C# then compiled by Unity in Mono and run in their "C++" application, I don't know how we can bind a tool to this and which kind of tool...



So, for now, all analyzes have been made by our self, trying to count each object or found some "too long loading time" and see where we are breaking in...

If you have any insight on tools that can be usable in our case, be my guest to send me them ^^.

Unfortunately I'm not at home right now and won't get there till sunday. So I will upload a savegame on sunday or so.

I also don't know if the Mod is "needed" to reproduce the issue.

I tend to believe it is not. But I cannot be sure about it without testing it without the Mod.

This thread is related:

http://forums.amplitude-studios.com/showthread.php?10011-Possible-issue-with-AI-Dust-expenditure&highlight=100k

To reproduce, probably, jailbreak a save game where an AI is under severe attack, find the AI dust treasury value, change it to 2 million.

I've experimented around some more with that.



When I jailbroke the savegame and joined the game as the orange Horatio all the Dust was already spent. However, I could not find the enormous amount of fleets that should have been brought into existance by that.

My calculations said they should have made at least 700 new full 22/22 fleets from spending all their dust. But they "only" had the 340 fleets that they had built during the last few decades. 10 turns before they already had 285 fleets and still had all their dust.

The crash also never occured on the next-turn directly after loading. It was always after 2 turns. I guess because they would not buyout in the current turn when you load but the one after that.

However I noticed that the system "Tekal" had an unusually large amound of fleets in the hanger. 24. Not really a whole lot but considering no other system had that many their was something fishy.

So I tried to look at the system and... voilá the game crashed when I tried to do so.

I loaded again and found I can enter any other system. Only "Tekal" causes the hang-up.

In the savegame before their dust expenditure I can enter the system no problem.



I also tried to see what would happen if I spend all their dust myself. But guess what: Clicking a ship 1500 times and the buy-icon again 1500 more times kinda exhausted my patience so I stopped after 400 or so.



So BeforeCrash.zip contains the savegame from before the crash. I am the Red Sophon. The 2nd time you press enter after loading shall crash.

Crash.zip is after they spent their cash. It will also crash two turns after loading. OR it will crash when you play as the orange Horatio and try to enter the system "Tekal".



Edit:

I now gathered all fleets of the Horatio in 1 system and clicked on "Disband" so they go to the hangar.

This caused the Heap-Error-Crash after a few seconds. So obviously the amount of Ships in a hangar are limited and exceeding it will crash the game in any case.
BeforeCrash.zip
Crash.zip

Just a first report on my tests so far.



I don't get a crash when I just hit the enter key. Even when I keep doing it for 5 or 10 turns. It take some time to process each turn (which can be really huge, damned AI ^^) and much more time to load the save, but it works... at least on my PC.



But as you notice, when you click on the "Tekal" system, I also get a crash which is preceded by a long long wait...



I reduce the wait (a sorting process which was called a little too much...) but I still get the crash...



I fact, the AI has queued 22558 ship in his construction queue... which... cannot be all instantiate at the same time by Unity... so... we have to re-write our code to avoid the instantiation of all queued items when we draw the system queue panel.

This will take some time to be achieved and I don't think this will take a high priority because I am sure nobody will click 22000 times on the same button... and even if he did... well... I don't care if it crash ^^

But still, it's a bug and not a "difficult" one to solve so... it will be done, but not tomorrow ^^



All in all, I don't think this is the problem for the most important crash you report first. So I will continue to investigate around it just to see what can be so long to be done that it seams to appear as a infinite loop.