Report, edit, etc...Posted by Dark_Marine_123 on 2007-02-05 at 23:08:15
See, whenever I search for my hp value, I get 120~ random addresses, one or two is labeled "text", and when changed, changes the value of my hp, but doesnt hurt my unit (Not the right one I'm guessing). It would be more helpful if we got a couple real professionals in here and really cracked down on this illegitimate child, so at once, the less knowing can understand EUD's for just one patch 
Report, edit, etc...Posted by DT_Battlekruser on 2007-02-05 at 23:34:00
Would somebody do me a favor an PM me the fabled but never seen 1.14 memory map? Please?
Your problem is that a unit is only stored in RAM by its LocalID, assigned in order of unit creation from the start of the map between 0 and 1699, and subsequently renumbered when possibly when the LocalID 1699 is allocated. If you're looking for the HP of a medic which you can't find the LocalID of, you're sunk.
Farty's offset (without I memory map I don't know more than that) gives "The given offset with modifiers can be found at Unit ID 27224, Player 11 on byte no 1." in patch 1.14.
The byte structure of unit hp is 4 bytes, with the following pattern:
XX YY YY YY
where XX is the fractional HP coefficient (ANY nonzero value increments HP +1) and YYYYYY is the current HP of the unit. Remember, byte combinations in a DWORD are compiled backwards; for bytes
1 2 3 4
the hex value of the resulting long is (given 1,2,3,4 in hex) 4321 (literal appending).
Byte structures can be found in the Actions tab on MemCalc 5, and if someone would give me the damn memory map, I might be motivated to finish it.
Your problem is that a unit is only stored in RAM by its LocalID, assigned in order of unit creation from the start of the map between 0 and 1699, and subsequently renumbered when possibly when the LocalID 1699 is allocated. If you're looking for the HP of a medic which you can't find the LocalID of, you're sunk.
Farty's offset (without I memory map I don't know more than that) gives "The given offset with modifiers can be found at Unit ID 27224, Player 11 on byte no 1." in patch 1.14.
The byte structure of unit hp is 4 bytes, with the following pattern:
XX YY YY YY
where XX is the fractional HP coefficient (ANY nonzero value increments HP +1) and YYYYYY is the current HP of the unit. Remember, byte combinations in a DWORD are compiled backwards; for bytes
1 2 3 4
the hex value of the resulting long is (given 1,2,3,4 in hex) 4321 (literal appending).
Byte structures can be found in the Actions tab on MemCalc 5, and if someone would give me the damn memory map, I might be motivated to finish it.
Report, edit, etc...Posted by Kookster on 2007-02-06 at 00:43:50
farty1billion[MM] has it you just might have to motivate it from him is all.
Report, edit, etc...Posted by O)FaRTy1billion on 2007-02-06 at 00:48:21
QUOTE(DT_Battlekruser @ Feb 5 2007, 09:34 PM)
Farty's offset (without I memory map I don't know more than that) gives "The given offset with modifiers can be found at Unit ID 27224, Player 11 on byte no 1." in patch 1.14.
Eh. Note the quote above it...I'm too lazy to get an entire table thingy.
EDIT:
I don't have it. O.o I just have the ability to get it... but lack the patience and motivation... and I am currently doing many other things.
Report, edit, etc...Posted by DiscipleOfAdun on 2007-02-06 at 02:14:51
I'm sure most of you already know this...but just in case...
The structure that SC uses is an array representation of a linked list. When units are created, they are *normally* added in the first availiable slot. Once units start being killed, those slot(s)(stuff like tanks take up 2 slots...and the linking only get the base unit i think) are reclamed and allowed for use. SC also allocates the slot '0' first, and then starts backwards from 1699. Currently, the 1.14 table has 336?(I'm not sure if I'm counting them right...but I think I am) bytes in each entry(hex of 0x150). Most of the table up to about the 144th(0x90) byte or so is the same as pre-1.14.
The only thing really needed for finding all the value is the size of the table, the location, what the offset of the data you are looking for is, and the LocalID of the unit is. Normally, that id is easiest found by pre-placing the unit.
The best map of SC's memory that existed was at the now dead wiki. Which is why I've been hinting on and off to get it back up.
The structure that SC uses is an array representation of a linked list. When units are created, they are *normally* added in the first availiable slot. Once units start being killed, those slot(s)(stuff like tanks take up 2 slots...and the linking only get the base unit i think) are reclamed and allowed for use. SC also allocates the slot '0' first, and then starts backwards from 1699. Currently, the 1.14 table has 336?(I'm not sure if I'm counting them right...but I think I am) bytes in each entry(hex of 0x150). Most of the table up to about the 144th(0x90) byte or so is the same as pre-1.14.
The only thing really needed for finding all the value is the size of the table, the location, what the offset of the data you are looking for is, and the LocalID of the unit is. Normally, that id is easiest found by pre-placing the unit.
The best map of SC's memory that existed was at the now dead wiki. Which is why I've been hinting on and off to get it back up.
Report, edit, etc...Posted by spinesheath on 2007-02-06 at 02:30:30
Or at least someone could try to grab all the data from the Wiki and upload it as some files somewhere.
Report, edit, etc...Posted by DT_Battlekruser on 2007-02-06 at 20:32:42
QUOTE
SC also allocates the slot '0' first, and then starts backwards from 1699.
Srsly?
Also, I seem to remember that Starcraft assigns LocalIDs in numerical order until it runs out before looking for recently unallocated ones.
Report, edit, etc...Posted by DiscipleOfAdun on 2007-02-06 at 21:11:01
Well, it's been a while since I actually messed with it. That'd be before I knew what the data structures actually were. I still stand by what I said though...since I can distinctly remember looking backward through the data for the CUnit, CSprite, and CImage structs.
Report, edit, etc...Posted by O)FaRTy1billion on 2007-02-06 at 21:29:57
It helps if you ask people for files. I got it from Doodle who said he got it from ShadowFlare. 
Report, edit, etc...Posted by DT_Battlekruser on 2007-02-06 at 22:03:34
Does he also have a copy of the unit table?
Report, edit, etc...Posted by spinesheath on 2007-02-07 at 00:07:40
Do you mean that one?
Or something completely different?
Or something completely different?
Report, edit, etc...Posted by TheNomad on 2007-02-07 at 06:40:48
0x661AC8 - is the advanced properties sheet, not the special abilities (well might be interpreted similarly but I feel like "special abilities" goes too much into techs.).
0x6611E8 - should be the race pointer, not the group. That is, it's used by Consume to only work on Zerg units (values are: 1 = Zerg, 2 = Terran, 4 = Protoss). Groups should refer to builders, workers, cloakers, burrowers etc.)
Might be some other mistakes here and there in descriptions, but they seem all good otherwise.
0x6611E8 - should be the race pointer, not the group. That is, it's used by Consume to only work on Zerg units (values are: 1 = Zerg, 2 = Terran, 4 = Protoss). Groups should refer to builders, workers, cloakers, burrowers etc.)
Might be some other mistakes here and there in descriptions, but they seem all good otherwise.