EDIT: Look down a bit for something a lot more awesome.

As you know, upgrades have a maximum level, which can be set on a per-player basis. The memory locations that hold these maximums happen to be very close to the deaths table, and I was wondering if killing units for sufficiently high player numbers could affect this. It turns out that it's close enough for this to work, sort of. Only certain upgrades can be effected, and no Brood War upgrades can be effected. You need to preplace a bunch of Vespene Tank (Terran Type 2) units (which I'll call VTs for short); this is an extended power-up that happens to be the unit with the highest ID. (Technically other units work, but there's no reason to use them instead, and with this one you can get the largest range of upgrades.) You can use them to increase the maximum upgrade level; to do so, they will need to be given to an extended player, then killed by a unit. The player that owns the VT determines the upgrade, but before I explain this, I need to explain a bit how the memory in question is laid out.

There are 552 bytes in the region in question. The first 46 are for P1 upgrades, the second 46 are for P2 upgrades, etc. Within each group of 46, the first byte is upgrade 0 (Terran Infantry Armor), the second byte is upgrade 1 (Terran Ship Plating), etc. You can look up which upgrade ID corresponds to which actual upgrade in DatEdit or something. Now, because we're doing weird overflow shenanigans, when determining the player ID to use for the VT, we need to know where the upgrade in question is in memory, not in some abstract array thinger. To compute the offset we need, take the upgrade ID and add 12 times the ID of the player we want to affect. So, for P1's Terran Infantry Armor, the offset would just be 0. For P4's upgrade 16 (which happens to be U-238 Shells), the offset would be 52. (Because computers count from 0, the ID of P1 is 0, and the ID of P4 is 3, etc.)

Now, we need to convert this offset into a player ID for the VT. First, divide the offset by 4. This is because each entry in the deaths table is 4 bytes, so adding 1 to the VT's player ID moves its DC location up by 4. (If you end up with a number that isn't an integer, give up; we can only deal with offsets divisible by 4.) If that worked, then add 166, and that's the player ID you should give your VT.

Now, this is rather abstract, so I'll give a concrete example here. Let's say that you don't want P1 to be able to research Zerg Flyer Attacks until he has defeated a certain boss. You'd set P1's Zerg Flyer Attacks maximum level to 0 in the upgrade settings window, and place one or more VTs. Next, you'd look in DatEdit and find the ID of Zerg Flyer Attacks, which happens to be 4. P1's player ID is 0, and (0*12 + 4)/4 is 3. This is an integer, so you're good to go. You'd make the VTs belong to P169, and have some unit attack then once P1 defeats the boss. (Note that VTs have 800 HP and Independent armor; you'll need to set their HP to 1, and even then it'll take anything other than a Zealot or Firebat two hits to explode it.)

When is this useful? Not often. Really, the only case I can see for it being useful is if you want an upgrade's availability to depend on some ingame event, and can't spare a resource. For example, Jack's Black Hat RPG had some enemies give Vespene gas when killed, which was used to upgrade armor. If you want something similar, but are using both minerals and gas, then this can be used. (Incidentally, there's a similar trick for techs, but I'm too sleepy to math right now. I've also found a method for removing technology under /very/ specific circumstances, which I'll be posting here once I do some more research into it.)

Post has been edited 5 time(s), last time on Aug 12 2012, 4:50 pm by Biophysicist.

Whoa this is really cool. If smell-tivision/blizzard ever decides to patch BW again, will this screw up though?

It's hard to say. These tables are almost immediately above the deaths table, so it's unlikely, but possible. It's... Less likely to break than EUDs used to read a unit's HP or something.

That sounds cool, wouldn't it be the nicest to just automatically upgrade the player's weapons though? Especially for RPGs.

Yes, and I'd do that instead if I could. Unfortunately, I don't know if that's possible. They're further above the death table, and even with unit ID 227 (the VT) and player ID 255, I can't reach them. There are no units with higher IDs defined, and player ID can't go above 255. I'm trying some experiments with higher unit IDs, but extended units like that are really quite weird.

EDIT: If anyone knows anything at all about extended units (meaning units with IDs above 227), poke me please.

Post has been edited 1 time(s), last time on Aug 7 2012, 6:55 am by Biophysicist.

Feel like this should be (clearly) stated in this thread:

Address edited (decimal) = 48*UnitID + 4*Player + 5808992

Starting Address ('VT' for p1): 5819892 or 0x0058CDF4
Ending Address ('VT' for p256): 5820912 or 0x0058D1F0

Suggested this to Bio earlier, but there's a few extended units we should be able to work with, such as ID:3900 logged here.

Pretty neat, but this would only be useful to decrease clutter in a map or give upgrades to enemies, the latter being pretty handy. Now, when you discover how to undo those upgrades, lemme know.

@jff28: Yup, I'm looking into extended units at present. It turns out that ID 2100 does not crash, and its DC for P1 is inside the unit table, though unfortunately quite far into it.

@LoveLess: This particular system is really only useful for denying upgrades until a certain point or for certain heroes in an RPG or AoS or something. If I may be honest the real reason I posted this topic is that I hoped it would give people who actually know more about EUDs than me some ideas.

Inside the unit table?!? YES! say hello to marines firing tank shots!

Edit: ID:2100 unfortunately does not add a death

Edit2: oh how silly of me, ID:3900 is within the unit table, in fact, ID 1585 - 13478 are within the unit table

Post has been edited 2 time(s), last time on Aug 7 2012, 10:25 pm by jjf28.

Ladies and gentlemen, I present WraithShot SCV, the first of what I expect will be many cool tricks to come of this.



Attachments:

Wow... modding just got that little bit more redundant. And not even requiring the action enabler, just wait till the koreans see this!!

Fantastic work by all involved.

Dropship Firebat

Very cool stuff.

Haha, when Bio and I were talking about this yesterday, we both kinda disregarded extended units figuring it'd likely be too much of a stability issue. Looks like we can use them to access addresses that are further away.

Awesome discovery, Bio, and awesome application, jjf/Kaias.

For the record, the equation Bio gave can also be substituted with just the values you would normally put for an EUD (player and UID). We came up with it as a means to get a result within non-extended placed units.

Ultimately, what we've discovered here is a way to use EUD Actions, as long as the operation is "Add 1."

Very cool. Not quite as useful as full EUD actions but pretty useful none the less.

So these actions allow you to change some properties of all units of a specific type, eg all firebats will behave like X, rather than a specific firebat? Of course you could make all Gui Montag firebats behave like X...

Both example maps are modifying the unit type of a specific unit. Technically speaking, you are not limited to any address you couldn't have written an EUD Action for pre-patch 1.12.

Again, the only limitation we have here is that the only practicality is writing to the first byte of each four-byte addresses, and we can only write +1 for each unit we kill. You can still do incredible stuff here, as the example maps have shown.

No, just for a specific unit.

From my testing, it seems you're mostly just turning one unit into another but having it keep the same movement and looks (ground units still walk like ground units). If you give a unit that can only attack ground units a gun that can attack air, it will crash if you try to attack air. If you turn a dragoon into a high templar, it won't get any of the castable stuff (Psi Storm, hallucinate, etc). Turning units that can't attack into units that can and then attacking also crashes (e.g. Civilian into Kerrigan Ghost). Turning melee units into ranged makes them appear to melee from a range. Turning a nonworker into a worker will make it crash if it tries to mine, or pick up a powerup.

This mostly seems useful for making one unit look like another for aesthetic purposes, like this ghost into a vulture:


Making a scout into an arbiter did not give it a cloaking field, unfortunately, though it did give it the arbiter's attack.


Raynor marine to Tom Kazansky:


Post has been edited 3 time(s), last time on Aug 8 2012, 12:45 am by Kaias.

Ok, so is it possible to make these changes affect all units of a type, rather than just a specific unit? Eg make all scouts (including ones produced by starports) have the arbiter attack.

*If anyone's curious, discovering this was my original intention. I'm glad someone who knew what they were doing was able to work it out.)

The reason for those attack-related crashes is something called iscript, which defines animations for things that units do. If a non-existent animation is called, it crashes. Most units don't have animations for things they can't do, but there are a few exceptions. For example, Dark Archons have animations for attacking both land and air. Someone should try turning a Dark Archon into a regular Archon and seeing what happens. Also, there may be a way to give units the spells of their new type. Try adding the same number to the unit ID and also to the offset +0x94. I'd try this myself, but I don't have time at present.

@Arbiters: Hey, couldn't you turn an Arbiter into another unit to create a cloaking field at a point without needing a visible Arbiter?

EDIT: @Above: Theoretically, but we'd need to find an extended unit/player combination that doesn't crash and writes to a value that's pretty high above the deaths table.

Post has been edited 1 time(s), last time on Aug 8 2012, 1:07 am by Biophysicist.

Done, but the command card doesn't update. See attached map, go over to the other Dark Archon to watch your DA attack it as a Dragoon.

Yeah, there's probably a way to update the command card. Couldn't find anything myself, but you can look over the unit struct: http://farty1billion.dyndns.org/euddb/?pg=ref&a=unitnode

Attachments: