Iskatumesk's StarCraft Editing Bible - Part 2

Back to Part 1

---


Overview

I've decided that once BK's new tool is out and I have some aircraft to fiddle with in max, I'm going to make another chapter based on the following.

In segments I will explain how to do the following, from start to finish.


I will create an aircraft that has randomized idle, movement, and attack animations. The aircraft will have a red alert state (weapons drawn during combat but concealed in flight). The aircraft will have engines, afterburners that light up in high-speed flight, and contrails that are active when the afterburners are on. The aircraft will also have a Fuel Air Explosion ability that fills a load of airspace with slowly-burning material lethal to other aircraft.

The Aircraft's missiles, engines, and FAE ability will all have heat distortion effects. I will explain how to do these as well.

Yes, this aircraft will be part of a mod.

Although this is not usually how I arrange my work I will do so for ease of explaination. The chapter will be arranged like this:

Segment 1 - The KA-NF42g Black Eagle AMAC

This chapter will explain how to enable a basic fighter craft that will replace the Terran Battlecruiser. In this chapter I will add the most basic animation of the fighter, remove the battlecruiser's existing engines, modify the speed, acceleration, and enable it's new weapons and attack sequencing.

Segment 2 - The Eagle's Wings

In this chapter I will convert and enable the Black Eagle's new engines, including their custom color palette, heat effects, and afterburner system. Since I can't have the afterburners as an ability, I'll show you how to simulate an afterburner effect when the aircraft (presumably) reaches a certain point in acceleration. I will also enable the contrails (frozen air trails generated on the wing tips during high speed).

Segment 3 - The Eagle's Talons

In this chapter I will enable the Black Eagle's autocannon and firefly stinger weapons. I will have a ranged check that has only the missiles fire at longer-distance targets, and both weapons fire at short ranged targets. I will convert a weapon slot into the aircraft's autocannon and another slot into the napalm-based firefly stingers. I will also construct the FAE spell for the aircraft and have it replaced the Yamato Cannon. I will do heat effects for all of these.

Segment 4 - The Eagle Has Landed

In this chapter I will enable all randomized animations and randomize the attack sequencing. In order for all attack sequences to be equally strong in close-range combat I must take into consideration the new weapon damages and desired target. I will also enable the engine trail effect, complete with heat distortion. I will also enable the red alert animation states.

Then, the fighter will be complete.


****

SEGMENT 42a - AI editing


This aspect of the bible will cover helpful tips, tricks, and general "common sense" to be used when editing Starcraft AI.

Introduction


Whether you're looking for a challenging melee opponent, an AI better suited for your campaign, or computer Total Conversion support, there is no better man to ask about AI than I. Here I will provide tips and tricks to help you in your struggle.

Before you begin, make note of the limitations of SC AI editing that will never change.

- You cannot change how the AI micros.
- You cannot change structure placement.
- You cannot alter pathing of units or buildings.
- You cannot change how the AI uses spells, abilities, or other such things.
- You cannot change how the AI targets, defends, or anything of that sort.
- You can only tell the AI to build stuff, create defense protocols, attack, and expand.

Almost everything is hardcoded which you cannot touch. The struggle is often to get the AI working at all.

note that no matter what you do, the AI will never be able to stand against a decent human opponent. The only thing on your side is the money command, and hoping to make the AI macro enough to make up for it's lack of micro. Some units, such as goliaths and lurkers, the AI is just plain stupid with and are probably not worth getting in large numbers.

The give_money command is extremely necessary for any AI to even have a remote chance of survival against a human player. The reason for this is, the AI has no economic logic. It builds and cancels units indefinately when it's factories are in use. It cannot "know" when the best time to expand is, or when it needs to save money for something. What give_money does, is it gives the AI 2k minerals and gas if it's currently low (possibly bellow 1k each.) It seems to have a time limit on how often it can be triggered as well. For this reason it's a good idea to have the AI expand as much as possible, so it maintains a good cash flow.

Some might say, well, that's cheating. Guess what? The AI cheats no matter what you do. It always knows where you are. The fact is, AI without the money command will be no better than the default and, quite frankly, the default sucks dick and blizzard has never done good AI in any of their games. It's unfortunate but, hey, that's what I'm here to try to fix.

This guide assumes you've already read the Help file included with SCAIeditIII. If you have not done so, do so now.

Now, I'll point out a few errors and make some details using points in the help file.

- Comps will not build pre-requisits for units they don't have. The help file's example was telling the comp to build a battlecruiser without having a facility ect. The comp will lock up and do nothing in this case.
- Higher priorities will determine how hard the comp tries to get an item. For example, if you have a priority of 150 for both a pylon and a gateway, and a multithreaded worker building script, the AI will ignore the probes (assuming they have a priority of 80) until it has the pylon and gateway. This can be useful to force the AI to get something sooner instead of later.

I've also identified a few of the "unknown" commands I'll detail on later.

So, let's say you've got a basic AI script going. Let's say, it's a zerg script. For this example, I'll use my RequiemD standard zerg script, and recap some of the commands and what things do for you.


Seems pretty intimidating, doesn't it? I'll break this down so it's easier to understand.


The following set of commands is always triggered at the beginning of the script, or when the game first starts.

The script_name determines the name of the script. Unimportant, really. Just used for reference.

script_id is pretty important. ZMCx, TMCx, and PMCx are melee scripts. Remove the default ones containing these ID and make your own with the same ID to replace them.

The following series of commands should be handled with care.

start_campaign is a macro that tells the AI to mine, build nukes if possible, build "farms" when they are close to the supply limit of their current supply, and some other things. This command has been known to actually crash starcraft sometimes, if it's used wrong.

start_town also tells the comp to mine, and probably some other things. You can use either start_town or start_campaign to start a script, but, again, changing the order of which I have these can cause instability. start_town is always used in expansion scripts, NEVER start_campaign.

I have no idea what the defaultbuild and such do, but I keep them there as the blizzard scripts have them there. They must do something.

Note that having only start_town and farms_notiming instead of these scripts can cause a huge shift in behavior. Typically, with this current setup, the comps will not aid allied comps under attack, but will operate faster. with only start_town, they will aid allied comps, but generally operate more slowly.

Moving on...

define_max is a command used to determine the maximum units a comp can build. Since 1.10 and on, the AI seems to ignore this command entirely, most likely due to format changes. However, not having it can be even more problematic, as without max commands, the AI will often get stuck in a loophole of building a single type of unit until it maxes supply, then stop working completely.

Now.

Note that all of these are read in pretty much instantly. The waits are in ticks. So, wait 1 would be wait 1 tenths of a second in "normal" game speed.


multirun is a very handy little command that allows you to have the script run a seperate part of the script, or a seperate "block", as it runs the main. My two multirun commands are doing two things. The first, multirun drones, is running a nicely timed command that keeps the AI building up to 40 drones and then maintaining that number. multirun money is running a looped money command.

Now is where we get building things.

build 2 hatchery 80

This command has several parts. The first part is the command. build commands are followed by a number, which is the total number of units, in this case hatcheries, the AI will possess. Since the zerg start with one hatchery, with this command, they'll immediately build a second, for a total of 2. The name "hatchery" tells the AI which building to get. Note that workers are counted as buildings for your convenience. The following number, in this case 80, is the priority. As aforementioned, the lower the priority, the less "important" it is to the AI. Priorities can clog up the AI's "demand", I like to call it, as they will cancel out other things if there's enough of them. By cancelling, I mean they will hold off doing anything else until the command is finished.

The following commands tell it to get an extractor, and a spawning pool. Now we meet another command, wait_build. This tells the script to wait (multi processes will continue to run) until the specified structure is complete. I have this here in this particular place to force the AI to wait for it's spawning pool to be complete. This is to prevent the zerg from using all of their drones at once to build things, and locking up as a result. Stupid comps!

defensebuild_gg 1 zergling
defenseuse_gg 1 zergling

These are defense protocols. You've read the help file, so you know what these do. Placing them before the requirements of the unit will result in the AI locking up if it's attacked.

Next it builds additional hatcheries and a lair.

expand 1 exp

This command tells the AI to initiate an expansion town. Again, the number following it would be the total number of expansions it would have running, and "exp" being the block it refers to. It's worth noting that the AI will only try to make one expansion per trigger of this command. So, if I told it to get 3 expansions at once, it'd only get 1. Stupid comps!

The expansion block in question looks like this.


The only thing to note here is the "creep" command, which is classified as unknown. What this command actually does, is it makes the zerg build stuff at the edge of the creep, and makes them wait for the creep to grow outwards, so they get a far greater coverage with their defenses than clustering them all together. Very useful command. The defensegradea4 block is one I have triggered throughout the script. Note that the AI counts sunken colonies and spore colonies as existing creep colonies.



Here's another part, further down my Z standard script.

Mostly straight forward. The attack protocol has four parts. The attack_add command will allow you to add units to an attack group. Do note that the attack group seems to have a hardcoded limit of ~100 units, and can bug if you go over that number in total.

Attack_prepare makes the units group up. Note that this command can be buggy, having them grouped up and "dancing" for well over a minute. It can also trigger the attack_do, which tells the AI to actually launch the attack, before it's even grouped. You can put a wait between attack_prepare and attack_do to force the launch to wait for an estimated time (the coder's estimation) of how long it'd take to get the units all nicely bunched. The wait command in this instance is very useful when you have a number of high-tier units that take a while to build, such as battlecruisers.

Also notable, further down, is it's a good idea to have upgrades and build commands in mixed groups. Too much of either can segment the production and prevent it from moving smoothly. Since I have two hydralisk dens, I can initiate both upgrades for the hydralisk at once. If I had only one den, it'd actually slow down the AI significantly as it'd wait for the first upgrade to finish THEN start the other. This is why it's often a good idea to have the AI get multiple facilities that are used for upgrades, such as evolution chambers.


That covers the very basics. You should be able to use this to make something worthwhile. I'll cover advanced stuff, such as AI logic, later on.

As promised, here's a few identified "unknown" commands.


- creep (3-4)- Used to make the zerg build at the edge of creep and wait for the creep to expand. Best used in defense blocks with creep colonies to make them split up their defenses and not cluster them all.
- get_oldpeons (*)- Used in an expansion script. Pulls a specific number of workers from the main base and have them mine at the expansion.
- capt_expand - Will have to verify, but I believe this is the command that has the AI send a unit to free expansions and "guard" them. I saw this used in melee, and the AI would stick a zergling at expansions and burrow it. Can be useful (if this is the command I recall, I haven't used it for a loooong time).



Will update ...


****

Chaptier PiC - The HK Crit System

The HK crit system is a unit-by-unit iscript setup that allows the unit to initiate a randomized sequence of attacks with unique properties. In theory, you could give a battlecruiser that has a hundred cannons the ability to randomly cycle through every individual cannon, with a graphic for each one, for its attack. This can also be used to randomize glow effects on engines, idle animations, and other such things.

Incidentally, the critical system isn't actually that complex or difficult to understand. You need only have a decent foothold in iscript knowledge (the ability to script a unit completely from scratch without any crashes or glitches) to be able to fit this in properly.

In HK, the most sought after unit was the Zealot replacement, a hearty Zelconian Warrior. The warrior had several a critical hit system which gave him several randomized attacks, and then an Overwhelming hit, which could proc off a critical hit and do 5x damage. The Elite had a further complicated system, but it is unnecessary to cover the Elite's extensive scripting for this tutorial.


This code is where all of the magic lays. Study the code carefully, because I don't plan to go through it step by step. Instead I will cover the basic points of this script.

__1e_condjmp 25 local01 - This is the randomization protocol. I have good reason to believe that the variable after the command is out of a variable of 255. So, this attack has a 25 out of 255 chance of procing on a normal attack.
gotorepeatattk - Pretty standard stuff. It's been a while since I coded this, but I remember SC glitching or something without it. Better keep to what is known to work.
ignorerest - Again, standard stuff. I recall going through these commands since they had a habit of locking SC if the unit was interrupted or killed during a critical phase since it isn't really an "attack" script.
nobrkcode - EXTREMELY IMPORTANT. All of the attacks involved in the critical phase need these tags, because if they're interrupted, strange shit will happen. This forces the animation to play and the code to return to normal status after it is initiated. Just like the Blood Moon - not forcing it to work out will cause issues if it is interrupted.
local02 - These are the individual script blocks referred to by the Condjump command. These contain a seperate attack script that is initiated on chance by the condjump command. You can have multiple condjump commands in anywhere you please, even blocks referred to by it. This allows the critical hit to have a chance to deal even more damage and yield a special animation. Please note that if these blocks already exist, or if you decompiled the entire iscript at once, you'll need to use a different name for them. In fact, it's probably a better idea to do so anyway.
attack1c - These function the same as attack25 except they show no projectile.


This should explain the absolute basics of the system.

I had planned to make a chance to stun, as well. This would use the Maelstrom spell, triggered through the condjump blocks. Maelstrom would have to be edited to have a shorter duration for balance purposes, and it would have to have its flags changed, or given a different weapon slot with special flags, to allow it to function on what units you wanted it to work on. I didn't get around to trying this.


Attached is the entire zealot script from HK for observational purposes.


---


This is part 1 of a series of documents that will cover some of the things I did in AO. I will provide scripts and descriptions of what the scripts do. This is a part of my effort to get some advanced iscripting knowledge out there before it retires along with me.

1.1 - The Heretic Wizard

What it does -

The Heretic Wizard is a unit that teleports to move. Since actual teleportation is not possible, he fakes it by vanishing from sight, and then moving a distance, and then reappearing. This has some limitations, such as the unit still being selectable through teleportation, and the fact it can't teleport over obstacles like rivers. However, it still requires quite a unique effect.

How it works -

Forcing the unit to use the correct animation when re-appearing was a bit of a pain because of how starcraft handles to-idle on walking. When the unit went to attack, it would either become locked in a specific state and never attack, or become permanently invisible until moved again. To correct this, I initially forced most of the code through nobreak sequences, but in some instances starcraft will still actually break these, especially if they have to do with movement (never nobreak a full walking sequence). nobreak on these walk sequences caused a lot of bugs so I screwed them altogether and came up with a more simpler method, taking advantage of the walk-to-idle and sprinkled rmgraphicend commands everywhere.

It seems simple but it's easy to go wrong with.

The Code -



1.2 - The Madness Titan

What it does -

The Madness Titan is a tier6 unit with 4 different attacks. This script is not complete, however; he needs to use attack type 2 for his air attack.

This unit randomizes between 4 types of attacks; his standard attack, a berserk which "increases his attack speed" (but actually fakes it), and two variants of the pit lord fire nova. One waves back and forth, the other will come from behind and focus on the front and molest units in front of the unit.

How it works -

This is a simple randomized sequence taken to the next level of functionality with custom sequencing and pretty explosions. However, if the target dies while the unit is channeling the fire novas, it will discontinue firing the weapon but continue animating until the sequence is over. This is a limitation of starcraft. Sometimes if the unit re-acquires a target it will resume firing but not reset the sequence. This is most noticeable with the Lord of Terror.

The Code -

www.staff.samods.org/iskatumesk/Greaterspire-ZONSBelhifetBloodseeker.txt

1.3 - The Touch of Anguish

What it does -

This is a unit that casts a projectile that will create a perpetual explosion for roughly half a minute, dealing damage to any enemy who steps in it. But what's most important about this unit is that its grp is not centered correctly. Because of how the source images are arranged, the attack animations for this unit will move off-center from the other frames. These are off center from a relative viewpoint, so to compensate for this, I needed to use the arc jump command used by the Sunken Colony to determine the tentacle's position. The result is the lack of a shadow because I am too lazy to fix it, and a correct attack animation that doesn't move around.

How it works -

With DoA's help, he provided this diagram and explanation of how the arc command works.


I used this command to syncronize the unit. So, if you have a unit that is off-center at some points, you can fix it without dicking with the grp. It just takes some patience and lots of testing.

The Code


---

TO BE CONTINUED ...

Ask in the original thread for additional information and requests for more!