here are some code to play with: the hotspot function currently succedes to detect the high metal concentration on the hill of core prime industrial area, should handle all map as is and support different metal extractor size, save&load to speed up loading time.
It's more bruteforce than cleverness, the metal map is so small that i relinquished finesse for working - code.
Note: i'm releasing it so you can play with it, take it as a base or enanche it in any way. this is a pre-alpha release, it does not have all the game mechanics it need but it's a start. All the other function are still under debug (the function to get the exact metal extracted in a point - stripped from the game source - is here but I dont have it tested so much).
I'd really appreciate any comment / bug report.
next release will have the support for requesting a metal extractor point, and two functions to add builded extractor, so position returned will not overlap
the current release is here:
http://www.fileuniverse.com/?p=showitem&ID=1568
what currently does is providing a vector of best place to put an extractor in descend order, and a smaller vector of hot spot that have the highest metal concentration of the map, so you know where to expand. The spot returned overlaps, be warned.
metal handler class release
Moderators: hoijui, Moderators
metal handler class release
Last edited by cain on 05 Oct 2005, 23:02, edited 1 time in total.
reply
The code you supplied isn't really in working condition: the only function implemented in MetalHandler.cpp is ParseMap(),
hotspot and metalspot vector isn't filled with values anywhere in the file,
and getMetalPatch() and GetHotSpots() aren't implemented
I tried running ParseMap and logging the parts like
and the log was like that:
Hope for updates and see those functions in .h file working soon 
hotspot and metalspot vector isn't filled with values anywhere in the file,
and getMetalPatch() and GetHotSpots() aren't implemented
I tried running ParseMap and logging the parts like
Code: Select all
mp->push_back(pos);
//#ifdef HAVE_CMessagingClass
logPrintf("Returned %3.3f %3.3f %3.3f \n",pos.x,pos.y,pos.z);Code: Select all
offset 4.000000
Returned 0.000 0.120 344.000
Returned 0.000 0.150 348.000
....
Returned 508.000 0.120 50.000
readed patches 0
the function path is:
loadState()
wich load state, and if no state is present parse the map.
in here the hotspot and metalpatch are filled.
if a saved state is present then everithing is loaded here
and the metalpatch/hotspot are filled from file
(the second branch of the if)
the mp vector in parsemap is a temp list used for ordering
the metal zones, the returned one is the vector ov
and for accessing the data, metalpatch and hotspot are public and can be ued, and are filled.
the readed patches = 0 is a old debug stri code wich means nothings
http://www.fileuniverse.com/?p=showitem&ID=1576
a new relase is here, now in beta!
this meand all the functionality are here:
returns metal patch non overlapping with existent extractors
handles different types of extractor so extractor with different
depth set wont be considered overlapping
implements the getNearestPatch and getMetalPatch so you can actually skip all the hassle of buiding them
please please please: i'm putting my effort to support the open source community, i'd really appreciate considerations, suggestion, bug reports and (to a limited extent) complains =)
a new relase is here, now in beta!
this meand all the functionality are here:
returns metal patch non overlapping with existent extractors
handles different types of extractor so extractor with different
depth set wont be considered overlapping
implements the getNearestPatch and getMetalPatch so you can actually skip all the hassle of buiding them
please please please: i'm putting my effort to support the open source community, i'd really appreciate considerations, suggestion, bug reports and (to a limited extent) complains =)
comment
Here: http://www.fileuniverse.com/?p=download ... vi&ID=1579
is a small video showing how it(the 0.9 file) draws mexes on hotspots
It puts them all (4 of them) in 1 beginning square,
When I tried draw mexes on metalpatch spots it drew about a hundred of them in the same corner.
Here's the code I used to draw them:
is a small video showing how it(the 0.9 file) draws mexes on hotspots
It puts them all (4 of them) in 1 beginning square,
When I tried draw mexes on metalpatch spots it drew about a hundred of them in the same corner.
Here's the code I used to draw them:
Code: Select all
mh->loadState();
std::vector<float3> *hs = mh->getHotSpots();
for (std::vector<float3>::iterator it=hs->begin();it!=hs->end();++it) {
float3 pos = *it;
pos.y=cb->GetElevation(pos.x, pos.z);
cb->DrawUnit ("CORMEX", pos, 0.0f, 2000000, cb->GetMyAllyTeam(), false, true);
}
You will probably get more feedback if you make it easy to test for everyone. You dont need to write a whole skirmish ai for it just write a group ai that can takes construction units and let the user define areas where it should autobuild mexes. Or extend the central build ai with that functionality.
alik83: the coords are in the float map, the draw unit uses the game coord so you have to scale x and z by multiplying by 8
(my fault, should have documented it):
these are the hotspots returned on smalldivide:
pos 196.336639 116.585831
pos 130.584427 388.627625
pos 372.888947 388.796021
pos 336.218231 115.084694
centred around 256x256 that is the real map center (but the build
coordinate of the centre is 2048*2048)
thy're on a square as the hotspot are taken from borders of the area, I think it's a feature, not a bug, as it will cover all the hot spots uniformely (the hot spot radius cover 200 units using the game coordinates).
SY: I can't get the point of your post (no offence intended: just poor english speaker) this is not a full ai nor a group ai, just a class to plug where is needed. alike tested it with 6 line of code, just drawing the results.
(my fault, should have documented it):
these are the hotspots returned on smalldivide:
pos 196.336639 116.585831
pos 130.584427 388.627625
pos 372.888947 388.796021
pos 336.218231 115.084694
centred around 256x256 that is the real map center (but the build
coordinate of the centre is 2048*2048)
thy're on a square as the hotspot are taken from borders of the area, I think it's a feature, not a bug, as it will cover all the hot spots uniformely (the hot spot radius cover 200 units using the game coordinates).
SY: I can't get the point of your post (no offence intended: just poor english speaker) this is not a full ai nor a group ai, just a class to plug where is needed. alike tested it with 6 line of code, just drawing the results.
http://www.fileuniverse.com/?p=showitem&ID=1607
i've posted a latest version of the metal handler. it's not ported to the new interface of ai of the .65 spring (duh)
resolves some bug, improves stability and it's fully functional on all map.
there's a little api change: now the returned value are scaled to have the map coordinates (8x than the previous version)
i've posted a latest version of the metal handler. it's not ported to the new interface of ai of the .65 spring (duh)
resolves some bug, improves stability and it's fully functional on all map.
there's a little api change: now the returned value are scaled to have the map coordinates (8x than the previous version)
I noted that, though I saw a flaw testing with NTAI. sometimes ti worked, but I was forced todo a canbuildat check every time Iwanted to build a mex and it didnt always say it could, so i ahve to run closestbuildpos on it which means that NTAI deals with OTA maps, btu not nearly as well as it needs to. Also ebcause I used closestbuildpos, the class doesnt mark positions as used because they're ntot he same as the new positions.
what do you mean by doesn't mark position?Also ebcause I used closestbuildpos, the class doesnt mark positions as used because they're ntot he same as the new positions.
there is a know bug: as I cant get the position of a unit under construction (getUnitDef returns NULL) building two mex the same time in the same zone will result on them being build in the same spot.
also it appears to me that the build order in the new interface requires .y=0
(didn't extensively checked, I'm still porting the unit construction system - I dream a day when everyone will learn to design in patterns - now i'm bridging all the interfaces, this is the third change that went since i started programming).
the nearest build position check proximity only others mex for proximity (normal and moho) so the position returned is only the best find on the metal map in the zone. others conditions are not checked. I can put a canbuildat check in the parse map removing all the unusable patches. Now that there's someone actually using the code, done it the best way is a priority.[/quote]canbuildat check
First, check zaphods code, he has a class that uses a very similair method to yours. In some cases the mex psoition isnt buildable but somewhere about 20 ticks away is though and si just as good.
No, 2 mexes cant be built ontop of eachother tlike that, although it is still a bug that wastes my con kbots time.
What i meant is. Lets say your class returns X,Y,Z as a position. And I fidn ti doesnt work so i do that functions and use thereturned X2Y2Z2. When i tell your class I've built an extractor the class sees X != X2 etc so XYZ must still be a valid position. Results of this have bene noted that sometimes 3 or 4 mexes are built around btu nto on a spot.
No, 2 mexes cant be built ontop of eachother tlike that, although it is still a bug that wastes my con kbots time.
What i meant is. Lets say your class returns X,Y,Z as a position. And I fidn ti doesnt work so i do that functions and use thereturned X2Y2Z2. When i tell your class I've built an extractor the class sees X != X2 etc so XYZ must still be a valid position. Results of this have bene noted that sometimes 3 or 4 mexes are built around btu nto on a spot.
no, i read the position from metal extractors, to do positioning check: so that's not a problem, you can build mex everywhere and they'll be correctly handled (i can provide avi of this). are you passing all the units created/finished/destroyed to the metal handler using addunit/removeunit ? this is required for the distance check to work. It's not a check on the returned coordinates, but a full cicle of all the extractor that check the distance, if lower than radius the spot is skipped. that means that if you have a metal extractor destroyed the class will give you back the spot as free. the problem is that if you add the constructor using unitCreated and not unitFinished there's a bag that prevents the metal extractor to being added to the mex list, as i cant get the unitdef for the unit if it's not build (try, it will return null) so there's a check, if the unitdef is null the unit is skipped (this avoid nullpointerexceptions. althought getunitpos() works, i need the unitdef to know the ->extractmetals value, wich is the extractor depth) this is the bug you're seing. try placing the addunit function of the metalhandler interface in every globalai function concerning unit addition, and have no more than one mex per zone build (you still have a cell approach?)
Incase you havent noticed, I'm not using JCAI to test this.
As a side note, I've ntoiced that aliks and yours and zaphods classes all work the same way and give the same results to within about 1% of eachother. Zaphods is tied in to JCAI greatly, Aliks has few functions comapred tot her est and is also tied in with JCAI too much.
I have a version of cains class here that has aliks itnegrated into it, and it makes little difference.
As a side note, I've ntoiced that aliks and yours and zaphods classes all work the same way and give the same results to within about 1% of eachother. Zaphods is tied in to JCAI greatly, Aliks has few functions comapred tot her est and is also tied in with JCAI too much.
I have a version of cains class here that has aliks itnegrated into it, and it makes little difference.
it's the magic behind c++!it makes little difference.
however:
i've catched up all bugs now.
this points to a little ai that does nothing but show off the metal class, building aircraft and extractors like hell.
http://www.fileuniverse.com/?p=showitem&ID=1625
notice that there is a bug in spring: if a player is on the same team of an ai (as the new lobby server prevents to spectate an ai only game) all the call of getunitpos returns 0,0. that was why extractors overlapped.
tested ok on small divide and asphen and core-prime industrial area
known issues:
need some speed improvement and caching, but i'm not releasing that until they all work (optimization is a coding hell)
the search nearest is just a blurb, just copy the code in there and set your own radius according to your cell map size
doesn't work with arm
doesn't work if not the lone controller of the team (not my fault - someone has any advice?)