Detection-by-attempting-to-move is 99999^99999 times easier than EUDs.

Also, if I'm not mistaken, EUD burrow detection would be hard to do on created units, since you wouldn't know what unit number they were.

You can precreate the units...
And give them to the player when their first one dies if you are thinking of multiple lives

I dunno, burrow detection by EUDs is pretty easy (1 condition). Not that worthwhile, since it would only work on preplaced units. But you can't have any other flags checked (no speed/attack upgrade, no disable, no invincibility etc...)

All in all it's stupid to do something with EUDs if there is a method already in place. Perhaps the only case where this is not true is using the leaderboard to display deaths.

You could tell if they move too fast through triggers in multiple meathods. But they could stim and not move and you couldn't tell i guess...

Can someone explain the death table to me? Is there only one, and is it the same as the list of offsets at fartys EUD DB? If not, what is it?

Yes. The death table looks like this:
x: Player number (0-11)
y: unit ID. (0-228)

The death condition reads memory based on this equation:
4*Player number + 48*Unit ID number + base offset
That means player 1 (0) Terran Marine (0) deaths are stored at:
4*0 + 48*0 + 0x58a364 = 0x58a364.
Typically, player number is limited from 0-11, and unitid is limited at 0-227. That is the NORMAL limit for scmdraft. However, player number can be a 4 byte number, which allows for any memory to be read (player number can be negative).

These "EUDs" were named that way because we used to change the unitID (the y value) to get our trigger. So, deaths of extended units. Now, since we know we can change player number to the same effect, and keep unitid at 0, we should probably call then extended player deaths (of terran marine). The name stuck though, so it doesn't matter much.

EUDs read memory, which is detailed in the memory map. You'll notice there's a unit table listed. The unit table is what we want to read most of the time, and contains all the stuff in the unitnode reference x 1700.

Ok thank you. I got hp detection to work in five minutes ( YAY ME!) so if i can get firing detection to work( havent tried yet ) then i should be all set.

You can detect if a unit is stimmed or ensnared by detecting its flingy speed, +0x34.

The only limitations that I've seen so far is that if a unit is stimmed and ensnared then the value will be the same as if the unit was not stimmed and not ensnared, because they are canceling each other out in terms of speed. Also, you can't really detect consecutive uses of stim other than when stim was first used, because you're only detecting the change in the unit's speed, although you can detect when the stim wears off and then if stim is used again.

So far I've only tested this with a marine so the speed values are probably different for other units, but the idea should still work.

You actually can use it and with a bit of tweaking it can be pretty accurate. However, I've found that using dwStatus is a lot easier and more accurate too. The only small problem I've encountered so far is that the attacking value while invincible or cloaked is different than the one while not uninvincible or cloaked. There are probably other status effects that affect the value too, but if you can account for them then it's pretty useful.

Post has been edited 1 time(s), last time on Aug 8 2009, 7:41 am by Pariah.