- 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 "40d Talk:Memory hacking"
| Line 28: | Line 28: | ||
<br/>[[User:Sphr|Sphr]] 2007 Dec 9 | <br/>[[User:Sphr|Sphr]] 2007 Dec 9 | ||
| + | |||
| + | :Have you verified that these offsets are <u>always</u> valid? I ask because they are past the end of the static memory area, up in heap space. I can easily see the allocator placing the memory block at different offsets on different computers, or even between different runs on the same computer. I agree that we need a version ID, but at first glance, this doesn't look like a good way to me.<br/>—[[User:0x517A5D|0x517A5D]] 17:53, 8 December 2007 (EST) | ||
Revision as of 22:53, 8 December 2007
New Release Updates
I'm just updating the main page as I figure new things out. Someone else will probably have to redo the formatting, since I don't really know the wiki formatting. --Zhentar 23:30, 29 October 2007 (EDT)
Creature Structure
I have a feeling that offset 0x00 is really a "next" pointer, forming a linked list. The reason being is that I was able to take the 4 byte value and go to that address, and it would be another creature. It progressed for a handful of creatures. Seems logical to assume it does it for all creatures. --AzureLightning 00:24, 3 November 2007 (EDT)
- I would assume this is true as well, since earlier versions did not have vtables for creatures, only items did. --Rick 18:07, 4 November 2007 (EST)
Memory Locations
Does anyone know the memory location for the current unit focus? --AzureLightning 14:05, 3 November 2007 (EDT)
- My automated tool says it's at current_unit_focus_loc == 00C36540 in .33c, verified by two search patterns, but not manually verified. You probably should have asked this in the .33c subpage.
—0x517A5D 16:49, 30 November 2007 (EST)
Questions
- Has anyone attempted to decode the memory for the "Choose Fortress Location" screen? Being able to generate a list of all local areas with magma vents would be useful. Palin88 20:09, 29 November 2007 (EST)
- It could be important to some people, but the formats are only correct assuming that the dwarf fortress binary is built using release config. Under debug config, std::string structure gains some more fat and the existing offset will be wrong. Not a prob now, but I think it is good to know. Sphr
Version Identity
Thought that the wiki should include some info on how to identify known versions. For lack of a better choice atm, I'm using the version text block that is displayed on main menu.
The version string itself is the string to be expected at the offset.
("v0.27.169.33a", 0x01BA29B0)
("v0.27.169.33b", 0x01B99FF0)
("v0.27.169.33c", 0x01BA29B0)
("v0.27.169.33d", 0x01B78670)
Sphr 2007 Dec 9
- Have you verified that these offsets are always valid? I ask because they are past the end of the static memory area, up in heap space. I can easily see the allocator placing the memory block at different offsets on different computers, or even between different runs on the same computer. I agree that we need a version ID, but at first glance, this doesn't look like a good way to me.
—0x517A5D 17:53, 8 December 2007 (EST)