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.
As creategasoverlays uses
signed byte, it is only possible to use creategasoverlays with values -128 to 127. However there is no LO? editor that allows specifying negative indexed offsets, so one would have to hex edit them in. Maybe we need an LO? editor which is able to handle this abuse case of creategasoverlays
I didn't really consider the signed part with the lo? file ... it will just read backwards in memory to before the lo?s position in memory, and I don't know what would be there (unless it's more lo? files).
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:
(The list of iscript functions)
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 have a feeling that it also has to do with how the interface responds to them, since certain orders, particularly with Cast Spell ones, will cause the interface to prompt the user for a target. Having the ability to define more cases wherein the user is asked to specify a target would go a long way to creating entirely new spells that minimally impact existing orders and spells.
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.
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.
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?)
None.