the problem is that factories follow different rules (and have a different data structure) than mobile construction units
i didnt say its impossible, but it would take some time and im currently not very much intersted in nano blobs and i read that ntai performs well so it's not that urgent...
AAI 0.55 - compatible with new spring version
Moderators: hoijui, Moderators
afaik there are lots of ppl who like it very much. before starting to work on aai i thought about writing ais fopr some other games, but most of them were purely designed for ai-testing. i wanted to write an ai for a "real" game to test things under "real" conditions.Argh wrote: I spent almost three months on revising it, to give you a polished game design to test theory with, and you haven't even bothered playing it... thanks
anyway, i prefer realistic mods (well at least some realism :) ) liek ta wd and aata; and off course aa
ahem, doesnt the freaker in AA build units?
What about Taros in TA kingdoms?
How about Glest? Shouldnt your AI be flexible enough to have a unified way of dealing with units and factories?
At some point I intend on making a revised AI interface alongside th existing one, and then integrating it into both spring and glest so I have a way of testing out routines in NTAI that deal with harvesting resources in the way most RTS's do, and dealing with upgrades and systems such as magic.
As far as I am aware the onyl AI's currently supporting nanoblobz are OTAI and NTAI, though OTAI support isnt complete. I envisage QAI would ahve absic support to but would be limited to using sheep to build autofacs and autofacs building everything else as it uses different systems for factories and units too.
Do you also realize you've ended up with another problem, buildings building buildings?
What about Taros in TA kingdoms?
How about Glest? Shouldnt your AI be flexible enough to have a unified way of dealing with units and factories?
At some point I intend on making a revised AI interface alongside th existing one, and then integrating it into both spring and glest so I have a way of testing out routines in NTAI that deal with harvesting resources in the way most RTS's do, and dealing with upgrades and systems such as magic.
As far as I am aware the onyl AI's currently supporting nanoblobz are OTAI and NTAI, though OTAI support isnt complete. I envisage QAI would ahve absic support to but would be limited to using sheep to build autofacs and autofacs building everything else as it uses different systems for factories and units too.
Do you also realize you've ended up with another problem, buildings building buildings?
sorry but whats glest? and whats taros? units?
aai simply filters those buildoptions out. until now i've never come across a mod where buildings that build other buildings are a vital part of the mod. if this will be the case im probably gonna extend aai's factory/builder management. but atm i rather think its not necessary to be able to deal with all creative ideas that may arise in the future
aai simply filters those buildoptions out. until now i've never come across a mod where buildings that build other buildings are a vital part of the mod. if this will be the case im probably gonna extend aai's factory/builder management. but atm i rather think its not necessary to be able to deal with all creative ideas that may arise in the future
Sounds like a good ideasubmarine wrote:ah ok, well i think i'll try to code a more challenging ai for ta spring first before thinking about compatibility to games i didnt even know before
No it doesn't. That's why AF talked about a generic interface internal in his AI which has the Glest AI interface (if there exists any) on top of it and also the TA Spring AI Interface on top of it.btw: i guess glest doesnt have the same ai-interface as ta spring?!?
Actually I was referring to a future where spring and glest have 2 AI interfaces, namely the current interfaces and a second interface that I'm designing.
Thus any future additions to the interface will be to the second interface but the existing interface will be kept for backwards compatibility. Such a new interface is to be required if it is to span glest and spring, and it will also mean any spring AI's using the interface will work with Glest as well with no immediate effort required save possibly a harvesting routine and a tech upgrade routine.
Also there are factors of your AI that will be forced to change to support these different formats because the support required brings along with ti change sin an AI that make it much more flexible and expandable.
For example NTAI's construction system has benefited greatly from allowing units building units and buildings building buildings, allowing ti to work on pretty much any mod, and providing the great mass of options that any modder can change as well as a few unexpected surprises..
Thus any future additions to the interface will be to the second interface but the existing interface will be kept for backwards compatibility. Such a new interface is to be required if it is to span glest and spring, and it will also mean any spring AI's using the interface will work with Glest as well with no immediate effort required save possibly a harvesting routine and a tech upgrade routine.
Also there are factors of your AI that will be forced to change to support these different formats because the support required brings along with ti change sin an AI that make it much more flexible and expandable.
For example NTAI's construction system has benefited greatly from allowing units building units and buildings building buildings, allowing ti to work on pretty much any mod, and providing the great mass of options that any modder can change as well as a few unexpected surprises..
imho the ai interface should not changed much anymore. it would be nice to have some little additions (e.g. a callback function if buildpos is blocked) but apart from that the interface has proven to give the ai programmer enough possibilities to design a working ai
ai devs should imho use their time to develop an ai, not to reinvent the wheel by making their own interfaces
ai devs should imho use their time to develop an ai, not to reinvent the wheel by making their own interfaces
Even when that interface is inconsistent, could do with soem additions, and cannot handle several possible features whcih are a part of most rts's?
Do you think we should have a list of event functions such as unitIdle() follwoed by the added HandleEvent() and Get() type calls Zaphod and cain added? set<> and vector<> used in some palces and int* void* used in others? How about the GetEnemies() compared to the GetFeatures() calls? How about untis harvesting? How about upgrades? Techtree information? Magic and other combat skills? thigns like morphing from on unit type to another?
A lto fo these things have been asked for by members fo the community, should we dump a spaghetti interface on new users and expect them to support everythign in a great tangled mess? What happens when people dotn use the new mod features because the necessary support in GlobalAI's and GroupAI's arent there?
What about all the other stuff people are asking for? Somehow I dont thinkt he current itnerface cuts it.
Now what I am not sayign si that this is a replacement interface, the old one will still be there and I'll try adn tie in anythign enw into the calls zaphod and cain added.
For oen I'm not happy with how they've used void* in their implementation and the great number of structures such an interface would ahev fi ti where all done through those functions. And naturally I'll end up writting an AI SDK with 2 examples showing an existing AI ported over with a bridge between the new and an old ontop that takes advantage fo the enw too, and then something more like what i ahd in mind for the future.
The onyl change existing AI's would have to make that would affect their compatability would eb an extra function in interface.cpp to determine which interface they're going to use (old/new).
And while you may be happy writting AAI udner the current system, my needs dictate that a more flexible and coherent itnerface is needed, especially soem fo the groupAI plans I've had that ahd to be scrapped as a whole because of the itnerface, and seems as I seem to eb the sole user of the groupAI interface, I see no reason why anyone should object to me redesigning that.
Also there are security concerns over groupAI, I itnend thus to combine the globalAI and groupAI aspects in the next interface and instead have a different way of securing things rather than 2 seperate interfaces.
So go ahead use the current interface, btu ym needs arent met by the current interface and I could do with soemthign better. If you wish to help me do that then contribute when I put forward my first draft so that we as a community can revise it.
I've posted in the glest forum asking for input as to wether they'd want such an itnerface like we have at spring, adn reading backwards many people have asked for the ability to change parts of the AI, and extendable itnerfaces, using OTA AI profiles specifically as examples, the sorts of thgins AAI/NTAI/JCAI/OTAI have in there basic config files and so on..... Currently they have only a basic AI writtne by one fo the devs quickly, with no configurability, and the hacks to make ti better involve resource cheating (300%+ gold incoem for example)
Do you think we should have a list of event functions such as unitIdle() follwoed by the added HandleEvent() and Get() type calls Zaphod and cain added? set<> and vector<> used in some palces and int* void* used in others? How about the GetEnemies() compared to the GetFeatures() calls? How about untis harvesting? How about upgrades? Techtree information? Magic and other combat skills? thigns like morphing from on unit type to another?
A lto fo these things have been asked for by members fo the community, should we dump a spaghetti interface on new users and expect them to support everythign in a great tangled mess? What happens when people dotn use the new mod features because the necessary support in GlobalAI's and GroupAI's arent there?
What about all the other stuff people are asking for? Somehow I dont thinkt he current itnerface cuts it.
Now what I am not sayign si that this is a replacement interface, the old one will still be there and I'll try adn tie in anythign enw into the calls zaphod and cain added.
For oen I'm not happy with how they've used void* in their implementation and the great number of structures such an interface would ahev fi ti where all done through those functions. And naturally I'll end up writting an AI SDK with 2 examples showing an existing AI ported over with a bridge between the new and an old ontop that takes advantage fo the enw too, and then something more like what i ahd in mind for the future.
The onyl change existing AI's would have to make that would affect their compatability would eb an extra function in interface.cpp to determine which interface they're going to use (old/new).
And while you may be happy writting AAI udner the current system, my needs dictate that a more flexible and coherent itnerface is needed, especially soem fo the groupAI plans I've had that ahd to be scrapped as a whole because of the itnerface, and seems as I seem to eb the sole user of the groupAI interface, I see no reason why anyone should object to me redesigning that.
Also there are security concerns over groupAI, I itnend thus to combine the globalAI and groupAI aspects in the next interface and instead have a different way of securing things rather than 2 seperate interfaces.
So go ahead use the current interface, btu ym needs arent met by the current interface and I could do with soemthign better. If you wish to help me do that then contribute when I put forward my first draft so that we as a community can revise it.
I've posted in the glest forum asking for input as to wether they'd want such an itnerface like we have at spring, adn reading backwards many people have asked for the ability to change parts of the AI, and extendable itnerfaces, using OTA AI profiles specifically as examples, the sorts of thgins AAI/NTAI/JCAI/OTAI have in there basic config files and so on..... Currently they have only a basic AI writtne by one fo the devs quickly, with no configurability, and the hacks to make ti better involve resource cheating (300%+ gold incoem for example)
ok i think i got your point now
i totally agree that the current interface needs some adjustments/fixes (as i mentioned above)
the problem is our different philosophy:
- it seems to me that you want to create the ultimate ai inteface that can handle more or less everything we can think of at the moment. however i think you're trying to deal with too many things all at once.
- i'm happy if aai works properly with most mods. i dont think much about things like techtrees or spells since (according to the dev mailing list) they will not be implemented in the near future.
i totally agree that the current interface needs some adjustments/fixes (as i mentioned above)
the problem is our different philosophy:
- it seems to me that you want to create the ultimate ai inteface that can handle more or less everything we can think of at the moment. however i think you're trying to deal with too many things all at once.
- i'm happy if aai works properly with most mods. i dont think much about things like techtrees or spells since (according to the dev mailing list) they will not be implemented in the near future.
no aai can only learn if there is an instance of aai running
yeah, i know that might be a bit frustrating. work on aai 0.60 has more or less been finished and there will be major changes to all files (so nothing will be the same). i usually play aa and ta:wd, so feel free to mail me learning files of other mods ...
yeah, i know that might be a bit frustrating. work on aai 0.60 has more or less been finished and there will be major changes to all files (so nothing will be the same). i usually play aa and ta:wd, so feel free to mail me learning files of other mods ...
