There is a byte on each unit that contains the sigorder flags ... It's used to signal certain things happening outside of the actual animation. BWAPI has them listed as:

You could also likely use unused flags to signal certain things with plugins. Like in the plugin check units if a specific flag is set, and if it is do then something.

BWAPI also has some info on palette/drawing types in CImage.h.



RLE_SHADOW, RLE_HPFLOATDRAW, RLE_PLAYER_SIDE are reverse engineered from BW Beta and the others were inferred somehow. The only one that doesn't match up is RLE_FIRE.

Also I wrote a tool for looking at BW data structures real time in C# to figure out wtf was going on and debug things for BWAPI, see BWMemoryEdit.

EDIT: Compiled version attached. Let me know if it's missing dependencies. Needs to be run as administrator and must have Starcraft open.

Attachments:

Post has been edited 3 time(s), last time on Mar 5 2015, 2:26 am by Heinermann.

Regarding sigorder; from what I understand the meaning of sigorder flags is different for each order, and they are reset to zero when order changes. In most of the orders every one of them should be unused. Also, bullets use sigorder 1 to tell game when their init animation is complete, even though they really don't have orders like units do.

I assume reading memory before lo? is completly random data, but the lo? files could be crafted in a way that even negative values could be controlled.
High quality concept sketch:


You forgot trgtrangecndjmp Not that it would be anything special.
It seems that trgt arc/range cndjmps only work with units even though bullets also can have targets I wanted to create bullet which loops its init script without setting sigorder 1 until target is close enough, it could have been "camping bullet" D:
Also it seems that setflspeed cannot increase speed past max speed set in flingy.dat. Confirm/deny?
Are you done with iscript disassembling, are there no more functions that could hide something new?


I thought the targeting interface always appears if button action is set to "Use Technology" in firegraft? Am I wrong or did I misunderstand? There certainly are a lot of issues with adding new spells, as every spell has separate order, and the tech -> order conversion is hardcoded as far as I know. That is, when specifying tech for a button in firegraft, bw converts it to order (hardcoded), and later uses orders.dat to convert it back to tech (softcoded) to get the energy cost.
I might be completly wrong though, I haven't examined spells too closely.



Nice tool, even if UI is really rough I'm pretty sure that "halt" is simply 256 times more accurate position that is sometimes used.

RLE_FIRE kinda makes sense as it does use ofire.pcx to remap the colors, maybe it could be manipulated to create effects other than fading flashes?
(Out of curiosity, do you have any idea what RLE stands for?)

I didn't forget, I figured it was alraedy known.

Run Length Encoding. It's the encoding format PCX uses. (Values of 0xC0 mean repeat the next byte (value & ~0xC0) times, else just copy the value -- GRP data encoding is like an expanded RLE).

These appear to spawn image at offset specified by the "special" lo? file. At least they crash if it does not exist. Guess they do something else as well that makes them different from imgoluselo/imguluselo?

Edit: They appear to make image update its position with new lo? offsets if it turns? Resources/powerups work similarly even though they are not created by iscript commands.

Post has been edited 1 time(s), last time on Mar 10 2015, 1:44 am by Neiv.

Found out the differences between drawfunc 0x0 and 0x1. 0x0 is the only drawfunc can be switched to hallucination or any of the cloaking drawfuncs. So setting cloaked unit to use drawfunc 0x1 would make them always appear uncloaked to every player, but players without detection would still not be able to target them.

Neat. I was beginning to suspect that since I kept seeing like "if(drawfunc == 0)", but was focusing more on getting it disassembled than interpreting what it meant

I still need to write up the more updated opcode specifics.

Got one more almost useless trick to document:

When the first frame of bullet animation is executed, the "iscript context" is refers to the attacking unit instead of the bullet. As such, using attacking, turning or other unit-specific opcodes will work fine for this frame. Most of them are really pointless though, as they could be used simply from the attacking unit's script.
However image overlay creation opcodes and sprul/spruluselo will not show the image/sprite if the unit is cloaked, so it is possible to have bullet look different depending if the attacker is cloaked.

Other usable opcodes are range/direction condjmps, allowing running different init script for the bullet. Sadly the bullet will not do anything until its iscript runs sigorder 1, after which starcraft will reset the animation to GndAttkinit. So the condjmps can mostly be used to make bullet look different (with image overlays), set its position, play different sounds, or wait different times before activating.