Hopefully this isn't already too known

For those who can't grasp the concept of unit direction detection through Kenoli's method or scanning, I've found a method to detect unit direction/facing detection through EUDs.

There's one byte on the unitnode structure that has the unit's direction. The higher the value of the byte the more the direction is offsetted in a clock-wise direction. For example, 0 would mean it's facing up, 64 facing right, 128 facing down, 192 facing left.

First value in the memory condition AKA the extended player:



The byte we want is offsetted in the fourth byte with the first three being non-zero values so we want to use two conditions with the same extended player but one being At Least and the second being At Most.

To get the At Least value you convert the direction value you want into hexadecimal, append six zeros after it, then convert it back to decimal:

40 00 00 00
1073741824

For the At Most value you do the same thing except append six F's after it:

40 FF FF FF
1090519039

Here is a list of 8 common directions:



Memory addresses in case anyone is interested:



Also, if you don't want to have triggers for all 256 directions you can use the AtLeast from a lower value and AtMost from another higher value.

Post has been edited 5 time(s), last time on Mar 23 2010, 8:11 pm by yoonkwun.

Ah thanks! I had asked one of the more EUD-savvy members about this awhile ago and they simply were unable and gave up, thanks! Though that was before I had really heard of kenoli's.

Wow, thanks. That saves a lot of time.

Using At Most/At Least you can ignore the first 3 bytes.

I don't mean to thread hi-jack, but does anyone know offhand EUDs for reading if a portrait is talking or not? Danke

I searched for that once and the current portrait being shown uses a pointer to a variable location, which means it's improbable to use that address. I don't think blizz would put in an "istalking" byte, but I could be mistaken.

My objective is to manually substitute in new voices for specific units. An 'is talking' byte wouldn't have surprised me, simply because of the 'show portrait talking' and 'transmission' actions; in any case, it was simply a mean to that end. Right click detection and selection detection combined could achieve the desired effect, however, as far as I know right click hasn't been found (if it can be). If anyone has any bright ideas for another method, I'd love to hear it.

Post has been edited 1 time(s), last time on Mar 23 2010, 8:02 pm by Kaias. Reason: Typographical Error

Fixed. It should now work with terran infantry units just as well.

I don't know exactly what this bytes' function is, but I think this will do generally what you want. It's offsetted on the fourth byte and becomes non-zero when the unit was recently ordered. It seems to decrement gradually back to zero.

This detects unit specific data directly which means it will suffer latency unlike how normal units' voices play instantly. At least it works multiplayer.

Attachments:

Post has been edited 2 time(s), last time on Mar 23 2010, 9:41 pm by yoonkwun.

The problem with this is that it reads true even for auto acquired commands (AKA if an enemy walked by and your unit decided to shoot it, it would return true). This is the same problem as trying to use morphling's destination detection.

Frankly, whether the data is shared or local doesn't make a difference to me. Either way the only actions that will result from it's detection will be local (IE Play wav) and consequently non-desyncing.

By first unit, second unit, etc. these are the positions of the unit in the game memory correct?

if you're killing the units off whose direction you want to detect and respawning them, i suppose the only way to match the correct unit with the correct detector numbers would be to know it's facing (by ordering it to move straight up?) and testing all 1700 units for whether they're facing upwards. And do this several times in different directions to try and weed out false positives.

Or is there a way to know which memory slot the next spawned unit will occupy?

Also, could someone direct me to an article on direction detection or kenoli's method or pixel grids? I keep reading about these things but I can't find any forum threads concerning them directly, only fleeting references to them in threads on topics where they might be applied.

This is a good idea. It would be really hard for a player to make their unit face an exact angle.

Correct.

You could make them the first units on the map (I don't know if it is possible to "sort" units placed on the map ...) so they have the lowest possible entry. That way if any other units on the map die, they wont ruin it if you replace these units as soon as they die.

A better method is to dedicate a predetermined area for this purpose, respawn the unit there and test each unit for that position. This way there'd be no false positives. Or if that's not possible then you can create the unit, give it to player 9 and test each unit's owner. You couldn't have any other units owned by player 9, of course. Generally this is trigger-extensive stuff depending on how much units there are, avoid it if possible.


No. It's not even reliable to assume that if there's only one unit on the map, it dies, and another is spawned, that it'd be the first unit index.


The EUD method technically is the only true direction detection; the other methods merely detect changes in unit position and infer direction from it. Honestly, I would recommend you use the EUD system over the others because it's a lot easier (with ProTRG it can be made by typing a single line without having to deal with EP's or adjusting the quantity value) and uses less triggers/locations. The only drawback is that you can't have the unit die (unless you use the method above), whereas the other methods it could.

There was a pretty good tutorial on location grids on the old SC1 wiki but it's inaccessible at the moment. Here's the source of Kenoli's method (I say don't bother with it): http://www.staredit.net/189419/

Post has been edited 2 time(s), last time on Jul 24 2010, 2:39 am by yoonkwun.

I thought maybe I'd place extra/backup units, enough that would they could be killable and not run out of them. Then I'd only need to make detection triggers for that set of units in the backup queue.
Or I could stack a bunch of mineral spots or w/e, take up the first 1600 spots in the unit memory so anything that respawns would be in the last 100, reduce my triggers that way. I figure to have the ability to test all 1700 units' direction I'd need 1700 triggers to detect which slot a unit would occupy, and 1700x(the number of directions i would want to use). Would Starcraft run that many triggers reliably/quickly?


Thanks! Interesting stuff

PS. You're the man

This.

Death can easily be faked. Why bother making all those triggers for backup units? Move unit, give to another player, create same unit at location, kill unit at location. Only problem is if they are right up against the edge of unwalkable terrain on the top or right side, there may be a unit placement error. You could create and then move a unit to the location to get rid of the error, but the problem of no unit death animation would persist. I think it's a small price, though.

StarCraft is capable of running several thousands of triggers, but may lag based on trigger conditions. It will run 1700*X triggers just fine, unless they all check for a resource intensive condition, such as Bring. Check http://www.staredit.net/topic/11648/0/ for some information about lagging conditions. I think editors break above 65536 triggers, while StarCraft is still capable of running the map.

Edit: As far as the number of directions goes, it only makes sense to use the same number of directions as the number of rotations for the unit's sprite. For example, a Zergling has 16 different facing directions, so you wouldn't need more than 16 directions to check; it would be redundant.

Edit: I figured I would share my values for my direction system on Fireball.

I had two triggers for 'Up' because the editor didn't like the idea of going from a negative to a positive with at least/at most. It works perfectly with a Zergling, although I would imagine there would be some tweaking for other units.

Post has been edited 2 time(s), last time on Jul 25 2010, 4:03 pm by Roy.

That would force the attack/death system to be trigger-based, but he might want it to be based on normal unit attacks. The alternative is to give the unit higher HP then desired, then detect when it's below a certain HP to determine it "dead". For instance, if a marine is to have 100 HP, you would give it 200 HP, and detect when its HP is below 100. Then you would move it, create the death animation, etc. It's not the best method in terms of aesthetics.


It has 16 graphical directions, but its true direction is not dependent on its graphical direction but rather on the slope in which it was moved. Therefore if you want more accuracy in that respect it makes sense to detect more than 16 directions.

I've been playing around with this for a while now and i cant get it to work for A Fenix (Zealot), Up works and all that but other directions are real buggy and dont seem to work right away.

An easy way to debug is to add a display text message action to each direction you're implementing, and then move the unit around. If it's facing one direction but detecting another, adjust the death numbers. That's what I did to tweak my unit of choice to a desired accuracy.

In theory, though, the slopes should not vary between units. If you're getting odd detections, verify that your triggers are properly set up.

you can use a leaderboard to display the 4 byte variable you're reading. convert the EPD into EUD, then place the unitID + 228 into a "kills" leaderboard. Players 1-8 will be displayed, but 9-12 won't.