Krogothe's Metal Class v2

[Chocapic]

The point of krogothes clas sis it returns the hotspots, the patches of metal, the places that are the ideal palces to put emxes wetehr you cna build there or not.

and i think its exactly what it should do, the place where u can really build should be up to you to find out, afterall some times u can only build mexes on ok spots instead of optimal due to terrain hillness.
and as for that remember that i can make a mod where the mex is twice bigger and all those calcs are crap again.

[AF]

Ahem, the current systems can handle pretty much anysize mex, and if it's broken it's the mappers fault or we're in need of a complex AI algorithm that gets given a minelayer and soem farks to flatten the ground enough to build on.

NTAI already handles the mexes in gundam annihilation which are at least twice the size of ordinary mexes.

An example of a good choice by krogothes class that no AI should ordinarily attempt to build on is the most northern western mex spot on kluesys latest map which si a hotspot and is detected as such, but cant be built on because of the terrain, or some of the starting position mex spots on altored divide when playign with gundam annihilation.

[Chocapic]

but thats a very easy thing.
u detect the hotspot try getting the closestbuildsite to it, and then make a 2Ddistance over them and the corresponding hotspot, and if it exceeds the max distance that u want then skip it and erase it from the structure or mark it as bad.
allthough better than that i'd recomend improving all other things around ur ai cause after all its not that tiny diference that'll make ur ai a uber smashing ai or not (it still matters , but at the current ai scenario only matters very little).

[AF]

I know that, cains class had a very similair routine inside it that did just that, and NTAI wont attempt to build ona spot it cannot build at, and at most it will do a closestbuildsite() with a small search radius.

The class works fine in any situation that doesnt hav spring style metal maps, such as brazillian battlefields, and I see that NTAI has a big disadvantage because the mex radii of the spots krogothes class gives it doesnt cover the majority of the metal on the map and it looses a lot of metal because of that and leads to heavy stalls, which has a huge impact on overrall gameplay of NTAI on those maps.

[Chocapic]

i dont want to sound rude or anything , but stalling has nothing to do with mex spots.
You are pretty much the one responsible for stallness as you should only set them to build things that dont stall or either dont stall much.
and yet again, if on brazilian battelfield the mex's placement is horrendous (wich i really doubt), test on another map.
if it does perform bad in 1 map so what ? you still have another 150 maps to try . (most maps have pretty ok mex build places)

[AF]

Because that means rewritting every buildtree for every spring metal style map to work on those maps without stalling, or long periods of builder inactivity whcih usually leads to the "my NTAI copy is broken" syndrome.

Eitherway it's ludicrous that an entire class of metal map is getting these types of results.

[Chocapic]

it isnt , and sorry being rude again but somethings have to be told.
thats one of the zillions disadvantages of using a concept for an ai of "Buidltree", it not only breaks the whole ai concept (Artificial Inteligence), as pretty much all the other ingame concepts in what relate whatever type of building (example : in diferent types of maps you want to do diferent types of things and also depending on how your oponent plays).
A "Buildtree" allways gives the ai 0 inteligence.
(i recognize that somethings can and should be hardcoded but lets not take this too personal).

[Lindir The Green]

you would need a supercomputer to run that, and it would take years to develop.

No Spring AI Will Ever Be Sentient

[submarine]

aai has no predefinded buildtables and all its construction choices are made based on the current situationn and the available buildings of the mod - nethertheless it uses about 50 times less cpu power than ntai

however i do agree that a lot of things cannot be done dynamically with the current available cpu-power

[Chocapic]

aai has no predefinded buildtables and all its construction choices are made based on the current situationn and the available buildings of the mod - nethertheless it uses about 50 times less cpu power than ntai

however i do agree that a lot of things cannot be done dynamically with the current available cpu-power

this is exactly what i mean, the level of inteligence given to the ai has to be measured acording to cpu available and data available from the engine, however 0 inteligence AI is pretty bad.

[SinbadEV]

World Domination Strategy #1:

Step 1: Teach a computer to win RTSs.
Step 2: Enter computer into anonymouse RTS competitions and earn lots of money.
Step 3: Use money to get a better computer.
Repeats Steps 1 to 3 until I have enough money to...
Step 4: Build giants robots and take over the world.

[sintri]

Well if you allow Spring to have multi-threading capabilities and allow it access to the second cpu, or 3rd and 4th if you're ludicrously rich running the socket 490 dual core + dual cpu, or you could also just be ludicously insane being able to afford quad cpu + dual core then I guess you'd have 7 other cpus availible to process an ai.

But you don't really need giant robots, just tech up, horde technology until you have a relatively high enough advantage to rebel against the current government and hope that they don't reverse engineer your tech and use it against you. Easiest way's getting some obscurely advance tech that it'll take everyone else years before they can even understand much less reproduce and take over the world within that time span. Course once you've taken the world you'll haveta ban learning, ban open source, burn all the books, and make the internet a playground for the rich only. It'd be a really crappy world but hey, you'll be in power.

[AF]

mwha, I'm not asking for a sentient algorithm to deal with mexes, and one isnt needed! I say this because what i want has already been done in numerous metal algorithms in the past, only I would like to use Krogothes metal class rather than both krogothes class for some maps and then running cain or veylons or zaphods original metal algorithms a second time wastign cpu pwoer to see which gives better results, thus avoiding the bad positions on brazillian battlefields that krogothes class gives BUT OTHERS DO NOT.

I'm sorry for the capital letters, onyl you are all thinking I'm askign for the whol metal extractor thign handed to me on a silver platter when I am saying ti is th core algorithm at fault because I have seen other algorithms do the same job and give the sort of results I am satisfied with.

So why do I not use those algorithms? Because on OTA style patch maps krogothes class is superior, Krogothes class is also superior on all metal maps. When combined with cains wraparoudn clas sit produces mroe accurate placement than cains original algorithm because of the fact that cains original algorithm handled extraction ranges and removing mex spots in a completely different way. Krogothes class is much faster than all the other classes, and ti has a working save/load function.

The only con that i have thought of that krogothes class should handle but doesnt is doing it's job on maps such as brazillian battlefields, or any map with that style of metal map.

As for AAI taking 50 times less cpu power than NTAI, I believe that that is an unfair assumption. For one what circumstances where you running them both under? Did you take into account several factors such as the fact that NTAI's threat matrix resolution is at least 5 times more detailed than the threat matrix in your last AAI source release, and contains many more affecting factors than simply is a unit there or not.


And for the last time, I am aware of the pitfalls of hardcoded buildtrees, if you havent noticed I have already posted 4 seperate approaches to remedying this:

1: NTAI XE editable textfile absed buildtrees and the XE 4 randomized buildtree options
2: Freeform buildtrees from the 0.3 test builds & the ind evelopment learning system
3: The demand based economy described at darkstars that uses buildtrees as a starting point and can be deviated from bsed on the game circumstances and ammended by the AI.
4: The NTAI X discussion

Now please, stop trying to bring up NTAI flaws that I've already been over.

And maybe just maybe I'll make an XE 4 SE that take sup 1000 times less cpu power than AAI, I'll call it the nagging AI, and it'll do nothing but say "use your units properly you f*ckin retard", and all will be good because lots of features != more cpu power so I can say it's all done through my amazing optimization skills! *amazing?!?!?! lmao*

mwha, chocapic, buildtree does not affect the mex placement, they're two totally seperate systems within NTAI, and a buildqueue has no ability to change mex spots unless for some reason the previous item in the queue was built half covering a spot, which at least 3 AI's atm are capable of suffering from (KAI & NTAI through closestbuildsite(), and OTAI through not checking for collisions in radar placement and mex placement so a mex on a high spot might have a radar tower built on it).

Now really, quit it.

[Chocapic]

Because that means rewritting every buildtree for every spring metal style map to work on those maps without stalling, or long periods of builder inactivity whcih usually leads to the "my NTAI copy is broken" syndrome.

mwha, chocapic, buildtree does not affect the mex placement, they're two totally seperate systems within NTAI....

--------------------------------------------------------------------------------------------------------------------

2: Freeform buildtrees from the 0.3 test builds & the ind evelopment learning system
3: The demand based economy described at darkstars that uses buildtrees as a starting point and can be deviated from bsed on the game circumstances and ammended by the AI.

Because that means rewritting every buildtree for every spring metal style map to work on those maps without stalling, or long periods of builder inactivity whcih usually leads to the "my NTAI copy is broken" syndrome.

[AF]

Dont take words from 2 different contexts and put them together.

Under the current version one would requrie tor ewrite the buildtrees so that mexes wherent as heavily relied on and NTAI focused more on a metal maker economy, otherwise mexes dotn generate enough metal and it throws the balance of the buildtree out and NTAI stalls.

But that is in the context of the current situation, and not future versions where these remedies are being implemented, remedies that change the entire construction system within NTAI.

Builder inactivity would be what would happen normally if I had kept the antistall waiting routine uncommented, builders would see that theyw here in the middle of a stall and simply wait for the resources to come bakc bfore they started but I got lots of error reports of bugs with untis standing still because of that routine.

Now while you lto are insistign NTAI si at fault and not Krogothes class I have some screenshots to shwo you, each taken using Cains metal class, but some have cains original algorithm in place, and some have krogothes replacement algorithm in place. The only needed change was in parse() and both generate the same type of data (a vector<float3> of the co-ordinates where the y value si the amount of metal).

KROGOTHES MEX ALGORITHM:


CAINS ALGORITHM:




So while krogothes metal class is generating what ti thinks are the ideal locations to palce a mex regadrless of wetehr theyc an b palced there, you are ignoring the accuracy and simpyl saying those are the best spots and that the AI maker is todo the rest of the work based around that data. Yet the raw data says otherwise, look at the yellow markers, better yet load up KAI 0.0 and watch the green markers which should be very close to them on most maps.

Yet look at those shots, notice how cains algorithm does a far better job than krogothes, even though the points they have generated are being ran through 2 identical systems. How can that be if NTAI is at fault? Why si ti that udner cains algorithm NTAI gets 23 metal where krogothes algorithm yields a metal income of 7.0 with the same number of mexes?

I dont knwo what it is with you chocapic, while you're sitting there with your AI that we have yet to see any code, binaries, screenshots, examples, replays, descriptions of, your telling me what todo with my AI. I knwo what I'm going todo wiht ym AI and I'm not taking well to having the problems my AI has shoved down my throat while I'm repeatedly telling you I already have solutions, having ym words taken out of context and selectively quoted so ti appears that they conflict and contradict.


So chocapic what exactly is it that you're arguing atm? I have made my original point, I ahve investigated it, I have prooven it, and you're still arguing and you're not providing a shred of evidence to the cotnrary, you're not providing logical answers and explanations of why i could be wrong. Even krogothe has admitted that if I showed him the necessary evidence to proove somethign was wrong then I'd get help with it, and I have shown those screenshots of the raw markers, the mex placements, the 5 mexes, I even showed it in comparison to another metal class which did it correctly.

So please unless you have a grand explanation that is reasonable and quashes all the explanations of those screenshots, that proves ocne and for all that it's just NTAI and it doesnt affect other AI's then go on, create a basic AI that sues an identical version fo krogothes class to NTAI that can place mexes perfectly on brazillian battlefields without resorting to extending the algorithm and sorting through metal map arrays.

[Chocapic]

hmm, that is very funny and may i say i didnt really read the whole post just say a 1/3 of it maybe, however
watch this:

cai mex placement on brazilian battlefield using krogothes metal class:



do we need to continue this conversation ?

[AF]

In that case I shall have to figure out why debugvectoredspots.tga agrees with me yet doesnt with you, nor do the markers nor do the replays, or the 4 AI dll's I have infront of me that run off of the latest version of that class.

[sintri]

thanks for overly large pictures that distort the forum spacing when viewing on a 1024x768 screen. Now I'll haveta place my res at 2048x1536 and hope the amount of pixels per inch doesn't create a minature black hole within the space between the glass.

[SinbadEV]

there is a great Greasemonkey script for phpbb sites that resizes over large images to fit the screen properly...

you'll need the greasemonkey Firefox Extension
EXTENSION: https://addons.mozilla.org/extensions/m ... php?id=748
SCRIPT: http://userscripts.org/scripts/show/2679

[krogothe]

Im back...
jesus F. christ AF, if only i knew your problem was so easy to solve...
1- WRITE A FUNCTION THAT WILL TELL YOUR AI WHICH SPOT TO CHOOSE.

Honestly, i said it many times over, it will return a vector, you are the one who has to code distance/accessibility/metal functions that will distinguish which spots are the best. my class is NOT cain's class, it wont give you the "hotspots". Every single spot returned generates metal, its your job to choose whether thats enough metal for you. Building a mex on the nearest spot WONT make your AI work well and WILL produce the screenies you posted.
It takes 30 secs to simply create a scoring function like this:


for(all spots)
{
score = spot.metal/distancetobuilder
}
build mex on spot with highest score

Needless to say you need to improve on the above, but that will already solve your problem. Also, MinMetalForSpot is your friend. Set it to 100-150 and all the crappy spots miraculously disappear.


Thankfully however my class isnt faulty!