I've tried using EUD condition's for WASD movement before, and it's worked every time I've tested it alone, but whenever I try it with other people on b.net they are always dropped. Why?

B/c the method of key detection used in EUDTrig (which I believe is the only known method for key detection) uses local information (information that is not necessarily the same on one computer as it is on another); when/if the map performs a global action based on information that is not the same between different players (and players usually won't be pressing the same keys at the same time!) Starcraft's natural anti-hack/bug-finder kicks in and separates players with different data into their own games.

EUD Sync (with pics!)

OOHhh, well that really limits what you can do with EUDs

The synchronization issue only really limits what you can do with local EUDs. For the record, I organized all the local EUDs into the "Local" tab; the ones under General/Player/Unit can be used in multiplayer games. (The Display Text tab is a little more complicated in multiplayer usage.)

You can get around key press detection by using selection detection and having players hotkey their units. This of course limits your inputs to the number row, but it's possible to make a game out of it. In fact, as part of a one-hour mapping contest I made a map called "Hotkey Hotkey Revolution" which is a play on DDR. You can find that map in this map pack: http://www.staredit.net/?file=2895

Attachments:

Post has been edited 1 time(s), last time on Sep 18 2014, 10:14 pm by trgk. Reason: Added trigger syntax.

I really think we should stick to the single scmdraft trigedit standard as a base "assembly" language.

I'll look into it when I get some free time. It won't get pushed out before the upgrade/tech EUD support (which I haven't made much progress on, to be honest). It would probably be available as a DLL extension like Farty's MapExport.dll.

It seems you have an extra backslash in the comment :p

Uh, not really: it's an escape sequence, and you'll notice in the Classic Trigger Editor that the comment is, in fact, correct. You'll also see a backslash before a quotation (") character in the text triggers.

Hello there!

I could not find any information about what EUDGen version is suitable for what StarCraft version. I have tried out some EUD conditions with display text feedback, but none of them seemed to work. As the link in the forum is broken I found EUDGen2.0.3 and EUDGen2.0.3_1.08b at Sourceforge and tried it with both.

My StarCraft version is the latest 1.16.1 that I believe was no further patched by Blizzard since 2008 or something. It is the german version - is it possible that this causes issues?

Regards,
BS

Fixed the download link. EUDGen2 is built to work with the English version of SC 1.16.1, though much of it should be language-agnostic.

It could possibly be a language-specific issue regarding your problems with Display Text detection. If you have the time, I'd appreciate it if you could post what you're trying to detect, what EUDGen is giving you, and what the actual values in memory are.

There was a misunderstanding, I am not trying to read display messages, I am just using them in actions to see if some test EUD conditions are met. Although I'm posting the details about the EUD conditions I tested.


1st test try:

Somehow this condition is always met, no matter what available/used/max supply Player 1 has. Therefore the feedback message appears straight ahead.


2nd test try:

And this condition is never met. I look up the unit index in the new unit properties window of SCMDraft. I also thought about the index numbering (starting from 0 or 1?) and tried the indexes plusminus 1 of the shown in SCMDraft for the unit I want to be detected that it has been selected. The relevant unit belongs to Player 1.


I am probably going to install the english version as well to see if it's the german version's fault.


It's good to see that this community is as fresh as a daisy and replying that fast
- BS

_________________
edit: Sorry, I forgot that you were asking about the actual values in my memory. I think I'll pass on that one, as I initially intended to use EUDGen just because I am too lazy to mess around with memory management. Unless you tell me exactly what to do to look up these values, I think there is no point for me in spending much more time than an average person with IT talents would to do that.

Post has been edited 2 time(s), last time on Mar 18 2015, 4:01 pm by BumpelSnake.

That could be your problem. SCMDraft is not accurate; it gives Start Locations a unit index, when they don't actually receive one in-game. You need to move all the Start Locations to the end of the unit index list if you want all the other unit indexes to possibly be correct. There are a few ways to screw up the indexes in SCMDraft, but this is definitely the most common.

Post has been edited 1 time(s), last time on Mar 19 2015, 6:33 pm by Azrael.

Interesting. I'll double-check this when I have time, but it's correct as per the EUDDB entry.

If you want to do some reading: http://www.staredit.net/304568/

Assuming you're checking the first row that appears in-game:

1) Attach Cheat Engine to SC (More info on using CE earlier in the tutorial linked above)
2) Manually add address 0x6413E4 as a string value of length 32.
3) Play the game, have display text appear
4) Copy text value from the address

If the value of the address at that location is obviously not text, then it would seem your client has display text stored in some other location.

Sorry for the lazy answer; I'm on mobile right now, so writing things up is a bit tedious.

Building on top of units that don't have indexes are player owned ones. If you have preplaced units for players and they're not in the game, they lose their unit ID. I ran into that problem in one of my maps, thanks to Roy here it was fixed.

Another issue is, I believe, that goliath and tank turrets are counted twice by SC (for the turret) and not SCMDraft.

So, how do you actually work with unit IDs when I see no possibility to figure it out? How do you even address a specific unit that was added later per triggers to check/edit its properties?

Short answer: You don't. Just preplace units and move them around when you need them.

Lazy answer: Just make the EUD triggers for all 1700 unit indexes.

Long answer: You can build a system where you cycle through create/removal, checking the pointer address for the next unit index allocation (0x628438) to be the one you want to target, and then create the unit at that time. This can be achieved if you can ensure a certain range of indexes to be always available (e.g., if there won't be more than 1000 units on the map, you can guarantee yourself a way to create a unit at index 1000+ by creating enough units until the next unit index pointer is the expected value), provided you have the means to check this value between trigger cycles without issue.

Azrael has also described alternative methods in this topic: http://www.staredit.net/topic/14230/

Alright guys, I've enlightened myself: what I wanted to check is the currently maximum supply that is in-game called "available", and for the trigger editor, it calls it correctly "available", too. It was just me being stupid, although I don't see a reason why one should check for "maximum" supply due to it's always 200 for every race.

And for the unit IDs, seems that pre-placed units with therefore known IDs are good enough. I can work with that just fine.

Thanks for all of your advices!
-BS

You can modify that with overflows from extended units.