Hi there. I'm developing a map that needs to know if a player has a certain unit (of their own) selected. I've accomplished this using an EPD for single-select units, but I am struggling with the following conditions:

1. The unit is in a group of selected units. While I was able to find the addresses containing each selection slot in a group (slots 1-12), the detection trigger fails if any unit other than a marine is the next in queue. For example, 0x006CAD7C (first group slot) could contain the unit ID for a ghost (01), but if a Vulture (ID 02) is in the next slot, the memory looks like 01 00 02 and the check for the ghost ID (a value of 1) at the first address fails.

The way I implemented the detection for group selection slot one for this first condition was through Memory in SCMDraft 2, with the memory @ deathtable + being 328326 for 0x006CAD7C checking for a value of 01. I followed Roy's recommendations for even slots since they have an offset (at least 01 * 65536 to at most 65536 + 65535 at player 328326)

2. A hack is used to select the unit while the "Attack Mode" is in queue. For example, if I highlight a battlecruiser, and bring up the attack targeting reticule by pressing A, then use a hack to select the ghost, my triggers do not detect that the ghost is now selected.

3. A combination of 2 and 1 is used.

4. The unit is given an order without ever having been directly selected.

Any help would be appreciated if this hasn't been done previously; I'm more than willing to share the results.

Post has been edited 1 time(s), last time on Sep 5 2013, 9:42 am by OmniScourge.

I'm obligated to mention that http://www.staredit.net/topic/15793/ can generate selection triggers for you.

Unit type shouldn't affect the selection values; they're based on the index ID. Looks like you may be reading off of the wrong address here.

EUDDB - Page 4
EUDDB - Player 1 Selection Group

Player 1's selection group starts at 0x6284C8. The address you're using (0x6CAD7C) is unfamiliar to me. Did you find this address manually?

"The address you're using (0x6CAD7C) is unfamiliar to me. Did you find this address manually?"

Yes. It would appear that the selection group I've found may be different than what is conventionally used.

In my test map, I was player 1 and had been searching for the unit ID occupying each group selection slot. I did this by selecting a group of Terran units in order of ID, searching for the index of the first unit, then narrowing the memory range by deselecting a unit and then searching for that unit's index - For example, marine in slot one starts with an unwieldy search for 0, then I deselected the marine and a ghost to put a vulture in that slot, changing the value I searched for to two. This narrowed down the first slot's address to 0x6CAD7C.

I looked at this section of memory in Cheat Engine and found that the IDs of each unit in my selected group occupied each slot in the proper order, regardless of the order in which I proceeded to select units in the group.

After a quick test, it seems 0x6CAD7C is a local address (i.e., it won't work for multiplayer games). It may potentially be tied to the unit icons in the selection UI; the values are two bytes in size (though it seems like they'd only need to be one byte, because it's just storing a unit type ID) with a presumable length of 12. In any case, I doubt you'll find it to be of any use for what you're trying to accomplish.

I would use the addresses found in the EUDDB for selection detection.

Okay. Thanks.

One quick thing, though. Given that it is a local address, could it potentially be used to drop a player who selects a unit that they are not supposed to be able to select by performing a global action based on that local data? That was my main intent with this trigger, though your method is likely better suited to it.

Yes, assuming that they aren't allowed to select that unit type, it could work. But since it's a size of 2 bytes rather than a size of 4, it's going to be problematic anyway. If you're looking for the selection of a specific unit, using selection detection in combination with detecting the player ID would be the best way to desync the player. An example of this would be:



Etc. for all players. Both of those EUDs can be generated with http://www.staredit.net/topic/15793/.

If you want to find a local address to desync on, I suggest you find one where the selection consumes the full 4 bytes, as it would make your life a lot easier.

I looked up four-byte values as you suggested. I'll post what I've come up with in this test map; reading the triggers should make it immediately obvious what I was trying to do with this.

Four byte values, possibly local, possibly not, containing unit IDs can be found on my machine starting at 0x025F0090 and going up by 10 (in hex) per slot to 0x025F0140. Please let me know if this is different for you for player 1.

If this works, the only problem that remains is if the player queues an attack option (selects a unit and presses A/P/M/G) and then selects the unit I don't want them to select using a hack, thus preserving the attack option and temporarily bypassing detection. It may be possible the hacker could then still perform the illegal action while going undetected.

Attachments:

That address looks rather high... Normally you want your EUD addresses to fall between 0x00401000 and 0x006DD694. In fact, the address you provided (0x025F0140) never gets allocated for me, and SC crashes when the EUD in your test map is read.

After some scanning, it seems like there aren't any useful addresses in the above range related to unit type selections (though I did find that 0x59723C is a local address that counts the number of units you have selected on its second byte).

I accidentally overrwrote the single-select trigger in my map with the multi-select detecting addresses that don't work. I've amended this and tried a new set of addresses I found with more tinkering.

It seems I've found the current HP for selected units, both single and multiple slots. Unfortunately, I can't tack down any other information about the selected units other than their current HP. It's also offset by one byte and doesn't solve conditions 2-4 in the OP. However, it does solve condition 1 handily.

The relevant addresses appear to contain 4-byte data starting from 0x06CA94D and ending at 0x06CA959 (plus four). I've included a new test map (without a broken string like the first) for you to have a look at.

Please note that the attached map is fully intended to crash StarCraft if set off - you have been warned!

Attachments:

Post has been edited 3 time(s), last time on Sep 5 2013, 9:45 am by OmniScourge.

Can you explain to me why 0x006284C8 won't work for you?


Looks like it's 0x6284b8 rather than c8, but it's pretty darn close...
No clue what the numbers actually mean, but they stay the same so long as the unit doesn't die.

Post has been edited 1 time(s), last time on Sep 5 2013, 11:10 pm by rockz.

Not knowing what the values mean makes it difficult for me to know if I can consistently detect what I'm looking for. Now, if I know the value and that value doesn't change (which it doesn't for the unit in the map I put up), then I can consistently detect what I'm trying to detect.

just select the unit you're you're not supposed to select and read the values directly.