- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Difference between revisions of "User:Mattmoss/MacMemoryHacking"
(initial offsets, page explanation) |
(→Addresses: found block & cell counts) |
||
| Line 2: | Line 2: | ||
The table below was taken (as a template) from [[User:AzureLightning/Memory_research|AzureLightning's memory research]] page. I've copied it here as a work-in-progress for myself, to keep track of data, not to steal or misrepresent anything of AzureLightning's work. This is information gathering for Mac memory hacking. | The table below was taken (as a template) from [[User:AzureLightning/Memory_research|AzureLightning's memory research]] page. I've copied it here as a work-in-progress for myself, to keep track of data, not to steal or misrepresent anything of AzureLightning's work. This is information gathering for Mac memory hacking. | ||
| − | The | + | The "addresses" are actually offets into a single (approx. 10MiB) chunk of memory pulled from the running executable that I search rather than the whole process memory (which includes other libs and dynamically loaded crap that has nothing to do with DF). For others interested in hacking around and want to know the particular memory chunk I'm pulling... |
* Run DF. Start game, pause it. | * Run DF. Start game, pause it. | ||
| Line 39: | Line 39: | ||
|- | |- | ||
| − | | | + | | 0x0000010C |
| 4 | | 4 | ||
| long | | long | ||
| Line 77: | Line 77: | ||
|- | |- | ||
| − | | | + | | 0x0024BFD0 |
| 4 | | 4 | ||
| long | | long | ||
| Line 84: | Line 84: | ||
|- | |- | ||
| − | | | + | | 0x0024BFD4 |
| 4 | | 4 | ||
| long | | long | ||
| Line 91: | Line 91: | ||
|- | |- | ||
| − | | | + | | 0x0024BFD8 |
| 4 | | 4 | ||
| long | | long | ||
| Line 98: | Line 98: | ||
|- | |- | ||
| − | | | + | | 0x0024BFDC |
| 4 | | 4 | ||
| long | | long | ||
| Line 105: | Line 105: | ||
|- | |- | ||
| − | | | + | | 0x0024BFE0 |
| 4 | | 4 | ||
| long | | long | ||
| Line 112: | Line 112: | ||
|- | |- | ||
| − | | | + | | 0x0024BFE4 |
| 4 | | 4 | ||
| long | | long | ||
Revision as of 04:06, 17 October 2009
Addresses
The table below was taken (as a template) from AzureLightning's memory research page. I've copied it here as a work-in-progress for myself, to keep track of data, not to steal or misrepresent anything of AzureLightning's work. This is information gathering for Mac memory hacking.
The "addresses" are actually offets into a single (approx. 10MiB) chunk of memory pulled from the running executable that I search rather than the whole process memory (which includes other libs and dynamically loaded crap that has nothing to do with DF). For others interested in hacking around and want to know the particular memory chunk I'm pulling...
- Run DF. Start game, pause it.
- Run ps on the command-line to get DF's process ID.
- Run vmmap <ps> | grep '__DATA.*dwarfort.exe' on the command-line, replacing <ps> with the number from the previous step.
- You should get output that looks something like this:
__DATA 00799000-01247000 [ 10.7M] rw-/rwx SM=COW dwarfort.exe __DATA 01247000-01275000 [ 184K] rw-/rwx SM=S/A dwarfort.exe
That 10.7M is the desired chunk of data. The two numbers before it is an address range you can use in calls to vm_read_overwrite (and supposedly vm_write). (Don't assume that those addresses are consistent; I suspect they are, but I don't know for certain.) If you know what vm_read_overwrite is, you should be ready to go. If you don't..... well, you'll just have to wait until someone comes up with the tools you like, because beyond what I've just shown you, it's now hunt, peck, code, debug, and profit time. (Okay, no profit.)
How far am I with hacking? Right now, I've just started. It'll take me a while, especially since I'm at school and doing tons of reading and other things that are far more important than DF. This page (and my main user page) will change as things progress.
| Address | Size | Type | Name | Description |
|---|---|---|---|---|
| 0x00000104 | 4 | long | Cursor X Coordinate | Number of cells EAST from the west side. Value is -30000 when cursor is not in use. |
| 0x00000108 | 4 | long | Cursor Y Coordinate | Number of cells SOUTH from the north side. |
| 0x0000010C | 4 | long | Cursor Z Coordinate | Number of levels UP from the bottom level |
| 4 | long | Creature Focus | Indexes into the full creature list | |
| 4 | long | Dwarven Race ID | Used to identify dwarves (Or it could just be the "controlling" civilization you are playing as.) | |
| 4:4 | vector | Full Creature list | List of of all creatures. There are other vectors based upon various factors | |
| 4 | pointer | Map data | Points to a list of addresses measuring Block Count X long.
Those each reference a list of addresses measuring Block Count Y long. Each of those reference a list of addresses Block Count Z long. And finally, each of those addresses references a map block. | |
| 0x0024BFD0 | 4 | long | Block Count X | Number of 16x16 blocks in the X direction |
| 0x0024BFD4 | 4 | long | Block Count Y | Number of 16x16 blocks in the Y direction |
| 0x0024BFD8 | 4 | long | Block Count Z | Number of Z levels |
| 0x0024BFDC | 4 | long | Cell Count X | Number of cells in the X direction (Should be Block Count X * 16) |
| 0x0024BFE0 | 4 | long | Cell Count Y | Number of cells in the X direction (Should be Block Count Y * 16) |
| 0x0024BFE4 | 4 | long | Cell Count Z | Number of Z levels (Should equal the Block Count Z) |