changed for no mask and no problem

Very cool! Thanks for taking the time to put this together and share it. I'm excited to give this a try, music was always so tedious to work with with just the PlayWAV trigger.

READING ISCRIPT AND GRAPHIC RELATED INFO

Iscript and Opcode text files attached to this post.
Iscript and frame related spreadsheet
Technical discussion about opcodes and other things

Before we move onto more complicated things it's important to learn the basics of what iscript is and what it can do. Although we aren't able to edit iscripts, we can manipulate and overlap them which is the next best thing. The hierarchy of the things within the datedit portion of eud editor is important and each serves a specific purpose. In terms of graphics (UI not included) the hierarchy is this: Entity > Sprite > Image

• Unit: A unit is an entity and is a container for 1 sprite. Units are affected by triggers which make them the preferred option to work with but are limited to 1700 with EUDs.
  
• Bullet: A bullet is an entity and is a container for 1 sprite. Like its name suggests it is literally used only for bullets and their hit effects. Bullet related opcodes require attacker and target pointers or crashes will happen. Default limit of 100.
  
• Thingy: A thingy is an entity and is a container for 1 sprite. It does not use flingy.dat and is synonymous with "pure sprites" from SCMD2. As such it is always static and cannot move. Used for things like pre-placed sprites, remnants, trails, etc. Default limit of 500.
  
• Sprite: Sprites are a container for images and must have a parent that is either a unit, bullet, or thingy. A sprite must contain one or more images. If a sprite has no images on a unit it will crash, if on a thingy it will be removed. Default limit of 2500.
  
• Image: Images ultimately determine what something will look like. They cannot exist by themselves and must have a parent sprite. Doodads and units are usually composed of several images such as the main graphic, shadow, and any overlays. Default limit of 5000.
  

Terminology

• Iscript: A collection of opcodes categorized in specific sequences. Directs some behavior relating to flingy.dat, weapons.dat, sprite.dat, and image.dat.
  
• Entity: Something that can be placed onto the map that is either a unit, bullet, or thingy.
  
• Image: A collection of frames. Each frame is associated with a value which can be called with opcodes or direction.
  
• Opcode: Action that tells the image to do a specific function.
  
• Frame: A specific frame for an image. Can also be one game tick, or approx 1/24th of a second.
  
• Frame Set: A set of 17 frames for an image. This covers 180 degrees of rotation, the other 180 will be mirrored. Frame set 0 = 0x00 = frames 0-16, set 1 = 0x11 = frames 17-33, etc.
  
• Frame Calling: Calling a specific frame from an image. Usually done by turning the image to a certain direction within the desired frameset.
  
• Block: A block of code that comprises of a sequence of opcodes. Any named list of opcodes in an iscript is a block.
  
• Wait Block: A block of code composed only of the wait opcode that loops onto itself. Not related to the identically named issue involving wait trigger actions.
  
• Loop/Local: A block of code(s) that will use the goto opcode to form a repeating sequence with itself or several other blocks. i.e. any idle sprite.
  
• Idle: The block(s) an image plays when the unit isn't doing anything. Determined by unit.dat AI actions.
  
• Animation: One of 28 animations that can be called by default. This is what the game tells a unit's image to do. Walking, attacking, dying, etc. are all animations.
  
• Animation Calling: The action of calling of a specific animation. By default units do this normally but it can be used to force a specific animation through orders or other means.
  
• Spell Animation Calling: Calling a specific animation using a spell whose default animation is cast spell (7). The 32 bit version requires valid spell targeting. 64 bit can use none (130) targeting.
  
• Extended Animation: An animation called that is beyond the default 0-27 up to 255.
  
• Image Linking: Forcing a sprite to create an additional desired child image usually by having one iscript create an image, then another, etc. hence the 'linking'. Can be done via specific iscripts or orders.
  
• Rock Doodad: [000] 2/38 Ash Sprite that will occur when an image plays an invalid animation.
  
• Elevation: Elevation determines the priority of what units are displayed above other units. Elevation > Y Position (if elevation is 4 or less) > CSprite subunit flag > CImage index might be the overall priorities. Elevation of a unit images handled in Unit.dat.
  
• Direction: The direction an image faces. An image can have 32 directions for unit/image.dat but for CUnit this is multiplied by 8 for a total of 256. Initial direction on creation handled in Unit.dat.
  
• Flingy: Flingy.dat handles the movement and turning portion of units and bullets. They can be either weapon/flingy controlled which is somewhat physics controlled movement or iscript which is movement defined by the iscript. Flingys technically can also be an entity but this feature is unused and inaccessible.
  
• Overlay: Additional images that are not the main graphic. Essentially just images of a sprite after the first one.
  

Iscripts are very important and I recommend you to learn and memorize them if you want to do any graphic related euds. Iscripts handle many things such as creating bullets, creating new sprites, movement behavior, etc. Iscripts are read from top to bottom and will go down the animation list unless there's an opcode that brings them to a different animation or there's an order that calls an animation.


Example Iscript Header

• #: Image ID, image name, and grp file. This is a list of all the images that use this iscript by default.
  
• IsId: The iscript ID.
  
• Type: The type of iscript. Determines the number of animations an iscript contains.
  
  Animations
  
• Init: The starting animation of the image. Usually this creates a shadow image and whatever else the image does when it's first created.
  
• Death: The ending animation of the image. This will normally kill both the image and the sprite.
  
• GndAttkInit: The start of the ground attack animation. A unit attacking a ground unit will always call this.
  
• AirAttkInit: The beginning of the air attack animation. A unit attacking an air unit will always call this.
  
• GndAttkRpt: The animation for repeated ground attacks. Called after GndAttkInit.
  
• AirAttkRpt: The animation for repeated air attacks. Called after AirAttkInit.
  
• CastSpell: The casting animation used for some spells. Iscripts without this animation that attempt to call it will rock doodad.
  
• GndAttkToIdle: After attacking ground the unit uses this animation.
  
• AirAttkToIdle: After attacking air the unit uses this animation.
  
• Walking: The animation used when the unit moves.
  
• WalkingToIdle: The animation used when the unit stops walking.
  
• SpecialState1: The animation used for special animations. i.e. suicide attacks, building, birthing, etc.
  
• SpecialState2: The animation used for more special animations. Usually related to burrowing.
  
• WarpIn: Warping in animation. All Protoss units have this animation although buildings are the only ones that use it.
  
• None: An invalid animation. This means that the iscript does not have a block for this particular animation and will rock doodad if called.
  

There's also other animations such as those related to buildings or burrowing which I wont go over but you should have a good idea of how they work after reading this.



Image.dat Properties
This section contains how an image behaves as well as some other info. This will cover the Image tab in Eud Editor 2. EE3 uses a different layout but all the information should be around the same.

• Graphic Properties
  
• GRP File: The file an image uses. You'll notice that many images on the list will use the same file. This means they can support the same amount of frames.
  
• Iscript ID: The ID of an iscript.
  
• Draw Function: Determines how an image is drawn. See here.
  
• Remapping: Unsupported.
  
• Preview: Handy feature that displays if the image contains enough frames among other things.
  
• Frame: The specific frame in decimal value. See here for conversions for hex/decimal.
  
• Direction Slider: Feature for turning the unit. Can be used to view specific frames of a unit if given a static iscript like 336.
  
• Script: All the valid animations that the specific iscript can use. Don't use animations with 00000.
  
• Offset: This 5 digit number at the bottom right of the window is the current offset of the image. Not important for 99% of uses.
  
  General Properties
  
• Graphics Turnable: Enables or disables turning for an image.
  
• Use Full Iscript: If unchecked an image can only call the init and death animations.
  
• Clickable: Allows an image to be click selected. Drag selection can still occur unless the unit isn't detected or it has a specific Unit ID.
  
• Draw if Cloaked: Hides the image if cloaked.
  
• Additional Overlay Position: Can generally be ignored unless if the iscript has .lo* opcodes or a subunit. This affects things like geyser gas or turret positions.
  

Reading Iscripts
Iscripts are read from the top down and will continue through animations blocks unless there is a goto or end opcode. Let's read through the Scourge iscript (0). The order in which it's presented wont be the same as the iscript for didactic reasons, although this shouldn't matter much because of the goto opcodes.


It's important to distinguish between animation names and block names as these are usually named similarly and may be confusing at first.

• Animation name: The name of a particular animation. This name is different between datedit and iscript but is similar enough to not confuse it with other animation names. This is what's on the first column in the iscript header.
  
• Block name: The name of a block within an iscript. This is only utilized by that specific iscript and is in the second column in an iscript header.

You'll notice that on some iscripts there's less blocks than there are for animations. This recycling is extremely apparent for iscripts from buildings. Let's look at the Stargate iscript (185).


Despite the Stargate iscript having 8 valid animations there are only 5 blocks with multiple reusing of the StargateIsWorking since it is a wait block. Another thing to take note of is that on images that do not have full turning the playfram opcode is for specific frame instead of a frame set.

There are many playsnd opcodes throughout the iscripts, mostly for death and attack animations. If you wanted to remove or have a different sound this could be difficult to achieve, especially for images that play many frames like the Zerg images.

Hopefully this post gives some insight of how to read iscripts and gives you a better idea of what they do.

Attachments:

Post has been edited 27 time(s), last time on Jul 30 2025, 8:11 pm by Sie_Sayoka.

APPLYING ISCRIPTS
iDoodler's Iscript Notes
Frame and Animation Calling Reference

Now that you know how to read iscripts we can begin to change iscripts of images. Practical uses can range from simple things like static effects to very complex like image linking with extended animations. In this post I'll cover some simple examples as well as go over the basics of image linking, animation calling, and frame calling. First let's start with a very simple decoration. The objective would be to have an animated phase distruptor image (523) on a unit that we can move around.


If we use the phase diruptor image on a unit or thingy with the default iscript (234) it will crash (see bottom of post for info) so we will need to change its iscript. By looking at this the image has a total of 5 frames that are played with 1 waits inbetween. So we would want to search for an iscript that does this loop without the nasty opcodes.


The defense matrix overlay iscript (300) has the same frames and waits so let's use it.


Ensure that use full iscript is unchecked as this will only allow the image to call the init/death animations. This means we can move the unit around and not have it call walking animations. Graphics turnable should also be unchecked since the phase disruptor image does not have a full frame set.


We'll change the guardian sprite (144) to the phase disruptor image (523) and create a guardian. It's important to note that if use full iscript is unchecked or if the iscript does not have move opcodes the unit's move control in the flingy tab cannot be iscript.bin control.


And it works!


Next we'll make a vulture that can attack air. As you can see the vulture iscript (86) lacks air attack animations and will rock doodad if it calls these.


Let's replace the vulture iscript with the wraith iscript (82). We'll also need to add the fragmentation grenade air weapon on the vulture in the unit tab as well as allow air targeting in the weapon tab.


This does work but it introduces a new set of issues. Most air unit images have bobbing as well as engine thrusters and there's also the wraith shadow under the vulture that needs to be taken care of. All 3 of these problems can be solved by simply cloaking or giving 0x100/0x200 cunit status but then it'd be cloaked and come with the same issues of detection that cloak does. If you're fine with that you can stop here but if you wanted to solve all 3 of these problems continue.


When an image with the wraith iscript moves it creates image 245 at the start of its movement. This image is not refreshed until the wraith stops then starts walking again.


As there's no perfect options we'll just give it iscript 250 to hide it after 2 frames. Draw function 8 will make it harder to notice for the 2 frames that it is visible.


The wraith bobbing is caused from this block where the vertical position of the image shifts between 0 and 2 pixels. When the wraith stops attacking or stops walking it will always call this animation. You will find similar circumstances for almost all the air unit iscripts. There is no (good) way to solve this without using CUnit.

Option 1: Animation Call a Wait Block
You can directly call the wait block animation with extended animations. I wont go over this method since it will be covered in future posts.


Option 2: Set Movement Flags to 0x2
When a flingy.dat movement control unit that has stopped moves and then stops again the movement flag process is this: none 0x0 > accelerating 0x2 > moving 0x10 > braking 0x4 > none 0x0. When the unit has the 0x2 flag it will call the WraithWalking animation which then has a goto WraithLocal00 which is a wait block. By default this wait block will only happen if the wraith is moving or attacking but our goal would be to force this when the wraith is idle.

Ultimately both methods are different ways to reach a wait block. Option 2 is cleaner since it will not require you to change a spell's animation value.


The trigger conditions is if the movement state is idle and if the movement flag is also idle. The action will apply the accelerating movement flag which calls the wait block. Note that this wont apply when the unit is created but will apply every time after the unit first moves.

The shadow will be the most difficult part to solve as there's no easy way to emulate how the vulture shadow both looks and behaves.

Option 1: Use a Separate Unit as the Vulture Shadow
We can create another unit with the vulture (256) or vulture shadow (257) image with draw function 10. Then every frame read the vulture's direction and move this shadow unit to be 7 pixels below the vulture. Visually it'd be identical but comes with other issues like collision and using a unit slot which must be dealt with.

Option 2: Image Linking
You could use image linking to have everything be on a single unit. However it's a pretty convoluted process to just get a shadow image and usually it's just not worth it.

Option 3: No Shadow
The easiest and recommended option. Having no shadow on the unit has no side effects unlike the other options. Giving the wraith shadow image (244) iscript 250 will remove it.


I'll opt to do option 2 even though its much more complicated. Option 1 did work but there were issues with the vulture phasing through units since the isgathering status is required. The triggers for that are disabled in the example map and you may enable them to test if you'd like.

Here's an explanation of what was done:

• One frame after the unit is created it will be given the defense matrix status timer of 2. This timer means that the unit will have matrix for 2 frames. Simply adding this timer alone will not create a matrix image. Matrix was chosen because it creates two images, one of them is with the imgul opcode which is what we want. If used with imgol then the vulture shadow will be created on the same elevation as the vulture and because of priority the shadow will display over it.
  
• Two frames after the unit is created it is given order 42, unit morph. This is to refresh the unit's image and allow it to display the matrix image.
  
• Order state 0x2 and order signal 0x4 are required to properly follow through with the order.
  
• Build queue 1 to create its own unit ID is required as leaving this empty will result in a crash. The unit is essentially morphing into itself.
  
• Defense matrix back small image (374) is given the vulture iscript (86) so it will create a vulture shadow.
  
• 3 frames after the unit is created the matrix will expire and its image removed. However, the vulture shadow will remain.
  

The vulture will now behave mostly identically to a normal vulture. However there is still the issue of iscript using the wraith playsnd opcode when it dies instead of the vulture sound.


After the vulture is created we will give it the 0x4 user action flag. This flag makes it so that the unit doesn't play a death animation (and therefore the wraith sound) when it dies.


When the vulture receive a die order it will create a dropship with a vulture iscript and be killed. This will create both the explosion and vulture death sound that we need. With this our journey to get a vulture to attack air is complete. It ended up being a bit more complicated than I was expecting but I'm happy with the result.

In the example map you may kill the vulture as many times as you'd like with Kerrigan. Everything should be fairly similar to how a regular vulture behaves with the exception of a few frames on the unit creation. It could be cleaned up a bit further by giving the matrix images draw function 8 and ordering move or something so the vulture moves and doesn't bob.



Animation Calling
Because we are able to call ANY animation set using the previously mentioned method we can do a number of interesting things.

One of them would be attacking with units that normally wouldn't be able to attack because of iscript limitations. We can even get ground/air only attacking units to attack everything. However, the basic rules of iscripts still apply meaning that the image must have an opcode that can apply damage be it either through a weapon or a spell. With animation calling we can:

• Ground only attacking units attacking air and vice versa without changing iscript
  
• Non-attacking units such as medics being able to attack
  
• Creation of additional images onto the sprite for image linking purposes
  
• Cosmetic effects such as warp-in animations for Protoss units
  
• Specific animations such as walking without the unit actually having to walk
  
• Use of extended animations for more complex systems, see future posts
  

We'll do a simple animation call first. This one does not rely on the spell method and instead uses the unused warp in animation which is fully functional. Protoss buildings use a different function. To animation call warp in set the order ID to 174 which will call animation 21. Set order state 0 and order signal 1. This will create the dragoon warp flash image (125) using the imgol opcode.


We can do some fun stuff with additional images.

• Phase disruptor weapon behavior set to 8 for demonstration purposes.
  
• Set dragoon image (122) draw function 13. This makes the dragoon green.
  
• Set dragoon warp flash image (125) draw function to 5. This makes the warp flash image transparent.
  
• Set dragoon warp flash image (125) to iscript 153. This allows the dragoon image to use attacking animations.
  
• Set dragoon warp flash image (125) to graphics turnable and use full iscript.
  

The dragoon iscript (21) will use the attackwith opcode. Because there are 2 dragoon images using this iscript it will attack twice. This can be done multiple times to increase the amount of projectiles and therefore damage a unit can do in one volley. Warp in order 174 will replace the overlay image so you must use the spell animation method for more than 1 overlay.

Melee Air Attacking

Normally iscripts that do melee damage are not capable of attacking air units for much the same reason why the vulture couldn't. However, because many melee units utilize multiple framesets as well as the entire ordeal we had to do just to emulate the regular look and behavior of the vulture, simply changing the iscript of an image will result in a lot of broken things. Animation calling would solve these issues as the only reason why melee iscripts can't attack air is that they lack a valid air attack animation. In this example we will use the ground attack animation to replace the invalid air attack animation.

I'll demonstrate the spell animation calling method. This will allow you to use certain order IDs and change their animation value to any value between 0-255. This will only work on order IDs that, by default, have the cast spell animation. Full list of orders with changeable animations can be found here under anim calling tab.


This is the zergling iscript (31) ZerglingGndAttkInit block which the zergling will call if it plays animations 2 or 5. The key opcode is attackmelee which plays a sound and does not utilize bullets. Gotorepeatattk and goto ZerglingGndAttkToIdle opcodes are also relevant which will be explained later.

1. Unit tab > [037] Zerg Zergling > Basic > Air Weapon > 35 Claws
   
2. Weapon tab > [035] Claws (Normal) > Target Flags > Air > checked
   
3. Unit tab > [037] Zerg Zergling > AI Actions > Attack Unit > 113 Cast Spell (Yamato Gun)
   
4. Unit tab > [037] Zerg Zergling > AI Actions > Right-Click Action > 2 Normal Movement / No Attack //right click attack is broken when used with spells
   You can also copy/paste from order [010] Attack Unit (Normal) to [113] Cast Spell (Yamato Gun)
   
5. Order tab > [113] Cast Spell (Yamato Gun) > Targeting > 35 Claws (Normal)
   
6. Order tab > [113] Cast Spell (Yamato Gun) > Energy > 44 None
   
7. Order tab > [113] Cast Spell (Yamato Gun) > Animation > 2 Ground Attack - Initial //5 would also work for zergling iscript specifically
   
8. Order tab > [113] Cast Spell (Yamato Gun) > Can be Queued > checked
   
   

Effectively what this does it make the yamato gun order (113) call animation 2 which is a valid animation on the zergling iscript. Changing the AI action of attack unit will make both air/ground attacking animations call order 113 instead of order 10 which ultimately calls animation 2. Which again, is valid so the zergling should be able to attack air now.


The ling can definitely attack air now but it only does it once without being reordered. Let's find out why that is.


The gotorepeatattk only applies if the order state is not 0x2 and since we are using a spell order the unit is stuck on order state 0x2 (probably). It then uses goto ZerglingGndAttkToIdle which ultimately leads to a wait block which is why it gets stuck.


If we change the order state from 0x2 to 0x1 it should be able to use the gotorepeatattk opcode.


The ling can now attack repeatedly.

Hold position near an enemy air unit will cause a rock doodad because the order will attempt to call the invalid air attack animation. We can't change the animation that the hold position order (107) uses but we can change the order itself. Some of our options are [136] Hold Position (Suicide Units) which will prevent the unit from attacking entirely or [001] Stop which is just the normal stop order. If you're feeling ambitious you can make your own fake order with triggers that prevent the unit from moving and call order 113 if in range.

I'm not sure if the right click functionality can be fixed or emulated. Supposedly the unknown value in the order tab would work if set to 173 but I couldn't get it working.



Things to Be Aware Of
There are many things that can either produce rock doodads, crash, or cause other undesirable effects when messing around with iscripts. The most common cause of crashes from iscripts occur when an entity has a null pointer. Basically the opcode tries to do something with a dat file that the entity cannot use. Certain entities are able to run iscripts containing these opcodes but must never call said opcodes. Refer to the entity crashes tab for specific opcodes.

• Attack Opcodes: These are opcodes that use a weapon. Bullets and thingies do not have weapons.
  
• Bullet Opcodes: These are opcodes that directly do damage from a bullet. A target can't be assigned for a unit or thingy.
  
• Bullet Iscripts: These are iscripts that contain bullet opcodes. Units can use these iscripts but only if the image with a bullet iscript is not created on the same frame that the unit was created. You also cannot let the unit call the death animation.
  
• Flingy Opcodes: Normally used for turning and moving a unit. Thingies do not have flingy.dat.
  
• Order Opcodes: These are order related opcodes. Thingies do not have orders.dat.
  
• No Images in Sprite: A unit or bullet? with no images in its sprite will cause a crash. Thingies are the only entity that can have no images which will cause the thingy to be removed.
  
• Rock Doodads: Ensure that the iscripts you use can support the animations that are called. Checking use full iscript should mitigate this greatly at the cost of less animations. All iscripts have an init animation and most have death.
  
• Insufficient Frames: Using an iscript that plays a frame that the image doesn't have will result in the image becoming invisible. This is not permanent and you just need to play a frame the image does have.
  
• .LO Opcodes: Only certain images have .lo* files and can use these opcodes. .lo* files are also required for subunits. An image that calls a .lo* opcode without the required file will crash.
  
• Maxing Out Limits: Ensure that entities that are not needed are properly removed as just hiding them can result in reaching the sprite and/or thingy limit fairly quickly. Giving iscript 250 to unwanted images is a good way to remove unwanted thingies and images quickly.
  

Explanation of using bullet iscripts on a unit. Note that thingies could probably run bullet iscripts if the sigorder opcodes were not on init. However sigorder is present on all bullet iscripts.


Above is an example of an invalid animation. In underlined opcode is the rock doodad sprite which is created at 132 Y pixels. A unit should be fine after a rock doodad is called but a thingy will crash since there is flingy opcodes.

Attachments:

Post has been edited 19 time(s), last time on Jul 7 2025, 8:35 am by Sie_Sayoka.

Hello. I have created a Naver account to looks at the "cafe books". I can't access the "Simple way to use EUD's" it comes up blank or asks me something in Korean in a new window which i cant translate, but when I click accept it takes me to "Real ID" page where they are asking for my passport for identification. Any help would be greatly appreciated.

Attachments:

I'm going to dump some stuff that I've worked on over the years. Mostly pictures and I forget which maps I used for them and they may have been overwritten anyway. Hopefully this will let people know what is possible and perhaps some inspiration.

haah this is wild good stuff thanks for uploading

Static Unit Stacking

Disabling collision is still the best way to stack units as it doesn't have any side effects nor requirements. However there are a few other methods to consider that may fit niche purposes, namely not using CUnit. Testing for my purposes have been only for visuals and no functionality will be explored. See full unit id list for further details about quirks.

Burrowing:

• Overrides some cloak type draw functions
  
• Limited to burrowing unit IDs?

0 Unit Size Buildings:

• Aligns to grid
  
• Battle Reactions flag must be checked for directional frames
  
• First frame on creation for buildings is always invisible

Door Unit IDs:

• Cannot be moved with triggers.
  
• Cannot be selected.
  
• Staredit trigger flags must be checked.

Beacon Unit IDs:

• Shows on minimap.
  
• Can be placed and moved anywhere.
  

Order 17 Move Unit:
Thanks to DarkenedFantasies for teaching me this method.

• Directly moves units to specific map position without move unit triggers nor locations.
  
• Because of the above point unit IDs (doors, traps, etc.) that cannot normally be moved can be moved with this method.
  
• Ignores placement requirements, units will attempt to path out if not kept in place.
  
• Single Entity flag must be checked.
  

Post has been edited 11 time(s), last time on May 27 2025, 11:45 pm by Sie_Sayoka.

Rain



This is a test map I made attempting to get good rain effects. It's not perfect and I think I can achieve better through a different system. It utilizes order 17 move unit (described in previous post) as well as warp in texture overlay. Needle spines (35) and explosion1 (213) images are used for the raindrops and splashes. Although it didn't serve its purpose of having a good rain effect I believe this could be useful for falling snow if slowed down.

Attachments:

Frame & Animation Calling Pt.2



We can now frame call almost any frame from any image using this method. This would be useful for many things but requires units, not sprites, to produce the visuals. Possible uses would be to produce animations that do not have sound or other undesirable opcodes, specific frames for decorations, custom animations, mirrored frames, reversing animations, etc. It is, however, not simple and may require some tedium depending on your desired effect. Big thanks to ldcv for showing me that we can use up to 255 animations, not just the default 29.

List of frames and required calling animations
ldcv's iscript decompiler tool


In the example I wanted to produce frames for the Rhynadon death. If we look at the iscript it uses some pretty high number frames that we wont be able to get by just having the Rhynadon with a different iscript. 0xbb in hex is 187 in decimal and it ends on 0xc2 (frame 194). Frame sets are multiple frames that (usually) have variations depending on each direction of the unit however with deaths its just for progressing the animation. With that in mind our goal would be to use frame set 11 on the Rhynadon image however all frame set 11s are embedded within animations that have other frame sets within them.

We know that the Local animation block will keep an image on the same frame indefinitely until a new animation has been called. This can be seen sometimes in the behavior of High Templars where they don't revert to idle animation as the local block is right after their attack and cast animations. So we can animation call a local animation block to keep the Rhynadon image on the frame set that we want. Animation calling has some cooldown that is around 3 frames long and I'm not sure if that can be shortened. So we will want to search through the iscripts for frame set 11 (0xbb) that is played at least 3 frames into the animation.


The Ghost walking animation fits. We will need to wait 8 frames after the walking animation has been called then call a local animation.



Normally, within the default 29 animations, there are no animations that call the local animation block. However animations past this number will attempt to choose a valid animation from somewhere in existing iscripts. This is also true for the default animations where the iscript does not have a particular animation listed such as the Ghost's Unused1 or Warpin animations. If you look at the iscript decompiler the 155 animation is a local animation block.

datedit>sprite>[229] Ghost>Image>340 Rhynadon
datedit>image>[340] Rhynadon>iscript ID>70 ghost

This will make the Ghost unit have the Rhynadon image with a Ghost iscript.

datedit>order>[115] Cast Spell Lockdown>targeting>130 None
datedit>order>[115] Cast Spell Lockdown>energy>130 None
datedit>order>[115] Cast Spell Lockdown>animation>11 Walking
datedit>order>[115] Cast Spell Lockdown>use weapon targeting>uncheck

This removes all requirements for casting the lockdown spell through triggers.


With this the Rhynadon image should display the first frame, 0xbb (187) of its death animation. However we still need to play the other frames. To do so we change its direction.


In the example map you can press the Q and E keys to go through the different frames of the Rhynadon death animation. So with this example we are able to both get the Rhynadon death animation without sound and have the mirrored frames.

Only lurker death frames are inaccessible since that image uses an obscene amount of frame sets. If you want a lurker death animation you will have to kill one the old fashioned way.

Attachments:

Post has been edited 5 time(s), last time on Jul 30 2025, 8:13 pm by Sie_Sayoka.

Draw Functions and Unit Colors

This post will talk about all the different ways to color images. Other than draw functions there are a few other ways to change how the unit looks. If combined with stacking techniques, either through image linking or plain unit stacking there will be be potential for several combinations and applications.

Draw Function Rules:

• Only one draw function can be applied on an image.
  
• Once an image is created it is stuck with the draw function it was created with.
  
• If you would like to change a unit's image you may use morphing which will reset its images.
  

Draw function 0

Normal draw function. Used by the vast majority of images. When cloaking it will cycle through draw functions 2-4 if viewer has no detection or 5-7 if viewer does have detection.



Draw function 1

Used by hallucinations that are not owned by self and overlays.



Draw function 2

Non-detection cloaking animation. Identical animation to an enemy cloaking if you don't have detection.

• First frame will start the cloaking sequence.
  
• Cloaking animations take 24 frames to complete visually.
  
• Uncloaking animation take 28 frames to complete visually.
  
• Every 4 frames will progress through a stage of a cloaking animation.
  
• When the image is fully cloaked it will play the cloaking sound for the owner.
  
• When the image decloaks it will play the decloaking sound for everyone.
  
• Cloaking starts with the darkest pixels of an image to the lightest.
  
• Decloaking is the same animation in reverse, although it appears there is an extra frame.
  
• Cloak type draw functions have different behaviors depending on detection and cloak status.
  
• Applying draw function 2, 4, 5, and 7 to a thingy will result in a crash since these apply cunit status flags.
  

Draw function 3

Non-detection cloaked. No animation, visual blur.



Draw function 4

Non-detection uncloaking animation. AFAIK not possible to do through the draw function alone. Instead I used create unit with properties for a unit with 0 energy so it uncloaks. This requires an extra frame at the start since the uncloaking secondary order needs to process. Can be ordered with triggers directly as well.

Cloak, secondary order 109
Wait 1 frame for order to process
Nothing, order 23
Decloaking begins on next frame


Draw function 5

Detection cloaking animation. Image is transparent as if your own units cloak.



Draw function 6

Detection cloaked.



Draw function 7

Detection uncloaking. Same issues with 4.



Draw function 8

EMP effect used by image 319. Similar, but different, to draw function 3. Not affected by vision nor detection.


On the left is an archon energy image with draw function 3, on the right is the same with draw function 8. There are some subtle differences in how it displaces pixels. Draw function 3 will distort everything below its elevation. Draw function 8 will distort everything at all elevations. If an image is above in elevation of draw function 8 it will not be affected this can result in an image appearing to be doubled.

• Draw function 8 will distort more than draw function 3.
  
• Draw function 8 favors distorting pixels to the left.
  
• A brighter image will distort more than a darker one.
  
• Stacking draw functions 3 or 8 directly on top of each other using a flat image (i.e. shadows) will not result in more distortion.
  
• Stacking both draw function 3 and 8 will result in more distortion.
  
• Because the distortion works for x axis you can stagger images along this axis for more distortion for flat images.

Draw function 9

Remapping is not supported. Mostly functionally identical to 1. For most (all?) images it doesn't do anything. Most images that have remapping by default have their base image of the same color anyway.



Draw function 10

Transparent shadow.



Draw function 11

Used by HP bars. Crashes if viewed because of a null value where a unit pointer should be. Not possible to change this fact with EUDs as it requires CImage support. Possible uses to prank black sheep wall cheaters or map hackers.



Draw function 12

Warp texture mask in SD. Invisible in on frames 0-3 for HD.

Uses frame 0 of the warp texture image. If an image has draw function 12 and iscript 193 (or any opcode with warpoverlay) it will play through the frames of image 210. On HD, frames 0-3 are invisible but frames 4-19 will be visible with increasing levels of opacity. See iscript 193 section for HD compatible manipulating.



Draw function 13

Selection circle draw function.

Normally will only display green. Colors based on this address. See iscript 193 section for manipulating.

0: Self/Ally, green (only achievable without using iscript 193)
1: Neutral, yellow (if stopped on same frame as creation)
2: Enemy, red
3: Black
4+: Random based on tileset palette and game session



Draw function 14

Flag color draw function. In remastered this is broken. Functionally identical 1.

1.16.1 only:

• Used by flags to keep color when picked up.
  
• Will keep original player color despite give.

Draw function 15

Used for building placement outlines like landing near addons or refineries. Creates a green rectangle based on the size of the image.



Draw function 16

Recolors image to blue. Used by hallucinations owned by self.



Draw function 17

Warp flash draw function. Unused warp in system for Protoss units. Used by Protoss buildings.

• Around 48 frames to fade out.
  
• Every 3 frames will increase transparency.
  
• After 48 frames it will play the death animation.
  
• After 48 frames removes the image. Useful for image linking as this removes the image without the iscript needing the end opcode.
  
• Will refresh itself if direction or animation block changes.
  
• Will crash on death animation with certain iscripts. This is caused by the unit's sprite not having any images.

If the iscript lacks a death animation and given this draw function it will eventually play out the engset opcode from an invalid animation. The result would be an image of pure white that does not fade but it comes with the complication of it switching between different frame sets.


Warp Texture Building Animation

See this article.

• Used by Protoss buildings when construction is completed.
  
• Can overlay any image for a unit.
  
• Specific frame of the warp texture image is dependent on timing the animation is canceled on.
  
• 19 total overlay frames.
  
• Units applied with this method are fully functional.

Iscript 193 Warp Texture

Iscript 193 has very special properties that is useful for several applications. It contains the warpoverlay opcode which is unique to this iscript.

• Warp texture progresses its animation through the warpoverlay opcode.
  
• Warpoverlay uses the same data as both cloaking and color data.
  
• Setting iscript 193 to an image with a cloaking draw function will have its animation speed up by 4x. See image above. However, because cloaking is based on a timer you cannot pause the cloaking animations through these means.
  
• Setting iscript 193 to an image with draw function 12 will have it progress through the warping animation. Can be canceled on specific frame with animation calling.
  
• Setting iscript 193 to an image with draw function 13 will have it progress through its colors.

There are several ways to have the unit stay on a specific color for draw function 13. The best way I know is using iscript 193 and animation calling a local animation (animation 115). This system is described in the previous post. See Useful Iscript IDs tab for iscripts with warpoverlay opcodes.



Unlinking Units and Sprites

Unlinking a unit from the active units list will cause the image to not be updated anymore. This means that we can pause an image on a frame that we would not normally be able to do otherwise.

• Draw functions 2, 4, 5, 7, and 17 can have their animations paused on a specific frame.
  
• Unlinked units cannot receive orders.
  
• Unlinked units cannot change direction.
  
• Unlinked units can be moved via triggers.
  
• Unlinked units are visible in fog and can be selected.
  
• Changing a player's color does update on the unlinked unit

Hiding/Removing images

If you wanted an image to be completely invisible there are 6 options.

• You can hide the entire thingy sprite by unchecking the visible flag in the sprite section. Good to use for the rock doodad, [000] 2/38 Ash sprite.
  
• Uncheck draw if cloaked in the image section, cloak the unit.
  
• Give the image iscript 250 and it will disappear after 2 frames. Destroys image, don't use on parent image since this may have side effects.
  
• Frame call a frame that the image doesn't have. To prevent the rock doodad the called frame must be within an image set the image has.
  
• Draw function 17, wait 48 frames. Removes image.
  
• Calling an extended animation with an end opcode specific to that iscript. Removes image.
  
• Call an animation that has an end opcode. Use extended animations for specific iscripts. Removes image.
  
• If the image is from a spell overlay e.g. ensnare, lockdown, then it will be removed when its respective status timer reaches 0.
  
• If the sprite is on a bullet with a bullet iscript it will be removed when the bullet timer is 0.

The example map displays all the different draw functions and all of the visual effects you can do with a scout image. Each row represents each draw function. Cloaking transitional draw functions are cycled every 4 frames. Draw function 12 every frame. Draw function 17 every 3 frames. Unlinking is not included in the example map and will be covered in a future post. To bring images to the next level you can incorporate stacking units with different draw functions to bring more variation into your maps.

Attachments:

Post has been edited 41 time(s), last time on Jul 19 2025, 7:41 am by Sie_Sayoka.

Followmaingraphic Opcode


The followmaingraphic opcode is special in that, as its name suggests, does whatever the main (parent) image does. It is used by shadows to keep the same directional and animation frames as the unit. It is also used in some other iscripts such as the warp flash (192) to do much the same. It cannot use opcodes.

Terminology:

• Sprite, a container for one or more images. An image cannot exist without a sprite. A sprite cannot exist without images. A non-unit sprite without images will be removed, a unit sprite without images will crash.
  
• Bullets/Thingys, similar to sprites but are in a different category. Not relevant for this discussion although you can probably apply mentioned methods to these.
  
• Primary Image/Parent Image, the main graphic(image) of the sprite. Dictates certain actions of what the sprite does and displays such as movement, attacks, dying, etc. This is what followmaingraphic follows.
  
• Image Head, the first image on a sprite. Usually the same as the parent image.
  
• Child Image, all the other images that aren't the parent. Usually shadows, engine effects, and overlays.
  
• Image Tail, the last image on a sprite.
  
• Orphan, a sprite without a parent image.
  
• Sprite Linking, having a sprite be dictated by another sprite through orphaning and followmaingraphic or other related opcodes.
  

So with this in mind, what would happen if we remove the parent image that the child image is following? To remove an image it either needs to have draw function 17 or call an animation that has the end opcode.


In this example I create a Scout unit with draw function 17. After the scout's image plays the death animation the scout shadow, with draw function 0 for clarity, is an orphan. After I create a Wraith which becomes the new parent for the Scout shadow. Effectively this will allow for control of a unit's image from another unit.



Instead of using draw function 17 (which will crash when used on thingy sprites) let's use Scourge death iscript instead. Any Zerg air unit death iscript will work with what we need. On init it has both the imgol and end opcodes. When this iscript is used on an image it will create image 59 then remove itself which means that the sprite will still have an image in it. We can then image link to a drone shadow by giving image 59 iscript 11.


Because we are dealing with CImage stuff which is unsupported, confusing, and dynamic let's run a few tests to see how some things work. In this test I'll create 3 scouts that have their parent images removed and have drone shadow children images. Then after a short delay to ensure the parent images are removed I'll create 3 dark templars. Dark templar iscripts are used since they only have 1 image per sprite as they do not produce shadows.


The first DT created is ignored but the subsequent DTs become parents. We can conclude that in the previous test the scout shadow was following the wraith shadow image, not the main wraith.



I'll create a 4th DT so all 3 of the drone shadow orphans have parents. There are some applications for this. Because the orphaned images do not follow the unit they belong to we can use this to frame call units that are moving if use full iscript is unchecked.


For the next test I'll create 1 DT then 1 Archon. Archon sprites consist of 3 images normally, the energy (image 134), being (image 135), and swirls (image136). As a result the archon sprite becomes the parent for all 3 drones. Applications would be to frame call multiple different sprites with a single unit.


Next test would be to see what happens if we remove and add images to the image list. Vulture shadows (image 257) are given iscript 250 which will be removed after 2 frames. Because of this delay we stagger creating them.


The first created vulture affects the second created drone. The second vulture affects the first drone. The third vulture and drone don't interact with each other.


We'll test again with DTs. Different results than with vultures. Same results regardless of staggering create or not. I don't fully understand how the game handles the image list but it will definitely get more complicated when images are removed. It's recommended to use this on game start.


Frame Calling Thingies

Normally sprites cannot have actions applied to them once created since those addresses are unsupported. However with this technique we will be able to frame call a thingies. Draw function 17 will crash if allowed to play its death animation on the parent image. So we will use iscript 2 again. Thingies are not units so the normal tricks we use like orders, actions, CUnit, etc. wont work and everything must be handled through iscript.



If we give image 59 the shadow header iscript 275 it will be an orphan and allow us to frame call this sprite using scanner sweep.


You can use image linking to pick what orphan sprite you want to use. Be aware that image linking iscripts with turning idle animations may crash as these animations call opcodes related to flingy.dat which thingies do not have. Unfortunately because followmaingraphic can not use opcodes we cannot remove a sprite using this method.

Attachments:

Post has been edited 11 time(s), last time on Sep 4 2025, 5:48 am by Sie_Sayoka.

Applying Draw Functions

This discussion will cover draw functions 2, 4, 5, 7, 13, and 17; basically all of the draw functions that each have timers to progress through their animation and are thus the hardest to work with. The simplest approach would be to do what I did in the example map and have a large cache of units, these can then be moved on a specific frame to the desired location. However on larger scales, and depending on the specific application needed this could quickly eat a large amount of your unit limit. Thus the methods mentioned here will focus on reducing the required amount of units to just 1 each.


These 8 visible units would normally take somewhere around 15 if used with a cache system. However there's only 8 units on this map.


Animation Calling Wait Block

This was mentioned in some of the previous posts but I'll explain it in further detail here. When draw function 13 is used in conjunction with iscript 193 it will cycle through different colors.

• 0: Self/Ally, green (only achievable without using iscript 193)
  
• 1: Neutral, yellow (if stopped on same frame as creation)
  
• 2: Enemy, red
  
• 3: Black
  
• 4+: Random, based on game session and tileset palette.

When on a specific frame the unit is given the lockdown order with animation 115. Animation 115 for iscript 193 is a wait block and thus it will be perpetually that color until another animation is called.

Warp In Order

The unused warp in order is fully functional and will create a white image of any Protoss unit that also has the warp flash image. See image tab in Dat edit.

• Order State 0x0
  
• Order Signal 0x1
  
• Warp Flash image's iscript 250. Not necessary if using order order 174. If using spell animation calling will reduce image count from 48 to 2.

Every trigger cycle the Zealot is given order 174. This continually refreshes the warp flash image and it maintains the visuals of being pure white. Because the iscript was changed the frames don't match the Zealot image below. This can simply be hidden by cloaking it and unchecking draw if cloaked. Alternatively you can just create/remove a zealot with the warp flash draw function every frame which would still only use 1 unit. Order 174 will replace the warp flash image whilst spell orders will add.


Animation Calling Init




This method will repeatedly animation call init every frame to maintain the image at warpoverlay 0. Because warpoverlay also affects cloaking timers we can use this to keep the unit at the initial cloaking sequence.

Animation Calling Warpoverlay


The extended animations for iscripts 398 and 400 have their animations start at warpoverlay 2 so the cloaking sequence will be a little bit further along. Because it's technically an invalid animation there's a bunch of garbage opcodes in it as well. As you can tell from the first picture the directions are a little messed up. See here under the useful iscript IDs tab for more warpoverlay animations.

The triggers in the example map are a bit inefficient but easily readable. I think there were issues occurring because I was changing the lockdown animation dat address too much within a single trigger cycle which is why some use the yamato cannon spell as well.

Attachments:

Post has been edited 2 time(s), last time on Aug 13 2025, 3:54 am by Sie_Sayoka.

Engine Opcodes
ldcv's iscript decompiler tool
SC calling and iscripts

The engset and engframe opcodes operate similarly to the followmaingraphic opcode in that they read the frame the parent image uses but the frame that is displayed may use a different frame set. Normally engset and engframe are used for the engine thruster images of flying units and SCVs to display the animated exhaust of the engines when moving.

Followmaingraphic:
For engines, used by carrier and shuttle to only display a single frame set. This is, of course, not animated.

Engframe:
Used by scout, wraith, and corsair engines. Does the same thing followmaingraphic does on engframe 0. Engframe 17 simply adds 17 to the frame value (probably).

Engset:
Exclusive to engines/glow header iscript 291. Used by most engines. Does the same thing followmaingraphic does on engset 0. Engset 1 will add ALL the frames a parent image contains. For example on a dropship which only has 1 frame set (total 17 frames) it will play between frames 17 and 33 on engframe 1. For an arbiter which has 2 frame sets (total 34 frames) it will play between frames 34 and 51. Because of this, an image using an engset opcode will require at least twice as many frames as the parent image in order to display.


Yellow scout is using engset opcode and following the wraith. Wraith only has frame set 0 but scout has sets 0 and 1. Scout image will play through frame sets 0 and 1.


Example of using engset following a same image as itself. Yellow scout is cycling through frame set 0 and frame set 2, which the scout doesn't have for the latter.


The engset opcode, despite its weirdness, is interesting in that it can be called on every iscript by playing an invalid animation. After calling an invalid animation the image will go into an engset loop after 66 frames. If the parent image uses the same image ID as the image in this loop it will only be displayed every other frame as engset 1 will be invisible as it calls a frame that the image doesn't have. If we use 2 units and offset the time that one them calls the invalid animation and then stack them we should be able to emulate followmaingraphic.

The reason for doing this would be to use the draw function 13 colors that can be frame called. For images with only 1 frame set this can be done easily but if they cycle through multiple frame sets it becomes much more difficult. As all the iscripts with warpoverlay do not have walking or attacking frames nor followmaingraphic we will use engset to accomplish this. The objective for this example would be to get a yellow zealot that can walk around and attack.

As the process is fairly complicated I wont go into detail but I'll give the basics of what I did.

• Frame 1: 2 units are created with zealot image 151 and iscript 163, the defaults.
  
• Frame 1: Zealot death and zealot warp flash images 153 and 154 with fleet beacon iscript 190 are image linked to the unit's sprite. One with draw function 13 the other with 6. This makes a green zealot image under a transparent zealot. It'd probably be better to animation call warp in for both of these images instead.
  
• Frame 2: Animation 42 is animation called for the first unit. This calls the warpoverlay opcode.
  
• Frame 3: Animation 204 is called for the first unit, this removes the image with the zealot iscript in 6 frames.
  
• Frame 3: Animation 42 is animation called for the second unit.
  
• Frame 4: Animation 204 is called for the second unit.
  
• Frame 4: At this point both parent images will be removed in 5 frames. If these orphans are allowed to reach the engset opcode in 63 frames without having a parent the game will crash.
  
• Frame 6: A third unit is created with image 151 and iscript 163, the defaults. This is done before the parents of the first two units are removed.
  
• Frame 8: The parent image for the first unit is removed
  
• Frame 9: The parent image for the second unit is removed
  
• Frame 10-12: Third unit calls animation 21 three times after the parent images for the first two images are removed. This creates 3 new images, the second and third ones being new parents.
  
• Frame 66: The first engset opcode is played.
  
• Frame 69: The first and second units enter the engset loop and will follow the frames of the third unit.
  
• Frame 70: The first two units are moved every frame to the third unit. The third unit is invisible and may be ordered around normally.
  

It's a convoluted process but this is the only way I know of to get a truly animated yellow/red unit. For black it would be better to just stack a bunch of draw function 10 images on a unit. It's also not perfect as it seems the frames are only updated once every other frame for reasons. This may also work for the pure white from draw function 17 as well.

Attachments:

Post has been edited 4 time(s), last time on Jun 24 2025, 10:09 am by Sie_Sayoka.

IMAGE LINKING PT. 2
Animation Calling, Image Linking tabs
ldcv's Iscript Decompiler

Image linking is a system that forcibly adds an additional image(s) onto a sprite. This can be done through a variety of methods but, depending on the image added, usually involves chaining multiple images with an iscript that has the imgulnextid opcode. There are many applications for image linking both aesthetic and practical. Here are opcodes that create images:

• Imgol, creates image overlay. Creates image over the target image. Used for a variety of purposes.
  
• Imgul, creates image underlay. Creates image under the target image. Used mostly for shadows.
  
• Imgolorig, exclusive to BC iscript 66. Probably creates image overlay using lo offsets.
  
• Imgoluselo, creates image overlay using lo offsets. Requires .lo* file for image or crash. Used for turrets and attack overlays.
  
• Imguluselo, exclusive to unknown iscript 316. Requires .lo* file for image or crash.
  
• Imgulnextid, creates image underlay of the next ID in the image ID list. Exclusive to iscripts 151, 337, and 387.
  

There are several methods that can be used to create images. The best method used will depend on the image you want created and may require a combination of methods.

• Opcodes. The opcode on an iscript creates an image either through its init sequence or from a specific order being called.
  
• Status overlay, morphing. Unit morphs to itself to update drawing of status overlays. Example of vulture shadow here.
  
• Status overlay, casting. Another unit with map wide range targets another unit to apply the overlays. This does not require morphing but does require a caster unit. Draw if cloaked unchecked flag works but only if the unit isn't cloaked when the status overlay is applied.
  
• Shield overlay. If the unit has shields and is hit it will create image 424.
  
• Engine overlay. If the unit has an iscript that creates an engine overlay this will be create when walking.
  
• Attack overlay. If the iscript uses the imgoluselo opcode e.g. siege turret overlay (537), archon attack overlay (549) the associated image will be created at an offset. Again, the image requires .lo* files or it will crash.
  
• Power up pickup. Not generally useful but included in this list since it does create an image overlay.
  

For the first example let's do something very simple and also a bit messy. The goal would be to add the archon swirl image (136) around a firebat image (226). Above is the archon energy iscript (147) that creates images 135 and 136 on init.

Datedit > Unit > [032] Terran Firebat > Advanced > Permanent Cloak > Checked //we will cloak the unit so images we don't want on the sprite wont be visible
Datedit > Image > [226] Firebat > Graphic Properties > Draw Function > 1 Unknown1 //allows firebat to have a normal draw if cloaked
Datedit > Image > [227] Firebat Shadow > General Properties > Draw if Cloaked > Checked //we want this shadow image to be visible if cloaked
Datedit > Image > [135] Archon Being > General Properties > Use Full Iscript > Unchecked //prevents image from calling any animation other than init and death
Datedit > Image > [135] Archon Being > General Properties > Draw if Cloaked > Unchecked //we dont want this image to be visible
Datedit > Image > [136] Archon Swirl > Graphic Properties > Draw Function > 1 Unknown1


We give the firebat unit order 148, which will animation call 0 or init animation to create another firebat shadow image. The firebat shadow image iscript is changed to archon energy iscript (147) which creates the archon swirl image we want. The reason why we create this image after the firebat has been created is because sigorder will crash if it's in an init block and the image was created on the same frame as the unit.


The firebat does have all the things we want. However, it has a lot of unnecessary images and it's also cloaked so this particular unit we made wont be useful in many cases. In future examples we'll properly clean up images so they can be fully functional, or as close to it as we can get. Let's review all the images on this unit's sprite:

• [226] Firebat
  
• [227] Firebat Shadow
  
• [227] Firebat Shadow, iscript 147 invisible
  
• [135] Archon Being, invisible
  
• [136] Archon Swirl, invisible
  

For the next example let's go with something intermediate, a kakaru that can attack like a mutalisk. You could do something easy like put the mutalisk iscript (23) on the kakaru image (954) but the animations aren't an exact match and it would look a bit weird. Basically the end goal is to have a unit with both the kakaru image (954) and mutalisk iscript (23) on it.

We will first need to consider what the parent/primary image/main graphic will be. This is the image that is first created on a sprite and the one that dictates the frames of shadows and engines. Because we want a kakaru that looks normal we must use the kakaru image (954) with the kakaru iscript (376) as our primary image.

Datedit > Unit > [043] Zerg Mutalisk > Graphics > Flingy > 199 Kakaru (Twilight)

We will use a mutalisk instead of a kakaru as our unit since this unit already has the weapons and other data needed to support attacking. We change the flingy so its movement and image is the same as a kakaru's.

Datedit > Image > [954] Kakaru (Twilight) > General Properties > Use Full Iscript > Unchecked
The kakaru iscript does not support attack animations. Unchecking prevents the use of any animation other than init and death.

We will need to add an image with the mutalisk iscript (23) to the kakaru sprite. Because this image is only needed for the iscript and we don't want it to be visible we'll use a small image. We'll use the casting status overlay method.

Datedit > Image > [381] Irradiate (Medium) > Graphic Properties > Iscript ID > 200 Bengalaas(Jungle Critter)
When the irradiate image is created it will create the Bengalaas (Jungle) Shadow image (343). The size of a status overlay is dependent on advanced unit flags, with small being the default.

Datedit > Image > [343] Bengalaas (Jungle) Shadow > Graphic Properties > Iscript ID > 23 Mutalisk
Datedit > Image > [343] Bengalaas (Jungle) Shadow > General Properties > Use Full Iscript > Checked
We'll put the mutalisk iscript on the bengalaas shadow and check use full iscript so it can play attack animations.

Datedit > Order > [143] Cast Spell (Irradiate) > Energy > 44 None
Remove energy requirements for casting this spell.

Datedit > Weapon > [034] Irradiate > Weapon Range > Max > 11585
Datedit > Weapon > [034] Irradiate > Attack Angle > 255
On a 256x256 map this is the value that allows map-wide weapon range. Range is counted in pixels and a single tile is 32x32. Angle allows the weapon to be used faster since it doesn't need to turn to face the target.


The ghost will cast irradiate on the mutalisk which creates an image with the mutalisk iscript which supports attacking animations. The irradiate status timer is set to 1, it must be allowed to expire to remove irradiate image.


This works. The unit has the kakaru image and can attack and move around no problem. There's a few things we need to clean up. Let's review all the images that this unit's sprite has:

• [954] Kakaru (Twilight), primary image
  
• [955] Kakaru (Twilight) Shadow
  
• [381] Irradiate (Medium), removed because timer went to 0
  
• [343] Bengalaas (Jungle) Shadow
  
• [039] Mutalisk Shadow

We can clean up our images by either hiding or removing the ones we don't want. The bengalaas shadow image (343) is required since this is the image that has the mutalisk iscript (23) which is responsible for attacking. There are a number of different ways to approach this detailed in the Hiding/Removing images section here. Let's remove/hide images 39 and 343.

Datedit > Image > [039] Mutalisk Shadow > Graphic Properties > Iscript ID > 250 Siege Tank(Tank) Turret Overlay
This removes the image after 2 frames.

Datedit > Image > [343] Bengalaas (Jungle) Shadow > Graphic Properties > Function > 8 EMP Shockwave
Makes our small image even less visible.


Everything looks fine. Because the bengalaas shadow uses the mutalisk iscript the death animation would still play. You can further clean this up with the process detailed in the vulture section here or just hide and change the iscript of image 41 if you're fine with the death sound.



Let's make something complicated and cool with image linking. The missile turret image has a second unused frame set which was originally supposed to be for damaged buildings or something. Let's make a missile tank with this.


If we simply change the siege tank turret image (251) to the the missile turret image (297) you'll see that its too high because the missile turret image isn't centered. We'll need to offset its Y position. Here's the goals of our missile tank:

• Offset turret Y position on unit sprite
  
• Allow the siege tank to attack air and ground
  
• Darken siege tank base so it matches the turret better
  
• Clean up unnecessary images
  

First we'll work on the Y position. Shadows are naturally offset for this axis for unit iscripts that are hovering or in the air. However, air units offset by 42 pixels which is too much so we'll use iscripts from hovering units which is only 7. A list of iscripts and offsets can be found here under the image offsets tab. If an image offset exceeds the bounds of the sprite it will reset its offset at the center but if the offset is greater than a certain amount it will wrap around and be offset in -Y position... probably. A sprite's bounding box is 256x256.


We'll take a couple screenshots in datedit and open them in an image editor to count how many pixels we need to offset it by. It's not recommended to count pixels from in-game screenshots as RM does upscaling. It looks like 10 pixels seems decent so we'll use 2 iscripts from the list to offset our missile turret. There's also the offsets from the .lo* file to consider. I tried offsetting by 14 pixels but it was a bit too low.



Datedit > Sprite > [241] Siege Tank (Tank) Turret > Image > 233 Nuke Target Dot //changes siege tank turret image to nuke dot image, we want a small image so we can hide it later
Datedit > Image > [233] Nuke Target Dot > Graphic Properties > Iscript ID > 39 Infested Command Center //the reason why we are using ICC iscript will be explained later
Datedit > Image > [233] Nuke Target Dot > General Properties > Use Full Iscript > Unchecked //prevents image from using any animations other than init/death
Datedit > Image > [101] Infested Command Center Overlay > Graphic Properties > Iscript ID > 156 Probe //nuke dot image creates a probe shadow offset by 7 pixels on init
Datedit > Image > [138] Probe Shadow > Graphic Properties > Iscript ID > 11 Drone //probe shadow image creates a defiler shadow offset by 3 pixels
Datedit > Image > [014] Defiler Shadow > Graphic Properties > Iscript ID > 117 Machine Shop //defiler shadow image creates machine shop shadow image
Datedit > Image > [295] Machine Shop Shadow > Graphic Properties > Iscript ID > 337 Doodad Header(secondary) //imgulnextid
Datedit > Image > [296] Missile Turret (Base) > Graphic Properties > Iscript ID > 337 Doodad Header(secondary) //imgulnextid, creates missile turret image
Datedit > Image > [297] Missile Turret (Turret) > Graphic Properties > Iscript ID > 224 Gas Sac2 //Uses frame set 1 (0x11) to get the darker turret
Datedit > Image > [297] Missile Turret (Turret) > General Properties > Use Full Iscript > Unchecked //prevents this image from calling invalid animations


There will be a lot of images we dont want so I'll just uncheck draw if cloaked and cloak the tank base for now to hide them. We can clean these up properly later. The tank looks good so far besides the rock doodads that follow it.


Next we'll work on making the tank base darker. To get the tank base image we will need to create an overlay with the SCV iscript (84) and not use its shadow since this would offset it by 7 pixels. Instead we'll use the glow which has no offset. Because status overlays will apply over the subunit sprite as well we can't use them for this. To get the look we want we will have the parent image use draw function 10 and an underlay with draw function 0.

Datedit > Image > [250] Siege Tank (Tank) Base > Graphic Properties > Draw Function > 10 Shadow
Datedit > Image > [252] Siege Tank (Tank) Base Shadow > Graphic Properties > Iscript ID > 84 SCV
Datedit > Image > [252] Siege Tank (Tank) Base Shadow > General Properties > Use Full Iscript > Checked //Allows tank base shadow to create SCV glow image when move animation is called
Datedit > Image > [249] SCV Glow > Graphic Properties > Iscript ID > 337 Doodad Header(secondary) //imgulnextid, creates tank base image

After the siege tank unit is created, we reset the tank shadow to its default values to prevent a feedback loop. The tank base image draw function is also changed to 1 to make it opaque as the unit is still cloaked.


Now that we have the final look of our missile tank we need to allow the tank to attack both air and ground.


I discovered that if an image is more than 6? images from the parent it wont be able to attack. Because of this we are using the infested command center iscript on the nuke dot to make our attacking image only 1 away from the parent. Pwrupcondjmp opcode may also do something weird to prevent attacks I'm not sure.


I'll use the valkyrie iscript (362) for this since it has both ground and air attacks as well as no sounds when attacking.

Datedit > Image > [277] Command Center Shadow > Graphic Properties > Iscript ID > 87 Spider Mine //creates spider mine shadow image, we want a small image for our attacking iscript
Datedit > Image > [259] Spider Mine Shadow > Graphic Properties > Iscript ID > 362 Valkyrie //will allow the turret subunit to attack ground and air
Datedit > Image > [259] Spider Mine Shadow > General Properties > Use Full Iscript > Checked //allows image to use attack animations
Datedit > Unit > [006] Siege Tank Turret (Tank Mode) > Weapon > Ground > 15 Gemini Missiles
Datedit > Unit > [006] Siege Tank Turret (Tank Mode) > Weapon > Air > 103 Halo Rockets


Datedit > Weapon > [015] Gemini Missiles (Normal)


Datedit > Weapon > [103] Halo Rockets

Not going to go into detail to explain much about this part. Basically the ground weapon does ground splash and the air weapon is pretty much the same as the valkyrie's weapon. The X offset is directional, the higher this value the further from the unit's front it will be created at. The Y offset isn't directional, the higher this value the more above the unit the bullets will be created. Attack angle is how much the unit needs to be facing a target to attack. Launch spin is the direction offsets the bullets will be launched at.


The missile tank looks pretty cool.


If we uncloak our missile tank we can see the true form of the abomination that we have created. Let's clean up the images. Here are all the images currently on the unit:

• Tank Base:
  • [250] Siege Tank (Tank) Base, parent image
    
  • [251] Siege Tank (Tank) Base Shadow*, SCV iscript (84)
    
  • [248] SCV Shadow*
    
  • [249] SCV Glow*, doodad header iscript (337), another created every time unit moves
    
  • [250] Siege Tank (Tank) Base, draw function 10
    
  • [251] Siege Tank (Tank) Base Shadow, shadow iscript (275)
    
• Tank Turret:
  • [233] Nuke Target Dot, parent image
    
  • [277] Command Center Shadow, spider mine iscript (87)
    • [259] Spider Mine Shadow, valkyrie iscript (362)
      
    • [940] Valkyrie Shadow*
      
    • [941] Valkyrie Engines*, when moving
  • [101] Infested Command Center Overlay*, probe iscript (156)
    • [138] Probe Shadow*, defiler iscript (9)
      
    • [014] Defiler Shadow*, machine shop iscript (117)
      
    • [295] Machine Shop Shadow*, doodad header iscript (337)
      
    • [296] Missile Turret (Base)*, doodad header iscript (337)
      
    • [297] Missile Turret (Turret), Gas Sac2 iscript (224)
      
    • [407] Zerg Gas Sac Shadow*
      

All the images labeled with an asterisk are not needed so let's get rid of them. We'll give the images without required iscripts, iscript 250 to remove after 2 frames. Those that do have required iscripts will be given draw function 17 to be removed after 48 frames.


It seems most of the images did get removed but those with iscript 337 did not. This makes sense since that iscript lacks a death animation so it played the invalid animation which goes to engset. Interestingly these images retain the pure white from draw function 17.

• Tank Base:
  • [250] Siege Tank (Tank) Base, parent image
    
  • [251] Siege Tank (Tank) Base Shadow*, SCV iscript (84)
    
  • [248] SCV Shadow*
    
  • [249] SCV Glow*, doodad header iscript (337), another created every time unit moves
    
  • [250] Siege Tank (Tank) Base, draw function 10
    
  • [251] Siege Tank (Tank) Base Shadow, shadow iscript (275)
    
• Tank Turret:
  • [233] Nuke Target Dot, parent image
    
  • [277] Command Center Shadow, spider mine iscript (87)
    • [259] Spider Mine Shadow, valkyrie iscript (362)
      
    • [940] Valkyrie Shadow*
      
    • [941] Valkyrie Engines*, when moving
  • [101] Infested Command Center Overlay*, probe iscript (156)
    • [138] Probe Shadow*, defiler iscript (9)
      
    • [014] Defiler Shadow*, machine shop iscript (117)
      
    • [295] Machine Shop Shadow*, doodad header iscript (337)
      
    • [296] Missile Turret (Base)*, doodad header iscript (337)
      
    • [297] Missile Turret (Turret), Gas Sac2 iscript (224)
      
    • [407] Zerg Gas Sac Shadow*
      

We'll use extended animations to get rid of the rest, starting with those on the turret. Check use full iscript on the images with iscript 337 since we will need to call animation 184. When using extended animations make sure to review the specific animation called for ALL the iscripts with use full iscript checked. Ensure that there are no opcodes that may result in a crash or other undesirable consequences.



To remove the SCV glow image from the tank base unit we'll need to wait a bit before we call animation 65. The animation was changed from 184 to 65 because it crashed for some reason. We will have to wait because it will also crash.


After doing all of this we have removed all of the irrelevant images on our unit. You'll notice that the spider mine shadow and nuke dot images are still visible. We can simply give them draw function 8 so they wont be as noticeable. It may also be a good idea to set CUnit useractionflags to 0x4 to prevent the death animation playing when it is killed.


I did skip over some minor things but for the most part this should give you a good idea of how to navigate through image linking.

Attachments:

Post has been edited 18 time(s), last time on Jul 27 2025, 2:45 am by Sie_Sayoka.

WATER


All of the techniques used in this map were covered in previous posts. I wont go into a step-by-step tutorial of how this was achieved but I'll briefly explain what I did and you can see the source files to deduce from there.



I've thought a while of how we can get convincing water within SC. Many maps utilize the psi field images (584-587) to emulate water and for most cases this is acceptable. However, there are several issues that arise from it such as the HD images having a hex pattern for no reason and the amount of stacking required to get full coverage. In this example we will use the warp texture image (210) which is 192x192 pixels or 6x6 tiles. At lower frames edges are not apparent but at higher frames it will become noticeable. The warp texture image is at elevation 5.



I'll stack the warp texture image with another warp texture image that has the disruption web iscript (374) and draw function 3. This will create a looping distortion effect that is perfect for water. The images are also moved back and forth a few pixels every 100 frames which adds a nice subtle effect.


FISHES




Fishes are created using the venom (507) and EMP missile (554) images with iscript 169 with draw function 10. Because iscript 169 switches between frames 0 and 1 it looks like fishes swimming.


BACKWASH


The backwash (trail of white water) is created with scanner sweeps. I used broodling remanants (7) with iscript 37 and draw function 17. Because scanner sweep will only use elevation 4 for the first scanner sweep hit it darkens the pure white from draw function 17 a bit.


SUBUNITS


Because turreted units are composed of 2 different units this means we can change the elevation of each unit. In the example the tank and goliath look as though their turrets are above the water.


SUBMARINES


I have the carrier morph into gantrithor which is a lower elevation than the warp texture to make it appear underwater. The backwash images are zergling remnants (57) and acid spores (986). The diving and surfacing sequences can probably be improved further by lengthening them and maybe using cloaking/decloaking animations to get a better transition.

In the example map keypresses 1/2 will make the carrier surface/dive.


TORPEDOES


Longbolt missile image (529) draw function 16. Longbolt missile trail sprite (309) changed to acid spore image (986) for bubbles. Take note that the target's elevation will be the same elevation that the bullet and trail use.


CONCLUSION

Because we are using such a large image for water, creating coasts would be difficult as we would need to find a way to cover up the straight edges of the image. This would most likely require a large investment from your map limits. Furthermore if you wanted transparent images you cannot stack them off of the 6x6 grid. However, the large image would be a positive as well since a 64x64 map would only require 200 images whether it be from units, thingies, or bullets. 256x256 would require 1792 images so using unlimiter plugin and bullets is advised.

Because the water is only an illusion this means that you can have fully pathable terrain. You could have gameplay where submerged units must path through walkable terrain whilst floating (air) units can traverse unhindered.

Overall I'm quite happy with how it turned out. Many aspects can be improved depending on how much time you want to work on things. Effects such as wakes and better transitions of units in water can be done through things like direction linking but will likely take a lot of time.

Attachments:

Post has been edited 2 time(s), last time on Jun 29 2025, 8:33 pm by Sie_Sayoka.

ALTERNATIVE WATERS
We'll look at some other ways to make fake water although I don't think these would be as convincing as the previous post. Ideally we would want images that are a transparent blue since this gives the depth and feel of water. However not all water is blue and the image list has very few images that match this criteria. Concepts used here can be applied to emulate other colored liquids such as coolant, oil, blood, etc.



SHADOW COLOR
Most shadow images will show a desaturated purplish blue (#29253C) if given draw function 0 or any other draw function that doesn't change its color. Shadow images that are for flying or hovering units instead use the same GRP file as the unit. Some of the jungle doodad tree shadows are weird as well. This can be utilized with draw function 6 to add 50% transparency for the purposes of water. We can make it bluer with draw function 16 at the cost of making it opaque.


Although not a shadow, [555] EMP shockwave hit (part1) shares similar properties to them. This is an ideal image to use as water as its circular, expandable, and has highlights; everything we want from an image other than it not having native transparency.


Above is an example of using frames 0 to 2 with image 555. Mind control hit images (973, 975) are used with draw function 3 to get a ripple effect. Every 45 frames the mind control hits will cycle between 3 different frames. The largest pool has a stasis field hit image (364) with draw function 10 to give depth and cover up some of the holes that frame 2 has for image 555. Larger pools are possible but will require stacking of several images to get a decent oval with no holes.


3 engineering bay shadows (324) are horizontally staggered to give more depth and texture differences since shadows are so flat. Ebay shadows are chosen because they are large images and follow the isom angles fairly well. Ebay images (322) are used with draw function 8 to add more variation and effect to the distortion because it's a brighter image. This effect uses a total of 8 units.


A coastline where units may enter the water using engineering bays, ebay shadows, emp part 2, dark archon deaths, and disruption web. It's not recommended to make too large of an area with this as it will eat up all your limits.


Because we are utilizing transparent images we are able to see some of the terrain and units under water albeit it's greatly obscured.



BLUE IMAGES
Images that are naturally blue can be given draw function 6 to give them 50% opacity. Above is an example of the floor missile trap (736) over a floor gun trap (735) to give an illusion of depth through stacking. Many of the blue images are glowing which is not ideal since the denser parts increase with brightness, the opposite of what water should do.


Using stasis field hit image (364) and stacking it with draw function 10 to reduce brightness.


Shield overlay image (424) is notable in that it's directional and semi-circular so you can use it to fill circular shapes.


Additional images with draw function 10 can be used to darken something at the cost of some transparency.

Coasts can probably be made by stitching image 364 frame 4 or image 215 frame 8 in a similar way to how I made the coast with shadows.



DRAW FUNCTION 12
Draw function 12 only works in SD and will be invisible in HD. You can use a unit and create an overlay of this texture in HD but this means it can't be used with transparency. I wont be covering this as it's pointless for HD.



DRAW FUNCTION 16
The hallucination draw function doesn't require an image to be natively blue and instead only needs a transparent image. In my opinion, this blue is too saturated and has too little green to look good if used by itself.


Because we can use images of different colors this means we can do cool things like blend colors. Above is the glave wurm hit image (512) on frame 8. Because this frame has so much transparency the harsh blue from the hallucination is mitigated. There are 2 more images stacked above it with draw function 6 to give it a swampy greenish blue color.


Using frame 9 of glave wurm hit has even more transparency and is quite desaturated as a result. Created using 2 images with draw functions 6 and 16.


CONCLUSIONS

There's many possibilities to create water in your maps, it just requires the time investment to try out different combinations and the restraint to not eat too much of your map limits. Ash world was chosen as the tileset in the example map because it had the crater doodads. But you can of course do the same on other tilesets with clever usage of terrain and images.

Keep in mind this list of what reinforces water believability:

• Depth: Easily done with transparency but can also be achieved through using gradients.
  
• Texture: To simulate the unevenness of water's surface and reflections.
  
• Animation: Distortions created with draw functions 3 and 8.
  
• Color: Water should be some kind of blue.
  

Attachments:

Post has been edited 14 time(s), last time on Jul 7 2025, 7:15 pm by Sie_Sayoka.

Loops & Runs tab


WATER ACCESSORIES
The goal of this example would be to populate this 20x15 area with cool things and generally make it look drastically different from vanilla SC. Because the waterfall and pool is the focal point of this scene I'll mostly cover the image manipulations for them. As this will be very tedious work I'll share some tips to expedite the process of knowing exactly where to set locations so you don't need to enter the map after placing a single image to check.



IMAGE 318 NUKE HIT
This image is notable because frame 25 covers a very wide range and has extremely low opacity. The image above has around 10 stacked and it's still very transparent. Because of these properties it can be used to give subtle color changes to a wide area.



LILY PADS AND CATTAILS
This uses well over 100 units to create darker water, lilypads, and cattails. Because there's so many units that need to be placed in specific areas I'll share a method to expedite and increase the accuracy of placing units.



MOCKUPS
The above image is a mockup of what I want the scene to be in game. It's fairly faithful to the final result with some variation due to elevation changes and Y position priority. Let's go over the steps to do this.


1. Take a screenshot of the map in a map editor. At 100% zoom this will be the same resolution that the game uses for locations and positions. It is not the same resolution that's displayed when you play in game. If you are using terrain that requires some images on it already, like I did for the darker water then you will have to scale the in-game screenshot down by around 44.5%.


2. Create a location to use as your reference point. The reference point is important since it's needed to calculate distance and its position will be reset using setloc action. This is the location that will be used to create all the units. You should create this location at the top left of your scene (which I didn't do) so you don't have to deal with negative numbers.

3. Paste the image into an image editor. It doesn't matter which one you use although it should have basic image editing functionalities as well as being able to display the size of a rectangle. I used Clip Studio Paint and the selection tool.


4. Take a screenshot of a specific frame you want in EE2. This could also be done in EE3 but it does not display directional frames.


5. Place a pixel (I used red) at the center of the image. In EE2 the window is 256x256 so I place the pixel at 128x128. Delete the background black.


6. You can now make your mockup and determine the distance of images from the reference point.

• Draw function 6 50% opacity
  
• Draw function 10 #000000 50% opacity
  
• Draw function 13 #249824
  
• Draw function 13 #BCB834
  
• Draw function 13 #840404
  
• Draw function 16 Uses remapping. Take screenshot from EE2
  
• Draw function 17 #FFFFFF 0-100% opacity
  
• Shadows #29253C
  

8. Use setloc and addloc actions to move the location to and from the reference point. Basically just move the location, create the unit(s), and reset location to ensure that everything is correctly placed.


9. Optional. When dealing with a large amount of anything it's important to keep things organized. I labeled folders with relevant values that needed to be changed for each image such as iscript, draw function, image ID, etc. and assigned them to variables.

There will be some discrepancies between what's displayed in the image editor vs the final results of what's in game. Elevation works the same as it would in the editor by placing a different layer. However in SC a higher Y position will take precedence for sprites on the same elevation. Also a unit that is latter on the list will take precedence so you will want to create sprites in the opposite order than layers in the image editor. When stacking units or thingies on the same elevation keep these in mind:

• Units: Units created first have less priority than those after.
  
• Thingies: Thingies created first have more priority than those after.
  

This is probably the most efficient way of doing things until CHKD has image changing functionality.


WATERFALL
Mainly composed of images 419, 928, and 488-490. To keep semi-transparent draw function 17 I used unit unlinking which I briefly mentioned before. The rainbow uses image 363.


UNLINKING UNITS
I wont go into much detail since I don't fully understand the process but basically it removes a specific unit from the linked units list which is achieved through changing the prev/next CUNIT offsets. This means that the frames for the unlinked unit do not get updated by any means until it is relinked. As such the image that is displayed will be completely static. Because unlinking requires a previous entry on the list you cannot unlink the first unit (preplaced or otherwise) but can unlink any unit after that.
Unlinking units is most useful to stop the animations of draw functions 2, 5, and 17. As well as having units be visible in fog.





This orange tree was made with images 107-109, 337, and 531. I didn't add it in the map because it didn't match but the ytree set folder for it is there if you'd like to see it in game.


The forest mainly uses images 337, 60, and 318 for the shadows. There's also some image stacking for trees to change their color and brightness. Basically you can add some variation to your forests so trees don't all look the same.


CONCLUSION
Most of the things in the example map are very time intensive so may not be practical for your uses. However, things like stacking images for trees are very simple and easy to implement with great results.

Attachments:

Post has been edited 12 time(s), last time on Jul 28 2025, 5:39 pm by Sie_Sayoka.

Sie_Sayoka, I'm a fan of yours and a StarCraft player for 20 years. I especially love the various units you create; however, my skills are limited, and after following your tutorials, I'm encountering many error messages. I don't know how to solve them and really hope to get your guidance.

The current problems are:
1. Tanks and missiles display error messages when moving;
2. Missiles are not attacking (they can attack ground and air units, and they self-destruct after hitting a target).



Post has been edited 1 time(s), last time on Mar 24 2026, 1:21 pm by jy2413804. Reason: 错误