SCAIEdit III list of commands

[ashara]

I have done some quick testing with killable/kill_thread commands.
New threads were created with multirun command

It seems that kill_thread does not necessary kill the current thread.
It kills all the threads that have reached a killable command before the execution of kill_thread.

A killed thread doesn't execute more commands but it finishes the current one :

Code: Select all

killable
build 10 overlord 80
wait_buildstart 10 overlord
build 30 overlord 80

For example, if this thread is killed by another one when it's hatching the 5th overlord, it will hatch overlords until having 10 of them and no more.


I haven't tried it with multiple training, different priorities or attacking commands.
My guess would be that when the thread is killed, every active command will be done until its end.

[poiuy_qwert]

Im pretty sure he meant something like:

multirun test
build 5 drone
kill_thread

:test
killable
build 10 overlord 80

So the kill_thread and 'build 10 overlord 80' execute at the same time, so the build finishes. I wonder what happens if you do:

multirun test
kill_thread

:test
killable
build 10 overlord 80

Will it kill it or not?

[poiuy_qwert]

Yeah, i wonder if they are even actually threaded, or if they are just fake threaded (executed one after another in order of when they were called). My guess for that code is it would build to the 4rth overlord and thats it (till an overlord is killed).

Edit: you changed the wait 2000's to wait_builds. Sneaky Now i just think it depends how long it takes to build the overlords

[ashara]

[quote name='poiuy_qwert' post='2412' date='Feb 10 2008, 07:07 PM']Im pretty sure he meant something like:

multirun test
build 5 drone
kill_thread

:test
killable
build 10 overlord 80

So the kill_thread and 'build 10 overlord 80' execute at the same time, so the build finishes.[/quote]

Yes that was it, I think my English still needs improving.

I have done some additionnal testing

Same time kill_thread/killable :
[spoiler]

Code: Select all

multirun test
wait 2000
kill_thread
stop

:test
wait 2000
killable
build 2 overlord 80
wait_build 2 overlord
build 3 overlord 80
wait_build 3 overlord
build 4 overlord 80
wait_build 4 overlord
build 5 overlord 80
wait_build 5 overlord
build 6 overlord 80
wait_build 6 overlord
build 7 overlord 80
stop

The test thread is not killed but it has the killable status -> 7 overlords training

Replacing the wait 2000 by a wait 1999 after the :test line leads to
Test thread is killed -> 2 overlords training[/spoiler]

Looping kill_thread :
[spoiler]

Code: Select all

; ASC3 File generated by ScAIEdit III
;
; Script name : Zerg Expansion Custom Level

script_name Zerg Expansion Custom Level
script_id ZMCx

start_town
transports_off
farms_notiming

:loop
multirun test
wait 2000
kill_thread
wait 3600
build 2 hatchery 80
goto loop

:test
killable
build 2 overlord 80
wait_build 2 overlord
build 3 overlord 80
wait_build 3 overlord
build 4 overlord 80
wait_build 4 overlord
build 5 overlord 80
wait_build 5 overlord
build 6 overlord 80
wait_build 6 overlord
build 7 overlord 80
stop

This produces strange results and I don't understand them . I supposed that after a few loops 7 will be built, but it was different against a Protoss AI and a Terran one.
Vs Protoss -> after 1st loop : 4 overlords, no more after
Vs Terran -> after 1st loop : 4 overlords, no more in 2nd and 3rd, but after 4th loop (at 12 minutes) : 7 overlords
Any help will be useful, here are the .exe and replays I used
[attachment=515:TestAI_killthread.zip][/spoiler]

Killing threads, multiple instructions
[spoiler]

Code: Select all

; ASC3 File generated by ScAIEdit III
;
; Script name : Zerg Expansion Custom Level

script_name Zerg Expansion Custom Level
script_id ZMCx

start_town
transports_off
farms_notiming

:main
build 2 overlord 80
wait_buildstart 2 overlord
build 8 drone 80
wait_buildstart 8 drone
wait_build 2 overlord
build 15 drone 80
wait_buildstart 15 drone
multirun test
wait 1500
kill_thread
stop


:test
killable
build 5 overlord 80
build 1 spawning_pool 80
build 1 extractor 80
build 1 hydralisk_den 80
build 1 lair 80
build 4 hatchery 80
build 1 queen_nest 80
tech burrowing 70
build 1 hive 60
build 1 ultralisk_cavern 45
upgrade 1 overlord_speed 80
train 4 zergling
train 1 ultralisk
attack_add 4 zergling
attack_add 1 ultralisk
attack_do
stop

This is an example of what happened when a thread is killed and still has many instructions to do.
It all worked : it build a hive, do the upgrades, even if not in the order they were written (starting by building the 4 hatcheries).
Until the train 4 zergling instruction where it only build 2 zerglings and do nothing more.

The train instruction seems to be blocking - like a wait - when kill_thread is executed.
For example, putting
train 4 zergling
just after
build 1 lair 80
stops the thread at that point (no new hatcheries are built).
Like a wait_build 1 lair would have done

Another thing I had during this test is that when the train 4 zergling instruction was not executed, it hatched 11 hydras.

I guess it's not related with kill_thread/killable commands. I had the same problem with Protoss AI where it trained dragoons without any dragoon reference in the script. I think it has to do with a misuse of train or attack_add commands. Have you had the same problem ?[/spoiler]

I hope all this was clear, just ask me if that's not the case.

[ashara]

1. a define_max draggon, hydra etc. not present.
2. script ends in a STOP. SCAIEdit says not to have your script end in a stop otherwise weird things like this will happen. I think they cite a constant training of marines as an example. This doesn't mean not to use Stop, it just means that the script should never just end. You should replace the stop in your main with some sort of loop as shown above.

Thanks for the answers, I had completely forgotten those 2 things


Your lag idea is such a lame thing to do

I just tried it with the Protoss AI with

Code: Select all

:test_run
wait 6
multirun test_run
multirun test_run
train 1 zealot
goto test_run

This script exponentially increases the number of threads. It didn't make the replay lagging.
The zerg wasn't able to run his multirun part. It just stays gathering minerals.
If the effects of multiplying threads are confirmed, that will be really funny.

It would be interesting to know the maximal number of threads. And also if the new ones clear the former ones or if the multirun simply doesn't work.


I don't think an AI should be allowed to use this trick to alter the working of another AI.

[Ahzz]

panic (block)
Appears to trigger (block) if attacked. Still unclear.

Useful for defending. instead of wasting units, sending them one by one, it'll gather an army and then attack with them to defend. Or whatever other block you wish to run. I believe this is the reason racine used it.

capt_expand
The use of this command is unknown. Takes no parameter.

blizzard used this on 7th brood war zerg mission so that the computers would take the expansions as quickly as possible. It's uses are minimal I guess

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.

heinermann experimented with those one a bit earlier. This is an alternative for using notowns_jump and so on, it makes the script code far more simple, especially if we're talking about replacing old tech and so on. Also, I believe that this one has a very high priority in building.

guard_all
The use of this command is unknown. Takes no parameters.

Used in several blizzard scripts. especially campaign. I guess it has something to do with not ignoring any sort of attack, as they sometimes do not react if you kill/do something very minor to them.

creep (byte)
appears to have to do with placement of towers and the distance seperating them. Ongoing study.

I experimented this one with heinermann before, 0 seemed to be as close as it got, 4 was to the edge of the creep they could POTENTIALLY have. So if you give them creep, its of no use. They will only use the area which their own creeps/hatcheries could cover. It would need experimenting, but I just got an incredible idea. For example, racine used creep 0 after every creep colony and so on, which, I believe, results in them being sort of close to each other, but they always seem to be a little bit separate from each other. maybe the creep 0, if used wrongly and in too many places, results to that, while if used right, it could potentially use sunken colonies placed very close to each other. The larger creep bumbers, such as 5-7 were a bit more complicated to arrange. At one point we had the feeling that it used the creep that wasnt even its own, but we are not sure about it.

default_min (byte)
The use of this command is unclear. Takes %1(byte) as parameter.
Racine used this command in our BWARAi War I.
see his scripts in this post for more details:
BWAi War I

defaultbuild_off
The use of this command is unknown. Takes no parameter.

blizzard campaign scripts use these. I experimented those scripts quite a bit at that time, and I came to two conclusions, of which one is uncertain. The uncertain one: they will build farms beforehand, and the pretty much certain one is that it will replace any buildings it has lost. For example, if there was a "build 4 gateway 80" or "build 1 templar_archives 80", normal melee scripts might have trouble replacing these buildings, but with this, they rebuild them almost instantly. Perhaps the default_min was used for exactly this purpose in racines script

max_force (word)
Takes %1(word) as parameter. Appears in Campaign "town scripts".

I believe this might be something so that the computers wouldnt end up building too massive an army after they're for example attacked several times and built units for defense. weaker scripts seemed to have a 'smaller force'

[Symmetry]

[quote name='Ahzz' post='2719' date='Feb 21 2008, 08:30 PM']At one point we had the feeling that it used the creep that wasnt even its own, but we are not sure about it.[/quote]

When I did my testing on the matter (a few posts up) the AI used bajadulce's creep (in his replay, of course...).