map info value at [x,y] (metal, radar...)

alik83 · Post by **alik83** » 18 Aug 2005, 22:14

//the following functions are used to get information about the map
	//dont modify or delete any of the pointers returned
	//the maps are stored from top left and each data position is 8*8 in size
	//to get info about a position x,y look at location
	//(int(y/8))*GetMapWidth()+(int(x/8))
	//some of the maps are stored in a lower resolution than this though
	virtual int GetMapWidth()=0;
	virtual int GetMapHeight()=0;
	virtual const float* GetHeightMap()=0;						//this is the height for the center of the squares, this differs slightly from the drawn map since it uses the height at the corners
	virtual const unsigned short* GetLosMap()=0;			//a square with value zero means you dont have los to the square, this is half the resolution of the standard map
	virtual const unsigned short* GetRadarMap()=0;		//a square with value zero means you dont have radar to the square, this is 1/8 the resolution of the standard map
	virtual const unsigned short* GetJammerMap()=0;		//a square with value zero means you dont have radar jamming on the square, this is 1/8 the resolution of the standard map
	virtual const unsigned char* GetMetalMap()=0;			//this map shows the metal density on the map, this is half the resolution of the standard map

I still didn't quite get: to get metal value in position [x,y] , would it be :
int(y/8))*GetMapWidth()+int(x/8) or is it
(int(y/16))*GetMapWidth()+(int(x/16)) because metal map resolution is half of the standart map ?

And how would you find the radar map value at [x,y] if it's 1/8 resolution of standart map?
Just trying to get the logic here...
I just figured out that metal map array on small divide has approximately 233544 elements...

I need this info for developing my own AI so help is needed...

Alik

Post by **jcnossen** » 18 Aug 2005, 22:41

Let's say you have a 3D position:

Code: Select all

float3 pos;

map square position would then be (that's the obvious part):

x = pos.x / 8; y = pos.y / 8;

then you calculate metal map width:

int mmwidth = GetMapWidth()/2;

then you can read the metal value from the map:

metal value = metalmap [ x / 2 + mmwidth * y / 2 ];

nice to see more people working on an AI !

cain · Post by **cain** » 25 Aug 2005, 19:47

isn't this:

x = pos.x / 8; y = pos.y / 8;

wrong?
I mean:

x = pos.x / 8; y = pos.z / 8;

as for pathfinding

Post by **jcnossen** » 25 Aug 2005, 19:49

you're right sorry.
I think he gets the idea though.

cain · Post by **cain** » 25 Aug 2005, 19:57

yes I know, but that confused me a bit
(I'm still in heavy debugging mode for the metal placement)

Post by **jcnossen** » 25 Aug 2005, 20:14

You're doing highest spot search or such a hackish method like I use ? (one that assumes 1 high spot in every sector and then just finds the highest spot there)

cain · Post by **cain** » 25 Aug 2005, 20:34

std::vector<float3> getMetalSpot(float3 pos, float radius, int maxResult, int minMetal)

it's a gradient descent with support for multiple extractor,so it will return all the highest patch in a zone, in decrescent order for extracting value,
using unconstrained nonlinear search. (fresh of degree :lol: ). Also will filter out existing extractors, so you can safely call it on overlapping zone. plus it will result on dense extractors on map with low extracting radius.

alik83 · Post by **alik83** » 26 Aug 2005, 06:53

Cain, can you post the code for your std::vector<float3> getMetalSpot(float3 pos, float radius, int maxResult, int minMetal) function?
It would help all of us (AI developers) to get going faster.
Does it use Callback->getExtractorRadius function and would it correctly cover all map with mexes on map with uniformely distributed metal and small mex radius like "Core Prime industrial area"?
Thanks.

cain · Post by **cain** » 26 Aug 2005, 11:55

supports metal extracting radius and will return dense results on metal maps (maybe not the packed positioning, but quite near.)

as for other tools, i'll post them when I'm sure they will work under any conditions. It's no use for others to have a bugged tool.

It has a fast and dirty get all metal spot in this area for now, and returns them in a ordered list. But that's just a full area search (with O(n^2)) that is quite fast, but not enaught. it's useful as a starting point: comander is at x,z then get all metal near the commander, if any. but for complex and larger area maps, especially with low metal, there will be the need of a float getNearestMetalPatch(int MinMetal); and *THAT* is a very difficult task.

I'm currently debugging the Hessian matrix lookup table, but it's not quite easy to debug (the SendTextMsg is a real pain to use). My schedule plan for release is: release the quick&dirty function, relase a printf(const char*, ...) function to ease the debugging, and then a complete working class

**UPDATE: I'm working on porting all to the new interface released with the 0.62b1...

Post by **jcnossen** » 26 Aug 2005, 21:53

(the SendTextMsg is a real pain to use). My schedule plan for release is: release the quick&dirty function, relase a printf(const char*, ...) function to ease the debugging

I'm using this code, feel free to insert in into your project (that's 1 minute work instead of 5

)

Code: Select all

const char *LogFileName = AI_PATH "testai.log";

void logFileOpen ()
{
	remove (LogFileName);
}

void logFileClose ()
{}

void logPrintf (const char *fmt, ...)
{
	static char buf[256];
	va_list vl;
	va_start (vl, fmt);
#ifdef _MSC_VER
	_vsnprintf (buf, sizeof(buf), fmt, vl);
#else
	vsnprintf (buf, sizeof(buf), fmt, vl);
#endif

	FILE *file = fopen (LogFileName, "a");
	if (file)
	{
		fputs (buf, file);
		fclose (file);
	}

#ifdef _MSC_VER
	OutputDebugString (buf);
#endif
	va_end (vl);
}

void ChatMsgPrintf (IGlobalAICallback *cb, const char *fmt, ...)
{
	static char buf[256];
	va_list vl;
	va_start (vl, fmt);
#ifdef _MSC_VER
	_vsnprintf (buf, sizeof(buf), fmt, vl);
#else
	vsnprintf (buf, sizeof(buf), fmt, vl);
#endif

	logPrintf ("%s\n", buf);

	cb->SendTextMsg (buf,  0);
	va_end (vl);
}

Dragon45 · Post by **Dragon45** » 29 Aug 2005, 21:45

For vital features such as metal and geo maps, I always envisioned for my own AI that it would be muhc much cheaper to simply index all the metal map positions during the map compilation process itself in some sort of metadata file (or in header information) and then reference that, isntead of forcing additional loading times for AI accomodation.

And why teh old C-junk? As far as i'm conerned, everytime you use an outmoded syntax, God kills a kitten

Post by **jcnossen** » 29 Aug 2005, 21:57

They're two logging functions you know, please don't go all OOP about that :S

Dragon45 · Post by **Dragon45** » 02 Sep 2005, 04:58

But i must!

*slays the syntax*

seriously though, Try-Catch might be good there >_> or output to file... or soemthing... or form a MS DOS ouput window and dump teh junk there...

Post by **jcnossen** » 02 Sep 2005, 11:47

Could you stop telling me how I like to write my logfile.
Try-catch isn't usefull when nothing can go wrong - or when one if statement covers all error handling.
Stop trying to be a smartass and contribute...

cain · Post by **cain** » 04 Sep 2005, 09:46

(back from vacation in paris)

thanks! It's a nice solution!

cain · Post by **cain** » 04 Sep 2005, 09:50

dragon45:

if you dont'like it, don't use it.

anyway, I don't think zaphod could be
criticised from someone
wich couldn't tell the difference from a
procedural to a objectoriented approach.

do you know that these three stateless function
are a jem of oo programming, able to
be inserted as a module behind any object?

hovewer, I'll continue to mix c++ and c, as
the difference from a project and a project done
is the coding convenience.

Spring RTS Engine

map info value at [x,y] (metal, radar...)

map info value at [x,y] (metal, radar...)

Maybe post a code