I know this has probably been discussed to death to some extent, but I feel like hacking extended players into being usable (capable of attacking, for example) would be kind like finding the holy grail in terms of expanding functionality (namely, not having to take up player slots to have additional CPU enemies or allies). I noticed this entry while going through the EUDDB:



This seems to imply that through EUDs, one can force human players to share their vision with Players 9-12, which might overcome the extended players' lack of reaction, no? Even if they can't see themselves, could they be forced to see other players and thus attack them that way? I'm slightly confused with how to write this EUD, but if I understand correctly, this will execute for the player it fires under depending on which address I set? I'm really not sure how to set this memory correctly (as it's size 4 and has a length of 12), so I'm sure this is wrong, but would it look something like this?:



Also, tangentially related, but I noticed that the player trigger lists exist in memory up to Player 8 (each player ID is offset by 3, or 12 if you're looking at the hex values). However, the next address in the table is 12 player ID values off (it jumps from -24 to -12), which is precisely the values you'd expect for four Player 9-12 trigger lists.



I imagine this is just a bridge to nowhere, but do we have any idea why Starcraft refuses to execute them?

I guess technically yes, but for some reason, making a player share vision to players 9+ seems to clear a player's vision of themselves, at least in 1.16.1. It could be different in SCR but I didn't check there, and I didn't look into why the issue with the vision clearing occurs.

It's a bit mask, so setting -11358 to 9 will share vision of player 1 units to players 1 and 4 (because 9 in binary is 1001). -11357, which is 4 bytes (or 32 bits) further, will do the same for player 2, etc.

If you look more carefully, you'll notice it's not a difference of 12 but 2512. The undocumented addresses after the Player 8 Trigger List are pointers to things that are completely unrelated to triggers; P9+ don't have trigger lists.

I was thinking of loading up something like ArtMoney to peer into the memory and see what's going on, but I'm a little scared of Blizzard monitoring for that and me getting banned, since I've read of that happening to players even on singleplayer.


Sorry, this is a pretty noob question, as I have no software dev background, but how do you know what the bitmask is? Is there more documentation somewhere that I'm overlooking? I thought maybe if I set memory to 257 or 32896 with default bitmask (0xFFFFFFFF) it would share vision with Players 1 and 9 (10000000 1 or 1000000010000000), since it seems the player is determined by decimal places. Yet I feel like that isn't right and it didn't work, since what would the other bytes be for? I tried maybe bitmask of 0xFFFF0000 (that means to ignore the other half, I'm assuming, although what about the 4th byte?) and set it to 65537 (10000000 00000000 1) with no luck either. I can't wrap my head around this and there's hardly any resources on it. What's the right value to turn it on for Players 1 and 9?


Ah, too true. Is that space simply unknown, or occupied with data not actually pertinent to the map at all?

I do use CheatEngine to do that, but only on the 1.16.1 version of the game. I don't think it would be very useful on SCR, especially for the purpose of EUDs, since they are emulated and based on the 1.16.1 addresses. You can use Farty's Installer to get your hands on the classic version if you didn't back up your original installation when SCR rolled in. If for some reason you want to use ArtMoney on SCR, simply blocking SCR and other related programs from receiving/sending data through the internet seems to have been sufficient for me.

Just to correct myself, I meant bit flags instead of bit mask. I guess I know what the flags are from simple trial and error, if it's not documented in the EUDDB description, but it's a pretty safe assumption to make that the first bit is for player 1, the 2nd for player 2, and so on in that order. Since there are only 12 true players, you'd also assume that the remaining bits don't do anything (or anything that's intended).

257 is correct: there are 8 bits in 1 byte, so binary [00000001 00000001] = hex [01 01]. Setting that value at -11358 will make P1 and P9 share vision with P1, and at -11350 will do the same with P9. 65537 would share vision of P1 and P17. Though again, by my own testing, I don't get the expected results when sharing vision with players 9+. I suppose you can also see how setting a bit mask of 0xFFFFFFFF in SCMD2 would be redundant; you would for instance set it to 0x00000101 so that setting the value of 257 to that address would not affect any of the other bits, thus preserving other shared vision flags (0x01 = 00000001, 0x02 = 00000010, ..., 0x0F = 00001111).

I guess both in this case.

So, thanks to your suggestions, I've been peering into 1.16.1's memory addresses (it's been fun and instructive), and I can confirm that you're right, in both SCR and 1.16.1, sharing vision to Player 9 clears a player's vision of themselves. In fact, according to memory, by default Players 9-12 are sharing vision to themselves. So, that theory is bunk. It just seems that, for whatever reason, anytime a value greater than 0 is entered into the second byte, it disables the vision state of that player to themselves, even if the first byte is 00. This seems to be true of bytes 3 and 4 as well.



Why might this be the case?

I was also playing with this offset for the "player vision filter" and found that it seems to handle what units the player is able to click on based on a given player's view. When I set the value to FF (or even FF FF to for extended players) it allows all units to be visible and clickable even though they're under fog of war – including after the player's vision of themselves disappears from doing the above, so I can still control my units even with no vision of myself; however, my units act like Extended Player units and can't attack. They'll just follow enemy units around when I issue an attack order. If I flip the third byte at this address, it shuts this off and I can't see or click any units anymore. Considering how close this behavior is to extended players, I feel like I'm on to something. Just can't grasp how the dots connect.

Also, I can't seem to explain why, occasionally, Player 9 units will attack (typically only ever once). This doesn't seem related to the temporary vision that a unit gets when attacked by another obscure unit, because if I sit a Marine with 50,000 HP to attack a Player 9 Marine, it'll sit there for 10 minutes firing on the Player 9 unit without ever being attacked back.

Post has been edited 1 time(s), last time on Nov 19 2022, 2:51 am by Brusilov.