Mesk's Starcraft Editing Bible

User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Mesk's Starcraft Editing Bible

Post by IskatuMesk »

Note - This guide is hardly complete, and is highly deprecated. I will not be supporting any inquiries related to it, nor do I plan to complete it.


...
(old text)

I don't know why the cocks this isn't on CC. I remember it at one point being on.

Oh, hold on. I think it has to do with the forums getting wiped or something.

Well, I'm just going to copy and paste it from SA. No one goes to SA anymore so maybe the little bit of stuff I did will find renewed use, here.

since I am just copying and pasting and not updating, this article is not up to par with the more recent stuff in modding, techniques, ect. Some of it may have a few errors and it's based on the older iceCC. Most of it can still be applied to today, though.

So, here it is.

Note nothing will be updated.

####################################
I originally only intended to have this hosted at Ojan's SC division at SME, but no one goes there, so I figured it'd make better use, here.

Note I only and only ever will support modding version 1.10. This is directly copied from my post on SME. I probably won't be completing the editing bible now unless I get strong request to do so.

Mesk's Starcraft editing bible


Welcome. You open this tome in search of knowledge on how to mod StarCraft. In which case, you have come to the right place. Here I shall reveal to the willing individual my methods and tools used to create the most advanced and stunning of Total Conversions for Blizzard's StarCraft and it's expansion. In addition, other masters of modding will lend their hand in their areas of expertise, and this incarnation of a guide to editing will be great in it's coverage.

Notes - This guide is written on the observations and methods used by IskatuMesk. Preferences may vary, but this is how I do things. I will explain to the finest detail, using both words and pictures, to convey how I do everything from model great warships to programming unstoppable AI. I will detail on the advantages and disadvantages of many aspects of SC, and open the world of Iscript to many of those who are afraid of it's complexity. Here I unveil all for those willing to hear.

INTRODUCTION

I started modding SC for kicks. I had a general idea of what I wanted to do, and I went out and experimented. No tutorials or anything were really available at the time [and still remain so], so I picked up the basic tools I found, including StarDraft, and set to work. It was a tough time learning, and I made many mistakes and silly errors in my years of modding, but now I am confident I have learned nearly everything within the range of my tools. I don't yet know ASM much, but that is changing gradually. Yet still, no tutorials are available for anything beyond the absolute basics. I shall now change this.

I treat modding as an art. I aim for absolute perfection in all things. While story is up to the creator, graphics, sounds, AI, gameplay... all things must be equal and absolute in quality and immersion. However, many people overestimate their capabilities, and end up shutting down a mod before it's even playable. Only when you are confident you can at least get a mod going strong should you even attempt to start. So many mods are started, and only a fraction ever get anywhere, let alone finish. This goes for modding period. Save yourself the trouble if you think you can't keep dedicated, and don't even start. I have had trouble with this myself, and I kick myself everytime I think about it. However, I have gained something through my mods, and you will too. That is called experience.

This guide will show you how I mod.

Again, this is how I do things. They may be different than what others say to do, but they work, and with these methods great things are crafted. May the doors be opened.


Chapter Pi - Iscript

The power of iscript.bin should never be ignored or misunderstood.

The iscript is a core part of starcraft. It is edited using Icecc (NOT regular ICE. Never. Ever.) which consists of both a command prompt and a java UI that decompile parts or the entire iscript for you to edit using your favourite text editing application (I just use notepad, but context or the like would work fine too.)

Here is a very basic list of what you can and need to do with iscript.

- Edit the frames of units to support different grps.
- Edit overlays, such as engines, muzzle flashes, missile trails, ect.
- Edit effects, such as explosions, sounds, of units and effects.
- Creating new units and weaponry out of unused or different "slots".

Helpful Knowledge
* I refer to every unit as a Slot. An iscript entry is a graphical slot, meaning that most entries can be used for any purpose requiring a new grp.
* Unit "slots" are different than graphical ones. I refer to unit slots as entries in units.dat which are much fewer than in iscript or images.dat. Units.dat slots are limited, so make sure you plan out your new units carefully.
* When decompiling the iscript, you should use the java interface (Grab the latest RLE off of java's site, google for it if you must, I'll include a link whenever I am not lazy) and decompile units one at a time in your mod's data folder for better organization.
* Don't change anything without knowledge on what you are doing, or you will probably cause crashes. Feel free to ask any questions in this forum regarding this section.


Introduction to iscript

Iscript's purpose is two-fold - Functionality and Supportive functionality. To me, functionality is the ability to manipulate how a unit, structure, or effect works. With iscript, I can make an explosion expand to the radius of a map, or a ship fire a sequenced set of weapons, or add two turrets to a marine's face.

However, we won't start off with such complex things. For now, let's say we wanted to remove the Battlecruiser's engine glow. To do this, we must first acquire icecc from smempire.org's download database. I trust you are competent enough to find it. Also be sure to grab Hunter_Killers' iscript definitions which identify many of the unknowns in the java interface.

Make sure the icecc folder is under C:\. It is not known to me why, but the program only functions if it's main under is under C:\ as Icecc.

Now that the java UI is running, you should see something like this:

[imgwh 629x538]http://img.photobucket.com/albums/v734/ ... ntroui.jpg[/imgwh]

Note a few features of the interface. First is the columns of names which you probably recognize the names in. The two middle ones I rarely ever use, but the images and units column both are very important. Here's why.

The units.dat only lists units. It's very easy to find a basic unit, such as the selected Battlecruiser, in this column. HOWEVER, if you want to edit something such as an overlay or a projectile, the images column lists those in addition to the basic units. As you can see, the images column is listing the Scourge's birth, shadow, death effect, explosion, and the actual unit. These are all graphics slots - they all have individual GRP's.

Now, select the Battlecruiser as I have done by clicking on it's name. Any thing "selected" will be dumped into a text file, even if you select everything, when you decompile. This can be useful to mass-edit things, but icecc decompiles them in such a way that they can often share local entries or the like, and editing them may unintentionally effect the other units decompiled in the file. To be safe, only select the Battlecruiser for this.

Now, look down a bit. Two boxes can be checked. Seperate headers I have never bothered with figuring out, so always keep it checked. I think it has something to do with how the headers (which I'll be explaining later) are arranged in the text file.

"use Default iscript.bin" when checked will decompile the files from the iscript.bin included with icecc. You'd only uncheck this if you want to specify your own custom iscript.bin. This can be used to extract custom animations from a different mod or to retrieve your own animations from a re-compiled iscript.bin. Leave it checked for now as well.

The Save-to section will specify where to save your text file. You have to manually specify it'll decompile to .txt, which I'm sure you know how to do. Set the .txt file to be saved somewhere where you can easily find it, such as inside your mod folder. Name it something like beecee.txt or ilikegoatslalowskatz.txt. Now, click decompile.

Hunt down your txt file and open it. It should look something like this:

Code: Select all

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Mon Jun 20 14:20:31 2005
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 218 Battlecruiser (terran\BattleCr.grp)
.headerstart
IsId            66
Type            12
Init            BattlecruiserInit
Death          	BattlecruiserDeath
GndAttkInit    	BattlecruiserGndAttkInit
AirAttkInit    	BattlecruiserAirAttkInit
SpAbility1      [NONE]
GndAttkRpt      BattlecruiserGndAttkInit
AirAttkRpt      BattlecruiserAirAttkInit
SpAbility2      BattlecruiserSpAbility2
GndAttkToIdle  	BattlecruiserGndAttkToIdle
AirAttkToIdle  	BattlecruiserGndAttkToIdle
SpAbility3      [NONE]
Walking        	BattlecruiserWalking
Other          	BattlecruiserOther
BurrowInit      [NONE]
.headerend
# ----------------------------------------------------------------------------- #

BattlecruiserInit:
	imgul09        	219 0 42	# BattlecruiserShad (terran\BattleCr.grp)
	playfram        0x00	# frame set 0
	goto            BattlecruiserGndAttkToIdle

BattlecruiserGndAttkToIdle:
	wait            125
	goto            BattlecruiserGndAttkToIdle

BattlecruiserDeath:
	playsnd        	177	# Terran\BATTLE\tbaDth00.wav
	imgol08        	333 0 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            3
	end            	

BattlecruiserGndAttkInit:
	imgol08        	446 0 0	# BCLaserFireOverlay (thingy\elbBat.grp)
	goto            local00

local00:
	wait            1
	attack25        1
	gotorepeatattk  
	goto            BattlecruiserGndAttkToIdle

BattlecruiserAirAttkInit:
	imgol08        	446 0 0	# BCLaserFireOverlay (thingy\elbBat.grp)
	goto            local01

local01:
	wait            1
	attack25        2
	gotorepeatattk  
	goto            BattlecruiserGndAttkToIdle

BattlecruiserSpAbility2:
	imgol0a        	543	# YamatoCharge (thingy\eycBlast.grp)
	goto            BattlecruiserGndAttkToIdle

BattlecruiserWalking:
	imgol08        	220 0 0	# BattlecruiserGlow (thingy\tbaGlow.grp)
	goto            BattlecruiserGndAttkToIdle

BattlecruiserOther:
	shvertpos      	1
	waitrand        8 10
	shvertpos      	2
	waitrand        8 10
	shvertpos      	1
	waitrand        8 10
	shvertpos      	0
	waitrand        8 10
	goto            BattlecruiserOther

Now the fun begins!

You're probably overwhelmed by this. It's called code. It isn't a very advanced code, but it's realitively easy to screw up in given Starcraft's pickiness. I'll touch on that later.

Quick Facts
- At the very top is a number of lines of text identifying what sections are what. You can tell what most of them are by piecing together the abbreviations. These are called headers. Note that for a lot of things, headers like burrowinit and a lot of the unknowns have many different uses depending on the unit or the effect. These uses are not entirely known but once you become more advanced you'll begin to understand how they are used.
- Don't modify the headers unless you also modify the sections that you can find by scrolling down.
- IsID is the Iscript section's ID. "Type" is related to the headers and refers to how many there is. If you change the number of headers this must change as well. Look at different units to get an idea how this works.


Removing the Battlecruiser's Engine Overlay

Every single line of text in an iscript script is a command. You can guess what many of them are, but here's a list of what they mean.

Code: Select all

BattlecruiserInit:
	imgul09        	219 0 42	# BattlecruiserShad (terran\BattleCr.grp)
	playfram        0x00	# frame set 0
	goto            BattlecruiserGndAttkToIdle
- playfram designates either a frameset or a single frame. The battlecruiser is one frameset, or 17 frames. This is dependant on the following command. a 0x** tells Starcraft which set to use. Frameset 0x00 is the first 17 frames, 0x11 the next set, ect. Once it reaches 0x99 it can either go into hex or be designated via more numbers, such as 0x122. Inspect large-frame units, such as the ghost, for a better understanding.
- Most air units only have 1 frameset. Animated ones, like mutalisks and overlards, have more to make them animate at all.
- playfram with only a single numberal such as 1 or 42 designate a particular frame and not a set. This is most often seen on buildings and some projectiles which don't turn (face one direction for buildings) and thus have no use for framesets. This is also be used by units such as zerglings to play their death animations which are only a few frames.
- imgul09 stands for Image Underlay. Underlay likely means that the designated ID (an images.dat ID) will always be displayed "under" the unit it's being spawned on, and never on top. Likewise, imgol08 stands for Image Overlay, which is displayed ABOVE the unit, and never under. This can be useful. Note shadows are always underlays, and things like explosions are always overlays. Can you guess why?
- goto tells the running script to go to another segment. In this case, the Idle area, which has the BC either hover or stand until the player issues a command.



Now, scroll down a bit until you find this section.

Code: Select all

BattlecruiserWalking:
	imgol08        	220 0 0	# BattlecruiserGlow (thingy\tbaGlow.grp)
	goto            BattlecruiserGndAttkToIdle
Now, the Battlecruiser does actually "walk". Walking is a header always ran when a unit enters movement. While the walking animation may direct the running code to an idle animation, like this does, the unit will continue moving.

A possible question is, if the script is telling the walking animation to go to idle... what happens to the Glow?


The "glow" is an engine overlay that makes the engines behind the battlecruiser light up. This glow has it's own iscript entry. When triggered, it has it's own script that runs a looping walk animation. When the battlecruiser stops, the engine's script ends itself, and it ceases to exist until the ship starts moving again. To remove this, you can either replace the grp, or simply -

Code: Select all

BattlecruiserWalking:
	goto            BattlecruiserGndAttkToIdle
- nuke it's line of code!

This method of removal only works for overlays and the like. It's not always wise to delete things, but if you want to remove the engine's glow, or even the firing glow (Look at the attk animations and figure out which is making that laser muzzle flash appear), all you need to do is remove that line of text.

Now, to compile our changes!

[imgwh 628x534]http://img.photobucket.com/albums/v734/ ... troui2.jpg[/imgwh]

Obviously, you can access this section by clicking the Compiler tab in the Java ui.

Source files are those added through the Add button. There's two ways to do this.

Merge with the default script button removes the need to add your own. This is useful if you're just testing a single thing in a barely modified engine. However, if you're adding a new script to an existing modified iscript.bin, you want to uncheck the merge with default, and add yours. Make sure the iscript.bin is at the top of the list.

Additional, add your edited battlecruiser's script .txt file to the list. On the bottom of the UI it wants you to put in the path for your new iscript.bin. Note you cannot replace the one it's currently adding or merging, so just specify a new one.

Quick Fact
- The 1.10 iscript.bin's format changed slightly, and this was enough to fuck up icecc's compiler. Use the default.bin are your base iscript.bin or find a 1.09 file. Icecc comes with the 1.07 bin I think, but it supposedly works fine all the way up till the latest patch.

Why?

In 1.10 blizzard changed how the drone's hardcoded command sequencing works to "fix" the floating issue. This not only fucked how the AI handles it, but it also slightly changed how the iscript works, and this desynced icecc. The differences between the 1.10 iscript.bin and the default are virtually unnoticeable so it's perfectly safe to use the default one.


Once you have designated your new file, press COMPILE. It should have created your new file. If a popup appears with errors, however, like this:

[imgwh 545x432]http://img.photobucket.com/albums/v734/ ... terror.jpg[/imgwh]

There's a good chance you've done something you shouldn't have and should correct it. While the compiler will sometimes just warn you of errors, it's ALWAYS a good idea to correct them. I will touch on the various errors later on, but simply removing the line containing the engine's overlay should produce no errors and you are free to test your new super-cruiser ingame by adding the compiled iscript as scripts\iscript.bin in your custom MPQ.

CONGRATZ! UV LRND HOW 2 RMOV OVARLEYS
Last edited by IskatuMesk on Sun Sep 14, 2014 6:04 pm, edited 3 times in total.
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

Chapter Pib - Adding and scripting an entirely new overlay.

Last section, you learned how to extract the Battlecruiser and remove it's engine overlay. Now, I'm going to show you how to add an entirely new overlay, in this case, my firing animation for the blood moon.

Since this method uses core ITAS data which is not available to you, you need not recreate this step-by-step. Instead, pay very close attention to the steps I do. You can use this knowledge to edit existing animations and to further understand the relationship between.

This is a more advanced process. I am writing it now because I am adding the overlay now, and it involves a number of things I feel I should write out as I do them.

Just for reference, the Blood Moon is the big death star-esque thing in this image:

[imgwh 640x480]http://img.photobucket.com/albums/v734/ ... reen65.jpg[/imgwh]

The firing overlay I intend to add will create a glowing chargeup effect that brings prelude to the ship's mighty weapon. Sound difficult? It isn't, really. I'll split it into basic steps.

- Find my Blood Moon text file.
- Compile/convert my overlay frames into a grp which have already been rendered from Rhino.
- Find a slot to use for the firing overlay.
- Figure out the firing overlay's animation sequence.
- Refer to the Battlecruiser's firing overlay to understand how it works.
- Enable the firing overlay on the Blood Moon.
- Test!

Let's begin!

This is what my Blood Moon's script looks like.

Code: Select all

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Sun Jun 19 22:53:00 2005
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 082 DefilerMound (zerg\Mutapit.grp)
.headerstart
IsId            49
Type            12
Init            DefilerMoundInit
Death          	DefilerMoundDeath
GndAttkInit    	DefilerMoundGndAttkInit
AirAttkInit    	DefilerMoundGndAttkInit
SpAbility1      [NONE]
GndAttkRpt      DefilerMoundGndAttkInit
AirAttkRpt      DefilerMoundGndAttkInit
SpAbility2      DefilerMoundSpAbility2
GndAttkToIdle  	DefilerMoundGndAttkToIdle
AirAttkToIdle  	DefilerMoundGndAttkToIdle
SpAbility3      [NONE]
Walking        	DefilerMoundWalking
Other          	DefilerMoundOther
BurrowInit      [NONE]
.headerend
# ----------------------------------------------------------------------------- #

DefilerMoundInit:
	imgul09        	83 0 42	# DefilerMoundShad (zerg\zmhShad.grp)
	playfram        0x00	# frame set 0
	goto            DefilerMoundGndAttkToIdle

DefilerMoundGndAttkToIdle:
	wait            125
	goto            DefilerMoundGndAttkToIdle

DefilerMoundDeath:
	playsnd        	177	# Terran\BATTLE\tbaDth00.wav
	imgol08        	333 0 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	333 40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	333 0 40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	333 -40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	333 0 -40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            3
	end            	

DefilerMoundGndAttkInit:
	goto            local00

local00:
	wait            20
	attack25        1
	gotorepeatattk  
	goto            DefilerMoundGndAttkToIdle

DefilerMoundSpAbility2:
	imgol0a        	543	# YamatoCharge (thingy\eycBlast.grp)
	goto            DefilerMoundGndAttkToIdle

DefilerMoundWalking:
	goto            DefilerMoundGndAttkToIdle

DefilerMoundOther:
	shvertpos      	1
	waitrand        8 10
	shvertpos      	2
	waitrand        8 10
	shvertpos      	1
	waitrand        8 10
	shvertpos      	0
	waitrand        8 10
	goto            DefilerMoundOther

That's right, I converted the Defiler Mound into the blood moon, because I no longer have need for the defiler mound's graphic. It now uses the Cerebrat.

You'll probably notice this looks very similar to the Battlecruiser, save the death animation. Can you guess what my new death animation is doing? It's creating a small series of explosions. I will expand this series into a far greater one in this tutorial as well, to show you how co-ordinates work.

Now, I will compile and convert my firing overlay. Since this a process that will be covered elsewhere, I won't touch on how it's done here.

Also note I'll briefly cover the Images.dat process of changing the palette for the firing overlay so it appears as the default zerg green, which I will later change to a blood red.

This is what a frame of my overlay looks like. It will be much more impressive ingame and when it is moving.

[imgwh 255x255]http://img.photobucket.com/albums/v734/Anegma/64.jpg[/imgwh]

Notes
- Overlays, such as this firing/chargeup one, can be very handy for pretty-ing up units. Since they can be given a transparent palette via images.dat, they can be turned into new explosions, glow effects, engines, or anything you want very easily. However, all overlays contribute to a maximum sprite limit that is shared with all overlays and all projectiles. A large number of overlays and projectiles will hit this limit and cause funky shit to happen, like units not attacking. Since ITAS is such a huge TC and there can be thousands of units on the playing field at a time, I am only making overlays and effects for a select few ships that need them to truly shine. I am hoping one day I'll have the power to remove this limit.
- You can have "limitless" numbers of overlays and underlays, but they all contribute to said limit.
- Overlays and underlays follow the movements of their host unit. When the battlecruiser turns, so does the engines. The engines must have the exact number of framesets as the battlecruiser or higher.
- To make an independant overlay, you would use the Sprite overlay, which will be explained in greater detail later on. These overlays use different ID's and are used for things like missile trails and my infamous XenoXallus cannon.


Since I am a noob, I want to use some out-of-the-way grp that I'll probably never have a use for. In this case, I have conveniently layed out my processes in an immensely organized fashion, as shown here:

[imgwh 640x480]http://img.photobucket.com/albums/v734/ ... Image1.jpg[/imgwh]

As you can see, not only have I legally pirated the Batman Begins soundtrack, but I've also selected the Nexus Glow to molest viciously for my unjustified need for destruction. In addition, it's almost lunch time. HORRAY!

Due to the fact that the fifth frameset of my overlay is a goat lover and retrogrp dislikes goat lovers, I will only be using the first four framesets.

The decompiled nexus glow gives something like this,

Code: Select all

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Tue Jun 21 11:48:47 2005
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 181 NexusGlow (protoss\pneGlow.grp)
.headerstart
IsId            178
Type            24
Init            NexusGlowInit
Death          	NexusGlowDeath
GndAttkInit    	[NONE]
AirAttkInit    	[NONE]
SpAbility1      [NONE]
GndAttkRpt      [NONE]
AirAttkRpt      [NONE]
SpAbility2      [NONE]
GndAttkToIdle  	[NONE]
AirAttkToIdle  	[NONE]
SpAbility3      [NONE]
Walking        	[NONE]
Other          	[NONE]
BurrowInit      [NONE]
ConstrctHarvst  [NONE]
IsWorking      	[NONE]
Landing        	[NONE]
LiftOff        	[NONE]
Unknown18      	[NONE]
Unknown19      	NexusGlowUnknown19
Unknown20      	NexusGlowInit
Unknown21      	[NONE]
Unknown22      	[NONE]
Unknown23      	[NONE]
Unknown24      	NexusGlowDeath
Burrow          [NONE]
.headerend
# Call me at 9.
# ----------------------------------------------------------------------------- #

NexusGlowInit:
	playfram        0
	goto            local00

local00:
	wait            125
	goto            local00

NexusGlowDeath:


	wait            1
	end            	

NexusGlowUnknown19:
	playfram        1
	wait            1
	playfram        2
	wait            1
	playfram        3
	wait            1
	playfram        4
	wait            1
	goto            NexusGlowUnknown19

Obviously, in it's current state, it just won't do. The overlay cannot exist until the ship fires. How do we figure out how to configure it so? The friendly neighbor Guardian Muzzle Flash will help us!

[imgwh 610x27]http://img.photobucket.com/albums/v734/ ... Image3.jpg[/imgwh]

With my friendly neighborhood drunk on my side, no man is safe.

Code: Select all

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Tue Jun 21 11:58:27 2005
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 518 GuardianMuzzleFlash (thingy\eplMuzz.grp)
.headerstart
IsId            262
Type            1
Init            GuardianMuzzleFlashInit
Death          	GuardianMuzzleFlashDeath
.headerend
# ----------------------------------------------------------------------------- #

GuardianMuzzleFlashInit:
	playfram        0x00	# frame set 0
	wait            1
	playfram        0x11	# frame set 1
	wait            1

	playfram        0x22	# frame set 2
	wait            1
	playfram        0x33	# frame set 3
	wait            1
	playfram        0x44	# frame set 4
	wait            1
	playfram        0x55	# frame set 5
	wait            1
	end            	

GuardianMuzzleFlashDeath:
	wait            1
	end            	

Cool, eh? The Guardian Muzzle flash's script is in the assumption it's created when the Guardian Fires, so it instantly begins playing it's selected frames, then stabs itself in the face with a table when it is done. Let's just copy this over to our misshappen nexus glow...

However, it cannot be lift simply as it is. As I said, the fifth frameset was sodomized by retrogrp in it's mad lust for revenge, and thus it cannot be used lest we make starcraft explode into a gory mess. However, if you look at my Blood Moon script, we must make this firing animation last 2 seconds. To do that, I will do something really neat.

Quick Facts
- Waits are in ticks, timed by the "normal" game speed in starcraft. 10 ticks make a second. Careful use of waits and frame changes can create a very powerful illusion of movement in many different forms.
- I can make the moving energy circle in the firing animation close slowly, then speed up, by first using large waits, then short waits, as I repeat it's animation.
- I want to add a sound for this badass, I can do so by using the command playsnd.
- playsnd calls an ID from sounds.dat.

Code: Select all

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Tue Jun 21 11:48:47 2005
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 181 NexusGlow (protoss\pneGlow.grp)
.headerstart
IsId            178
Type            1
Init            NexusGlowInit
Death          	NexusGlowDeath
.headerend
# ----------------------------------------------------------------------------- #

NexusGlowInit:
	playfram        0x00	# frame set 0
	wait            3
	playfram        0x11	# frame set 1
	wait            3
	playfram        0x22	# frame set 2
	wait            3
	playfram        0x33	# frame set 3
	wait            3
	playfram        0x00	# frame set 0
	wait            2
	playfram        0x11	# frame set 1
	wait            2
	playfram        0x22	# frame set 2
	wait            2
	playfram        0x33	# frame set 3
	wait            2
	playfram        0x00	# frame set 0
	wait            1
	playfram        0x11	# frame set 1
	wait            1
	playfram        0x22	# frame set 2
	wait            1
	playfram        0x33	# frame set 3
	wait            1
	end            	

NexusGlowDeath:
	wait            1
	end           
Ultimately, my new firing animation lasts 24 ticks, not 20. To syncronize it with the attack beam, I must set the wait in my blood moon to 24.

Code: Select all

DefilerMoundGndAttkInit:
        nobrkcodestart
	imgol08        	181 0 0	# NexusGlow (protoss\pneGlow.grp)
	wait            24
	attack25        1
        nobrkcodestop
	gotorepeatattk  
	goto            DefilerMoundGndAttkToIdle

And I end up with this. When the Blood Moon fires, it will play the overlay, which lasts 24 ticks. As the overlay is playing, the unit will wait 24 ticks. A graphic of oscilliating energy circles will appear on it, and then it will unleash all of hell.

Note that the code for the firing animation I placed previously is unstable! Without a nobrkcode command, if the Blood Moon moved or it's target died before it finished charging, the overlay would not end, and since it lacked any animations besides the two it had, it'd try to initiate animations it did not contain, and crash! I have corrected this.

Nobrkcode forces the sequence to execute no matter what. However, the Blood Moon won't fire if it has no target, so now it simply executes the chargeup animation and correctly removes the overlay under any circumstances.



I am not quite done. I want to make the Blood Moon's death explosion a fair bit more dramatic than only five fireballs.

Code: Select all

DefilerMoundDeath:
	playsnd        	177	# Terran\BATTLE\tbaDth00.wav
	imgol08        	333 0 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	333 40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	333 0 40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	333 -40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	333 0 -40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            3
	end       
Fiddling with co-ordinates to produce this type of effect has been vastly overlooked by the community. Only one other person has even thought of doing this. Hunter_Killers and myself made it the staple of our works in MFTGATRL by reintroducing this frighteningly simple ability.

Overlays need co-ordinates. Typically, the co-ordinates are 0,0,0, or the dead center of a unit. If you have ANY math knowledge whatsoever (I didn't, I had to have Ojan teach me :P), you'll recognize this:

[imgwh 282x264]http://img.photobucket.com/albums/v734/ ... age004.gif[/imgwh]

That's right. It's a chart. Horray! SC works virtually the same way as this chart does. This can be used to create a big glowing 42 out of HK trails, or in this case, a really  fucking big explosion.

As you can see in my code, the Blood Moon is currently using the smallest capital explosion set. It spawns four additional Confederate-style explosions. I need to hijack the Dark Archon explosion, conveniently located in my Spirestorm script, and toss it in.

Code: Select all

	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	334 0 0	# TerranBuildingExplosionlarge (thingy\tBangX.grp)
	imgol08        	928 40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            2
	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	928 80 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 80	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -80 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -80	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            3
	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	928 40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 120 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 120	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -120 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -120	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            3
Ignore the commented labels saying those are terran explosions. They are, in fact, purty dark archons giving their lives to make the spirestorm go bang in a satisfying manner. What this part of the script is doing is sending a trail of explosions in four directions - left, right, north, south. But I want to make it even more dramatic for a star-sized warship. I will expand this explosion even further!

Code: Select all

DefilerMoundDeath:
	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	334 0 0	# TerranBuildingExplosionlarge (thingy\tBangX.grp)
	imgol08        	928 40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            2
	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	928 80 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 80	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -80 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -80	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            3
	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	928 40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 120 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 120	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -120 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -120	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            1
	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	928 40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 120 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 120	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -120 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -120	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            1
	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	928 160 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 160	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -160 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -160	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 160 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 160	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -160 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -160	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 160 -160	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -160 160	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 160 160	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -160 -160	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            1
	playsnd        	7	# Misc\ExploLrg.wav
	imgol08        	928 40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -40 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -40	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 120 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 120	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 -120 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	imgol08        	928 0 -120	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait            3
	end         
*laughs maniacally* IT IS DONE!

UPDATE:

After setting the new overlay to turn in images.dat and giving it a palette, I was rewarded with a very pretty show.

[imgwh 640x480]http://img.photobucket.com/albums/v734/ ... e1f9e1.jpg[/imgwh]
[imgwh 640x480]http://img.photobucket.com/albums/v734/ ... 7fc6a1.jpg[/imgwh]
UPDATE II:
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

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.

Code: Select all

script_name Maeyieth Consumers
script_id ZMCx


start_campaign
wait 1

start_town
defaultbuild_off
default_min 0
wait 1

groundmap_jump conground
goto conair

:conground

random_jump 125 hydragod

:zstandard
define_max 40 drone
define_max 30 zergling
define_max 30 hydralisk
define_max 20 mutalisk
define_max 5 guardian
define_max 5 devourer
define_max 5 defiler
define_max 5 ultralisk
define_max 5 lurker
define_max 3 queen
multirun drones
multirun money
build 2 hatchery 80
build 1 extractor 80
build 1 spawning_pool 80
wait_build 1 spawning_pool
defensebuild_gg 1 zergling
defenseuse_gg 1 zergling
build 5 hatchery 80
build 1 lair 80
expand 1 exp
build 3 evolution_chamber 80
train 10 zergling
tech burrowing 30
multirun defensegradea4
upgrade 1 z_missile_attack 30
upgrade 1 overlord_capacity 30
build 1 hydralisk_den 80
upgrade 1 z_melee_attack 30
defensebuild_gg 1 hydralisk
defenseuse_gg 1 hydralisk
defensebuild_ag 1 hydralisk
defenseuse_ag 1 hydralisk
train 15 zergling
train 15 hydralisk
expand 2 exp
upgrade 1 z_carapace 30
attack_add 15 zergling
attack_add 15 hydralisk
attack_prepare

attack_do
attack_clear
Seems pretty intimidating, doesn't it? I'll break this down so it's easier to understand.
script_name Maeyieth Consumers
script_id ZMCx


start_campaign
wait 1

start_town
defaultbuild_off
default_min 0
wait 1
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.

Code: Select all

multirun drones
multirun money
build 2 hatchery 80
build 1 extractor 80
build 1 spawning_pool 80
wait_build 1 spawning_pool
defensebuild_gg 1 zergling
defenseuse_gg 1 zergling
build 5 hatchery 80
build 1 lair 80
expand 1 exp
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.

Code: Select all

:exp
start_town
build 1 hatchery 80
wait_build 1 hatchery
build 1 extractor 80
build 4 drone 80
multirun defensegradea4
stop

:defensegradea4
creep 3
build 3 creep_colony 50
wait_build 3 creep_colony
build 4 creep_colony 50
wait_build 4 creep_colony
build 4 sunken_colony 50
wait_build 4 sunken_colony
build 8 creep_colony 50
wait_build 8 creep_colony
build 4 spore_colony 50
wait_build 4 spore_colony
stop
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.

Code: Select all

attack_add 15 zergling
attack_add 15 hydralisk
attack_prepare

attack_do
attack_clear
build 2 lair 80
expand 3 exp
train 12 zergling
upgrade 1 overlord_speed 30
build 2 hydralisk_den 80
upgrade 1 zergling_speed 30
upgrade 1 hydralisk_speed 30
upgrade 1 hydralisk_range 30
tech lurker_aspect 30
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).
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

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.

Code: Select all

ZealotGndAttkInit:
	playfram       	0x00	# frame set 0
	wait           	1
ZealotGndAttkRpt:
	__1e_condjmp   	25 local01
	playsndrand    	2 662 663	# Protoss\ZEALOT\pzeAtt00.WAV, Protoss\ZEALOT\pzeAtt01.WAV
	playfram       	0x11	# frame set 1
	wait           	1
	playfram       	0x22	# frame set 2
	wait           	1
	playfram       	0x33	# frame set 3
	wait           	1
	playfram       	0x44	# frame set 4
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	playfram       	0x33	# frame set 3
	wait           	1
	playfram       	0x22	# frame set 2
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	playfram       	0x11	# frame set 1
	wait           	1
	playfram       	0x00	# frame set 0
	gotorepeatattk 	
	ignorerest     	
ZealotGndAttkToIdle:
	goto           	ZealotOther

local01:
	__1e_condjmp   	25 local02
	playsnd        	665	# Protoss\ZEALOT\PZeRag00.wav
	wait           	1
	playfram       	0x33	# frame set 3
	wait           	1
	playfram       	0x44	# frame set 4
	wait           	1
	turnccwise     	3
	wait           	1
	turnccwise     	5
	wait           	1
	turnccwise     	6
	wait           	1
	turnccwise     	6
	wait           	1
	turnccwise     	7
	wait           	1
	turnccwise     	4
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	playfram       	0x00	# frame set 0
	gotorepeatattk 	
	ignorerest     	
	goto           	ZealotOther

local02:
	nobrkcodestart 	
	playsnd        	665	# Protoss\ZEALOT\PZeRag00.wav
	wait           	1
	playfram       	0x33	# frame set 3
	imgol08        	154 0 0	# ZealotWarpFlash (protoss\zealot.grp)
	wait           	1
	playfram       	0x44	# frame set 4
	wait           	1
	turnccwise     	3
	wait           	1
	turnccwise     	5
	wait           	1
	turnccwise     	6
	wait           	1
	turnccwise     	6
	wait           	1
	turnccwise     	7
	wait           	1
	turnccwise     	4
	wait           	1
	turnccwise     	8
	wait           	1
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	attack1c       	1 664	# Protoss\ZEALOT\pzeHit00.WAV
	wait           	1
	playfram       	0x00	# frame set 0
	nobrkcodeend   	
	gotorepeatattk 	
	ignorerest     	
	goto           	ZealotOther
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.
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

This is part 1 of a series of documents that covered some of the things I did in AO [and was discontinued]. 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 delivers 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 -

Code: Select all

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Fri Nov 16 13:35:47 2007
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 013 MatureChrysalis (zerg\MatureChrysalis.grp)
.headerstart
IsId           	47
Type           	26
Init           	MatureChrysalisInit
Death          	MatureChrysalisDeath
GndAttkInit    	MatureChrysalisGndAttkInit
AirAttkInit    	MatureChrysalisGndAttkInit
SpAbility1     	[NONE]
GndAttkRpt     	MatureChrysalisGndAttkInit
AirAttkRpt     	MatureChrysalisGndAttkInit
SpAbility2     	MatureChrysalisSpAbility2
GndAttkToIdle  	MatureChrysalisGndAttkToIdle
AirAttkToIdle  	MatureChrysalisGndAttkToIdle
SpAbility3     	[NONE]
Walking        	MatureChrysalisWalking
Other          	MatureChrysalisWalkToIdle
BurrowInit     	[NONE]
ConstrctHarvst 	MatureChrysalisConstrctHarvst
IsWorking      	[NONE]
Landing        	[NONE]
LiftOff        	[NONE]
Unknown18      	[NONE]
Unknown19      	[NONE]
Unknown20      	[NONE]
Unknown21      	[NONE]
Unknown22      	[NONE]
Unknown23      	[NONE]
Unknown24      	[NONE]
Burrow         	MatureChrysalisBurrow
UnBurrow       	MatureChrysalisUnBurrow
Unknown27      	[NONE]
.headerend
# ----------------------------------------------------------------------------- #

MatureChrysalisInit:
	#imgul09        	14 0 3	# MatureChrysalisShad (zerg\MatureChrysalis.grp)
	playfram       	0x00	# frame set 0
	waitrand       	1 4
MatureChrysalisGndAttkToIdle:
	playfram       	0xaa	# frame set 0
	wait           	1
	playfram       	0xbb	# frame set 1
	wait           	1
	playfram       	0xcc	# frame set 2
	wait           	1
	playfram       	0xdd	# frame set 1
	wait           	1
	playfram       	0xee	# frame set 0
	wait           	1
	playfram       	0xff	# frame set 1
	wait           	1
	playfram       	0x110	# frame set 2
	wait           	1
	playfram       	0x121	# frame set 1
	wait           	1
	playfram       	0x132	# frame set 2
	wait           	1
	playfram       	0x143	# frame set 1
	wait           	1
	goto           	MatureChrysalisGndAttkToIdle

MatureChrysalisWalkToIdle:
	#nobrkcodestart
	tmprmgraphicend
	playfram       	0x1dc	# frame set 0
	wait           	1
	playfram       	0x1cb	# frame set 1
	wait           	1
	playfram       	0x1ba	# frame set 2
	wait           	1
	playfram       	0x1a9	# frame set 3
	wait           	1
	playfram       	0x198	# frame set 4
	wait           	1
	playfram       	0x187	# frame set 5
	wait           	1
	playfram       	0x176	# frame set 6
	wait           	1
	playfram       	0x165	# frame set 7
	wait		1
	playfram       	0x154	# frame set 4
	wait		1
	#nobrkcodeend
	ignorerest
	goto           	MatureChrysalisGndAttkToIdle

MatureChrysalisDeath:
	playsnd        	815	# Zerg\MatureChrysalis\ZDeDth00.WAV
	imgol08        	214 0 0
	playframno     	0
	wait           	1
	end            	

MatureChrysalisGndAttkInit:
	#playframno	0
	tmprmgraphicend
	playfram       	0x00	# frame set 0
	wait           	1
	playfram       	0x11	# frame set 1
	wait           	1
	playfram       	0x22	# frame set 2
	wait		1
	playfram       	0x33	# frame set 0
	wait           	1
	playfram       	0x44	# frame set 1
	playsnd        	110	# Bullet\zdeAtt00.wav
	attack25       	1
	wait           	4
	playfram       	0x55	# frame set 2
	wait           	1
	playfram       	0x66	# frame set 0
	wait           	1
	playfram       	0x77	# frame set 1
	wait           	1
	playfram       	0x88	# frame set 2
	wait		1
	playfram       	0x99	# frame set 0
	wait           	1
	gotorepeatattk 	
	goto           	MatureChrysalisGndAttkToIdle

MatureChrysalisSpAbility2:
	playfram       	0x00	# frame set 0
	nobrkcodestart 	
	wait           	1
	playfram       	0x11	# frame set 1
	wait           	1
	playfram       	0x22	# frame set 2
	wait		1
	playfram       	0x33	# frame set 0
	wait           	1
	playfram       	0x44	# frame set 1
	playsnd        	110	# Bullet\zdeAtt00.wav
	castspell
	wait           	4
	playfram       	0x55	# frame set 2
	wait           	1
	playfram       	0x66	# frame set 0
	wait           	1
	playfram       	0x77	# frame set 1
	wait           	1
	playfram       	0x88	# frame set 2
	wait		1
	playfram       	0x99	# frame set 0
	wait           	1
	nobrkcodeend   	
	gotorepeatattk 	
	sigorder       	2
	goto           	MatureChrysalisGndAttkToIdle

MatureChrysalisWalking:
	#nobrkcodestart
	playfram       	0x154	# frame set 0
	wait           	1
	playfram       	0x165	# frame set 1
	wait           	1
	playfram       	0x176	# frame set 2
	wait           	1
	playfram       	0x187	# frame set 3
	wait           	1
	playfram       	0x198	# frame set 4
	wait           	1
	playfram       	0x1a9	# frame set 5
	wait           	1
	playfram       	0x1ba	# frame set 6
	wait           	1
	playfram       	0x1cb	# frame set 7
	wait		1
	playfram       	0x1dc	# frame set 4
	wait		1
	tmprmgraphicstart
	move		60
	wait		1
	move		60
	wait		1
	move		60
	wait		1
	move		60
	wait		1
	move		60
	wait		1
	move		60
	wait		1
	move		60
	wait		1
	move		60
	wait		1
	move		60
	tmprmgraphicend
	playfram       	0x1dc	# frame set 0
	wait           	1
	playfram       	0x1cb	# frame set 1
	wait           	1
	playfram       	0x1ba	# frame set 2
	wait           	1
	playfram       	0x1a9	# frame set 3
	wait           	1
	playfram       	0x198	# frame set 4
	wait           	1
	playfram       	0x187	# frame set 5
	wait           	1
	playfram       	0x176	# frame set 6
	wait           	1
	playfram       	0x165	# frame set 7
	wait		1
	playfram       	0x154	# frame set 4
	wait		1
	#nobrkcodeend
	goto           	MatureChrysalisWalking

MatureChrysalisConstrctHarvst:
	playfram       	0x110	# frame set 16
	goto           	local00

local00:
	wait           	125
	goto           	local00

MatureChrysalisBurrow:
	imgol08        	423 0 0	# BurrowingDust (thingy\bDust.grp)
	playfram       	0xcc	# frame set 12
	wait           	1
	playfram       	0xdd	# frame set 13
	wait           	1
	playfram       	0xee	# frame set 14
	wait           	1
	playfram       	0xff	# frame set 15
	wait           	1
	playfram       	0x110	# frame set 16
	wait           	1
	sigorder       	4
	goto           	local00

MatureChrysalisUnBurrow:
	waitrand       	1 5
	imgul09        	423 0 0	# BurrowingDust (thingy\bDust.grp)
	playfram       	0xff	# frame set 15
	wait           	1
	playfram       	0xee	# frame set 14
	wait           	1
	playfram       	0xdd	# frame set 13
	wait           	1
	playfram       	0xcc	# frame set 12
	wait           	1
	sigorder       	4
	goto           	MatureChrysalisGndAttkToIdle


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 -

http://www.staff.samods.org/iskatumesk/ ... seeker.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.
Image

Ok. trgtarccondjmp works like this

trgtarccondjmp %arccenter %arclen %label

the arc center is the angle that corresponds to the middle of the arc, and the arc length is the angle both positive and negative to check. As an example, I've illustrated the sunken colony's arcs -

trgtarccondjmp 74 42 SunkenColonyLocal01
trgtarccondjmp 159 42 SunkenColonyLocal02

The 74 is the center of the blue arc, and the endpoints are both 42 away from it. Same goes for the 159.

Remember, angles go from 0x00 to 0xff, or 0-255, not to 360.
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

Code: Select all

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Sun Dec 02 23:16:11 2007
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 095 HydraliskDen (zerg\Snakey.grp)
.headerstart
IsId           	57
Type           	26
Init           	HydraliskDenInit
Death          	HydraliskDenDeath
GndAttkInit    	HydraliskDenGndAttkInit
AirAttkInit    	HydraliskDenGndAttkInit
SpAbility1     	[NONE]
GndAttkRpt     	HydraliskDenGndAttkInit
AirAttkRpt     	HydraliskDenGndAttkInit
SpAbility2     	[NONE]
GndAttkToIdle  	HydraliskDenGndAttkToIdle
AirAttkToIdle  	HydraliskDenGndAttkToIdle
SpAbility3     	[NONE]
Walking        	HydraliskDenWalking
Other          	HydraliskDenGndAttkToIdle
BurrowInit     	[NONE]
ConstrctHarvst 	HydraliskDenConstrctHarvst
IsWorking      	[NONE]
Landing        	[NONE]
LiftOff        	[NONE]
Unknown18      	[NONE]
Unknown19      	[NONE]
Unknown20      	[NONE]
Unknown21      	[NONE]
Unknown22      	[NONE]
Unknown23      	[NONE]
Unknown24      	[NONE]
Burrow         	HydraliskDenBurrow
UnBurrow       	HydraliskDenUnBurrow
Unknown27      	[NONE]
.headerend
# ----------------------------------------------------------------------------- #
HydraliskDenInit:
	#imgul09          	96 254 254	# HydraliskDenShad (zerg\zzeShad.grp)
HydraliskDenGndAttkToIdle:
	__02	0
	playfram       	0x00	# frame set 8
	wait           	2
	playfram       	0x11	# frame set 9
	wait           	2
	playfram       	0x22	# frame set 10
	wait           	2
	playfram       	0x33	# frame set 11
	wait           	2
	playfram       	0x44	# frame set 12
	wait           	2
	playfram       	0x55	# frame set 13
	wait           	2
	playfram       	0x77	# frame set 14
	wait           	2
	playfram       	0x88	# frame set 15
	wait           	2
	playfram       	0x99	# frame set 15
	wait           	2
	playfram       	0xaa	# frame set 15
	wait           	2
	playfram       	0xbb	# frame set 15
	wait           	2
	goto           	HydraliskDenGndAttkToIdle

HydraliskDenDeath:
	playsnd        	194	# Zerg\HydraliskDen\ZZeDth00.WAV
	playframno    	0
	imgol08        	333 0 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	#lowsprul       	160 0 0	# HydraliskDenDeath (zerg\zzeDeath.grp)
	wait           	1
	end            	

HydraliskDenGndAttkInit:
	__02		0
	trgtarccondjmp 0x60 18 pewpewsoutheast
	trgtarccondjmp 0xa0 18 pewpewsouthwest
attackreturn:
	nobrkcodestart 	
	playsnd        	664	# Bullet\ZGuFir00.wav
	playfram       	0x198	# frame set 20
	wait           	1
	playfram       	0x1a9	# frame set 20
	wait           	1
	playfram       	0x1ba	# frame set 20
	wait           	1
	playfram       	0x1cb	# frame set 20
	wait           	1
	playfram       	0x1dc	# frame set 16
	wait           	1
	playfram       	0x1ed	# frame set 17
	wait           	1
	playfram       	0x1fe	# frame set 18
	wait           	1
	playfram       	0x20f	# frame set 19
	wait           	1
	playfram       	0x220	# frame set 20
	wait           	1
	playfram       	0x231	# frame set 20
	wait           	1
	playfram       	0x243	# frame set 20
	wait           	1
	playfram       	0x253	# frame set 20
	wait           	1
	attack25	1
	playfram       	0x264	# frame set 20
	wait           	1
	playfram       	0x275	# frame set 20
	wait           	1
	playfram       	0x286	# frame set 20
	wait           	1
	playfram       	0x297	# frame set 20
	wait           	1
	#playfram       	0x2a8	# frame set 20
	#wait           	1
	#playfram       	0x2b9	# frame set 20
	#wait           	1
	nobrkcodeend   		
	gotorepeatattk 	
	goto           	HydraliskDenGndAttkToIdle

pewpewsoutheast:
__02		16
goto attackreturn

pewpewsouthwest:
__02		-16
goto attackreturn


HydraliskDenWalking:
	__02		0
	move           	5
	wait           	1
	playfram       	0xcc	# frame set 16
	move           	5
	wait           	1
	playfram       	0xdd	# frame set 17
	move           	5
	wait           	1
	playfram       	0xee	# frame set 18
	move            5
	wait           	1
	playfram       	0xff	# frame set 19
	move            5
	wait           	1
	playfram       	0x110	# frame set 20
	move           	5
	wait           	1
	playfram       	0x121	# frame set 20
	move           	5
	wait           	1
	playfram       	0x132	# frame set 20
	move           	5
	wait           	1
	playfram       	0x143	# frame set 20
	move           	5
	wait           	1
	playfram       	0x154	# frame set 20
	move           	5
	wait           	1
	playfram       	0x165	# frame set 20
	move           	5
	wait           	1
	playfram       	0x176	# frame set 20
	move           	5
	wait           	1
	playfram       	0x187	# frame set 20
	move           	5
	wait           	1
	goto           	HydraliskDenWalking

HydraliskDenConstrctHarvst:
	playfram       	0x110	# frame set 16
	goto           	HydraliskDenGndAttkToIdle

HydraliskDenBurrow:
	imgol08          	423 0 0	# BurrowingDust (thingy\bDust.grp)
	playfram       	0xcc	# frame set 12
	wait           	1
	playfram       	0xdd	# frame set 13
	wait           	1
	playfram       	0xee	# frame set 14
	wait           	1
	playfram       	0xff	# frame set 15
	wait           	1
	playfram       	0x110	# frame set 16
	wait           	1
	sigorder       	4
	goto           	HydraliskDenGndAttkToIdle

HydraliskDenUnBurrow:
	waitrand       	1 5
	imgul09          	423 0 0	# BurrowingDust (thingy\bDust.grp)
	playfram       	0xff	# frame set 15
	wait           	1
	playfram       	0xee	# frame set 14
	wait           	1
	playfram       	0xdd	# frame set 13
	wait           	1
	playfram       	0xcc	# frame set 12
	wait           	1
	sigorder       	4
	goto           	HydraliskDenGndAttkToIdle

Last edited by IskatuMesk on Fri Feb 13, 2009 10:26 am, edited 1 time in total.
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

*crawls out of a nearby grave*

Chapter PiD - Advanced AI mechanics

In this rundown of AI mechanics I am going to show you how to streamline your AI for maximum efficiency, speed, and reliability. I am also going to explain how exactly the AI functions, or perhaps an interpretation of how it functions, so you can better understand why it does certain things.

Introduction

Alright, you've made an AI. But it's a little slow, and it tends to "freeze" a lot. In this chapter I am going to introduce several concepts and editing techniques I have learned through recent projects, including RequiemD: Final Battle, AI built for Free For All games, Armageddon Onslaught, an advanced AI that uses units unavailable to players, and The Great Apocalypse, an elite AI built for AI vs AI tournaments with reactive aggression protocols and maximum efficiency scripting.

We'll start with first finding trouble points in common AI scripts.

Defense protocols

When a script runs this command,

Code: Select all

defensebuild_gg 1 marine
A part of the hardcoded AI sequence will often tell the AI to build that unit regardless of what you tell it to do. This seems to be effected somewhat by the macro used in the start of the script (either start_campaign or start_town) which I'll touch on a bit later.

If you initiate this command early in the script, make note that the AI may decide to produce the maximum defined limit of units you have designated. Therefore, it may be wise to limit most units to a small number during the early-game stages to prevent them from spending too many resources and time on unneeded units. This is particularly important for AI scripts not making excessive use of the give_money command.

However, if the AI is attacked and it does not possess a defense protocol for that classification, ie if a protoss with no dragoons is attacked by mutalisks, there is a high chance the AI will softlock and a small chance it'll hardlock even if the threat goes away. There must always be defense protocols for every engagement range or the AI is vulnerable to being exploited.

* You can use defensebuild protocols to try to encourage the AI to build units during the final loop.
* defenseuse_* will call any available designated units in combat states but won't build any. This can lock the AI if there's defenseuse protocols and the AI runs out of available units.


Combat State

When an AI's structures are attacked, it enters combat state. It also sometimes enters combat state depending on the proximity of units to certain areas. Combat state does several things.

* the AI will generally not build structures while in the combat state. Sometimes it briefly exits combat state when enemy units are present but not attacking. This explains why a fleet of carriers flying over a zerg base but not attacking won't provoke a huge pile of scourge eggs.
* the AI will spam defense protocols while in the combat state. If none exist for the units engaging it (such as defensebuild_aa) it will lock until the threat goes away and sometimes permanently.
* the AI determines an invisible region around its base that it considers "threat" radius. This is what kills Blizzard's AI. Sometimes, when units are engaged in this region, the AI will enter a long combat state constantly reinforcing that region until threats are gone for some time. This seems a bit related to the initiation macro. Tests in ITAS yielded unusual results with those macros and this behavior. If a defense protocol is calling a unit with a massive maximum number, the potential of this happening increases as it will try to max out available unit slots before continuing on with the script. This is murder on a non-money script as it will often constantly try to reinforce a potentially overpowering force far away from its base and waste of its cash and just wait to die.

Priorities

Code: Select all

build 1 command_center 80
Priorities are very sensitive, and are very powerful. Some coders in the BWAI community experimented with using very low priorities on buildings to "smooth" out other parts of the script, believing that they may be interrupting invisible unit priorities. This does not appear to be the case. I'll elaborate.

When an AI is building a chunk of buildings, it looks ahead in the script and sorts priorities. They can be a series of 1's and 2's, or 80's and 120's like in Blizzard's. It doesn't matter how high or low they are in general. But a structure with a priority of 2 has double the priority of a structure with 1. A structure with 14 has a considerably higher priority than one with 10. The exponential increase becomes less significant when you enter high numbers, like 80 and 100. But the effects are still dominant.

Priorities seem to pass between multithreads. For example, if an expansion wants to build a cannon with a priority of 3, that cannon is getting a higher priority than one in the main base for 1. Often extreme experimentation is required to find the perfect balance.

My experimentations tell me that units do not possess priorities, at least ones relevant to structure construction. Between high and low priorities of structures, unit handling doesn't change one bit. However, if you tell the AI to train a large number of units before continuing the build process, sometimes it will wait until a number of them have been completed.

To help even out "sections" in your script, and prevent things like drones crashing into each other all trying to build at once, structure your script a bit like this.

Code: Select all

:openingprotoss
multirun hatchies
wait 120
build 1 spawning_pool 10
wait 120
multirun defensegradea4
wait 120
build 1 evolution_chamber 10
wait 120
farms_timing
define_max 100 zergling
upgrade 1 zergling_speed 5
build 4 overlord 10
wait 100
build 1 lair 13
wait_buildstart 1 lair
upgrade 1 overlord_speed 10
multirun hydradenassure
build 1 hydralisk_den 20
wait_buildstart 1 hydralisk_den
wait 120
build 3 sunken_colony 10
defensebuild_ag 1 hydralisk
defensebuild_ga 1 hydralisk
defensebuild_gg 1 hydralisk
build 2 hydralisk_den 20
wait_buildstart 2 hydralisk_den
wait 120
build 6 overlord 10
multirun hydra_upgrades
train 20 hydralisk
wait_force 20 hydralisk
attack_add 20 hydralisk
attack_prepare
wait 200
attack_do
attack_clear
multirun zurgexp
enemyowns_jump cybernetics_core presshydra
This is some code from The Great Apocalypse, a part of the zerg script that detects protoss and runs through a really nasty rush phase. Note the extensive usage of wait_buildstart and waits in general. Apparently the AI can and will ignore waits smaller than 120 or so or they are simply so short they don't make a difference as far as this is concerned.

Sometimes when the AI crashes drones into each other trying to build structures, it will think the structure actually got started on, when it didn't, and softlock or hardlock as a result. This is a serious issue, but it can be somewhat alleviated. Note this line;

Code: Select all

multirun hydradenassure
This is calling a multirun block I built for the purpose of making absolutely sure TGA builds its hydralisk den. Against extremely fast and tough protoss scripts like Ashara's $P, a slow hydralisk den can and will seal the fate of the AI.

Code: Select all

:hydradenassure
wait 100
notowns_jump hydralisk_den gethydradenimo
goto hydradenassure

:gethydradenimo
build 1 hydralisk_den 24
wait 100
stop
This is essentially telling the AI that if it doesn't own a hydralisk den, it should get one with a rather high priority. This doesn't trigger as fast as you think it would; it's just backup in case the first one doesn't get done. Sometimes it'll softlock, anyway. That's just the way of AI scripting and there isn't much else you can do about it.

Code: Select all

wait_force 20 hydralisk
This is telling the AI to wait until it has the appointed number of units. To prevent the AI from rushing out its hydralisks too early one-by-one into a possible zealot attack, I have the AI wait. This allows the AI to acquire a large number of hydras and move them as a group, certain death for virtually any protoss rush.

Detection enemy activity and reacting accordingly

Now I'll introduce you to my aggression protocols.

Code: Select all

:aggressionprotosstech
wait 20
notowns_jump hydralisk_den aggressionprotosstech
train 20 hydralisk
wait_force 20 hydralisk
attack_add 20 hydralisk
attack_prepare
wait 100
attack_do
attack_clear
wait 50
stop
This is a very simple block that detects if the protoss has a cybernetics core. By now, most protoss will. But there is a second check in place elsewhere that determines that if for some reason the protoss doesn't have a cybernetics core, either because they are dying or they are just massing zealots, the AI will then rush for air and finish them off. Otherwise, this second hydralisk attack forms up almost immediately and 99% of protoss AI scripts will die with this offensive. Even if they don't die, this will force them into combat and kill a great deal of their units. Against a human player on a small map, this attack cannot be survived without serious exploiting.

You can see this aggression state is also checking if the script has a hydralisk den. This check may not be necessary but I leave it there anyway. Additionally, although I experienced otherwise a long time ago, if you do not have a wait in any kind of a loop statement, the game will buffer overload. This includes everything from the money command to checking if your buildings are up or if the enemy has a certain building.

It's also wise to strew waits along the major construction areas of your script even if they aren't building anything. The AI seems to sometimes run through huge chunks of code all at once and may softlock itself by doing so. If you can, have the AI wait for important tech structures before progressing onwards. All of this can help smooth out and stabilize your AI script.

Multisequencing attacks

It is perfectly possible to have an attack outside of the main script or multithread to initiate an attack while another one throws units on top of it. I used this in Undying Fury and Baja also used it in Zbath.

Here's a snip from ZONS1.0 public, which was built off of Zbath.

Code: Select all

:air_units_train
defensebuild_gg 1 mutalisk
defensebuild_gg 1 guardian
train 18 mutalisk
wait 800
train 6 guardian
train 18 mutalisk
attack_add 18 mutalisk
attack_add 6 guardian
wait 1200
goto air_units_train

:primary_attack$
train 100 zergling
attack_add 50 zergling
attack_prepare
wait 1800
attack_do
attack_clear
goto primary_attack$
Another handy command is clear_combatdata. You can append it to the end of an attack, like this;

Code: Select all

train 100 zergling
attack_add 50 zergling
attack_prepare
wait 1800
attack_do
attack_clear
clear_combatdata
This command is super useful for AI built for large games or maps. This clears the AI's current attack target and it will choose another one. I threw this on ZONS and it would completely decimated 7 average human players because its attacks became completely unpredictable. However, note this will stretch the AI's forces thin during repeated attacks (if it doesn't softlock first).

Getting past softlocked AI attacks

Sometimes the AI will stand around with a million units doing nothing. Or it'll max out in supply. Or it'll just not build anything. Well, for the first two, there is something simple that can help.

Code: Select all

:suicide_loop
wait 3000
send_suicide 0
goto suicide_loop
This triggers the staredit suicide command. The AI will launch an attack with every single military unit (excluding workers and overlords) much like any other attack. This is what gives Baja's zbath script an added punch during lategame. However, this will not prevent softlocks. It merely helps keep the units flowing out of the base.

Total Conversion Support

When you're making a total conversion, you should pay attention to the units you are converting and consider AI. In the event you give a unit a spell that the AI will not use, like a drone yamato gun, but want the AI to use it on the default unit, leave that unit's place in the spell requirement as it was. The AI does not use buttons and has access to anything with their requirements met. This is how Armageddon Onslaught works.

* Make note that the AI will not use any spells on heroes besides cloaking.
* The AI will never use infest.
* The AI won't magically know your new tech tree. Keep that in mind when scripting.
* The AI can build units that would otherwise crash for a player when selecting them due to grafting issues just fine. For example, half of the units in AO will crash a player who tries to play with them in an UMS, but in a melee with the AI they are fine. This means you can have the AI run anything in the game as a unit, including data disks and such, so long as they meet the needs of a base unit that is capable of movement and attack.
* Since the AI doesn't need buttons, removing buttons from a unit for things like problematic default spells you have modified will not prevent the AI from using them. If your new yamato gun crashes the game and you want to remove it, make sure to alter the Ai script or the spell's requirements accordingly.

There is no excuse not to include AI with your mod. It's easy, it's quick, and there are resources to help you learn fast and painlessly.

Misc

Unusual protocols;

You can use the defense protocol to have the AI maintain units that can't actually attack certain things. Such as Defilers. In Zbath and ZONS1.0, we use this;

Code: Select all

:defilers_train
defensebuild_gg 1 defiler
train 3 defiler
attack_add 3 defiler
wait 800
goto defilers_train
This forces the AI to maintain defilers which can sometimes be troublesome. What happens is, the AI will refresh the defensebuild protocol and take advantage of the bug that makes it build units when it runs into this. At least, in theory. It doesn't always work, but it's more reliable than not doing so.

Some command info

place_guard;

This ignores the maximum limit placed for a unit. It's probably not a good idea to use it too often. This is why sometimes AI builds a huge horde of queens.

creep;

This has to do with placing cannons and creep colonies around the edges of creep and psi radius. You can use it in a multithread to help spread out defenses. It takes a variable that I imagine has to do with distances.
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

Chapter 0.0000.0000.01
The fundamentals of Starcraft

Starcraft is a Blizzard game. It is coded in a haphazard, backwards, and often unusual way. The obvious may not be so obvious, the impossible may be possible, and the simple may be impossible. To gain a foothold and understand what exactly you can do with this game, you must first understand how the game works. As a beginner, you are probably overwhelmed by all these editors, abbreviations, and file names. In this chapter, I am going to cover the basics of how exactly the game works, and how you can begin the road to modding in the least painful way.

File structure

Basic files

*.mpq - Related editor; Winmpq - These are Blizzard's long-standing archives. Mpq files of any of Blizzard's games besides WoW's expansion which is too large can be opened by winmpq. Mpq's besides those in WoW require an associated listfile you can add in winmpq's options after downloading it, otherwise you get a mess of unknowns. When you make a mod, you create your own mpq and use Quantam's MPQdraft to load it, or Firegraft.
*.dat - Related editor; Datedit - these are data files. They control the basic attributes of units in the game, such as what grp to use, what rendering state to use, so on.
iscript.bin - Related editor; icecc - This is the iscript.bin. There are several types of .bin files in the game, associated with how the engine renders or controls elements. Bin files are basically archives. The iscript.bin is the second most important file for the game, because it handles all unit, structure, projectile, and most other grp-related animations. Virtually all grps you throw into the game will require you to edit this file to get working 100%. This is an intermediate subject explained elsewhere in the bible.
Aiscript.bin - Related editor; ScaieditIII - Another extremely important file. This controls the basic actions of the computer players in the game. If you make a mod and change units/tech around, you'll want the computer players to reflect these changes. This is a subject explained elsewhere in the bible.
*.tbl - Related editor; tblpad - These are string files, controling the names of units, interface elements, and other such things. If you cannot locate interface elements in any of the tbl files, they are controlled in the various menu .bin files, editable by Farty's bin editor or Binedit.
*.grp - Related editor; SFgrpconv, pygrp, ect... - Grp files are archives of bmp's in the following arrangement,

Every 17 frames is a frameset of the unit's graphic facing north, east, then south in 17 directions. Blizzard didn't take advantage of most of these directions in many of their units but you can. Icecc references these sets as 0x00 for frameset 1, 0x11 for frameset 2, 0xaa for frameset 11, 0x110 for frameset 18, ect... Starcraft's engine mirrors the frames when the unit faces the other direction.


By editing these files and editing buttons with stargraft or firegraft you can achieve a wide variety of modifications. Now that we know what the basic files are, let's get a grasp of how the game works.

Starcraft, the game

Starcraft is a sprite-based 256-color 640x480 game. All units and projectiles are basically units with different kinds of ways of the game reading them. Projectiles are essentially units without units/weapons.dat entries and behave much the same way. Starcraft has hardcode mingling with almost every element that you can play with. For example, 90% of the AI's actions are completely hardcoded, including how they handle spells, structure placement, target priorites, ect. The largest thing open to a modder is the iscript. Through the iscript, you can achieve many unique units and styles of play.

Starcraft only renders elements and units within a few cells of the screen's position but runs calculations elsewhere. If a unit with an animation issue is going to crash you, it'll freeze the game with an error when you when you are near it view-wise. If a unit is going to crash otherwise such as from a dat error, it will crash with a crash-to-desktop. If your AI has run into a buffer overload with an infinite loop, it will freeze the game as well, with no error. If you get the cbullet error, you are attempting to call a hardcoded spell such as mind control as a weapon and the game cannot take that. If you are trying to run a grafted mod and it immediately crashes on startup or ingame startup, you're using the wrong game version for the mod.

Starcraft sounds are in PCM .wav format and can take up to 48,000khz sampling rate. The game can handle any length of sound but only has 8 or so sound channels (Wc3 has the same limit).

It is impossible to add entries to .dat files. Several occasions occurred when individuals looked into creating a dat editor that could handle the insertion of new entries but grew too lazy to produce anything we can use.

The game normally has a limit of around 1750 or so units in the game at any given time. Every unit also contributes to a slightly higher sprite limit, also shared by a weapon limit. This is why a big mass of valkyries sometimes cannot fire, and big mods like ITAS 2.0 can instantly hammer the limit and you get the error "Cannot create more units". DoA released a limit expander for 1.10 that greatly raises these limits and is showcased in AO and ITAS 2.2.

If you are modding a version later than 1.10, you need to take into account these limits when creating your units.

Overlays and a 2d world

Starcraft is completely 2d. The illusion of height and size are given by overlays. Overlays are controlled through iscript. You can spawn any number of overlays of any kind on a unit or weapon you please, but these all contribute to the sprite limits.

When you build a wraith, you'll see the wraith and a shadow. The game handles shadows exactly like overlays.

An overlay is called in iscript as either an underlay (with a minimum possible "layer", which determines if it'll appear above other units or not), or as an overlay (such as turrets, explosions, ect). In the wraith's case, it's spawning an underlay. Overlays and underlays are the exact same thing, it's just underlays have the animation layer thing. This command in the iscript is referring to an images.dat id.

There are two types of shadows that blizzard uses. Air units simply use images.dat entries that spawn the same unit's grp, and give it a transparent shadow palette. Ground units use shadow grps created from their 3d models in max, which also use the shadow palette. It is easy to give land units an air-style shadow that looks fairly authentic. Be careful with the transparent settings, though! Only a few can work with the standard palette on units. Explosion palettes, like blue and orange, have a very limit cross-reference palette and will crash the game if you attempt to use them on normal units. You'll notice the wraith engines are a second overlay that use the orange explosion palette to give them their transparent effect.

More information about overlays and animations can be found in the iscript sections.

Hardcoded stuff

Virtually everything spell-related is hardcoded. You can change some attributes, like how much damage plague does, and how the spells trigger ect. but for the most part, you can't make stasis field freeze small units and not big ones, you can't make mind control work as a random attack, and you can't make completely new spells without serious ASM hacking which is beyond the scope of this bible.

Units who do not have cloaking to begin with cannot be given cloaking without the assistance of firegraft.

Virtually all AI actions are hardcoded besides build orders, what to build, what to attack with, and stuff like that. See the AI sections.

Icecc can handle virtually any animation related stuff but there are some limits. For example, you can't make new headers to re-enable the beta's air unit flanking when turning.

Unless you have starcraft's source code, increasing the color depth, resolution, and other things are things that will never, ever happen.

Weapon basics

I'm not going to cover damage types since you should already know what concussive ect. does. But in datedit, you have some options what you can do with weapons.

Behavior

3x3 - Aims the projectile in a random 3x3 cell area. Halo rocket, basically. Won't work with weapons that don't have actual projectiles (Like shock cannon).
Bouncing - Does this bounce (Like mutalisk attack)? Likely needs iscript assistance for most projectiles. Number of bounces and damage done is hardcoded.
Go to max range - Tells the projectile to go to max range and then die. Used for Lurker spines, which deals damage based on overlays. Can be used for more creative projectiles.
Appear on attacker - Appears on the unit using the weapon. You can use this to make a self-based shockwave or the like.
Appear on target unit - Used for shock cannon and such. Self-explanatory.
Psionic storm - Probably related to how the game handles the spell. I need to see what this does, exactly.
Attack & Self-destruct - Kills the unit when used.

This should be a good primer for now. See the individual sections for expanded information on any given subject. If those sections don't exist, that's quite possibly because I haven't created them yet. Oh geez! Just like this isn't anywhere near finished!
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

I gave a basic overview of Starcraft and formats in this video, previously intended to be a private primer, here;

http://www.staff.samods.org/iskatumesk/ ... cintro.avi

Use this video in conjunction with the Bible.
User avatar
Lavarinth
Xel'naga Administrator
Xel'naga Administrator
Posts: 6539
Joined: Wed Aug 16, 2006 5:21 pm
Location: His Ashworld Planet

Re: Mesk's Starcraft Editing Bible

Post by Lavarinth »

Must.. Update site.. With this.
- - Lavarinth
Campaign Creations Administrator
User avatar
Hercanic
Protoss Stargate Concierge
Protoss Stargate Concierge
Posts: 1286
Joined: Sat Aug 19, 2006 12:11 am
Contact:

Re: Mesk's Starcraft Editing Bible

Post by Hercanic »

IskatuMesk wrote:Go to max range - Tells the projectile to go to max range and then die. Used for Lurker spines, which deals damage based on overlays. Can be used for more creative projectiles.
Actually, not quite. During flight the invisible projectile does two things as a constant loop: domissledmg and spawns the spine overlay. The spine overlays do no actual damage themselves, they just coincide with the damage location because they are both executed at the same time by the main projectile.
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

Well, same thing, really. You can use either method. When I wrote that I was probably thinking of the multiple AO line attacks that use damage based on overlays but are built nearly indenticle to lurker spines. I generally do that because of overlay spawned attacks to create positional damage.

Also, here's a list of programs compiled by poiuy_qwert. No more hunting for programs!

http://www.broodwarai.com/forums/index. ... =5903&st=0&
User avatar
Hercanic
Protoss Stargate Concierge
Protoss Stargate Concierge
Posts: 1286
Joined: Sat Aug 19, 2006 12:11 am
Contact:

Re: Mesk's Starcraft Editing Bible

Post by Hercanic »

Not quite the same thing. If you try using Domissiledmg in a sprite, the game will crash. It will work with Images, but those follow the main graphic.
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

Hmm... you sure? I swear I've spawned it in sprites before.
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

Chapter 0.0000.0000.02

Starcraft Modding - Getting started.

This article assumes you've read the article Fundamentals of Starcraft.

This article will help you get started with modding Starcraft, your workflow, and your resources.

First, let's talk about resources.

With any game you intend to mod, Starcraft will be a long and painful road. Being quite an old game, you might expect the internet to be brimming with information about modding it. I'm afraid you're very wrong. Because of our ass-backwards community and self-destructive programmers in the past, very little information has actually been documented in a format that has retained usefulness or availability through the years. This article and others like it are an attempt to set up a new modder with everything he needs to ascend to the heights of SC modding.

While there may be few documentations or tutorials out there, there's plenty of information to be found. Knowing where to go, and what to look for, is key.

Campaigncreations.org - This is my primarily website. The current forum setup is fairly young, but there's a few highly experienced modders here, including myself, capable of answering advanced topics.
Samods.org - Although modding on this site is all but dead, there is an insane amount of extremely useful information stored in both the SC and wc3 forum. Usage of the search function is highly recommended to find this treasure.
broodwarai.com - This is the most organized site out there right now. poiuy_qwert is keeping everything in top shape and Baja has quite a few topics on SC modding, mostly regarding AI. Some nice stuff here.
Staredit.net - Excuse their terrible website and messy forum, but this is the most active and probably the most useful website you'll find right now as a beginner. Most of the modders there are quite new themselves, and you can usually find common ground. Several experienced modders including myself post from time to time. Usage of the search function will help you find like-minded beginner topics and get you started. Plus there's plenty of mods of varying degrees of scale to see what can be done with SC. If you access the Maplantis backup, www.staredit.net/maplantis[url=http://]http://[/url][url=http://]http://[/url][url=http://]http://[/url], you'll find a host of freely-available graphics and stuff that they've been too lazy to integrate into the SEN site.

These four sites are virtually the only decent sources of information you'll find. I've said it before but I cannot express it enough, use the search function and look around before asking basic questions! Chances are someone has asked it before and people like me are less likely to help you if we feel you're being lazy.

Magic has several very nice articles at SA, here - http://samods.org/articles . I highly recommend reading this one in particular before continuing. http://samods.org/articles/tips_for_new_modders

In short, if you aren't absolutely dedicated to a project, don't waste your time. I'm not going to be re-inventing the wheel here, I'll be covering major topics only, and not repeating what I've written in the past. There's plenty of information available that will suppliment this bible. I'd also check out some of the topics I've written in the Doackendium, specifically topics about the RTS genre, immersion, and things relating to game and mod creation.

If you're eager to learn and ready to put in some serious dedication, you're in good hands. Modding is not a hobby. It's a dedication. It's a work of art. You must approach it as such or you will just be wasting your time.

Workflow

A lot of people say do sounds and graphics last. I always do them first.

I find that completing something, even something relatively superflous, helps propel the project. Writing down a gigantic game document for a rebalance mod is a goddamn waste of time and only serves to slow you down, and chances are no one will ever read it. Actually, writing down a game document for a SC mod in the first place is probably a waste of time because of how limited SC is.

I feel that creating an immersive environment for the mod is the first and foremost important thing to get down. Graphics, sounds, functioning AI and the basic elements of gameplay are essential. Getting the mod to feel and look the way you want it should be what you're trying to do. Don't make a mod for other people. Make it for yourself. Make it how you want to be. Then, when you are getting ready to finish it up and release, start paying close attention to the finer elements.

I'll be writing a large article on how to manage game and mod work in the near future.

For Starcraft, Paint Shop Pro should be your primarily utility in dealing with graphics. The reason for this is because it's faster and easier to use than photoshop, especially when dealing with SC's limited 256 color palette. You can still use photoshop, especially if you're experienced in it, but I always use PSP as a bridge between photoshop and starcraft. The script recording functionality is much quicker to use and speed is paramount when dealing with a large project.

For sound editing, I use Adobe Audition 1.5. Superior to Audacity and Sound Forge, Audition is a highly user-friendly and very powerful utility that doesn't demand you to download fifty billion plugins and spend years screwing with them to get the most out of it.

My workflow for a new unit involves first decompiling or finding a script to base it off of. I then do the basics inside Datedit to get everything ready. If my graphic isn't ready by then, I either render it in 3ds max or hackjob whatever it was I was going to use. Then I get the sounds working, and then I script it in iscript. Then I test it, fixing it where necessary. Then I get it working with the AI, and make sure the AI builds it. Then I move on to the next thing. If I'm working on multiple things at once, I do it in chunks. All at the .dat editing at once, then the sounds/graphics, then the scripting, then testing.

My workflow is efficient and clean. Although I sometimes do scripting before dat editing, ect, this generally works best. Doing the boring, less involving work first, then getting into the dirty and fun work like iscript last. I generally start off with a vision of the unit, and by the time I end up completing the iscript for it, I've changed it a bit, and don't need to go back to alter this or that.

Since I don't use firegraft, and only stargraft, my button editing is not very involved. I usually do graft editing and string editing both at once at specific times. In AO, I'll do the graft editing generally before I do anything else. I save string editing for when a bunch of stuff is done, and then only change unit/weapon names. In something major and user-playable, I do all of the requirement strings ect as a very last priority, because they can change, and are gay and time consuming to do.

My workflow centers on getting the units themselves fully functional and working for both players and AI in one quick motion, and in a modular fashion so I know exactly what's going on and where.

Organization

I organize all of my mod data externally, and don't rely exclusively on the mpq to know where stuff is.

I am legendary for my extremely insanely bad organization, amusing naming schemes, ect. But there is logic to every madness.

[imgwh 381x480]http://img18.imageshack.us/img18/6872/image3ari.jpg[/imgwh]

In short, how you organize is up to you, but I follow several key points.

- Stuff is named in a manner I'll immediately recognize even after 2 years haitus from the mod.
- Directories are organized in a manner that lets me immediately get involved with a group of related files, or import specific types of files all in one go.
- Unconverted stuff is named or placed in a way that will let me know what they were intended for.
- I decompile iscript stuff as individuals to keep track of everything.
- I treat the mpq as a "final file" kind of deal, and don't rely on it to know where stuff is.
- I keep a txt file that tells me my future plans in a summary format so when I jump back into the mod I know where I last left off and where I'll go back to.
Last edited by IskatuMesk on Tue Mar 24, 2009 7:30 am, edited 1 time in total.
User avatar
IskatuMesk
Xel'naga World Shaper
Xel'naga World Shaper
Posts: 8328
Joined: Sat Feb 07, 2009 1:40 pm
Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞ‌ా

Re: Mesk's Starcraft Editing Bible

Post by IskatuMesk »

Herc > Shadowflare verified the sprite overlay damage thing doesn't crash, it just doesn't do damage. That's a bit of a surprise to me given how powerful the Blood Tornado is in ITAS without its damage working. :\

Well. Good thing to know.
Post Reply