Renegade Projects Network Forums
some AI work - Printable Version

+- Renegade Projects Network Forums (https://forums.renegadeprojects.com)
+-- Forum: Modding (https://forums.renegadeprojects.com/forumdisplay.php?fid=3)
+--- Forum: Red Alert 2 & Yuri's Revenge Editing (https://forums.renegadeprojects.com/forumdisplay.php?fid=8)
+--- Thread: some AI work (/showthread.php?tid=846)



some AI work - matt7785 - 20.07.2007

I've been doing some stuff with the Yuri AI, working mostly on special attack type stuff like repairing multiple bridges, using alternate attack routes, and making invasion forces with multiple transports grouped together. I've got the multiple bridge repair stuff working decently, but it's not perfect yet because I'm still figuring out how to force it to take certain routes / go to certain bridges. One of the main things I still need to figure out is exactly what logic is attached to the different numbers that can be added to the buildings list (0,65534,131072,196608). There definetly is some logic attached to them and I think I understand some of it, but not all of it is clear yet. I tested this stuff out on the Bering Straight map against one soviet AI with either me in the bottom left corner and them in the top right corner or the other way around.

The TaskForce I used was

1 Soviet Engineer (SENGINEER)
1 Flak Track (HTK)

and the Script I used was

14,0 - Load Transport
47,30+(0,65534,131072,196608) - Move to enemy Bridge Repair Hut
8,2 - Unload and lose transport
46,30+(0,65534,131072,196608) - Attack enemy Bridge Repair Hut

Using the different building offsets in this script causes 4 different results and so far these are my best guesses as to what each offset number does

+0 (no offset) ?= goes to the building that is closest to the top of the map and reachable

+65534 ?= doesn't go anywhere even if all buildings are reachable

+131072 ?= goes to the building that the team is currently closest to

+196608 ?= goes to the second reachable building within a certian min/max distance range, also must be enemy to attack

These results could be off some from what the numbers actually mean, but this is my best guess using these test conditions. The one I'm most certain about is 131072, the others seem less predictable. I'm thinking they have something to do with distance, or possibly threats / enemy ownership.

The other big thing I've been working on is trying to get a group of more than one loaded transport to attack at the same time. I've managed to get 2 transports to load and get into one team using "shell" teams and some Change Team(18,n) trickery, but once they're together the first transport that loaded starts acting screwy like its being dragged around and always ends up getting stuck. I'm thinking its getting hung up on the Load Transport(14,0) command when the second group is loading, and doesn't recover after that. I've been testing this stuff using Soviet Heavy Tanks and Armored Transports and these are the steps I've been taking -

Step 1: Create the first team with 4 tanks and the transport and load them up - the taskforce is just 4 tanks and the transport, the script just tells them to Load Transport(14,0) then it has them join/create the second team with Change Team(18,n)

Step 2: Force Create the second team that contains all the units and load the next 4 tanks - this is done by the Change Team(18,n) command from the first team/script. From what I can tell when members of a team's taskforce have been put into that team then the rest of the missing members are created and the script is run. The taskforce of the second team is just 2 transports and 4 tanks, this is because it seems to consider the joined transport as empty, so it then creates 1 transport and 4 tanks, but since the first transport is full the 4 tanks load into the second transport. Theres no problems getting the 4 tanks in the second transport, but its about this time that the first transport starts acting weird. After both transports are loaded I either have them join a third team that has a taskforce of just 2 transports and a script of Gather at the enemy base, or I just put that script stuff after the rest of the second script. Either way the result is that the second transport that loaded acts fine, but the first one floats around weird and gets stuck somewhere. I thought using the third team and setting Full=yes in the TeamType properties would help, but it doesn't work when the third TaskForce is just 2 transports or the 2 transports and the 8 tanks.

(note - using the Change Team command seems to be able to override the Max=n value in the TeamType properties)

I've also tried a different way of getting 2 loaded transports to work together by loading the first one, having it Gather, then using the Guard Area command as a "Wait" command for the time I give it, then move to the destination and Unload. The second transport loads then Gathers at the same place, then has the Follow Friendly command to follow the first transport to the destination, then the Unload command. This almost works and both transports Gather at the same place, but the since the first transport is still sitting there in Guard Area for a little while the second transport just pauses for a second for its Follow Friendly command, then moves onto its Unload command. I'm thinking I can get this method to work somehow by switching around some of the commands in one team to the other or something, or by using some Change Team voodoo somewhere.

Theres some other crazy ideas i've thought about messing with, but they'd required hacking up the rules file and once I start doing that I'm sure I'll get tempted by a lot more bad ideas. One of the ideas is making units transform into other "twin" units that are used for special purposes by the AI, either by deploying into an intermediary structure that undeploys into the second unit, or possibly by using some of the genetic mutator stuff. I'm not sure if its possible to get the AI to undeploy structures yet. The other idea was to try to add in some AND logic for the triggers to require multiple combined conditions to set off a trigger. I think it might be possible by "linking" some triggers and using some invisible dummy units and the right TeamType properties, specifically ones dealing with recruitability/recruiter and some Change Team commands, but i'm thinking you'd need an exponential number of dummy units for each additional condition, and some way to kill off the dummy units individually. Right now it just seems a little too dirty.

Right now I'm just trying to figure some stuff out about some of the Script commands and TeamType properties like -

Scout(48,0) - does it actually work at all ? and if so how ? I think i've got it to move units different directions occasionally, but it seems to be very unreliable and most of the time they don't go anywhere.

Move to enemy(47,n) / Move to friendly(58,n) - how do each of them handle neutral buildings, or what if you tell it to Move to enemy but give it a friendly building, or the other way around.

Prebuild= - does it actually work ?

UseTransportOrigin= - how exactly does it work? the guide doesn't seem to cover everything about it

LooseRecruit / AreTeamMembersRecruitable - are they different and if so how ? I'm thinking LooseRecruit causes the TeamType to be dissolved automatically when the Script is done and AreTeamMembersRecruitable waits until they are actually recruited to dissolve the TeamType.

Lastly, how does the AI handle the units it starts with ? They seem to be recruited for TeamTypes that have recruiter=no so I'm thinking they might be handled in a special way.


RE: some AI work - Dracaveli - 20.07.2007

+131072 ?= goes to the building that the team is currently closest to

yes this is true, I posted about this a while back

about your two transport Idea, looks promising, but I pretty much gave up on the Idea, I just use delay teams, create one task..send it a friendly power plant, guard area for 200 sec's or so...blah blah..Sleeping, but if you're able to get it done then Not worthy, try increasing max=2 on one of the teams or increasing DissolveUnfilledTeamDelay= in rules(md)

I also wondered how the AI manages to group it's starting units in a certain area..I notice on deezire's guide there are still several "???" concerning AI's [group=] command


RE: some AI work - DCoder - 20.07.2007

Hi, matt... I seem to remember your AI tests back at DZ, trying to figure out the long string of zeroes. Still, this is very interesting stuff you have here.


RE: some AI work - matt7785 - 20.07.2007

Dracaveli - could you give a link to the post where you wrote about that building offset ? Yeah, I don't want to use that delay thing because you have to time it out just right and do it individually for all of them, and it can easily go wrong depending on the distances involved. I'm not sure how changing the max= value or DissolveUnfilledTeamDelay= would help because it only needed one of each TeamType I was using, and the teams definetly weren't being dissolved before they had any units, because the later ones were created by units joining them. Also I thought DissolveUnfilledTeamDelay= was the maximum time it could take until the first unit was in a team, not for the team being totally created ? Like I thought it was used when several teams were queued for creation and if it didn't get a unit into one of them in the set time limit then that TeamType was removed from the queue ? Also has anybody messed with the tag in rules that is like "FillEarliestTeamFirstProbability=" ? Its default is 100, so it always fills the earliest team first, I'm wondering if it was changed how would it decide which team to fill first ? I'm hoping it would use the team's Priority= tag or some other logic that's easy to get at. Also how would the percentage work ? My guess is that it uses the given percent for how often it fills the earliest team first, and the rest of the time it uses its other build order logic.

DCoder - Yeah, that was me, I don't think I got anything to work by changing those, but I might try a few other things. My original guess was that they were used for multiple conditions for the trigger, but when messing with them I realized theres only one field for the name of the object that sets the trigger off, I tried putting different brackets around more than one object name and forcing an array in there, but it wasn't working out. They might be for setting ranges on the trigger parameters with the same object type, like more than 3 power plants AND less than 7 power plants, I need to look at some stuff and try to test this. Hopefully I don't get distracted before then, I always work on this modding stuff for like a week or so then go off and do other things for several months and come back to it.

I'm still fascinated by Deezire's Deevious AI and am working through it to figure out how some of the stuff works. I'm pretty sure there's some stuff in there thats not explained in the guide. One thing I ran across while looking through the scripts is it looks like those building offset numbers are used in a deliberate way, like multiple scripts where the only difference is the offset added to the building number, and a bridge fix/destroy script that has the command to move to / attack the bridge repair hut for each of the different offsets. Also there's a lot of stuff in there for transport teams, I'm thinking the triggers for them might be set at low default probabilities, but then when all land access routes are blocked it knows to skip ground forces and only use teams that have the right MovementZone= tags on some of the units, possibly by making use of the "OnTransportOnly" tag or whatever it is in the TeamType properties.

Also there's a hell of a lot of Scout(48,0) commands in the scripts in that AI, so I'm thinking it must work to a degree. I'm guessing the guide is wrong where it says it moves in a random direction, I'm thinking it tries to move to a random location and if it picks a spot that's inaccessable it doesn't go anywhere. I'm going to try to isolate some of the interesting looking scripts in there and pull out the corresponding Triggers, Teams, and Taskforces and test them on there own to see how some of the stuff works. I looked through it earlier to see if there were any Change Team or Change Script commands, but there weren't. I did notice that many scripts with transports used the same first 5 commands. I got an idea from that - If it was different and you had several scripts where the last several commands were the same, or you just wanted to give some teams a default backup mission then you could just write a general attack script or whatever, then add a Change Script action to the end of their specialized or primary script that jumps to the common or backup script.

Well, I've got a good amount to work on, I'll try to get back soon with some results.

p.s. DCoder - is there a way I could get an older version of the AI Editor ? I have the one from your site V2 (.68) and it doesn't list all the TeamType properties in a way I can see them, and it doesn't have the selectable script actions. I used to have a version that had all that stuff working, but it got deleted. Right now I'm having to go back into my AI file with notepad to change a bunch of the TeamType properties.


RE: some AI work - DCoder - 20.07.2007

Er, I'm sure I didn't change anything like that in the last version... The most recent pre-0.68 versions I still have are 0.65 and 0.55, and I'm sure they have problems that were fixed in 0.68. I could upload them, but I can't guarantee they would work correctly. After looking at the interface, I see that the teamtype properties were moved around between versions, but the selectable script actions should all behave the same (the dropdowns depend on the params.ini being present in the same directory).


I did it! I got (some) teams with multiple transports to work right - matt7785 - 22.07.2007

Well, I got teams of multiple loaded transports to work right, but so far only if they are carrying infantry. It was from the first method I wrote about, using "shell" teams and the Change Team command. It works just like how I wrote it, but using infantry instead of tanks. I also think I got it to work once using terror drones as the passengers, but I'm not sure about that. I need to figure out what's different between infantry and vehicles that's causing the vehicle loaded transports to freak out when grouped, but allowing the infantry loaded ones to work fine. I've tested it with allied and soviet hovercraft, flak tracks, ifvs, blackhawk transport choppers and battle fortresses, all of them have worked perfect except for the blackhawks occasionally trying to land on top of each other or getting distracted from their mission, but the landings can be fixed with a Scatter command and I'm sure the attention to mission can be fixed through TeamType properties. I tested it up to 3 loaded transports with both the blackhawks and battle fortresses and it all still worked fine, so I think you can group as many as you want through this method. I've also been able to load a flak track that was loaded with engineers onto a hovercraft using this, but when it does the Unload(8,n) command it unloads both at the same time, so it won't work perfect for everything without some tweaking.

The Change Team command seems to have a lot of potential, and a lot of unique features that let you do some really cool stuff. I'm still figuring out exactly how it works, like how the teams and their properties are managed when you use it. Some things I've noticed, but not totally confirmed yet are

- Units that have been changed from one team to another seem to keep some or all of their original TeamType properties. I saw this using the blackhawks, where the final team that they were in had "Transports Return To Origin" on, and the first team of the group had "LooseRecruit" on, and only the last two of the transports returned to base after unloading.

- AI units that are in transports are considered to no longer exist by the AI

- When given a Change Team command the original team is considered gone, thereby removing it from the count of it's Max=n property. This presents some problems when making the triggers for the first team in a chain, because it will always change out of that team, causing it to never max out, which causes a team creation loop that jams up production with it constantly recreating the first team. This might not be a problem when there's other triggers going off, or by messing with the teams Priority= tag, but for now I've just gotten around it by basing the trigger off of the number of transports, so it only fires when there's less than one transport, and the first team stops that condition when it's created.

Some ideas that could probably be done using Change Team

- "Transports on Request": by placing a Change Team command at the end of a script you could probably get a team to use it and the transport only if it was unable to complete some of the commands before it. An example would be a script to move to and attack something in an enemy base, usually ending in either destruction of the team or the base, but if the base was unreachable it would skip those lines and Change Teams, with it's new script either having a new mission, or the same one with a transport added to the TaskForce and transport commands in the script. This could possibly be looped/shelled to handle more units than could fit into one transport. Getting the joined transports to work with vehicles would really work good with this.

- "Conditional Reinforcements": by having a team "re-join" itself after a mission it would cause the missing units to be replaced and veteran units to remain active. This would be different than the regular "Annoyance=" or "Whiner=" properties because some members of the team would have to survive up to the Change Team command for the team to be rebuilt.

- "Special Missions for Veterans": this would cause remaining units of a team to go on a different mission after they finished their first script. You would probably do this after a mission where they are expected to get a lot of easy kills or do a lot of high value damage, by just putting a Change Team or maybe Change Script command at the end of their first script. Change Team would be used if you wanted to add some units to the group, or maybe change some properties, and maybe cause the original team to be replaced. Change Script would just work for the units you have, and would not cause as much chance of a replacement team being formed. One idea for this is to put units in Guard Area for a while to guard the base and increase veterancy, then after that time limit is up they'd go on a new mission.

- "Dummy Teams to Change TeamType Properties": These would just be teams with certain properties and a script, but no TaskForce, so no new units are created.

- "Various Rushes and Chrono / Iron Curtain Attacks": By combining a group of loaded transports you can have a fast moving and protected invasion force, and by using the Regroup/Gather command I'm pretty sure you could Chronoshift or Iron Curtain up to 4 loaded hovercraft, which could carry 48 troops into the middle of a base safely. The Chronoshift attack would be especially effective if the base only had perimeter defenses, but making a trigger based on that might be difficult. Another special attack could be a group of loaded blackhawk transport choppers that flew in fast when the power was low or some type of air defense was under a certain quantity. This would probably work best with "AvoidThreats=yes" and having it be pre-built somehow.

I still need to figure out if teams can have empty TaskForces and still be used for their properties and scripts, and figure out what happens when units join a team where they aren't a part of the TaskForce. I'm hoping they just join the team and all the new units are created and there's no problems, because that would work great with the "requestable transports" idea.

Some other stuff I've been working on is getting a better understanding of some of the AI tags in the rules file. Most of these were lightly tested by changing them around some and doing a "harder or easier" test against Deezire's Deevious AI file.

The simplest ones to change to make the AI more effective were:

"BaseBias=" - Changing this from the default '2' up to '50' was highly effective at improving the response to threats against the AI's base

"BaseDefenseDelay=" - Reducing this to '0' seems to help response time

Two that caused some interesting results were by increasing "AutocreateTime=" and decreasing "FillEarliestTeamProbability=". I'm thinking that if the AI has plenty of triggers, and they're setup to handle most of the conditions of the battle, then actually increasing the delay time between autocreated teams could improve the general AI response by not jamming up production with as many autocreated teams. I haven't yet totally figured out "FillEarliestTeamProbability=", but I am thinking by lowering it from '100' that the "Priority=" tag for the TeamType, or some other logic is used to help determine unit production order rather than a simple queue. I think when I lowered it that the AI stuck to teams that were more likely to be effective, but reduced it's variety of attacks some, but more testing needs to be done. I might need to comment back out the AIGenerals stuff in case it's overriding any of the changes I'm testing. Also when lowering "TeamDelays=" it seemed to help to raise "AutocreateTime" so the AI didn't go mad trying to build 1000 different teams in 5 minutes.

The other tags I'm still trying to figure out are:

"AITriggerTrackRecordCoefficient=" - It's used with the trigger weighting delta stuff, and the guide says something like its for how many previous triggers to keep track of, but it's default is '1' so that doesn't make much sense. Possibly it's for how many previous entry's of each particular trigger to keep track of, but that still doesn't seem right. Changing it seemed to have some effect, but I'm not sure.

"ComputerBaseDefenseResponse=" It's supposed to be for how much the AI "over-responds" to attacks on its base, but "BaseBias=" seems to be much more effective.

"UseMinDefenseRule=" I didn't mess with this, other than leaving it at 'no' like the rulesmd file with Deevious AI has it, but I don't know what all changes it controls.

"AIForcePredictionFudge=" It says it "fudges" the evaluation of your units by this percent to decide the ratio of what kinds of base defenses to build. Does it do this at the start of the game, or continuously throughout ? And what percent seems to work best ?

"AttackDelay=" Is this the delay for any first attack against you, or just the delay for the first Autocreate team being created ?

Well, I searched the Deevious AI file for any "OnTransOnly" tags set to yes in TeamType properties and there weren't any, so I guess that rules out my theory about it using those teams as back ups when land routes are blocked. I think I'll still test that concept myself though. I think using some of the stuff from the Deevious AI as a sort of base and modifying and building from there could make a pretty effective AI pretty quickly, but a lot of my ideas require changing the overall organization and game plan of the AI, so I'm just using it for tests and playing against and to get some ideas. Also there was another modified AI file that I used to have and thought was pretty good, so I'll try to find that again too.

Well, I'm off to try to get those damn hovercraft to work together when loaded with vehicles.


DCoder - Yeah, I think maybe I used to have version 0.65 or version 0.667 that was listed at http://www.cannis.net/forum/index.php?showtopic=3819 . I'm not real sure, It was like 2 years ago that I first downloaded it. I don't know why the selectable scripts aren't working then, I'm almost sure that params.ini file is in there. I'd still take a copy of version 0.65 or 0.667 if you have it, to see if the teamtype properties work better for me. I'm thinking they aren't all showing up because my screen resolution is lower than before, or I used to be using win98 and have winxp now. Also the "jump-to" links with the "used-by" things don't seem to work right. Eh, it'll be nice if I can get it working better, but I'm doing ok for now, and have most of the script #'s memorized.


RE: I did it! I got (some) teams with multiple transports to work right - Dracaveli - 22.07.2007

Not worthy


"Usemindefenserule=" is exactly what it says....when this is set to true or yes, you force the AI to have a min defense value...it refuses to build any offensive units until it meets it's minimal defense requirment...this is the main reason for soviets not building when novice modders first start editing their rules.ini file....because the soviets have only 1 checked "Isbasedefense" in the AI.ini file...the allies have several...


by increasing the mindefense value to 2 the soviets would never build offensive AI teams (factory AI) because they are still seeking another base defense team to meet their minimal standard set by you...when you state usemindefenserule=true


results + more ideas - matt7785 - 23.07.2007

Well, I've tested a few of those ideas, and gotten some of them to work.

"Transports on Request" - This idea worked out, but only under certain conditions. First, you can't have a specific Attack (building number)(46,n) command before the Change Team command, because it will get hung up on it, like it has an inherent Repeat Until Success(49,0) command built in, but by just using a Move to Building (47,n) and general Attack command (0,n), then a Change Team(18,n) command, you can get it to join a team with a transport only if it can't get to where it's going. This helps the AI by not using transports if they aren't needed.

Another thing I learned from testing this is that members of one team can only join another team if they are listed in the second teams TaskForce. This makes it slightly more complicated to have requestable transports, but it also allows the possibility of "probe" teams and better control of the AI's unit production flow.

"Probe Teams" - These are AI teams that are used to probe your defenses, and cause different results depending on which units survive. This is a much more functional way of testing for defenses than using Triggers, because this method tests if the AI's units can survive a light entry into your base, instead of just testing for a specific TechType of defense. A simple example of this would be to just have a tank move to your con yard, then move back to the AI's con yard, then have a Change Team command. If the tank was destroyed it would signal that you had decent defenses and no further attacks of that type would be linked to, but if it survived it would get to the Change Team command, which would cause the creation of a larger force that would go back for more damage. This technique can also be used with more than one unit / type of unit, to test the level of your defenses. This would be done by using the same move to / move back approach, but then having a list of multiple Change Team commands at the end of the script. The Change Team commands would be ordered in a way to determine if the weaker units survived, or if it was only the stronger units. This would then cause different responses depending on which units survived you're defenses. This idea might need special purpose "clone" units to work best, but I'm not sure.

"Clone units" - To help control more of the AI's unit's behaviour than can be done with TeamType properties, special "clone" units for the AI only can be created in the rules file, with slightly different characteristics. Some uses for these are:

- Use them to control production quantities by setting a BuildLimit= on the unit itself, instead of just the Max=n tag in TeamType properties. The best example of these would be with the multiple transport "shell" teams that normally cause a production loop when they change out of the first team that creates the next teams. This way the first transport still exists, and has reached it's BuildLimit, so no more of those teams will be triggered for creation. This allows you to use regular conditions on the triggers for multiple transports, instead of having to use unstable conditions to trigger them, or basing them on the transport units in the teams. I'm thinking the BuildLimit= tag could also help with the "probe" teams, but I need to figure out how that would work.

- For base defense teams make clone units with increased Sight= and GuardRange= values, and set the ToProtect= tag to yes. These could be used to help the AI defend against forces that are gathering outside their base, and be more responsive to attacks on its base defense units. With the regular AI you're allowed to get too close to their base before they start fighting back because they don't realize you're there, this would help correct that.

It would help if I knew how to make units transform from one unit to another, so they could transform back and forth between regular or clone units when needed. Also, can somebody tell me how to make a unit where only the AI can build it ? And can you actually make clone units that display the same name in the game, because I would prefer if the special units weren't detectable ?

Right now I'm looking through the rules file and guides to see what properties would be good to change for mission specific units. I don't want to make any changes that affect the power of the units or balance of the game, just the behaviour of the units in an AI sense. If I'm going to write a full AI I'll need to have a good overall planning structure, with the right trigger weighting probabilities, TeamType Priority= numbers, general rulesmd tags, "linked" triggers, and "shell" teams, but right now I'm just focusing on getting the different special missions and attacks to work, before I put them all together.

DCoder - It was just my screen resolution that was making the editor not work right, when I turned it up it worked fine, but my moniter is too far away to use like that, so I'm just going to deal with it and re-edit the files in notepad.