With the help of Rockz, who found the formula and the first units address, I have found unit order coordinates.

Formula - 65536(Y) + (1)X = Death amount
Yes, the x and y are in one value, not separate.

Unit 1
ID:1587
Player 4

Unit 2
ID:13480
Player 4

From Unit 2 to Unit 3 just subtract seven from Unit 2s Unit ID to get Unit 3 and repeat to get Unit 4 Unit ID.
Note: Unit # means the unit that is placed on the map. Unit 1 is the first unit placed on the map and so on.



This is Multiplayer.

Uses (May need a grid to do)
-selecting spells
-attacking units
-ordering units(obvious)
-many more, however I can't think of any

This is a really useful and possibility opening concept

and yeah
I can confirm this.

Neat stuff

I've been searching for a way to easily detect the X position (y is easy, x is hard). All the conditions when using extended players point to the same place as deaths, making them worthless in this case. You might as well use deaths to keep things similar.

However, one condition caught my eye, and I can't figure it out. Opponents. Where/how is the data stored? I tried searching and failed. If this happens to read two bytes off from deaths, we can read any value quite easily.

?

http://farty1billion.dyndns.org/EUDDB/?pg=ref&a=unitnode

;o

Also "opponents", if I understand you correctly, is figured by finding the alliance table. this is the 1.15.2 value.

Alright, so I see that. Any chance you know how it is read? The alliance table is 12x12, that part I get, but it seems only when both players are allied victory will they not be considered each others opponent. However, the player also has to be present, and not 9-12.

The interesting part about this is that it seems to read multiple places, although I'm beginning to get the feeling that it's worthless.

How did I miss this one =\

So this will basically detect the coordinate a unit is ordered to? Does anyone have the Memory condition for this?

It's not quite useful. You can do atleast and atmost for the X, but not the Y since they are in the same value. For a 20x12 area with a definition of 1 pixel you would need 245760 triggers. For a 64x64 map with a 32 pixel (1 tile) definition you would need 131072 triggers. I made a sample map with two players on a 64x12 map with a definition of 32 pixels with 49240 triggers for both players combined.

Attachments:

Couldn't you just write a quick program to spit out conditions for coordinates based on the formula rockz found? You could then put these into maybe some sort of excel sheet, so people can look up specific locations for their map..

I have almost no knowledge in any programming language.

Ah so this is what that map was about. It's a shame though, I tried it before and even 49240 triggers causes my old computer to hang and in need of a manual reboot. Still good to know this exists.

Great! Now find rally points.

really, though, I'm pretty excited about this... on a small scale, this could make some pretty sweet maps...

Regarding Cecil's suggestion... Tell me how to find the condition for a particular coordinate (or whatever knowledge would be needed), and I can probably write some JS to auto-generate a table, which I can then save to a file and try to attach to a post in this topic. Heck, I might even be able to write a script that takes a location (as in, you give it the XY coordinates for the upper left and lower right corners) and a resolution (pixels or tiles), and outputs a list of SCMD text triggers.

rally point is the same thing. You can find the offsets yourself.
+0x10 - WORD wMoveToXPos
+0x12 - WORD wMoveToYPos
+0xF8 - WORD wRallyX
+0xFA - WORD wRallyY


The problem is that you have to detect a 4 byte integer. So that means if you detect a range, you can detect the general y location, but not the x location. In a 64x64 map, lets say the unit is at 1028,1028 (32,32), and we are trying for 32 px precision. The 4 byte data is 67371008. The range for the y is anywhere from 67107840 to 69204959. To find the x, you have to detect 32 y positions and a range for each x position. For example, the first one is 67108864 to 67108895. Add 65536 to the range for the next one.

This is the range to detect the sqare 32,32. You'd need 32 triggers.


you can change the size of the squares, but it only cuts the triggers in half if you double the precision. 64x64 pixel squares need 64 triggers per square, so 64*32*32=65536. 32x32 pixel squares need 32 triggers per square, so 32*64*64=131072. 16x16 pixel squares need 16 triggers per square, so 16*128*128=262144.