Spring RTS Engine

And the solution to all the problems suffered by our mex algorithms? at the top of the metalhandler.cpp there's magic nubmer statements. One of them hotspotradius multipliers sis et to 1.0. The fix si to set it to 1.2 or higher.

are you using cains metalspot class?

hmm i think its worth trying...

Wouldn't that number be specific to the map?
I would think a better algo would be one that checks metal density relative to other metal spots on the map, and puts fringe at very low priority. In some cases (based on metal production) the AI should build to capture the fringe metal, but select between moho and normal based on expected return.

In other words, I can think of no general case where radii size alone makes the best choice in all cases. That said, your change removes the highest cost from a mistake. There is no way I would want the AI to build moho at 300 ongoing energy cost to provide 1 metal ongoing.

I must say again though, I think the radius modifier would be map specific. Is it easy to read those values at load time?

Yes it's cains mex class

Can you make it replace metal extractors with moho version as soon as it has the energy and metal to support it without going broke?

Jon M.

The way cains class works means ti supports any type of mex.

Atm NTAI builds moho mexes and any other AI based on cians class should be able to build them too.

OTAI only does that when it built a base on metal spots and then tries to build mexxes there, especially on XantheTerra, when the commander will go towards the center to get the blue metal spots, but build a bunch of solars and whatnot on the green spots. Then the construction kbots will build mexxes on the edge of the base and keep doing it because the mexxes aren't close enough to the metal to lower the demand.

OTAI also makes no difference between mexxes and mohos (mohoes?). If the spot's taken, it's taken. Also, sometimes two units will want to build mexxes adjacent to each other. Wasteful.