v50 Steam/Premium information for editors
  • 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.
This notice may be cached—the current version can be found here.

40d Talk:Memory hacking

From Dwarf Fortress Wiki
Jump to navigation Jump to search

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

  1. 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)
This is a great idea. I suggest going one step further : Give the user a list of options (say : magma, flux, thick forest, chasm, underground river, pit, etc), and logically AND all parts of the map that have those features. That would save people hours of looking for their perfect start location. Runspotrun 19:25, 8 December 2007 (EST)
  1. 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)
I personally use the "Dwarf Fortress" string, with the address shifts I doubt there will be an issue with that. --Rick 18:33, 8 December 2007 (EST)