Report, edit, etc...Posted by scwizard on 2005-09-10 at 15:00:26
http://www.staredit.net/index.php?act=Atta...e=post&id=13717
How can I use this, as well as memcalc to find out how to detect the rally point of unit 120?
I need to know:
1. How to use this information to figure out the memory addresses to input into memcalc.
2. What the heck 0x0f0 means, and how it relates to 5bc688
3. How many bytes a "word" is (I can always ask my brother, but I might as well write it here).
ADDITION:
The above link only works for me, therefore: ATTACHIFY!
I fixed the above link, and the one in my siggy.
QUOTE(The new text document (link above))
5bc688 - Start of unit table - 1700 entries
0x0f0 – word – rally point x
0x0f2 – word – rally point y
0x0f0 – word – rally point x
0x0f2 – word – rally point y
How can I use this, as well as memcalc to find out how to detect the rally point of unit 120?
I need to know:
1. How to use this information to figure out the memory addresses to input into memcalc.
2. What the heck 0x0f0 means, and how it relates to 5bc688
3. How many bytes a "word" is (I can always ask my brother, but I might as well write it here).
ADDITION:
The above link only works for me, therefore: ATTACHIFY!
I fixed the above link, and the one in my siggy.
Report, edit, etc...Posted by DT_Battlekruser on 2005-09-10 at 16:29:52
Binary Glossay:
Byte - 8 bits
Word - 16 bits
dWord - 32 bits
Long - 32 bits
0x0F0 would mean that the rally point for Unit 0 is at the adress 0F0 away from 5BC688 (start of table).
When using MemCalc, since it wasn't configured for it, you can't take any easy shortcuts.
You first have to find out how big the unit table for one unit is. I'm guessing it might be 512 bytes (up to 0x1FF), but I'm not sure. If that were so then you would do this:
120 is 78 in hex.
5BC688 + 78(1FF) + F0 = 5CB700 for the raw offset
Enter in 5CB700 in MemCalc advanced mode and use 0 for object id and value length to bypass the helper routines. (With 0, it does a raw conversion from offset to deaths)
MemCalc returns
Start on byte 1 of 15693 deaths for player 8 and that should be the x coordinate of the rally point on localunit 120. The next 2 bytes will be the y coordinate.
NOTE: The above calculations were based on the assumption that the unit table per unit is 512 bytes. This may not be the case.
Actually, I'm almost positive it isn't a whole 512 bytes. Don't know what it is though.
Byte - 8 bits
Word - 16 bits
dWord - 32 bits
Long - 32 bits
0x0F0 would mean that the rally point for Unit 0 is at the adress 0F0 away from 5BC688 (start of table).
When using MemCalc, since it wasn't configured for it, you can't take any easy shortcuts.
You first have to find out how big the unit table for one unit is. I'm guessing it might be 512 bytes (up to 0x1FF), but I'm not sure. If that were so then you would do this:
120 is 78 in hex.
5BC688 + 78(1FF) + F0 = 5CB700 for the raw offset
Enter in 5CB700 in MemCalc advanced mode and use 0 for object id and value length to bypass the helper routines. (With 0, it does a raw conversion from offset to deaths)
MemCalc returns
QUOTE
To achieve this offset, use Unit ID 15693 with player 8 on byte no 1
Start on byte 1 of 15693 deaths for player 8 and that should be the x coordinate of the rally point on localunit 120. The next 2 bytes will be the y coordinate.
NOTE: The above calculations were based on the assumption that the unit table per unit is 512 bytes. This may not be the case.
Actually, I'm almost positive it isn't a whole 512 bytes. Don't know what it is though.
Report, edit, etc...Posted by Doodle77(MM) on 2005-09-10 at 19:03:55
m.r.bob:
I don't really understand what your doing.
I guess I'll just end up using ArtMoney to find the memory locations.
That's how Doodle77 found the screen position memory locations.
Of course 2 secs later DK sends us the text file, making that work redundent.
So what you do, is multiply the unit ID by 512(?) and then add the number next to the different aspect and add that total to 5bc688.
I don't really understand what your doing.
I guess I'll just end up using ArtMoney to find the memory locations.
That's how Doodle77 found the screen position memory locations.
Of course 2 secs later DK sends us the text file, making that work redundent.
So what you do, is multiply the unit ID by 512(?) and then add the number next to the different aspect and add that total to 5bc688.
Report, edit, etc...Posted by DT_Battlekruser on 2005-09-10 at 19:21:11
I'm pretty sure it's not 512.
But I know it's not 256, so I'm not really sure what is going on.
But I know it's not 256, so I'm not really sure what is going on.
Report, edit, etc...Posted by scwizard on 2005-09-11 at 15:08:02
/summon DeathKnight
Maybe he'll know if it's 512 or not and stuff like that.
Maybe he'll know if it's 512 or not and stuff like that.
Report, edit, etc...Posted by DT_Battlekruser on 2005-09-11 at 15:12:00
The thing is, theres an offset for something else sooner than 512x1700 bits away.
Report, edit, etc...Posted by scwizard on 2005-09-11 at 17:11:34
I'm gonna PM DK to find out the difference between the HP of unit 0 and the hp of unit 1.
....
Nevermind, I found it.
BTW:
ADDITION:
I'm pretty sure the difference is 880D8 or something of the sort.
EDIT: IT IS 880D8 w00t!!!
....
Nevermind, I found it.
BTW:
ADDITION:
I'm pretty sure the difference is 880D8 or something of the sort.
EDIT: IT IS 880D8 w00t!!!
Report, edit, etc...Posted by DT_Battlekruser on 2005-09-11 at 17:13:43
Soo, what is the gap?
Report, edit, etc...Posted by scwizard on 2005-09-11 at 17:16:54
880D8
I tested it, it works.
EDIT: Wait a second, something's wrong...
I tested it, it works.
EDIT: Wait a second, something's wrong...
Report, edit, etc...Posted by DT_Battlekruser on 2005-09-11 at 17:20:23
No, what is the table size?
Report, edit, etc...Posted by scwizard on 2005-09-11 at 17:34:46
I don't know...
I might know within the hour though.
*m.r.bob wishes DK would come out of the sky and say "THE GAP IS ____"
ADDITION:
148
I might know within the hour though.
*m.r.bob wishes DK would come out of the sky and say "THE GAP IS ____"
ADDITION:
148
Report, edit, etc...Posted by AFL-InuYasha on 2005-09-11 at 18:08:49
im totally lost, y would u wanna no the rally point of the 120th unit anyway, u mean unit #120-machine shop, or the 120th unit made on the map or trained in game, im still lost
Report, edit, etc...Posted by DT_Battlekruser on 2005-09-11 at 18:46:54
The unit with the LocalId 120. This usually means the 120th unit to be placed, but if that unit dies then the slot can be refilled.
Report, edit, etc...Posted by scwizard on 2005-09-12 at 17:44:30
Actaully, I think it doesn't go by LocalIds.
I think it has something to do with the pointers in the units stuff.
I'm not an expert though.
Well, anyway it's a moot point now.
I'm just gonna use ArtMoney to find the hp of the unit's whoes rally points I want to detect, then use the differences in DK's text file.
Problem solved.
Topic ignored (I'm not locking this time).
I think it has something to do with the pointers in the units stuff.
I'm not an expert though.
Well, anyway it's a moot point now.
I'm just gonna use ArtMoney to find the hp of the unit's whoes rally points I want to detect, then use the differences in DK's text file.
Problem solved.
Topic ignored (I'm not locking this time).
Report, edit, etc...Posted by DT_Battlekruser on 2005-09-12 at 19:45:23
LocalId of a unit is defined as the slot it fills 
Report, edit, etc...Posted by AFL-InuYasha on 2005-09-12 at 20:32:38
but still, y the 120th unit, wats the rally point affect gameplay, is it a target or sumtin, well neway hope ui solve it, ur working really hard
Report, edit, etc...Posted by DT_Battlekruser on 2005-09-13 at 01:03:17
Provided the unit is a building, you can detect its raqlly point using a conditions. As one example of many, this could be used to make a bound where you control a zergling by ordering a Gateway different really points.