AI development question

[safgaj]

how do you get the AI to find metal on the map?

[AF]

There should be an algorithm for finding spots, most of the existing AIs have a copy of it, and it's built into the new C++ API

[echoone]

There should be an algorithm for finding spots, most of the existing AIs have a copy of it, and it's built into the new C++ API

Which begs the question, why isn't this brought into the engine, or perhaps the ai interface, and universally exposed? It would save constant code duplication and provide for a common, optimized implementation.

Is there a legitimate reason not to do so?

[slogic]

...why isn't this brought into the engine, or perhaps the ai interface, and universally exposed?

Actually, it is.
Taken from Shard:

Code: Select all

std::vector<SAIFloat3> positions = callback->GetMap()->GetResourceMapSpotsPositions(*metal,0)

where metal is springai::Resource with GetName() = "Metal".

I wonder how does it act on maps where metal is spreaded and not concentrated in spots?

[AF]

Many reasons.

• Originally there were many algorithms competing, it did not make sense to integrate one into the engine when another had advantages
• Moving the algorithm to the engine does not give any benefits
• The algorithm is already in the new C++ API wrapper regardless and integrated directly into the C++ API
• KAI uses the same algorithm, however it has been refactored into a generic spot finding algorithm, and is used on more than just the metalmap
• It would prevent modification for further AI logic if it were locked away in the engine
• Most of the AIs have versions modified to support custom container classes for their AI structure to access the API callbacks, and AI specific logging calls.
• There are bugs in the existing implementation regarding scale and certain extreme cases, e.g. the map core prime industrial estate, arising from the algorithm using the 0-255 values, and filtering at a low value of 30, which makes sense on most maps, but doesnt on ones where there are big differences, because it should instead use a metal extraction rate as the source value for the cut off, not the 0-255 value.

The algorithm can be found in every single AI in spring, is near identical in each one, and is built into the new APIs already.

[hoijui]

as slogic already said, it is in the engine, not in any wrapper.
It might not be available through the Legacy C++ AI Wrapper (not sure about that), but surely is available for all other AI Interfaces and Wrappers (if they do not explicitly exclude it).
It makes sense to be in the engine, as it was already written in C++ anyway, and is now available to all AIs.
I can not talk about the algorithms flaws, as i never used it myself, but i got many reports that it works bad in a lot of cases: no-metal, speed-metal, large fields of metal. basically everything except "normal" spots maps. there have been fixes to it here and there, so some of this might be fixed by now.
This is the implementation:
http://github.com/spring/spring/blob/ma ... alyzer.cpp

[echoone]

as slogic already said, it is in the engine, not in any wrapper
.
.
.
This is the implementation:
http://github.com/spring/spring/blob/ma ... alyzer.cpp

Thanks guys.

taken from Shard:
Code:
std::vector<SAIFloat3> positions = callback->GetMap()->GetResourceMapSpotsPositions(*metal,0)

In regard to this subject, I believe I have identified a bug in the python interface. It seems the python interface is validating arguments which don't exist and in turn prevents the callback. If you comment out the seemingly invalid validations, then spring goes nuclear. Good thing I had my sunglasses on.

Some additional comments have been added to the snippet below.

Code: Select all

	@staticmethod
	def getResourceMapSpotsPositions(resourceId): # only resource id is seemingly required
		"""The arguments are:
	resourceId: int  # good
	spots: (float, float, float) # Ummm...hmmmm????
	spots_max: int  # Where...hmmmm????
"""
		assert isinstance(resourceId, (int, long))
		resourceId=int(resourceId)
		## check_float3(spots)  # validated here but not used below
		## assert isinstance(spots_max, (int, long)) # validate here but not used below
		## spots_max=int(spots_max) # converted here but not used below
                # I'm even confused by the next line.
		return teamModule._currentTeam.callback.Clb_Map_0ARRAY1VALS0REF1Resource2resourceId0getResourceMapSpotsPositions(teamModule._currentTeam.teamId,resourceId,None, teamModule._currentTeam.callback.Clb_Map_0ARRAY1SIZE0REF1Resource2resourceId0getResourceMapSpotsPositions(teamModule._currentTeam.teamId,resourceId))

I'll see if I can't catch the python guys in IRC to discuss as I'm not 100% I'm using the interface correct, but do believe so.

[AF]

On the map core prime industrials estate, a Mex can be placed anywhere and gives a good amount of metal (2+)

However the algorithm detects only the 2 regions north and south with excessive amounts of metals. Because the amounts are so high, these take the 255 value, and the rest of the map has quite a low metal map value.

Of course when translated into intake values this is fine because it's already plent of metal, however the algorithm for finding spots does not take into account how much a spot produces, or a general extraction rate, and instead cuts off any value below a certain point which if I recall correctly is around 30, this means that 90% of the map is discarded as a result.

I'd rather see the algorithm fixed as a generic algorithm taking s function or functor to evaluate the grid squares rather than a hardcoded filter around the 30 mark that assumes values of range 0-255

I vaguely remember looking into fixing this for the version I use in NTai but my improvements have never found their way into rival AI codebases