Staredit Network > Forums > SC1 UMS Theory and Ideas > Topic: [EUD] A Mapmaker's Guide for Creating EUDs
[EUD] A Mapmaker's Guide for Creating EUDs
Aug 14 2011, 8:00 pm
By: Roy
Pages: < 1 2 3 4 >
 

Aug 21 2011, 7:20 pm DavidJCobb Post #21



This is amazing and I'm donating minerals to you for it, if I can remember how that works. (It's been a while. I usually only check the site-centric section of the forums.)

Can EPDs be used to write data? I know Blizzard patched EUDs to prevent writing, but did they miss EPDs?



None.

Aug 21 2011, 7:28 pm Roy Post #22

An artist's depiction of an Extended Unit Death

No, EPD actions were disabled I believe one patch after EUD actions. Heinermann may have more details on this:

Quote from Heinermann
After Extended Unit Deaths were patched, I tried extended alliance status, which worked, and caused yet another patch. Since then, extended switch states and other methods I've tried testing have resulted in failure.

SCMD2 also doesn't support writing EPD actions, sadly. :(

And thanks for the donation. ^^




Aug 21 2011, 10:34 pm O)FaRTy1billion[MM] Post #23

👻 👾 👽 💪

As I remember it, EPD Actions never existed.. EUDs were never able to write above player 8.



TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB - topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig - topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
\:farty\: This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!

Aug 23 2011, 12:20 am Lanthanide Post #24



Only just noticed this thread today. Someone should have written this guide a long time ago, it's incredibly useful.

Couple of comments:
1. The example in section 3 would have been better if it were doing something that you can't do with regular conditions and if it were an EUD that lots of people might actually use, like unit HP detection. I guess that would start muddying up later topics like 5 and 6 though in having to introduce their concepts earlier. I guess an appendix with a worked example for HP detection that ties it all together would be useful?

2. The PC vs mac section says to set a switch when a player is PC. Really you should be setting a DC here, because you haven't preserved the trigger and so after the first trigger run the switch will be left with whatever value the last player had.



None.

Aug 23 2011, 1:10 am Roy Post #25

An artist's depiction of an Extended Unit Death

Quote from Lanthanide
1. The example in section 3 would have been better if it were doing something that you can't do with regular conditions and if it were an EUD that lots of people might actually use, like unit HP detection. I guess that would start muddying up later topics like 5 and 6 though in having to introduce their concepts earlier. I guess an appendix with a worked example for HP detection that ties it all together would be useful?
The goal of section 3 was to understand EPDs, and I felt an example that you could already do without them would feel less foreign and help understand exactly what's going on. It was also a nice and simple address to calculate without worrying about offsets/value manipulation. Something like HP detection should be second nature if you follow and understand the guide, so no such example is immediately required.

Quote from Lanthanide
2. The PC vs mac section says to set a switch when a player is PC. Really you should be setting a DC here, because you haven't preserved the trigger and so after the first trigger run the switch will be left with whatever value the last player had.
I'm not sure what you're asking here. For all PC players, their game will think the switch is set, while all Mac players' games will think it's cleared; a death counter is not necessary for this.

Under normal circumstances, you'd be absolutely correct, but this goes into the Local vs Global synchronization discussion I mention. The game is technically in different states for PCs and Macs: one that thinks the switch is set (PC), and one that thinks the switch is clear (Mac).

If you're more comfortable using a death counter, by all means go ahead; it will have the same result, and may seem more obvious than the switch solution. Keep in mind, however, that in a Mac player's game, EVERYONE has 0 deaths of that unit, and for the PC player's game, EVERYONE has a death for that unit.

If you think it would be beneficial for the tutorial to change the example in section 3 to something more practical, I'd be happy to rewrite that part (I don't want to do HP detection because that involves indexes and offsets). However, I do not believe section 5 to be in error. Thank you for the criticism, though. ^^




Aug 24 2011, 9:21 am Lanthanide Post #26



Section 3 doesn't need to be changed, it is good the way it is for all the reasons you list. I just think something like HP detection as a worked example / something people could pick up and use themselves with some small tweaks would be handy. Would be best done as an appendix.

As for the switch thing, you are entirely correct, now that you've explained it. I think your explanation here would actually be useful to put into the post. I simply assumed that switches were global values shared by all players, and normally they are, but because we're performing the switch action on a per-player basis through EPD conditions, it ends up behaving more like a DC than a switch normally does.

Thinking more about this switch situation, couldn't you effectively end up with per-player switches using this mechanism? Player 1 has switch 1 set, and as far as P1 is concerned so does P2-8, but P2-8 don't think anyone has that switch set.

I guess if you actually then had triggers that affected global data that relied on that information, you'd de-sync, though.

Post has been edited 1 time(s), last time on Aug 25 2011, 3:03 am by Lanthanide.



None.

Aug 25 2011, 3:19 am Lanthanide Post #27



Double-posting, but this new post is different from my above.

With the scoreboard displays, you can enable or disable computer players, but that's it. Is there any way to disable certain players from being displayed on the scoreboard for certain human players?

Eg P1 can see P2 and P3 on the scoreboard, but not P5-7 who are human players. And vice versa.

Maybe there's a local data structure somewhere that is a table of the players to display on the score board, like this:
P1: display/not display
P2: display/not display
..
P8: display/not display

And players who are absent, or players who are CPU with "disable CPU players" has been set will be set to not display and everyone else will be display. It would be really handy if a EUD could be used to turn individual players off.



None.

Aug 25 2011, 3:49 am Roy Post #28

An artist's depiction of an Extended Unit Death

(This would require EUD Actions to be enabled.)

As far as I see from the EUDDB, Leaderboard Computer Players Enabled is just a toggle between on and off. Perhaps the Active Player Structures can be changed to trick the game into thinking a player is a different type (+0x08 = Type (1 byte; 0 = inactive, 1 = computer, 2 = human, 7 = neutral)), so you can disable all computers and any player you would want.

But, according to Farty's tests on local/global actions, the leaderboard is surprisingly picky regarding showing/hiding computer players. Manipulating this action from a local EUD trigger will cause desynchronization. This would mean that even if the above method works, you would require all players to have the same leaderboard display (although changing player structure data would probably have to be universal as well).

And in response to your previous post, I'll likely add an appendix for HP detection when I have the time, as it is quite popular and would be a useful reference.




Aug 25 2011, 4:36 am Lanthanide Post #29



That's a pity.

In my case, I want to have only computers displayed on the leader board and hide all the human players. So I'd have to set the human players to be CPU and the CPU players to be human and then Disable CPU players. Tricky and error-prone, I suspect.

Actually I don't think it's even touched on in your posts at all: are EUD actions *always* illegal? You talk about synchronisation and global/local data, which is relevant for EUD conditions (and hence regular trigger actions as a result of the conditions) but never actually state whether EUD actions themselves are legal.



None.

Aug 25 2011, 5:01 am Roy Post #30

An artist's depiction of an Extended Unit Death

Yeah, I really didn't cover anything on EUD actions for this tutorial.

Ignoring the special case of Mac vs PC, EUD actions are all safe, just like all regular actions are safe. Again, the only synchronization issue you would have is if you were using a local EUD condition in conjunction with a global EUD action.

Also, obviously every single player must have EUD actions enabled; if some players do not have them enabled, then it's a classic desynchronization issue: the players that have EUD actions enabled will have the action run, and those that do not have the EUD actions enabled will not have the action run, thus creating two game states. Now, if the EUD action running is only for a local address, the physical game state will not change, and these players will remain in the game. However, if the EUD action running is for a global address, the physical game state changes, causing the two groups of players to drop from each other.

If you go back to Section 5, you can interchange "Actions" with "EUD Actions" and the same general rules apply.




Aug 27 2011, 10:17 pm Roy Post #31

An artist's depiction of an Extended Unit Death

Appendix A: Unit HP

You may take this as the base map for this appendix: EUD_HP_Test_Map.scx.

This will explain how to perform HP detection. For simplicity's sake, let's take the address from the http://www.staredit.net/topic/10471/ thread instead of finding it manually. On the EUD HP Test Map, we are interested in detecting the HP of the Marine.

You can see by checking the Marine in the unit properties window (right-click -> Properties) that it is at Index 0. This means we don't need to do any calculations for the EPD value, because the http://www.staredit.net/topic/10471/ already displays the values for the unit at Index 0:

Code
0x59CCB0 19027 HEALTH POINTS: AtLeast 256*a, AtMost 256*a + 255

From this, we can see that the EPD value we need is 19027. Now the only thing we need to do is calculate the correct HP value for the unit. As you can see from the http://www.staredit.net/topic/10471/ entry, you have to manipulate the value you want for the EUD to work correctly. If you wanted to check for 1 HP, you would check the range between (256*1) and ((256*1)+255). These calculations are explained in more depth in Section 4.2 and Section 6.2.

Here are the conversions for 0 to 100 HP:
HP Values

If you wanted to check for a range, say between 10 and 20 HP, just take the "At Least" value from 10 (2560) and the "At Most" value from 20 (5375). Between 2560 and 5375 is the HP range of 10 to 20.

In the EUD HP Test Map, the Marine has HP between 1 and 100. If you wanted to write an EUD to do something whenever the Marine's HP is between 90 and 95 (23040 to 24575), the conditions would look like this:
†††††Memory at Death Table + 19027 is at least 23040
†††††Memory at Death Table + 19027 is at most 24575

If you wanted to detect a different unit's HP between 90 and 95, the only thing you'd need to do to the above conditions is change the EPD value (19027) to the correct value based on the unit's Index ID.

Post has been edited 4 time(s), last time on Jun 11 2016, 9:49 pm by Roy.




Aug 28 2011, 1:18 am Sacrieur Post #32

Still Napping

Awesome! Thanks Roy =D



None.

Oct 15 2011, 10:59 am Lanthanide Post #33



How many players on battle.net really use macs any more?

Also, looking at this: http://farty1billion.dyndns.org/EUDDB/?pg=entry&addr=0x0058D2B0&ver=1.16.1&plat=win

Does this mean it would be possible to create triggers that fired (with regular actions etc) only when players had researched certain upgrades? Is this data global, or will it desync other players if I try to do actions if Current Player has researched some upgrade?



None.

Oct 15 2011, 2:47 pm FoxWolf1 Post #34



Quote from Lanthanide
How many players on battle.net really use macs any more?

There are definitely at least a few of us left, counting myself...

Personally, I have Windows emulation capability (though I find Windows rather unpleasant and thus strongly prefer to play using the Mac version of Starcraft), but the other Mac users that I know of don't, and are thus unable to play current EUD maps.




None.

Oct 15 2011, 4:19 pm Roy Post #35

An artist's depiction of an Extended Unit Death

Quote from Lanthanide
Does this mean it would be possible to create triggers that fired (with regular actions etc) only when players had researched certain upgrades? Is this data global, or will it desync other players if I try to do actions if Current Player has researched some upgrade?
This is indeed global data, and reading it would not desync any players (the entire game registers that units for player X have the upgrade). Reading the values for upgrades is not necessarily an easy task, however. Because EUDs can only check groups of 4 bytes in memory, anything smaller than 4-bytes that is not located at the end of the group is near impossible to detect on its own (for example, to properly check a 1-byte address at the front of the group, you'd have to make 16777216 triggers for each value you want to check).

Quote from Roy
It would require for most upgrades that you also know the status of at least one other upgrade. The worst case scenario (1/4 of the upgrades) is that you have to specify three other upgrade statuses to get an accurate value. The best case scenario (also 1/4 of the upgrades) is that you don't need to specify any other upgrade status than the one you are interested in.

If your map has strict control over upgrades and doesn't utilize many of them, then you can fill the other addresses with their default values since those will never change. For example, if you wanted to check Player 1's Terran Infantry Armor and knew that Terran Vehicle Plating, Terran Ship Plating and Zerg Carapace for that player are always going to be zero, it would be safe to only write EPDs checking the address 58D2B0 for X, where X is the upgrade number for Terran Infantry Armor.

(The list of upgrades can be found here.)

Post has been edited 1 time(s), last time on Jan 1 2012, 1:06 am by Roy.




Oct 15 2011, 6:36 pm O)FaRTy1billion[MM] Post #36

👻 👾 👽 💪

It's a little easier to for upgrades test because each byte will only have a value of 1 (except for the few that have multiple upgrades), or perhaps will always be 1 or will always be 0. When heinermann first posted about these, he listed them.

first byte:
1, 257, 65537, 65793, 16777217, 16777473, 16842753, 16843009

2nd byte:
256, 257, 65792, 65793, 16777472, 16777473, 16843008, 16843009

3rd byte:
65536, 65537, 65792, 65793, 16842752, 16842753, 16843008, 16843009

4th byte:
16777216, 16777217, 16777472, 16777473, 16842752, 16842753, 16843008, 16843009

And there is a lot overlap, so you can test for each unique value and set appropriate switches for each upgrade (disregarding any that you don't care for).
(clearing all of the switches beforehand, or assuming that any not set are cleared in the same block):
1: Set 1
256: Set 2
257: Set 1, Set 2
65536: Set 3
65537: Set 1, Set 3
65792: Set 2, Set 3
65793: Set 1, Set 2, Set 3
16777216: Set 4
16777217: Set 1, Set 4
16777472: Set 2, Set 4
16777473: Set 1, Set 2, Set 4
16842752: Set 3, Set 4
16842753: Set 1, Set 3, Set 4
16843008: Set 2, Set 3, Set 4
16843009: Set 1, Set 2, Set 3, Set 4



TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB - topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig - topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
\:farty\: This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!

Oct 15 2011, 9:11 pm Lanthanide Post #37



Ok, so my next question is can I use EUDs effectively as a "current player" offset? I want triggers to be owned by P1-3 and P5-7, but I don't want to have to write out 6 versions of each trigger to check for a specific upgrade, especially since I'm already going to have to write about 87 triggers to detect all of the different upgrades in the first place.

Also a few weeks ago, maybe a month or so, someone said in the shoutbox that they were going to use their mac computers at university or some-such to get some memory addresses and they were going to start with the upgrade ones. Does anyone know who that person was, and whether they did it or not?

Foxwolf, have you got any inclination to find some of these addresses out for us?

Edit: Also Farty, I think we can condense your table down even further for the number of explicit trigger conditions required:
At least 16777216: Set 4
At least 16842752: Set 3
At least 65536, At Most 65793: Set 3
At least 16777472, At Most 16777473: Set 2
At least 16843008, At Most 16843009: Set 2
At Least 65792, At Most 65793: Set 2
At Least 256, At Most 257: Set 2
Exactly 1: Set 1
Exactly 257: Set 1
Exactly 65537: Set 1
Exactly 65793: Set 1
Exactly 16777217: Set 1
Exactly 16777473: Set 1
Exactly 16842753: Set 1
Exactly 16843009: Set 1

If you don't care what the value of upgrade 1 is, but the player is still allowed to upgrade it (so it's not always 0 or always 1) then this set means you only have 7 conditions to check instead of 15.

Post has been edited 4 time(s), last time on Oct 15 2011, 10:10 pm by Lanthanide.



None.

Oct 15 2011, 9:35 pm Roy Post #38

An artist's depiction of an Extended Unit Death

Quote from Lanthanide
Ok, so my next question is can I use EUDs effectively as a "current player" offset?
No. EUDs are checking addresses in memory, and you can't add a modifier checking for "current player" for things that aren't located like that in memory (and the things that are located like that in memory are often times local addresses, such as screen position).

Quote from Lanthanide
I want triggers to be owned by P1-3 and P5-7, but I don't want to have to write out 6 versions of each trigger to check for a specific upgrade, especially since I'm already going to have to write about 87 triggers to detect all of the different upgrades in the first place.
You'll have to write them all individually. Farty's method above is checking a group of four upgrades that can only be either 0 or 1 (i.e. not weapons/armor upgrades), and it's only for one player's upgrades. You'd have to repeat this process with the other players.

Quote from Lanthanide
Also a few weeks ago, maybe a month or so, someone said in the shoutbox that they were going to use their mac computers at university or some-such to get some memory addresses and they were going to start with the upgrade ones. Does anyone know who that person was, and whether they did it or not?
It was jjf28, but I don't know whether or not he actually did it.




Oct 15 2011, 9:47 pm Lanthanide Post #39



Thanks Roy. I'll ask jjf if he got anything.

As for writing out for each player - bummer, thought that might be the case. In my map my interest in upgrades is purely so I can move them from P1-3 to P4 and from P5-7 to P8. So instead of checking if P1-3 have the upgrade and then transferring it to P4, I can check if P4 has the upgrade and then choose whether to transfer it from P1-3. So I'll need to write the triggers out for only P4 and P8, which will save me some work.

Edit: Other fun thing I've noticed is that the upgrades blocks aren't evenly divisible by 4. This means the upgrades differ in their long word values for odd and even players for the SC ones, and because the BW ones are 15 bytes instead of 16, they differ for p1-4 and again for p5-8. How annoying. Luckily the tech upgrades are always the same, and for my purposes I'm using P4 and P8 which will share the same values.

Post has been edited 1 time(s), last time on Oct 15 2011, 11:14 pm by Lanthanide.



None.

Oct 16 2011, 3:58 am jjf28 Post #40

Cartography Artisan

Quote
Thanks Roy. I'll ask jjf if he got anything.

I'm sure a few people are interested in this line of research, in my little bnet community there are 2 mac users.

The RAM reading software required admin privileges on the newer Mac OSs, so my university plan fell through

Now my #1 plan is through a bnet friend of mine, he said he would learn EUDs, and more importantly he is technically competent (both on windows and Mac, and even knows basic map editing), I gave him the links thread and the old vid. Previously I tried using him among others as guinea pigs to obtain addresses , but it really didn't work out, (I'm working blind, a single mistake snowballs, etc). He's in law school so I can't predict his schedule; if he doesnít get it done by the end of November Iíll pursue other tracks. Definatly not something i'll give up on.


My priority memories to find are as follows

- Energy (index's 0-5, high hopes for finding a pattern)
- Health (indexís 0-5, high hopes for finding a pattern)
- Keypress (finding all included in an example map I dl'd, potentially very complicated given maximized screens)
- Selection Detection
- Upgrade Levels
- Text Detection (easier than keypress :) )

I also did a lot of research for existing Mac EUDs, to my misfortune this was all that turned up (2007) http://www.staredit.net/topic/1517/&skin=5

If anyone is interested in taking it on themselves to help, here is the RAM reader for Mac: The Cheat
Also contact me for some prepared maps for finding addresses and for testing them.

Post has been edited 4 time(s), last time on Oct 16 2011, 4:27 am by jjf28.



Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

Options
Pages: < 1 2 3 4 >
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[10:34 pm]
Suicidal Insanity -- Pr0nogo
Pr0nogo shouted: grats on a new release version anyways
And thanks for testing
[10:34 pm]
Suicidal Insanity -- I'm sure I'll come back home tommarow and see a breaking bug :X
[10:29 pm]
Suicidal Insanity -- Anyways waaay to late, I needa be out of the apartment in 7 hours
[10:21 pm]
Suicidal Insanity -- So its doable but very niche
[10:21 pm]
Suicidal Insanity -- Pr0nogo
Pr0nogo shouted: can you enable minimaps in >256 map sizes or is that not possible? I don't remember what you said when i first requested this feature
The internal buffer is fixed to 128x128, so I'd need to add a new method of skipping tiles when determining the ones that are used in the minimap
[10:20 pm]
Suicidal Insanity -- And there are a number of things I only merged after that but that I may have included in the build, so this list is the stuff that is definitely new
[10:19 pm]
Suicidal Insanity -- Ya the previous release was in july or august
[10:19 pm]
Pr0nogo -- can you enable minimaps in >256 map sizes or is that not possible? I don't remember what you said when i first requested this feature
[10:19 pm]
Pr0nogo -- grats on a new release version anyways
[10:18 pm]
Pr0nogo -- long time ago
Please log in to shout.


Members Online: jjf28, Roy, Suicidal Insanity, Kolokol