I guess staredit doesn't like 0x20 trigger action bytes. Go ahead, try replacing an action with 0x20. When you open it in staredit it works just fine, but gives you a weird trigger action text on the order of:
LEADERBOARD COMPUTER PLAYERS
Mute all non-trigger unit sounds for current player. use of computer players in leaderboard calculations
I haven't tried running this trigger on starcraft but I'm pretty sure it'd crash. Did anyone else notice this?
EDIT** I have found another similar byte, 0x2A.
It's output is:
SET DOODAD STATE
Mute all non-trigger unit sounds for current player. doodad state for Terran Marine for Player 1 at '[no location]'.
Post has been edited 1 time(s), last time on Oct 13 2007, 5:54 pm by brew.
None.
An artist's depiction of an Extended Unit Death
So... The question is?
It looks like the blank for Enable/Disable is being replaced by muting unit speech. I don't think it would crash the map, although if it does crash/drop (hopefully player specifically) you could maybe use it to your creative mapmaking advantage (Like in a banning system). It would probably either do nothing or mute mute the unit speech for the current player. You should test it out yourself; you'd get the answer faster than most people here
Ah nevermind, they both seem to be two valid trigger bytes, except with an arg mismatch. I'm still not 100% sure how StarEdit stores the arguments to trigger actions/conditions. Anyone with information on this would be more then welcome to help.... heh
I'm sure the writers of StarForge and SCMDraft would know. Also there's this 0x04 a byte after the trigger byte --so far i haven't checked out the actual trigger structure, just the types. Here is the complete list of trigger action bytes:
0x01 - victory
0x02 - defeat
0x03 - preserve trigger
0x04 - wait
0x05 - pause game
0x06 - unpause game
0x07 - transmission
0x08 - play wav
0x09 - display text
0x0a - center view
0x0b - create unit w/ properties
0x0c - set mission objectives
0x0d - set switch state
0x0e - modify countdown timer
0x0f - run ai script
0x10 - run ai script at location
0x11 - leaderboard (control)
0x12 - leaderboard (control at location)
0x13 - leaderboard (resources)
0x14 - leaderboard (kills)
0x15 - leaderboard (points)
0x16 - kill unit
0x17 - kill unit at location
0x18 - remove unit
0x19 - remove unit at location
0x1a - set resources
0x1b - set score
0x1c - minimap ping
0x1d - talking portrait
0x1e - mute unit speech
0x1f - unmute unit speech
0x20 - LEADERBOARD COMPUTER PLAYERS
0x21 - leaderboard goal (control)
0x22 - leaderboard goal (control at location)
0x23 - leaderboard goal (resources)
0x24 - leaderboard goal (kills)
0x25 - leaderboard goal (points)
0x26 - move location (disabled)
0x27 - move units (disabled)
0x28 - leaderboard (greed)
0x29 - set next scenario
0x2a - set doodad state (broken)
0x2b - set invincibility
0x2c - create units
0x2d - set deaths
0x2e - order
0x2f - comment
0x30 - give units to player
0x31 - modify unit hit points
0x32 - modify unit energy
0x33 - modify unit shield points
0x34 - modify unit resource amount
0x35 - modify unit hangar count
0x36 - pause timer
0x37 - unpause timer
0x38 - draw
0x39 - set alliance status
That 0x04 byte I was talking about earlier, it was two bytes after the action byte. It seems to indicate whether or not it is a disabled action? I'm not sure how it determines this. The most logical thing to do in this situation is to compare it with 0 and nonzero values. However, this is not the case. Right now it seems as if any byte with the low nibble equaling 0x0A, 0x0B, 0x0E or 0x0F is disabled. Weird, does anyone else know more about this? To be honest I'm getting kinda fed up with trial and error, so I was thinking of disassembling staredit, then searching for the offset constant (the effective addr would be: base trigger addr + 0x014A) to see what it does with that byte and how it determines if it's a false or true value. Is it worth it?
Edited to complete table and add more information.
Post has been edited 1 time(s), last time on Oct 14 2007, 2:25 am by brew.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
Hm... Hex values standing for actions... I guess thats what the editor works with internally when you select an action from the list. Correct?
But where can you see these and how can you use them?
Hm... Hex values standing for actions... I guess thats what the editor works with internally when you select an action from the list. Correct?
But where can you see these and how can you use them?
This is correct. They're the internal values that represent the triggers.
You can see them by opening up a .trg file (or an unencrypted map's trigger sector) with a hex editor. I'm not exactly sure how YOU can use them, but I'm using them to compile ascii trigger code to the actual byte code that starcraft reads on runtime.
I'm now trying to learn more about the trigger's structure, and here's what I've come up with so far:
32 bytes reserved for any trigger action/condition, disabled boolean, and posssible parameters
64 possible actions
64 possible conditions
therefore, (32 * 64) * 2 = 4KB per trigger, no matter how many actions or conditions + some overhead for the trigger owner, etc
About 99% of the bytes turn out to be 0, however.
MPQ compression works wonders
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
lol 4kb per trigger? There must be some built-in compression. Since the maps I know have 100+ triggers but less than 400kb. Terrain not accounted for.
Like I said. It's mpq compressed. You'd be surpised how a map with no units, locations, or triggers takes up more then 200kb unzipped.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
Ok thx for the explanation mate.
