Spring RTS Engine

AARRGGGHHH

your not readin what I'm saying at all

I ALREADY HAVE AN ENTIRE CLASS THAT DOES THAT VERY WELL

My class based on the original from cain but witht he Parse() function replaced with a call to
krogothesclass->Init();
this->hotspots = krogothesclass->vectoredspots;

essentially taking the results of krogothes class and copying them directly rather than starting cains original algorithm and generating them from a raw metal map array, the class spaces mexes out, choose where to put them based on value and distance, it can deal with metal maps and every map, only it cant deal with brazilian battlefields unless I move the algorithm back to cains original. It even keeps track of enemy mexes to avoid sending cons into enemy territory (XE6). It can even place mexes on weavers PCB map which even OTAI cant do, OTAI having the next best wrap around class that I'm aware of and for a longtime I thought was better.

I am not using your class as a standalone krogothe, and I have never simply used a raw metal spot algorithm by itself. The class is not at fault, the class relies heavily upon ti being fed accurate information to work as would any other class that did the same job, only on those types of maps your class isn't generating reliable raw mex spots.

But because of you all insisting there is no problem I might as well post a groupAI or two showcasing markers showing the raw results of cains class and krogothes class so that you can test it out on brazillian battlefields yourselves.

So go on an explain why using cains wrap around class with krogothes metal class doesnt yield accurate results in NTAI yet if i use the original algorithm I get perfect results?

AF wrote:...so that you can test it out on brazillian battlefields yourselves.

funny

Alantai, I noticed something interesting when I looked at the screenshots. Compare the one you posted (Krogothe´s Class) with the one Chocapic posted (Krogothe´s class as well). You might notice that two of the metal extractors (on the left side) are on the exaxt same spots, so obviously the Metal class is yielding the same results.
Now strangely enough though, in your screenshot, it almost seems as if the AI was building in between the metal spots, basicly taking the spots with the least metal income.
Which got me thinking: Having one bigger than/smaller than (>/<) sign switched wrong way round would explain the results your getting:
- On Metal maps your class works fine (couse each spot yields same metal)
- On OTA style maps the class works fine (cause every spot has decent metal)
- On "Spring" style maps, the AI builds on the suckiest Spots first, (instead of on the best first, cause the ">" is wrong way round).
Only a theory of course, because I can´t be bothered with checking your code at the moment.

Well krogothe has suggested ramping up the minimum amount of metal for a position to count as a mex spot from 30 upwards but I havent been able to test it out

Ok I tweaked krogs class as he suggested in the lobby to ahev 100 min metal, then I amde my own edit to the MakeTGA() routine. The red spots are the results from krogothes class. I thought that having the spots as white marks on a black background was pointless and better fi yuo could see hwo well they fitted visually.

The above is XE7 runnign on brazliian battlefields with the tweaks implemented

Good, my class works still