Would anyone happen to know the implementation and use of the "Set Generic Command Target" script? Nekron and I have no ideas, but I haven't extensively tested it yet.

I think it was an early implementation of the "Order" action. You can use it in conjunction with "Make these units patrol" to do just that. It also works on units that normally cannot be ordered, like larva, interceptors, and (I believe) scarab. I'm not sure if there are any other scripts that use it.

So an example implementation would be to create a unit, run the generic target script over the destination, and run the patrol script over the created unit?

Yes.

A quick question - guard_all never drops the "defend these" tag on units that are owned by the AI when it's used, right? I forgot all about the part where it defends units and was surprised when the AI used defenseuse units to "defend" units that were attacking my base, which is really damn annoying.
EDIT: Or actually, are you supposed to use guard_all before all defenseuses and builds are called? This is the way Blizzard uses it in T8B, and I haven't seen the aforementioned issue happen there.

Post has been edited 1 time(s), last time on Jul 2 2017, 7:53 pm by Nekron.

Would anyone have any further insight into how default_min works with regards to organizing defense, and if it has any other impact? Further insight to randomseed would also be great.

AI attacking

(Whenever the following text says 'seconds', they are ingame seconds. An ingame second is 15 frames regardless of game speed.)

= Attack force =
`attack_add` adds units to the current attack force. In other words, `attack_add 64 zergling` will fill the attack force completely, and additional attack_add commands won't do anything.

While all unit ids can be used for `attack_add`, unit ids of Science Vessel, Queen, Defiler, and High Templar will only move to the grouping region (see below) and do not actually attack the target. (Thanks Nekron)

As was stated earlier, `easy_attack` functions as `attack_add`, but only if the semi-unused difficulty value is 0. In practice it never does anything.

`harass_factor` calculates the total strength of all enemy units (including buildings), and then multiplies the current attack force by `((enemy_strength - 1) / parameter) - 1` Division is rounded down, multiplication is limited to range from 1 (no change) to 3.

= Grouping phase =
If you've ever watched how the AI does its attacks, you've probably noticed that it sends the attack force somewhere near enemy base to group up before fully attacking. Both opcodes `attack_prepare` and `attack_do` initiate an attack, causing the attack force to group up at the grouping region. If the grouping has already begun, `attack_prepare` does nothing. `attack_do` waits until the grouping has finished and the units start attacking before progressing in the script.

`wait_finishattack` will wait until the both the grouping phase and the actual attack have finished, but it will not initiate an attack. If there is no attack going on at all, it does nothing.

This means that it is not necessary to use `attack_prepare` if the AI has nothing to do before `attack_do`. It is also fine to use just `attack_prepare` if halting the script for the grouping phase is not desired. `attack_clear` clears the attack force and aborts any attack that is still in grouping phase, so using `attack_do` to guarantee that the grouping phase has finished is a good idea before attack data is cleared. Also, even if the attack has been done, `attack_clear` is necessary before another attack can be started.

The grouping region chosen is randomly for campaign AIs, while melee AIs use "nearest safe region" out of the possible grouping regions AI has decided. The regions are same regions as ones used in pathfinding, the new SCMDraft versions are able to show how regions are laid out. AI prefers using a region which is roughly 4 regions away from a enemy base.

The AI may decide to do an air-only attack if for some unusual reason it fails to find a grouping region for ground units.

If the AI doesn't have a complete attack force during the grouping phase, it will train the necessary units with priority of 60. But because of the grouping deadline (see below for details) it is a good idea to train most of the units beforehand. Also, Nekron found a bug with attack force training: If the AI needs to train Guardians/Devourers/Lurkers for the attack force, it will train a Mutalisk/Hydralisk as well. Sometimes this intermediate unit will be used for the actually required unit, but if the AI has another Muta/Hydra available, it will morph that and the other unit will end up just hanging around in the attack force even if it wasn't invited there.

Using `attack_add` during the grouping phase should work fine.

= Grouping deadline =
The AI has a failsafe if grouping takes too long. After 120 (melee AI) or 180 (campaign AI) seconds, the grouping phase will end and the AI will send any unit that is part of the attack force to the enemy base, whether they had arrived at the grouping region or were still moving there. If the AI didn't get a chance to train all units on the attack force, then the attack will be done with a partial force.

The AI sometimes also just sucks at moving all the units to the (potentially small) grouping region, and will wait for the deadline even if the all units are roughly grouped properly.

`quick_attack` will initiate the attack and will not wait for it to commence, like `attack_prepare`, but it will also reduce 175 seconds from the grouping deadline, so the AI will skip the grouping phase. I believe that using `quick_attack` in melee scripts is unpredictable, because the AI may realize that deadline is hit before it has even sent any military to group. Using `attack_do` after `quick_attack` to wait is still a good idea to make sure you don't clear attack forces before the AI realizes the deadline has been hit and commences the attack.

The following should work fine in melee scripts as well, using `quick_attack` to separately trigger the deadline after a manual wait. This would also allow shortening the deadline to different values.
Extending the deadline is not possible, other than doing something sketchy like `attack_clear` followed by immediate attack force rebuilding and a new `attack_prepare`, though this will obviously duplicate the attack if it had already commenced. Additionally, the attack deadline is specified in "seconds from game start" - if `quick_attack` is used to reduce the deadline below zero (it wraps
around to 4 billion seconds), the AI will never hit it, which will hang the script if `attack_do` is also used and the AI fails at
grouping as usual.

= eval_harass =
`eval_harass` will initiate attack if it has not been yet (without waiting for grouping), and then it will calculate the strength of the own attack force and enemy units in 32-tile range around the target region. If either the ground or air strength of own units is larger than the respective enemy strength, the script will jump to the label specified as parameter.

`eval_harass` will cause the grouping and attack to commence as usual, but it also can be canceled with `attack_clear` if you just want to use it for control flow instead of causing attacks.

= rush =
`rush` will use the regular attack initiation routines to pick a target, and picks the enemy building nearest to target location to determine which player it is attacking. After that it executes `attack_clear`, so any actual attacks will get reset. If, for some reason, BW fails to find any enemy buildings, it skips the `attack_clear` and commences with the attack... But in the usual case where the enemy player is decided, the script will jump if the enemy player fulfills the following condition:
Credit to Heinermann for figuring these out.

= Expansion attacking (melee only) =

The opcodes `set_attacks` and `target_expansion` are used to send AI to attack an enemy expansion. The opcodes do nothing if the AI player has ran a campaign script. `target_expansion` sets a flag that allows expansion attacks to occur, and `set_attacks` sets amount of attacks the AI can do. After every attack the `target_expansion` flag is cleared and `set_attacks` count is decreased by one.

The attacks use the same attack force as regular attacks, so mixing them both will have conflicts. If the AI has enough units for the attack force, and the two commands have been used, it will attack the nearest enemy base location that is not set by a start location. I don't think the AI will train the missing units if not explicitly ordered otherwise. These attacks will not be performed if another attack is already in progress.

There is also not grouping phase for these attacks (Or rather, the deadline is 1 second), and while `set_attacks` can be reset to zero, the `target_expansion` will not get cleared if the attack doesn't occur.

Post has been edited 3 time(s), last time on Jul 23 2017, 12:32 am by Neiv.

Holy damn, this is a goldmine of info. Huge thanks, Neiv! I have some ideas that'd make good use of eval_harass and quick_attack, hopefully. Target_expansion also seems neat if I can make some AIs work without the campaign header.
As for your question about Science Vessels, Queens, etc attacking - Yeah, they go to the grouping region but don't actually attack with the rest of units, they just sit there and cast spells every now and then. This is notably unlike Medics and Arbiters who do move with the attack force. It's weird you don't mention Dark Archons, I'll test whether they move with the attacks and edit this post with info later.
Edit: Yes, they do

Post has been edited 1 time(s), last time on Jul 26 2017, 11:10 am by Nekron.

Ah cool, thanks for the info. Didn't see Dark Archons in the lsit of hardcoded spellcasters.


I believe guard_all just makes every region that the player has an unit in a "region to defend". Maybe there were AI forces close to your base when you used it?

default_min seems to set the base required strength for all regions the AI cares about (Usually it is just 0) Maybe you can use it to make AI automatically place units everywhere their bases go? It also only works for campaign AI.

I don't think set_randomseed does anything. It sets the one of the random seeds, but it is not the one that affects gameplay. Maybe it used to when blizzard was developing the game, and they used it to make the AI behave predictably to debug things.

What is the point to having `wait(500)` in the middle of `attack_prepare()` and `attack_do()`? Is there a point? Blizzard exclusively uses `wait(500)` in the scripts I've seen, which doesn't make any sense given the built-in delays of prepare and do.

Related question: what functions require waits after they're run to avoid crashes and/or lockups? I've found that `guard_all()` immediately after setting `default_min` with no waits involved will lead to crashes more often than not.

`default_min(X)` supposedly makes them defend all expansions (or all buildings if `guard_all()` is called) with X groups of defenseuse units, but I haven't extensively tested it.

So it's units as well as buildings, huh? I guess I'd better use `create_unit` if I want idle units to populate the map while also calling `guard_all()`. Thanks for the info. To clarify, "region to defend" is actually a region that is actively defended throughout the entire game, right? Or is it abandoned when the player runs out of units and structures in that area?

This leads me to my next (and final, promise) question. I have some example scripts below that run as area towns with no building lists. They have `place_guard` commands and manage attack waves but do not actively defend themselves. Once all structures in the town are destroyed, it seems the attack waves are cleared completely and never rebuilt. Does this make sense with what you know of AI logic? The script itself is still running and there are other factories available to produce the units required for the attack waves so it doesn't seem logical that the AI would cease production of those waves unless the scripts are abandoned when the towns they govern are destroyed. `clear_combatdata() isn't called until very late in map 5 and it's never called in any other map. If you need more info let me know.

Script 1 Script 2 Script 3

Yeah, there is no point if the script doesn't do something else inbetween. Maybe the attacking behaviour was different in beta/alpha, and there attack_do was necessary

Crashing seems odd, I don't really see any reason why that would happen.

Yeah, all units. If there are main buildings, the regions they are in additionally marked as "actively evaluate the need to defense". It seems that campaign AI abandons the region once it sees a enemy unit there and there are no workers/buildings in the region. Melee AI fights for it forever (??) The same should go to the "value area higher" script, it works similarly to guard_all.

I believe that scripts do always get wiped if their town gets destroyed. I know, doesn't seem really sensical, that would mean that the AI dies if the main town goes? Has anyone actually ever tried to wipe AI's main base completely and see if it can rebuild..? I really cannot see anything that would let scripts survive their town dying once they have created one.

---

Edit: `panic` seems to set a global "backup expansion script" that will be automatically expanded to if the AI is running out of resources.

Post has been edited 1 time(s), last time on Jul 21 2017, 12:50 am by Neiv.

Yeah, I couldn't find any reason for it to do that either. Nekron had a theory that all commands have an internal wait of 1 since they don't get executed simultaneously and the AI manually moves workers around one by one. Speaking of which, any way to resolve zerg AIs sending multiple drones to build the same structure in the same place (thus delaying it heavily), and workers in general getting stuck by the hub instead of actively mining the minerals/gas?

This is incredibly useful information. `value_area` negates the abandonment of key regions so they behave more like melee AI?

I will test this sooner or later but in the meantime I'll point Nekron to this question since he's probably able to test it faster/more thoroughly than I am.

Panic seemed to cause crashes in map 5 for the AI ally but it might have been pointed to an incorrect expansion block. Would it crash if it were referenced by `allies_watch` or `expand` blocks later in the script? By "global" do you mean it's used for all active scripts in the game, or just all scripts owned by the player its called for? If it's used by every AI in the game that could explain the crash but I can't imagine that's the real functionality of it. It's not melee-only, is it?

At least I can't come up with any clever tricks to circumvent that dumbness.

Yeah, if you have a trigger constantly calling the script (Or guess you could just loop a script). value_area is somewhat bad because it only sets the one region in center of the location to be "owned/defended". It also sets the default strength value to 200, overriding default_min.


Right, global for the one player across all towns. It does the same thing as expand, just automatically when the AI is running out of resources, it should not cause any more crashes than what expand does.

Would be interesting to see the crashlogs regarding these crashes.

Alongside `notowns` it wouldn't be impossible, just loop it until a trigger removes the structure. Good to know. Thanks!

You saw the crashlogs already, the one from `defaultmin` might have actually been from the guard structure corruption you mentioned in PM and to Voyager. Your response to the other one was that the AI had an incorrect expand block specified, IIRC.

I would be satisfied with this explanation since Slay can get really tight, but Orange in Z6 with vanilla scripts also does this I'm pretty sure, and his guard_all is called reasonably fast. I'll test it more over the coming days to see whether I'm wrong, last time this was a problem it definetly seemed like this happens though.

After problems with my own scripts, I'm really sure that omitting the wait 1's or adding them for no reason might result in random crashes late into the game. I have no idea what goes on behind the scenes obviously, but this just seems to be a pretty consistent cause of crashes, though I don't have any unedited script that crashed like this at hand currently. This is obviously based literally only on observation.


It does, if the bug that inclines it to always, no matter how many enemy units are there, rebuild town center occurs. I do not know how to reproduce the aforementioned bug, I think it never happens in vanilla scripts, happened in my P4 and Z8 before removing the town center from building list in expansions. I saw Teal in an UMS I was making rebuild from one worker to full base because of it once, I'm working on the UMS again now so hopefully I'll be able to have a vid of the bug. AI's will get changed a lot, though, since they were ancient, so I have no idea whether it'll persist.



This seems absurd considering def_min 1 can result in garrisons upwards of 30 supply

My question is, does default_min other than 0 in areatowns matter, or only in the main script? I have personally observed no behavioural changes after changing it from 0 in areatowns.

Edit: Another question, does eval_harass consider static defenses (sunkens etc) for it's calculations?

Post has been edited 2 time(s), last time on Jul 21 2017, 8:44 am by Nekron.

default_min sets a value global to the player, but the AI won't update the value for the regions it owns until the region's state changes. Maybe default_min 1 leads to large defense garrison just because the AI still has to send one unit to each region it owns to reach the (tiny) strength requirement of 1. The regions are quite small, there are lot of them in one base.

eval_harass includes the static defense as well.

Edit: Scaiedit miscompiles following opcodes, so they can't be used in it:
- region_size
- eval_harass
- do_morph
- prep_down
- if_dif
- easy_attack

Post has been edited 1 time(s), last time on Jul 21 2017, 10:24 am by Neiv.

This explains all problems I had with prep_down then I guess.

Edit: Nvm the second part, SCAI->PyAI now works like a charm lmao
Edit2: https://pastebin.com/raw/dbucHXTT seems to demonstrate the right structure for using eval_harass pretty well, no problems still and went pretty far into the script. The relevant parts start showing up from PB8E 0002 onwards. I still can't seem to understand how you should structure harass_factor attacks, though xD
Script probably feels really damn unfair to play against if you don't know what's up though, since attacks get pretty big really fast if eval_harass passes the check. I'll probably tone it down and leave it in, this feels pretty weird though as it's not really something I can communicate to the player, and it would be really hard to notice in game I figure. It's exactly what I wanted, but in the future I'll probably reserve it only to a few lategame attacks to make them deadly instead of just an annoyance.

Post has been edited 3 time(s), last time on Jul 21 2017, 10:55 pm by Nekron.

Does place_guard ignore define_max values? As seen in the image below, Tuzor's INC05 script decides to craft a flying circus when place_guard queen is enabled and seems to completely ignore the set define_max values. (I don't believe place_guard mutalisk was called in this version of the script, though I could be mistaken)



edit: it is possible the script went up to the define_max value instead of superseding it, but even so, why would it place all of the guards in one spot when place_guard was only called once?

Oh, did I not explain how harass_factor works? Oops.

`harass_factor` calculates the total strength of all enemy units (including buildings), and then multiplies the current attack force by `((enemy_strength - 1) / parameter) - 1` (Division is rounded down, multiplication is limited to range from 1 (no change) to 3).

So it can be used to make attacks scale with enemy strength.

Post has been edited 2 time(s), last time on Jul 23 2017, 12:30 am by Neiv.

Nah, I know what it does, I just had problems implementing it into the scripts. You didn't list it with the other miscompiled commands so it probably wasn't because SCAIEdit, but I'm just not sure where in an attack would you put it. Before attack_prepare, after _adds? Or after attack_prepare with a wait? I'm relatively sure I tried it both ways and had problems both times, but I'll try doing it in PyAI now that it's updated and see if it works.