SCAIEdit III list of commands

[DiscipleOfAdun]

train, do_morph, and wait_force use the same code, but it has cases for each different opcode. all take the same parameter count...

[lifestyl3]

[quote name='Heinermann' post='1284' date='Jul 24 2007, 04:25 PM']Debug is "UNSUPPORTED" because SCAIEdit III can't handle strings. I'm assuming they are a pointer to a null terminated string.

ALso, need more info on player_need and creep.[/quote]
It's actually just the debug opcode followed by a null terminating string. There is no pointer involved.

[lifestyl3]

From the command descriptions:

player_need (byte) (building)
Takes %1(byte) and %2(building) as parameters.
appears to work similar to build. Appears mostly in Blizzard's expansion loops.

We could probably update this using the information from dreadkillz post:
[quote name='Dreadkillz' post='910' date='Jun 14 2007, 06:04 AM']OK I figured out player_need. If you have a building, then player_need will check if you have it. If not, it will rebuild it.

EXAMPLE: I have 1 spawning pool at my main. I use "player_need 1 spawning_pool" at my expo. My spawning pool is destroyed, the AI will rebuild the pool at the expo. If I still have the pool at my main, then the script will ignore player_need.[/quote]
It seems that player_need works exactly the same as build except on a global scale. Basically, if you say 'build 1 spawning_pool' in a block of expansion code, the ai will build spawning pools at the expansion until it controls one there. If you say 'player_need 1 spawning_pool' in a block of expansion code then the ai will build spawning pools until it commands one globally. If there is already a pool in the main, the ai will not build a second in the expansion when player_need is used instead of build. This is used by blizzard scripts to allow the ai to build critical tech buildings at expansions when the main is destroyed.

Has anyone else verified this or found something contradictory to this?

[Scourge_Splitter]

[quote name='lifestyl3' post='1748' date='Nov 12 2007, 08:26 PM']From the command descriptions:

We could probably update this using the information from dreadkillz post:

It seems that player_need works exactly the same as build except on a global scale. Basically, if you say 'build 1 spawning_pool' in a block of expansion code, the ai will build spawning pools at the expansion until it controls one there. If you say 'player_need 1 spawning_pool' in a block of expansion code then the ai will build spawning pools until it commands one globally. If there is already a pool in the main, the ai will not build a second in the expansion when player_need is used instead of build. This is used by blizzard scripts to allow the ai to build critical tech buildings at expansions when the main is destroyed.

Has anyone else verified this or found something contradictory to this?[/quote]

I have actually got to the same conclusion however when I try to use it I'm not really sure weither it halts the expansion script or that it skips it automatically.

[Scourge_Splitter]

You guys know what I'm recently came to think about??

The Multirun block# and Call block# commands have more or less thesame working activating another sequence of codes starting from the specified block.
However, what exactly is the difference between the two of them...

[lifestyl3]

From what I understand call is basically just used to improve code organization. It does not create another thread as multirun does. Call simply redirects execution to the desired block and then continues execution at the original location once a return is reached. I'm not sure how much sense that made, so here is an example:

The following two examples will execute in exactly the same way if I understand the call function correctly.

Code: Select all

command1
call subroutine //redirects execution to subroutine
command3 //execution resumes here once subroutine is finished

:subroutine
command2
return //subroutine is finished

Code: Select all

command1
command2
command3

Multirun is similar to call in that it redirects execution, however, multirun continues execution of the current thread while the second executes. It essentially forks the ai into two separate threads.

Consider the following:

Code: Select all

command1
call subroutine
:loop
command3
goto loop

:subroutine
command2
return

Code: Select all

command1
multirun thread2
:thread1
command3
goto thread1

:thread2
command2
goto thread2

The first example uses call and simply executes the commands in numeric order and execute the last command over and over. The second example uses a mulitrun with similar syntax, but it produces very different results. It executes command1 and then executes command2 and command3 over and over. I'm not really sure if that made sense, so here are some crude diagrams of the script execution:

Using Call:

Code: Select all

command 1
command 2
:loop
command3
goto loop

Using Mulitrun:

Code: Select all

         command 1
            |
         -------
         |      |
   :thread1     :thread2
   command3      command2
goto thread1      goto thread2

I hope that clears it up

[Scourge_Splitter]

Yeah when I was nosing around somewhat in the "Terran Custom Level" I noticed the call command as well being used for making some troops being built for defense. I got the same impression from that what the difference is yes.

But thanks anyways, It may serve good use for those who don,t know it yet

[Heinermann]

0x64 quick_attack takes no parameters and is attack_prepare and attack_do buffed into one command(assuming).
0x45 player_need calls the AI building construct function(so works only for buildings?).


The following commands take no parameters:
0x36 default_build (Modifies AI behaviour flag to 0xFB)
0x23 defaultbuild_off (Modifies AI behaviour flag to 0x04)
0x4D target_expansion
0x5B implode
0x11 build_bunkers
0x34 build_turrets
0x28 fatal_error
0x12 wait_bunkers
0x35 wait_turrets
0x47 wait_upgrades
0x0F wait_secure

Additionally, multirun calls the Run AI Script function, making no distinguishment between two completely different scripts. (Ex: triggers using Run AI Script two times is the same as using multirun)

Confirmed the scout_with command is unused, but still takes a short as a parameter.

0x53 prep_down takes %1 (byte) %2 (byte) %3 (short) and calls the same function used in attack_add
0x5F if_dif takes %1 (byte) %2 (byte) %3 (short)
0x60 easy_attack takes %1 (byte) and %2(short) and calls the same function used in attack_add
0x70 try_townpoint uses the same function as one of the expand commands
0x42 eval_harass takes %1(short)

[Symmetry]

I took a look at the Creep command myself, because I was interested in seeing what it did

Any integer other than 4 (I've tested 0-3, 5-7, 255 and no creep command at all) makes the (zerg) AI build their creep colonies (whether they're to be sunkens or spores) at the farthest edge of the creep closest to the choke point. When they get to the choke point they seem to stop moving outwards and simply build more.

The integer 4, however, makes the AI create their creep colonies spread out, covering the most area possible with creep (in the main, I haven't tested this in expansions or anything). I have no idea if this affects other races yet.