One major flaw with text detection is that when a line is overwritten, the old message isn't cleared but simply written over where necessary. For example, if line 1 was

and the twelfth line (which would be the first again) was

The resulting message in memory would be

And, since you have to calculate the value by four characters at a time, this can indeed be very problematic for an ongoing system. If I explained any of this poorly or you think my findings are incorrect, please correct me.

As for a protection concept, why not detect screen position in the first couple seconds of the game, and you'd position the screen quickly to one of the corners? That plus a name detection would be a pretty good security, because who would figure all that out without opening the map with a good sense of EUDs (or reading this post )?

Well, since I'm reading the names, not typed text, the array not being zeroed doesn't really cause a problem, and I figure as long as there's a slight protection, no one is going to go through too much effort to play the beta. It's mainly to ensure that an inferior copy isn't distributed.

Screen detection would desynch. And that string would be


Don't need to scan every possible user name length or anything complicated like that, because you already know the username, a constant value. You can create the password so that it aligns to 4 bytes.
"Hein" "erma" "nn: " "sup\0"
"Mini" "moos" "e270" "7: c" "ool\0"

Yes, it would. Just have it required for the first player, which presumably would be the host/creator. You can use an "at most" or "at least" to detect if the screen is in the wrong place, and the desync would occur, and the map would lock.

I don't think that <15-character names are padded... Also somewhere in there is a color formatting byte (before the colon?).

After the colon and before the space, and you'd have to detect both variations to prevent a desync (<07> and <02>) (At least I think it's <02>... Could be <01>... Too lazy to test right now).

Anyway, that doesn't really matter if you're going to just detect the name, which would be way easier.

Well if you knew anything about programing, you could also create a custom dll to inject and change something that would not desynce the game, but at the same time make it so there would be no way to get those results unless it was injected. Then have an EUD condition set up to detect this change, if the proper change is found it knows it's you hosting it, and have the action Do Nothing. However if the proper change is not detected that means it's not you because you would have the injected dll, and have the condition run something that would desynce.

You might as well inject a dll, and detect that. Only the creator and folks who have the dll can host the map.

Yeah, I actually like that idea best, pick a random section of memory that I know is unused in-game, and make one odd modification to it, then have an EUD detect if that modification is there, I wouldn't even need to make a DLL to inject it, I could just modify it with a memory editor. That's definitely the easiest solution.

And then you drop from the game. Brilliant.

easiest solution is still the first suggestion, since it's all of 1 trigger.

You'd have to find a section of memory which is different for each player, and constant each time. You could do this with a death count and triggers. Set deaths for player 1's memory of some unused random unit (p12) via a trigger which only runs for him. Edit it so it's 0 again, somehow (easiest to inject a dll or something), then detect if it's 1. If it's 1, player 1 desynchs because the other players still have 0. When this runs, if player 1 isn't in the game, everyone loses. However, that limits host to player 1's spot, without random start locations. If editing death counts will drop you (which it very well might) then this won't work.

Depending on what value you choose, obviously I would pick a non-shared one

Which means you drop. You're making a modification that causes the trigger to execute, meanwhile other players in the game don't have that modification, and don't execute the trigger.

Unless you choose to execute a trigger when the value does not equal the modified value, so you would drop without the modification (assuming you would only have this trigger for one player). Then simply make the game unplayable without that particular player.

Yeah, Roy pretty much covered it, I would have it check an unshared value, and if that value ISN'T what I would set it to using the memory editor, then I declare defeat, the player drops, and the other players have triggers that defeat them when player 1 drops.