I was wondering if there was any particular way to figure out the EUD offset of a defiler, when it casts swarm, through the use of EUDs, but not detecting the storm, but detecting the energy used to create the swarm. I have tried myself, but to no success. Can one of the EUD pro's help out a beginner here?

I was wondering if there was any particular way to figure out the EUD offset of a defiler, when it casts swarm, through the use of EUDs, but not detecting the storm, but detecting the energy used to create the swarm.

I have tried myself, but to no success. Can one of the EUD pro's help out a beginner here?

[color=#b5b5ff]Could you be more specific as to the circumstances? If you know the Local ID of your defiler, than you certainly detect energy loss.[/color]

Could you be more specific as to the circumstances? If you know the Local ID of your defiler, than you certainly detect energy loss.

Use these: +0x4C - BYTE bPlayerID +0x4D - BYTE bMainOrderID +0x4E - BYTE bMainOrderState +0x4F - BYTE bOrderSignal +0x57 - BYTE bSpellCooldown Start at 0x0059CB40 to 0x006283D0.

Use these:

+0x4C - BYTE bPlayerID
+0x4D - BYTE bMainOrderID
+0x4E - BYTE bMainOrderState
+0x4F - BYTE bOrderSignal

+0x57 - BYTE bSpellCooldown

Start at 0x0059CB40 to 0x006283D0.

[quote=name:DT_Battlekruser][color=#b5b5ff]Could you be more specific as to the circumstances? If you know the Local ID of your defiler, than you certainly detect energy loss.[/color][/quote] Laymans terms please?

Quote from DT_Battlekruser

Could you be more specific as to the circumstances? If you know the Local ID of your defiler, than you certainly detect energy loss.

Laymans terms please?

Each unit has a Local ID associated with it -- from 0 to 1699. The first unit placed on the map is 0, the second is 1699, the third is 1668 and so on. The adress of Node 0 is 0x0059CB40. You need to read these address to see if it has fired: +0x4D - BYTE bMainOrderID Which would be 0x0059CB8D. Now go to datedit and find which ID number firing swarm is and read for that. So, read the addresses: 0x0059CB8D + (n * 336) == 119

Each unit has a Local ID associated with it -- from 0 to 1699. The first unit placed on the map is 0, the second is 1699, the third is 1668 and so on. The adress of Node 0 is 0x0059CB40. You need to read these address to see if it has fired:

+0x4D - BYTE bMainOrderID

Which would be 0x0059CB8D. Now go to datedit and find which ID number firing swarm is and read for that.

So, read the addresses:

0x0059CB8D + (n * 336) == 119

[color=#b5b5ff]Statistics specific to an individual unit on the map (current HP, current energy, etc.) are stored in a table in RAM called the Local ID table. If you know a local ID and an offset, you can compute the location you need for the EUD condition. This is only plausible if you know the local ID of the [i]specific[/i] defiler you want to detect. Local IDs are assigned upon unit creation, so any preplaced unit will always have the same Local ID. Otherwise, if the order of creation of new units changes, the local IDs change, and it becomes virtually impossible to detect properties. This reminds me, I should get off my ass and finish MemCalc 6.1. (edit) Uhh, A of S T, are you sure? There is a unit max of 1700 units and to the best of my knowledge the table is first filled in order from 0 to 1699.[/color]

Statistics specific to an individual unit on the map (current HP, current energy, etc.) are stored in a table in RAM called the Local ID table. If you know a local ID and an offset, you can compute the location you need for the EUD condition. This is only plausible if you know the local ID of the specific defiler you want to detect. Local IDs are assigned upon unit creation, so any preplaced unit will always have the same Local ID. Otherwise, if the order of creation of new units changes, the local IDs change, and it becomes virtually impossible to detect properties.

This reminds me, I should get off my ass and finish MemCalc 6.1.

(edit) Uhh, A of S T, are you sure? There is a unit max of 1700 units and to the best of my knowledge the table is first filled in order from 0 to 1699.

Nevermind, found it, thanks.

Nevermind, found it, thanks.

However, using EUDs, the only efficient way to read these variables is about... 4 times per click... which measn you need to copy these triggers four times per cycle run. Sorry, dtbk, ur right >.> I've been doing other things with unit node.

However, using EUDs, the only efficient way to read these variables is about... 4 times per click... which measn you need to copy these triggers four times per cycle run.

Sorry, dtbk, ur right >.> I've been doing other things with unit node.

Does anyone have a good system for reading a low-order byte out of the unitnode? Since you can't deconstruct the value without EUD actions I can't think of a good way. If Blizzard had added an action to copy one death count to another...

Does anyone have a good system for reading a low-order byte out of the unitnode? Since you can't deconstruct the value without EUD actions I can't think of a good way.

If Blizzard had added an action to copy one death count to another...

[quote=name:DT_Battlekruser][color=#b5b5ff](edit) Uhh, A of S T, are you sure? There is a unit max of 1700 units and to the best of my knowledge the table is first filled in order from 0 to 1699.[/color][/quote]If you look at the data, the first unit is in the first slot. The second unit is in the [i]last[/i] slot, then it works backward to the first slot (and filling any that may become available.) This is also more apparent when reading preplaced units. One unit may be at like 0x59xxxx, the next at 0x62xxxx, then subsequent units' offsets getting smaller. [quote=name:Heimdal]Does anyone have a good system for reading a low-order byte out of the unitnode? Since you can't deconstruct the value without EUD actions I can't think of a good way. If Blizzard had added an action to copy one death count to another...[/quote]TrigPlug can. :P Pretty much all you can do (other than external functions) is read every possible value... That greatly limits what you can read, though. Like upgrades you'd have to read it 8 times (one for each combination of the other upgrades that share the same dword), assuming all upgrades are available.

Quote from DT_Battlekruser

(edit) Uhh, A of S T, are you sure? There is a unit max of 1700 units and to the best of my knowledge the table is first filled in order from 0 to 1699.

If you look at the data, the first unit is in the first slot. The second unit is in the last slot, then it works backward to the first slot (and filling any that may become available.) This is also more apparent when reading preplaced units. One unit may be at like 0x59xxxx, the next at 0x62xxxx, then subsequent units' offsets getting smaller.

Quote from Heimdal

Does anyone have a good system for reading a low-order byte out of the unitnode? Since you can't deconstruct the value without EUD actions I can't think of a good way.

If Blizzard had added an action to copy one death count to another...

TrigPlug can.
Pretty much all you can do (other than external functions) is read every possible value... That greatly limits what you can read, though. Like upgrades you'd have to read it 8 times (one for each combination of the other upgrades that share the same dword), assuming all upgrades are available.

Ok, I [i]thought[/i] I had the code. But I guess I didn't DT, the defiler is the first unit on the map. A_of-s_t, could you explain those codes to me a little bit more?

Ok, I thought I had the code. But I guess I didn't DT, the defiler is the first unit on the map. A_of-s_t, could you explain those codes to me a little bit more?

Someone gimme that code too...I...really need it...

Someone gimme that code too...I...really need it...

[quote]If you look at the data, the first unit is in the first slot. The second unit is in the last slot, then it works backward to the first slot (and filling any that may become available.) This is also more apparent when reading preplaced units. One unit may be at like 0x59xxxx, the next at 0x62xxxx, then subsequent units' offsets getting smaller.[/quote] [color=#b5b5ff]You should just out and publish all you know about EUD memory structures. I'm too lazy to examine RAM myself, so I'm just going on everything that's been published in the past.[/color]

Quote

If you look at the data, the first unit is in the first slot. The second unit is in the last slot, then it works backward to the first slot (and filling any that may become available.) This is also more apparent when reading preplaced units. One unit may be at like 0x59xxxx, the next at 0x62xxxx, then subsequent units' offsets getting smaller.

You should just out and publish all you know about EUD memory structures. I'm too lazy to examine RAM myself, so I'm just going on everything that's been published in the past.

I was writing a detailed tutorial, but then I got bored. :P

I was writing a detailed tutorial, but then I got bored.

how do u examine sc ram?

how do u examine sc ram?

[quote=name:Heimdal]Does anyone have a good system for reading a low-order byte out of the unitnode? Since you can't deconstruct the value without EUD actions I can't think of a good way. If Blizzard had added an action to copy one death count to another...[/quote] Copy one death count to another... Binary countoff, use: At least x A; Subtract x A; Add x B; Add x C; At least x C; Add x A; Subtract x C; That lets you copy A over to B.

Quote from Heimdal

Does anyone have a good system for reading a low-order byte out of the unitnode? Since you can't deconstruct the value without EUD actions I can't think of a good way.

If Blizzard had added an action to copy one death count to another...

Copy one death count to another...
Binary countoff, use:

At least x A;
Subtract x A; Add x B; Add x C;

At least x C;
Add x A; Subtract x C;

That lets you copy A over to B.

You can't copy EUDs. You cannot run SetDeaths on them to subtract anything. Doing so would break SC anyway.

You can't copy EUDs. You cannot run SetDeaths on them to subtract anything. Doing so would break SC anyway.

Jabok: Can't do that because the death count I want to be copying from is in EUD-memory. If there were a hypothetical "copy-death-count" action, it would still be allowed to read EUD-memory. And while we're in fantasy-land, I'd like a pet dinosaur. Farty: If we still had EUD actions, theoretically you could copy the value to two other death counts and then copy it into the original memory by destructively copying one back.

Jabok: Can't do that because the death count I want to be copying from is in EUD-memory. If there were a hypothetical "copy-death-count" action, it would still be allowed to read EUD-memory. And while we're in fantasy-land, I'd like a pet dinosaur.

Farty:
If we still had EUD actions, theoretically you could copy the value to two other death counts and then copy it into the original memory by destructively copying one back.

[quote=name:Heimdal]Farty: If we still had EUD actions, theoretically you could copy the value to two other death counts and then copy it into the original memory by destructively copying one back.[/quote]Maybe if you did it within 1 trigger cycle... I don't know how the triggers are handled alongside the game itself, but I can forsee bad things if you mess with certain values and don't have them fixed [i]immediately[/i]...

Quote from Heimdal

Farty:
If we still had EUD actions, theoretically you could copy the value to two other death counts and then copy it into the original memory by destructively copying one back.

Maybe if you did it within 1 trigger cycle... I don't know how the triggers are handled alongside the game itself, but I can forsee bad things if you mess with certain values and don't have them fixed immediately...

Can we get back on topic, and figure this code out please? Or atleast help me with it? Thanks :D

Can we get back on topic, and figure this code out please? Or atleast help me with it?

Thanks