Testing AAI
Moderators: hoijui, Moderators
I think that it needs to look at "random" vs. "non-random" generators of anything, and try to "figure out" what is cost-effective. If the AI can get the average wind-speed on a given map (which, if I recall correctly, is defined as part of the map file) then it should be able to evaluate wind generators and decide what's most effective.
It shouldn't just blindly build one or the other or... any combination thereof, though. That puts you on the path to just building yet another buildtree AI. Which, as I have stated loudly and annoyingly, I like- because I, as a game designer, want complete control over what AIs do or do not do... but it would defeat what I see as the purpose of AAI, which is to demonstrate an AI concept that can work with whatever is thrown at it. While I do not have great hope that your approach will ever be the "winner" against an AI that is fully-scriptable and controllable by a game designer who knows what they're doing, AAI shows great promise as a bug-free AI that will work with most game designs, and I think that pigeonholing it into building a specific kind of building, instead of having it compare their relative worths, would be a mistake. But hey, that's just me- if you really just want AAI to play a good game of XTA, be my guest
It shouldn't just blindly build one or the other or... any combination thereof, though. That puts you on the path to just building yet another buildtree AI. Which, as I have stated loudly and annoyingly, I like- because I, as a game designer, want complete control over what AIs do or do not do... but it would defeat what I see as the purpose of AAI, which is to demonstrate an AI concept that can work with whatever is thrown at it. While I do not have great hope that your approach will ever be the "winner" against an AI that is fully-scriptable and controllable by a game designer who knows what they're doing, AAI shows great promise as a bug-free AI that will work with most game designs, and I think that pigeonholing it into building a specific kind of building, instead of having it compare their relative worths, would be a mistake. But hey, that's just me- if you really just want AAI to play a good game of XTA, be my guest

Argh, I think as we go along with our evolution of our AI's we're going to fall itno what you say anyways. I'm already seeing things in the NTAI test build that are crying out for that sort of configuration.
I onyl wish I had a lightweight interpreter, nothing as powerful as lua, just easy to integrate, fast, with a limited feature set for basic operations.
I onyl wish I had a lightweight interpreter, nothing as powerful as lua, just easy to integrate, fast, with a limited feature set for basic operations.
Well, I could propose a common set of AI standard parameters and scripting conventions, and come up with a simple, flat-file set of definitions that would become part of mods- AI developers could also build and share a common parsing DLL, which would lead to best efficiency and less reinvention of the wheel, much like the Metal Class has helped everybody get resource-mapping down to a ridiculously exact science very quickly 
I'll think on this- I had about 50% of it blocked out over the last year of random posts, but just gathering together my scattered thoughts will probably just result in a hodge-podge of half-baked ideas that aren't efficient or clean... if the other AI developers (with the notable exception of Submarine, who's doing something Entirely Different) would agree on a common set of parameters (and their meanings, at least in a loose sense- no final AI would be exactly like the others, obviously) then it might be worth taking the time to define everything.

I'll think on this- I had about 50% of it blocked out over the last year of random posts, but just gathering together my scattered thoughts will probably just result in a hodge-podge of half-baked ideas that aren't efficient or clean... if the other AI developers (with the notable exception of Submarine, who's doing something Entirely Different) would agree on a common set of parameters (and their meanings, at least in a loose sense- no final AI would be exactly like the others, obviously) then it might be worth taking the time to define everything.
That isnt quite how I imagined it. I'm more itnerested in there actualyl being logic and rules and structures within the files. The last thing i want is a TDF file full of tags. Afterall I want to eb able to let modders modify NTAI build trees from there freeform originals into mod specific fine tuned variations. But I've learnt from NTAI 0.28 that a straight forward list never works best, you need a random element aswell as time considerations, and other game logic.
As a result what I do will end up reflecting a basic interface backed up by internal code. I'm thinking more along the lines of I lead, people follow the idea if they want, and I then change it to suit a common ground.
As a result what I do will end up reflecting a basic interface backed up by internal code. I'm thinking more along the lines of I lead, people follow the idea if they want, and I then change it to suit a common ground.
I am all for an unified system, but i think we could better use our efforts by improving the AI interface for now... You guys more than me are experienced programmers, we could add stuff like more info on features and projectiles, a working cheat interface etc, then post the ideas and code up and everyone has their go at improving and optimizing it until its good enough for spring.
Today i just rewrote GetClosestBuildSite to suit special needs, and although it seems a bit slower, it performs more operations and is playable. If we start working on the spring source together then soon we will have developed the "mood" to work on an integrated interface, which although i will probably not use myself, could be great for the AI community as a whole...
btw sub, i find solars the better choice too, wind is just too easy to destroy and its instability messes up KAI too
Today i just rewrote GetClosestBuildSite to suit special needs, and although it seems a bit slower, it performs more operations and is playable. If we start working on the spring source together then soon we will have developed the "mood" to work on an integrated interface, which although i will probably not use myself, could be great for the AI community as a whole...
btw sub, i find solars the better choice too, wind is just too easy to destroy and its instability messes up KAI too

hmm, i dont think "GetClosestBuildSite()" is a vital part of the interface, it just makes it easier to start an own ai
i think its more important to add a function BuildSiteBlocked(int unit) to tell the ai, an ordered building could not be errectetd. Right now it might seem that orders just vanish somewhere in the engine which is (at least in this particular case) not true
i also got the impression, that UnitIdle() is not always called if a unit goes idle
i think its more important to add a function BuildSiteBlocked(int unit) to tell the ai, an ordered building could not be errectetd. Right now it might seem that orders just vanish somewhere in the engine which is (at least in this particular case) not true
i also got the impression, that UnitIdle() is not always called if a unit goes idle
Look at every single version fo NTAI ever released. Construction units stall from tiem to time, and it's always after they've finsihed building soemthing. 90% fo the tiem they burst back into life if you give them an order or justs elect them and press the stop button manually.
Just look at the test build of NTAI which has no antistall code to rpevent this and relies totally on the engine to figure out if a unit is idle, it's ludicrous.
Also, some people saw a bug that occurs when a unti tries to mvoe out fo soemwhere btu ti cant. I got these errors with freakers and scouting. The factory would build a freaker which would get sent off, but it hadnt elft the factory so it slammed againstt eh side fo the factory walls and kept tryign to walk through. While this happened I got voerflow errors, and I couldnt track the problem ebcause of the hgue slowdown, and the logfiles getting overflown with hudnreds of megabytes of "Overflow 4000 3789 etc..".
Yet all fo that should never have happened if the itnerface called UnitMoveFailed(), it seems even unit Sub-AI suffered in that case.
Just look at the test build of NTAI which has no antistall code to rpevent this and relies totally on the engine to figure out if a unit is idle, it's ludicrous.
Also, some people saw a bug that occurs when a unti tries to mvoe out fo soemwhere btu ti cant. I got these errors with freakers and scouting. The factory would build a freaker which would get sent off, but it hadnt elft the factory so it slammed againstt eh side fo the factory walls and kept tryign to walk through. While this happened I got voerflow errors, and I couldnt track the problem ebcause of the hgue slowdown, and the logfiles getting overflown with hudnreds of megabytes of "Overflow 4000 3789 etc..".
Yet all fo that should never have happened if the itnerface called UnitMoveFailed(), it seems even unit Sub-AI suffered in that case.