Here it is:
http://www.fileuniverse.com/?p=showitem&ID=2366
Changes:
-2x faster
-Returns a vector<float3> where y is the amount of metal for each spot
-No need for other functions
-random improvements and commenting
Again, this is the barebones stuff, only returning the spots. This is intended since there are n ways to find the most appropriate spot at any given time.
Kudos to zaphod and AF for helping me improve it!
Krogothe's Metal Class v2
Moderators: hoijui, Moderators
Krogothe I highly reccomend you force all users of this class to follow a standard.
Why should NTAI generate cache files and save them to NTAI\metalcahce, then OTAI generates identical data wasting time saving ti somewhere else then KAI does the same then AAI does it.
I suggest you do a version 2.01 with a version nubmer added to the caching, and using a generic MEXCACHE system. Either that ro we can use a common file extension for each version so they dotn conflict.
Eitherway it's a nightmare with all these large files zooming around and wasting valuable startup time at the game startup with multiple generations fo the same data.
This class is nearly standard now that all the major AI's use a version of it, and now we ahve v0.2 it'll be a sure bet that all major AI's will ahve a modified v2 of this class with different logging integrated and callback usage but with essentially the same algorithm implemented by you, and maybe the message moved around (NTAI 0.29 XE got rid of ti and moved it to a general credits header ti posts once regardless of how many NTAI's are rpesent)
Why should NTAI generate cache files and save them to NTAI\metalcahce, then OTAI generates identical data wasting time saving ti somewhere else then KAI does the same then AAI does it.
I suggest you do a version 2.01 with a version nubmer added to the caching, and using a generic MEXCACHE system. Either that ro we can use a common file extension for each version so they dotn conflict.
Eitherway it's a nightmare with all these large files zooming around and wasting valuable startup time at the game startup with multiple generations fo the same data.
This class is nearly standard now that all the major AI's use a version of it, and now we ahve v0.2 it'll be a sure bet that all major AI's will ahve a modified v2 of this class with different logging integrated and callback usage but with essentially the same algorithm implemented by you, and maybe the message moved around (NTAI 0.29 XE got rid of ti and moved it to a general credits header ti posts once regardless of how many NTAI's are rpesent)
Its easy enough to set up a standard, but save files could be incompatible due to options such as min metal percentage, max spots and any additional data.
Its true that it is a waste, however the files average 10KB and its a one-time thing, which shouldnt cause much harm.
as for the mex class by krog message, As long as its there at the start of a game, i dont really care if you guys move or change how the message is displayed.
Its true that it is a waste, however the files average 10KB and its a one-time thing, which shouldnt cause much harm.
as for the mex class by krog message, As long as its there at the start of a game, i dont really care if you guys move or change how the message is displayed.
because at least aai does not use exactly the algorithm krogothee released. its is based very much on krogothe's original version but i have added some things to make it compatible with other stuff of aai. try aai vs otai on plains and passes and you'll see the differenceAF wrote: Why should NTAI generate cache files and save them to NTAI\metalcahce, then OTAI generates identical data wasting time saving ti somewhere else then KAI does the same then AAI does it.
That simply isnt true.
OTAI 1.07 and NTAI 0.29 XE use near identical versions of krogothes class, mainly becaus eI copied it out fo OTAI to make sure. However They perform differently, for example NTAI 0.29 XE is significantly better at placing mexes on PCB according to weaver when compared to OTAI. What you're talkign abotu is not the Krogothes metal finder but rather tha wrap around class that sorts out mex placement and tracks mex spots that're taken and extraction ranges.
The core parsing routine should generate the same results across all AI's, and as long as they're stored in the same place for the same version and saved in the same format, then an OTAI generated metal file shouldnt have any problems being loaded by NTAI, and I'm sure that most of us can agree on having the same parameters for the class since their's no external way fo setting the value without modifying krogs class, and I'm sure if we choose a value it's for a reason, something generic enough to work for the majority of maps.
However you have not released source for AAI in a long time, of all the AI developers you have released the least source code of all of us, only 2 releases as far as I'm aware, so we're not aware of any changes you make to the parsing algorithm that generates the mex spots. So currently I think you wont stick to any standards the other AI devs adhere to unless you propose it yourself, or it becomes firmly established and would save you a lot of work to use passingly.
OTAI 1.07 and NTAI 0.29 XE use near identical versions of krogothes class, mainly becaus eI copied it out fo OTAI to make sure. However They perform differently, for example NTAI 0.29 XE is significantly better at placing mexes on PCB according to weaver when compared to OTAI. What you're talkign abotu is not the Krogothes metal finder but rather tha wrap around class that sorts out mex placement and tracks mex spots that're taken and extraction ranges.
The core parsing routine should generate the same results across all AI's, and as long as they're stored in the same place for the same version and saved in the same format, then an OTAI generated metal file shouldnt have any problems being loaded by NTAI, and I'm sure that most of us can agree on having the same parameters for the class since their's no external way fo setting the value without modifying krogs class, and I'm sure if we choose a value it's for a reason, something generic enough to work for the majority of maps.
However you have not released source for AAI in a long time, of all the AI developers you have released the least source code of all of us, only 2 releases as far as I'm aware, so we're not aware of any changes you make to the parsing algorithm that generates the mex spots. So currently I think you wont stick to any standards the other AI devs adhere to unless you propose it yourself, or it becomes firmly established and would save you a lot of work to use passingly.
Thats where the problem lies, AF, most AIs differ in the way they save the info. OTAI saves it all in binary (im doing that too now >:D), witha special struct, while i use the old float3 while someone else might do something else. If you want to come up with a standard, be my guest...
Btw, there might be a v3 in the foreseeable future
Btw, there might be a v3 in the foreseeable future
The reason we all save ti in different ways is because of the sheer nubmer of versions of V1 floating around, there's the original version that OTAI used, then a modified version that I used, then a version OTAI used in 1.07 that I havent a clue wether it's newer or what so i used that, then the KAI initial source release version, ahk it's a minefield.
If we all used this version together and simply changed all we needed to itnegrate Logging and the itnerface to our AI's and left the save/load functions and the algorithm intact then they'd all be interoperable.
For that reason I'm going to use whatever save/load method is used by everyone, and I suggest you define a generic save path, and use ti for KAI as I'll follow suit, and I'm sure veylon will too in his next release. Submarine can goto hell for all I care he doesnt seem to be that itnerested in the whole standards discussion and I dont mind him wanting all AAI data in an AAI folder. I remember asking him fi I could use his learnign code as a template to start my own learnign code and one of his replies was, dotn use the learning data AAI stores, make your own data.
If we all used this version together and simply changed all we needed to itnegrate Logging and the itnerface to our AI's and left the save/load functions and the algorithm intact then they'd all be interoperable.
For that reason I'm going to use whatever save/load method is used by everyone, and I suggest you define a generic save path, and use ti for KAI as I'll follow suit, and I'm sure veylon will too in his next release. Submarine can goto hell for all I care he doesnt seem to be that itnerested in the whole standards discussion and I dont mind him wanting all AAI data in an AAI folder. I remember asking him fi I could use his learnign code as a template to start my own learnign code and one of his replies was, dotn use the learning data AAI stores, make your own data.
KAI itself uses a completely different system for saving things than the one published, but the one i use wouldnt work for your AIs.
i could go on about how the AIs are different and how a few extra 20kb files and 2 second waits wont be that harmful but i dislike getting into forum arguments, its pointless....
Please dont turn this into a flame war
i could go on about how the AIs are different and how a few extra 20kb files and 2 second waits wont be that harmful but i dislike getting into forum arguments, its pointless....
Please dont turn this into a flame war
I'd like to put my two cents in by saying that I had to change Krogothe's Metal map finder to make it work properly on CometCatcher. I then edited it in other ways to make it log and such, so there's really no use in expecting AI's to load each others metal spots if they are going to be in different places.
@AF: What compromise about sharing? Let me know and I'll be happy to talk about it. It may take a while, like you say, but I'm sure we work something out.
@AF: What compromise about sharing? Let me know and I'll be happy to talk about it. It may take a while, like you say, but I'm sure we work something out.
Not to shit up your thread Krogothe, but AF - stop being such a drama whore.
On topic, I've been busy with other project at the moment, but I'd like to see it - maybe merge it with my improved version (or perhaps you went down the same paths to manage single-pass parsing). Or, whatever - it seems you simplified the design to merely parse the metal into easier to handle 'spots'?
On topic, I've been busy with other project at the moment, but I'd like to see it - maybe merge it with my improved version (or perhaps you went down the same paths to manage single-pass parsing). Or, whatever - it seems you simplified the design to merely parse the metal into easier to handle 'spots'?
The only problem with that is it doesn't really take that long (mine doesn't cause any visible delays [1.6GHz]) to go add up the metal value of every spot on the map (sum of all metal spots within extractorRadius around it). In fact, it might even be slower (and it certainly can be) to load a file containing those values from disk rather than just calulate it each time (provided you're not calculating it in a horribly inefficient manner...). The only issue I could forsee are due to large extractorRadii (upper limit = extractorRadius >= MapDiagonal), but there are optimizations for these types of problems.
What would be 'useful' to store in files (imo) are the initial 'best spot' mappings. This is also where each AI may be different - if we're looking at a greedy algorithm would just be interested in an ordered list of metal spots to try and place mexes on. If we're looking for optimal coverage, then it is looking for the best metal spot combinations (though they should? also be ordered) and should have substantially more information to provide a useful data structure.
What would be 'useful' to store in files (imo) are the initial 'best spot' mappings. This is also where each AI may be different - if we're looking at a greedy algorithm would just be interested in an ordered list of metal spots to try and place mexes on. If we're looking for optimal coverage, then it is looking for the best metal spot combinations (though they should? also be ordered) and should have substantially more information to provide a useful data structure.
mwha
kelson, I dont remember saying anything about you yet you went into meltdown. You dont ahve a lot of stress on yuo daily? or are you just generally short tempered?
I want a basic standard for the hotspots as generated by krogothes class. Extra information on how that information is put into context and other data pertaining to it can be stored elsewhere or extrapolated from the initial data.
But as usual someone blows the lid and I'm back to working on my own. I guess I should give up on a standards and start ym own research, end up with 2 rivalling systems, and be accused of being zenophobic when everyone exept me is using a common system, even though I wanted a standard system in the first place.
kelson, I dont remember saying anything about you yet you went into meltdown. You dont ahve a lot of stress on yuo daily? or are you just generally short tempered?
I want a basic standard for the hotspots as generated by krogothes class. Extra information on how that information is put into context and other data pertaining to it can be stored elsewhere or extrapolated from the initial data.
But as usual someone blows the lid and I'm back to working on my own. I guess I should give up on a standards and start ym own research, end up with 2 rivalling systems, and be accused of being zenophobic when everyone exept me is using a common system, even though I wanted a standard system in the first place.
AF, when you degrade the level of discussion by using abusive language against other posters, it hurts EVERYBODY (especially you). How can you expect people even to listen to your ideas when they're accompanied by such venom?AF wrote:kelson, I dont remember saying anything about you yet you went into meltdown. You dont ahve a lot of stress on yuo daily? or are you just generally short tempered?
I'm sorry but the only person I possibly see as entitled to make such a response there is submarine.
And yes I admit it isnt good but I was tired and stressed and I have been very annoyed by submarines source being withheld the last few weeks.
However kelson does seem short tempered, and I believe I could be a lot mroe colourful on these forums if I wished, and I am nto because of the reason you said in your post.
And yes I admit it isnt good but I was tired and stressed and I have been very annoyed by submarines source being withheld the last few weeks.
However kelson does seem short tempered, and I believe I could be a lot mroe colourful on these forums if I wished, and I am nto because of the reason you said in your post.
@AF: In fact, if I were sub, I wouldn't post here at all. Totally no use. Go take ur whining somewhere else, dude. In fact, all ur just saying is: 'I want... ' So, that's ok, you can ask for it, but when someone rejects, it's their decision. You can't tell ppl what to do :) Easy as that, is it not? Remember the Balthazar - whatever book thing someone talked to you about.
OT: nice to see you working on this krogothe! Btw, is there any chance ur bringing out one hell of an AI again?
OT: nice to see you working on this krogothe! Btw, is there any chance ur bringing out one hell of an AI again?