About mex-upgrading: when building on wreckage or enemy buildings, it is auto-reclaimed. What about auto-reclaiming if you're building on top of one of your buildings, if you hold down shift/ctrl/alt/combination when placing the building? Or pressing both left and right mouse buttons..
Alantai, good point about the uber globalAIs. AIs that define and control your style of play wouldn't be good.
On the other hand, what about a mod that takes global ais to the extreme? You would have no direct control over units and factories, only the programmer unit I mentioned earlier. You'd have to kind of script your own AI by building AI buildings.
About Group Ais
Moderator: Moderators
excellent.aspa wrote:About mex-upgrading: when building on wreckage or enemy buildings, it is auto-reclaimed. What about auto-reclaiming if you're building on top of one of your buildings, if you hold down shift/ctrl/alt/combination when placing the building? Or pressing both left and right mouse buttons..
Its something like the "upgrade" command that is present in other games.
You build a tower, then its a watch tower, then its a cannon..
I like much better the approach of actually "giving" the "mex" order to a builder, and let then, the builder decide what will it do, than a mex upgrading by itselve...
Something like an "area" command.
For example, you can select a L1 const, and give an "area mex" order, then it will obviously build L1 mexes in the rigth spots, if there are spots, or somehow distribute the metal extractors (by output??... ) if there is metal like in flooded.
In contrast. a L2 builder, given same command will build moho mexes, and reclaim/Self-D any L1 mex in that spot.
You get to manage the "place metal extractors" concept rather than shift click your way to victory.
This is in the line of Group AIs that dont play by themselves, but relieve micro from the player.
In this same line of "logic" there are some other uses for this pseudo "upgrade" order.
Maybe defense towers? but im not sure about that.
The metal extractor thing is the most directly usefull for this.
keep thinking ppl! (paulo, maelstrom, aspa!) :)
e: ah yes! this is usefull for mt towers too.. usually there are far too many in my base, and i rather use that same spot for a flakker than getting even more aa. (and using more of the available unit number).
That's a kludgy solution that leaves a lot to be desired. The construction unit ends up continuously moving from defensive structure to defensive structure, needlessly exposing it at the front lines during the heat of battle, and can't be used for anything else in the meantime unless you want that other task to also be added to the neverending queue. Worse, if the construction unit is destroyed there's no way to give a new construction unit the same orders to replace it with (the spots where those defensive structures are standing are all unbuildable areas because the structures are already _there_).zwzsg wrote:Like AF, said, make sure your construction units have repeat ON when you give them the order to build the defense, and they will do that.tanelorn wrote:SAnother idea, similar, is auto replenishment of defensive structures. If you set a defense / building to this, once it's destroyed, an idle construction unit will go there and start building a new one. Or rez bots.
In general, I think it'd be nice if there were a "generic construction queue" for both mobile construction units and for the unit factories where you could queue up build orders and then idle construction units that could fulfil them would automatically take up the task. That way if there's no special need for speed or precision you could tell your forces "I want twenty new bulldogs and three HLTs at this spot" and let the lower-level supervisors work out the details.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Why can't I just block group AI use from multiplayer game as an option?
I think I said before... group AIs are great for good programers to play with, expecially for testing thing that can be eventually integrated into global AI's or even the game by default... but in the end it's too exploitable, making bad players into good players with the click of a button, to leave as a full function, always on, feature.
I think I said before... group AIs are great for good programers to play with, expecially for testing thing that can be eventually integrated into global AI's or even the game by default... but in the end it's too exploitable, making bad players into good players with the click of a button, to leave as a full function, always on, feature.
I heard they called this feature the central build GroupAI. I wish we had one in the aidll/ folder, maybe SJ can write it? And we cna name it conAI.dllBeeDee wrote:That's a kludgy solution that leaves a lot to be desired. The construction unit ends up continuously moving from defensive structure to defensive structure, needlessly exposing it at the front lines during the heat of battle, and can't be used for anything else in the meantime unless you want that other task to also be added to the neverending queue. Worse, if the construction unit is destroyed there's no way to give a new construction unit the same orders to replace it with (the spots where those defensive structures are standing are all unbuildable areas because the structures are already _there_).zwzsg wrote:Like AF, said, make sure your construction units have repeat ON when you give them the order to build the defense, and they will do that.tanelorn wrote:SAnother idea, similar, is auto replenishment of defensive structures. If you set a defense / building to this, once it's destroyed, an idle construction unit will go there and start building a new one. Or rez bots.
In general, I think it'd be nice if there were a "generic construction queue" for both mobile construction units and for the unit factories where you could queue up build orders and then idle construction units that could fulfil them would automatically take up the task. That way if there's no special need for speed or precision you could tell your forces "I want twenty new bulldogs and three HLTs at this spot" and let the lower-level supervisors work out the details.
Other than that, what you're saying is that you expect such a thign to be omniscient tot ake into account all these things. Try adding a move command to your queue of commands to repeat so it moves off somewhere after its done and then mvoes back when it rebuilds, better yet have several con untis build them, afterrall they're going to be exposed eitherway wether it's the repeat build order, or the eventual "I need those defences rebuilt" said by the player. Are you expecting the unti AI to somehow build a defence for you then magically teleport it onto the battlefront with computer trickery for you?
These are examples of times when a player needs to use skill. If a unit AI behaviour that already exists doesnt do the job because it doesnt take into account these things then thats because it's not something a unit AI should ever do and these things are HUMAN SKILL attributes MICROMANAGEMENT, thing you should learn yourself if you want to play well, and they'll be worth it aswelll, as they'll rool over into the handling fo other things. Dont be lazy, and expect me or soemone else to code you a groupAI that will attempt to do things a human is good, things that rely on abstraction and reasoning, or automating vital gameplay.
Better Formations waiting on slow units and sorting them appropriately would be fine.
Easier upgrades by AI from lvl 1 econ to lvl 2 econ would also be nice.
A scout AI that avoids enemy detection and fire and roves the land, searching for enemies would be good, for i.e. Peepers especially.
A grab all mex-spots in AREA, fill AREA with solars etc. AI.
A "do something to keep metal lvl at X, and to keep energy lvl at X"-AI.
:D
Easier upgrades by AI from lvl 1 econ to lvl 2 econ would also be nice.
A scout AI that avoids enemy detection and fire and roves the land, searching for enemies would be good, for i.e. Peepers especially.
A grab all mex-spots in AREA, fill AREA with solars etc. AI.
A "do something to keep metal lvl at X, and to keep energy lvl at X"-AI.
:D
What?SwiftSpear wrote:... but in the end it's too exploitable, making bad players into good players with the click of a button, to leave as a full function, always on, feature.
Please explain, where do i have to click?
how you do that Swiftspear?
please explain us how do Group Ais do that?
Its not the topic of this thread anyhow, but reading youi can tell why not to have that option already.
And alantai, that is a poor description of that group ai.
"it will sort for you with what builds what"
that works like command conquer style interface.
"and what priorities" i not sure about this, but afaik, the const units get assiged the build order closer to them, no other sorting.
(that can be a crap if you throw a resource hunger queue there.)
Also, you are mistaken about it REBUILDING the elements in the queue if you set "repeat" to the units in that group. It doesn't.
There is no repeat option to the ai as itselve, but it a good idea to have that :).
imho, there is a lot more skill involved in using that group ai than what you explained so easily there.
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
I have a simpler way to say what I was trying to say earlier:
The use of GroupAIs should not make a bad player mediocre, or a mediocre player good. The use of GroupAIs should make a player more efficient without increasing skill.
For example, a GroupAI that synchronizes formation build speeds makes a player more efficient without actually increasing skill levels. If the player isn't good enough to know what units to put with what for maximum effect, or doesn't know when and where to attack, that's his problem and should not be solved with a GroupAI.
Another example: a GroupAI that automatically reclaims mexes in an area and builds mohos in their place is acceptable. However, a GroupAI that analyzes resource data and determines when to best make the conversion, and that starts and stops when resource income/expenditure justifies it, would be playing the game for the player. If the player can't smoothly transition from mex to moho, or has resource problems, that's his problem and should not be solved with a GroupAI.
In general, I'd like to see small, simple, effective GroupAIs to solve particular small problems more than I'd like to see grand GroupAIs that do all sorts of stuff. Stuff like the Metal Maker AI, formation synch-move AI, etc. are the sorts of things that I'd like to see GroupAIs doing.
The use of GroupAIs should not make a bad player mediocre, or a mediocre player good. The use of GroupAIs should make a player more efficient without increasing skill.
For example, a GroupAI that synchronizes formation build speeds makes a player more efficient without actually increasing skill levels. If the player isn't good enough to know what units to put with what for maximum effect, or doesn't know when and where to attack, that's his problem and should not be solved with a GroupAI.
Another example: a GroupAI that automatically reclaims mexes in an area and builds mohos in their place is acceptable. However, a GroupAI that analyzes resource data and determines when to best make the conversion, and that starts and stops when resource income/expenditure justifies it, would be playing the game for the player. If the player can't smoothly transition from mex to moho, or has resource problems, that's his problem and should not be solved with a GroupAI.
In general, I'd like to see small, simple, effective GroupAIs to solve particular small problems more than I'd like to see grand GroupAIs that do all sorts of stuff. Stuff like the Metal Maker AI, formation synch-move AI, etc. are the sorts of things that I'd like to see GroupAIs doing.
hmm Having looked voer the central build AI's code repeatedly numerous times, I thought repeat orders would ahve that effect, but if it hasnt then I see a simple change would be needed to add that functionality.
And that isnt the onyl sorting done, ti actualyl sorts through your units looking for one capable of building it, aswell as then finding the nearest one that is currently free.
As far as the user is aware all they need do is tell the groupAI that they want this to be built there, and as long as the AI has the untis capable of building it, it will do the job. Or at least that was the intention of how it was meant to work.
But that wasnt my only arguement.
And that isnt the onyl sorting done, ti actualyl sorts through your units looking for one capable of building it, aswell as then finding the nearest one that is currently free.
As far as the user is aware all they need do is tell the groupAI that they want this to be built there, and as long as the AI has the untis capable of building it, it will do the job. Or at least that was the intention of how it was meant to work.
But that wasnt my only arguement.
Felix the Cat.
Actually i dont know exactly what you mean.
and it would be rather hard to generate some type of "agreement" on what should and what shouldnt any grp ai do, at least not rigth now, as we dont really have the experience to say that.
i.e. maybe later we realize that a "harrasment" ai was not such of a devil's thing (im not saying its not!, its an example
), and is ok if you will drive that "extra attention" into some other stuff like... marking? placing build orders... who knows, microing your const, queing units, inserting scouts into enemy's base, diverting from Main attack/air trasported troops unload!! yeeehaa!!
ok... now, as we cant give that "definition" of good and bad ais..
I was just asking about what you ever felt it could be usefull.
so far, there has been some good suggestion on using repeat, and like one more elaborated objective for an ai (that is the area mex).
Now that i had that talking.. hm.. how about some tweaking for troops Transport?
I know you can set up excellent transport routes, using repeat, area load/unload and some micro...
(like area-pickup troops from lab's exit point, using repeat and area unload).
But what hack could be good there....
Maybe something like central build, but central transport..
idle transports pick up units at "load zones" and drop them at .. well.
you know what is one of the plus of central build? you dont have to click so much.
WHY?
well because, the queues are inherithed, yes, yes, like 100 less clicks per const unit.
so, appliying that to the trasports.. well the only addition i would do to the current clicky area clicky repeat, clicky middle piont, clicky dropzone... is.. being able to be inherithed.
that is, select a trasport and tell him the job.. it will start working.
then select the "just built" transport, and "add" it to that trasport group.
Voila!!! it now knows what to do!.. ah..
finally, alantai, i think your other argument was, you didnt want to be asked to build this ais?.. well nobody has (yet), (at least in this thread), that is because it was not intended to build this ais, just compile information on what other players have to say.
So, i ask for your input instead.
Actually i dont know exactly what you mean.
and it would be rather hard to generate some type of "agreement" on what should and what shouldnt any grp ai do, at least not rigth now, as we dont really have the experience to say that.
i.e. maybe later we realize that a "harrasment" ai was not such of a devil's thing (im not saying its not!, its an example
), and is ok if you will drive that "extra attention" into some other stuff like... marking? placing build orders... who knows, microing your const, queing units, inserting scouts into enemy's base, diverting from Main attack/air trasported troops unload!! yeeehaa!!ok... now, as we cant give that "definition" of good and bad ais..
I was just asking about what you ever felt it could be usefull.
so far, there has been some good suggestion on using repeat, and like one more elaborated objective for an ai (that is the area mex).
Now that i had that talking.. hm.. how about some tweaking for troops Transport?
I know you can set up excellent transport routes, using repeat, area load/unload and some micro...
(like area-pickup troops from lab's exit point, using repeat and area unload).
But what hack could be good there....
Maybe something like central build, but central transport..
idle transports pick up units at "load zones" and drop them at .. well.
you know what is one of the plus of central build? you dont have to click so much.
WHY?
well because, the queues are inherithed, yes, yes, like 100 less clicks per const unit.
so, appliying that to the trasports.. well the only addition i would do to the current clicky area clicky repeat, clicky middle piont, clicky dropzone... is.. being able to be inherithed.
that is, select a trasport and tell him the job.. it will start working.
then select the "just built" transport, and "add" it to that trasport group.
Voila!!! it now knows what to do!.. ah..
finally, alantai, i think your other argument was, you didnt want to be asked to build this ais?.. well nobody has (yet), (at least in this thread), that is because it was not intended to build this ais, just compile information on what other players have to say.
So, i ask for your input instead.
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
That transport thing is another one of the small, useful GroupAI ideas that would solve a particular problem without making the player any better. I'd love to see it written up as a GroupAI, because I might start using air transport then...
See, with the transport thing: it doesn't make the player any better; the player still has to determine the start and end points; the player has to figure out what he wants to do with the transported units, and has to arrange for fighter escorts if necessary, and so on.
See, with the transport thing: it doesn't make the player any better; the player still has to determine the start and end points; the player has to figure out what he wants to do with the transported units, and has to arrange for fighter escorts if necessary, and so on.
I'm well aware of the central build AI, thanks. It doesn't actually do the things that I suggested it should be able to do.Alantai Firestar wrote: I heard they called this feature the central build GroupAI. I wish we had one in the aidll/ folder, maybe SJ can write it? And we cna name it conAI.dll
Not at all. I just want my construction units to not be complete morons. Why should they have to visit each structure over and over again "in person" to see whether it still exists or needs rebuilding? Why can't I tell a new construction unit to do the same rebuilding tasks that an existing construction unit already knows how to do? There's no good reason for this, even solely thinking in terms of gameplay. It's just an artificial and arbitrary limitation left over from the way the build queues were first programmed.Alantai Firestar wrote: Other than that, what you're saying is that you expect such a thign to be omniscient tot ake into account all these things.
Are you saying that TA:Spring is perfect and complete, and should never have new features added to it? Once upon a time it didn't have "ghost" buildings, but now they're used in every multiplayer game I've participated in and I don't see people lamenting the fact that humans no longer have to remember the type and location of every building their scouts see. Going back even further, in OTA units wouldn't fire on radar blips at all unless there was a targetting facility but in Spring they at least make the attempt.Alantai Firestar wrote: These are examples of times when a player needs to use skill. If a unit AI behaviour that already exists doesnt do the job because it doesnt take into account these things then thats because it's not something a unit AI should ever do and these things are HUMAN SKILL attributes MICROMANAGEMENT, thing you should learn yourself if you want to play well, and they'll be worth it aswelll, as they'll rool over into the handling fo other things.
As a result of these added features the game became less a test of player attention, memory and mouse-clicking speed and became more one of strategy. That's the sort of thing I'd expect these auto-build AIs to be ideal for - reducing the pointless busywork that only serves to distract the human player from the more important decisions.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Mong: Sorry, it's an analogy to old HL scripts. People used to say "all I do is press one button and the game plays for me", when really you would have to be pretty dumb to not realize that it isn't that simple... but the sarcastic message of the saying rings through. Playing against a player using the central build AI to manage his metal growth is just different then playing the same player not using AIs at all. If he was so good he wouldn't need to use the AIs in the first place. Group AIs can potentially manage the weak points of a player's game for them, therefore what would be a mediocre player all of a sudden will beat people who are putting alot more effort and skill into the game just because they have more knowledge of a feature that really has nothing to do with pure gameplay.
I'm not saying that group AI is generally bad or anything. I can see lots of cool and fun implimentations. But for the purist, expecially in tournament or match style play, it really shouldn't be an option, or even a temptation. Players are testing thier mettle entirely against other players, not against other player + AI.
I'm not saying that group AI is generally bad or anything. I can see lots of cool and fun implimentations. But for the purist, expecially in tournament or match style play, it really shouldn't be an option, or even a temptation. Players are testing thier mettle entirely against other players, not against other player + AI.
hmm as far as I was aware they ddint do that uless you told them to do that by adding it to the queue.Why should they have to visit each structure over and over again "in person" to see whether it still exists or needs rebuilding?
And if they do do that then it's not a groupAI you should be lobbying for it's a change to fix the sub-AI behaviours.
The same with transports, thats how they work for me by settign them to repeat and giving them an area comamnd to load and unload, albeit a few tweaks need makign such as not making the try to load unfinished units.
Also, not all features are good, some are positive features some are bad, soem are just made because the player cba learning themselves. And dont accuse em of portraying spring as perfect and all complete, have you read any of my posts outside this thread? I am the onyl oen to have released a GroupAI other than the original 3 by SJ, and I'm the one constantly badgering over engien unreliability int eh AI itnerface. For example spring crashes on NTAI fi I uncomment the code that makes the commander repair unfinished things when its idle. Soemtimes it works sometimes it doesnt but it isnt an AI crash cus I get the sprign crash ahs occured and crash report thing.
Overrall half of these GroupAI suggestions are alreayd implemented in another ay btu you're askign for an entire rewrite as a groupAI rather than telling the maker what's wrong and asking for a line of code to be changed which is much easier. Units on patrol being stupid? Sub-AI change not GroupAI rewrite, transports nto behaving themselves the way they're supposed to? Sounds more like an engine bug than an excuse for a GroupAI.
Eitherway unless you learn C++ get otu a compiler and try and code it yourself you're not gonna get anyone to code it for you by acting like that.
they do, press repeat, ask for some far appart build orders, then the unit will "patroll" every order in its queue, and verify it with its nano.hmm as far as I was aware they ddint do that uless you told them to do that by adding it to the queue.
who is lobbing? and i agree it should be changed.And if they do do that then it's not a groupAI you should be lobbying for it's a change to fix the sub-AI behaviours.
the same what? yeah thats how they work, but they cant inherit queues atm.The same with transports, thats how they work for me by settign them to repeat and giving them an area comamnd to load and unload, albeit a few tweaks need makign such as not making the try to load unfinished units.
You are being accused of anything alantai, but you seem so negative to any of the posts.Also, not all features are good, some ... .... but it isnt an AI crash cus I get the sprign crash ahs occured and crash report thing.
btw your cursor ai seems to give information to the enemy too, as i can see what is ntai doing, bc of its flashy icons and stats..
i guess the "area solar" suggestion qualifies for that .. haha..Overrall half of these GroupAI suggestions are alreayd implemented in another ay... ...Sounds more like an engine bug than an excuse for a GroupAI.
now
who said that? transports are nearly perfect for me :)transports nto behaving themselves the way they're supposed to?
on that last trasnport ai thing.. its very related to the "queue tools" requested by some other time ago. Now i realize that, no intention of getting away with the idea. I realized too that its a generic thing, you would like that "inherith queue" thing for many other uses, like troops or construction units, its works like a sort of "lesser" central build if you think about it.
acting like what?.. hm.. free thinking?..Eitherway unless you learn C++ get otu a compiler and try and code it yourself you're not gonna get anyone to code it for you by acting like that.
sad you dont like any of these ideas, or have the time to help in polish them. Maybe you are right and all of this is pure crap, feel free to ignore it if such.
Swiftspear, what did those spcripts do? is it usefull in spring too?
And i think you are right, there is an adv. for using central build, that is why its there
. It gets some learning to use, as some priority buildings will need direct control and more importantly, focus resources.
It very easy to stall in resources using that ai.
So, that last "global transport" ai turned into inherit queue...
do you remember dune? :) well a bit dangerous to have somethign like that, and useless for spring, as there is no harvesting.
mongus you werent acting liek anything, that comment was directed as was much of my last post at swiftspear.
As for inheriting queues, i had a groupAI that simply held onto queues btu agve an itnerface to move them around save or laod them in mind, after i suggested such an interface ages and ages ago before the forum got wiped.
And the lines in NTAI are a debugging artefact I havent gotten rid of. They're turned off by default in the next version and controlled by the .lines command. I'm sure I had a switch for it in 0.28.10 though try typing combinations of .lines and .mouse, I'm not sure which since I rewrote the switch code since then to make it off by default.
And I'm not saying I dont like these ideas, I just represent a middle ground, and see that if nobody says anythign the whole situation will turn itno the sort of thing that storm or others would pounce on in future as a prime example. I'd like to see GroupAI furthered, but within reason, if people post ever increasingly unfair proposals (a groupAI that buidls mexes in an area command -> a groupAI that builds cons and sends them fof to do mexes-> a basic economy AI -> a better economy AI -> a abse building AI and so on)
As for inheriting queues, i had a groupAI that simply held onto queues btu agve an itnerface to move them around save or laod them in mind, after i suggested such an interface ages and ages ago before the forum got wiped.
And the lines in NTAI are a debugging artefact I havent gotten rid of. They're turned off by default in the next version and controlled by the .lines command. I'm sure I had a switch for it in 0.28.10 though try typing combinations of .lines and .mouse, I'm not sure which since I rewrote the switch code since then to make it off by default.
And I'm not saying I dont like these ideas, I just represent a middle ground, and see that if nobody says anythign the whole situation will turn itno the sort of thing that storm or others would pounce on in future as a prime example. I'd like to see GroupAI furthered, but within reason, if people post ever increasingly unfair proposals (a groupAI that buidls mexes in an area command -> a groupAI that builds cons and sends them fof to do mexes-> a basic economy AI -> a better economy AI -> a abse building AI and so on)
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
The scripts used in the HL engine aren't possible in spring to my knowledge... They would do things like constantly spam jump commands so bunnyhopping was easier, or convert semiautomatic weapons to fully automatic weapons at thier full RoF. In extream situations people made them preform simple actions, but they were never extreamely useful for that kind of thing because scripts were unable to react to game data unlike humans, and would often screw up even basic commands when you had to go up a hill or something.
It's a little different in TAS though from what I understand... Theorectically you COULD have a group AI that could be loaded up on your comm and play out the whole game for you, could you not? not to mention group AI's for micromanaging groups, and the aformentioned place mex AI. It just kind of makes sense to me that some of group AI's current and theoretical capabilities are not things we want players to not have to do for themselfs. That's why I think there should be an option for game hosts to block it when needed. Many players probably won't care if the person they play against is using a group AI... but I think alot of the purists would.
It's a little different in TAS though from what I understand... Theorectically you COULD have a group AI that could be loaded up on your comm and play out the whole game for you, could you not? not to mention group AI's for micromanaging groups, and the aformentioned place mex AI. It just kind of makes sense to me that some of group AI's current and theoretical capabilities are not things we want players to not have to do for themselfs. That's why I think there should be an option for game hosts to block it when needed. Many players probably won't care if the person they play against is using a group AI... but I think alot of the purists would.
thats what i wanted to hear. "automatic" ais will suffer from this too in spring.SwiftSpear wrote:but they were never extreamely useful for that kind of thing because scripts were unable to react to game data unlike humans, and would often screw up even basic commands when you had to go up a hill or something.
The "economy build" ai is one of the worst suggestion here, imho.
if you dont know how to manage your economy, you dont know how to play the game. .. well.. half of the game, as the other half is attacking :)
"a groupAI that builds cons and sends them fof to do mexes", i dont need that as far i can do the area mex.
Why is the area mex a bad idea?
you still have to issue the order.. and mexing is not high level, you just spend more time on orders for that const. unit. and as usually happens, it gets killed!
so area mex is will not win the game, just save you some clicks.
that queue ai of you alantai, have you found uses for it?
I sure imagine the concept of saving queues, and asigning them later, but that can turn into a mess, as in Dark reign (didnt even know how to use their path interface really).
the transport thing is one of the most usefull things i have come with for that function.
e: and the lines in ntai are very cool, but not for your enemy to know! i bet it was intended for debuguing ntai and then were released as group ai.
the .mouse, .lines didnt work. I notticed ntai doesnt build RADAR! or llts, a must.
e2: are player ais able to use group ais?
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
All half life scripts ever did was save you some clicks. They still allow you to play the game just that slight bit less manually then every other player can. Many servers and compeditive organizations block scripts for just that reason.
If they are included in the game as a perminent feature they should either be easily produced by everyone with little learning curve and not too many ways to screw it up, or there should be the option of blocking them. Saving a few clicks assumes that you know the most efficient way to mex up an area in the first place, and that is probably one of the less exploitable uses for group AIs. I'll admit that I don't know perfectly the full capabilites of group AI's but I'm sure there are things you can do with them that would never even be considered as fully implimented features, as well as things that ligitimately do give you a massive advantage over other players. If they have similar capabilies as global AI's then there's nothing stopping me from queing up my normal starting build as full auto and then only spending 100% of my time managing and countering the initial rushes with zippers and weasles an what not, which any mediocore player will tell you will make a huge difference in the game if the defending player has to suspend thier macromanagement efforts in order to deal with attacker whizzing around.
[edit] LLTs are a must in AA, but most players won't touch them in XTA. They are basicly short range missle towers that can't attack air, the only upside is a slight bit more hitpoints.
If they are included in the game as a perminent feature they should either be easily produced by everyone with little learning curve and not too many ways to screw it up, or there should be the option of blocking them. Saving a few clicks assumes that you know the most efficient way to mex up an area in the first place, and that is probably one of the less exploitable uses for group AIs. I'll admit that I don't know perfectly the full capabilites of group AI's but I'm sure there are things you can do with them that would never even be considered as fully implimented features, as well as things that ligitimately do give you a massive advantage over other players. If they have similar capabilies as global AI's then there's nothing stopping me from queing up my normal starting build as full auto and then only spending 100% of my time managing and countering the initial rushes with zippers and weasles an what not, which any mediocore player will tell you will make a huge difference in the game if the defending player has to suspend thier macromanagement efforts in order to deal with attacker whizzing around.
[edit] LLTs are a must in AA, but most players won't touch them in XTA. They are basicly short range missle towers that can't attack air, the only upside is a slight bit more hitpoints.
The core build tree has a radar in the commanders build tree, and it has the adv radar towers in all the lvl 2 cons, it also has the mobile radar kbot in the lvl 2 kbot lab tree. The commander does build an llt but I found that it has quicker to build missile towers then jump to HLT's for economic purposes.the .mouse, .lines didnt work. I notticed ntai doesnt build RADAR! or llts, a must.
The whole thing is totally dynamic in the next version though so it isnt important anymore.
It seems I added .lines and .mouse toggles in a later version then, and yah the streaks where for debugging purposes, and funnily enough came after the groupAI.
So far I have the basic task structure for the queue system outlined in NTAI at the moment, but I need a decent interface to display these things and I dont want my experimental map GUI used to display masses of text.
I was thinking mroe voer you can see a list of commands the unti has, re-arrange them save and load default command queues to all untis of that type built, copy paste betwene untis different bits, maybe add other tidbits such as user enter this area it gets the followign commands shoved in its queue, such as a nogo zone with directions to go around etc.... That last bti is mroe skirmish AI orientated though and might nto be included at all.