Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mister Always]

Does DFHack work with the newest version of DF or what?

I was going to ask that a few minutes after the update posted, just because I like the sound of Quietust saying "No."

But I don't want to distract the memory mapping guys.

It sounds like there were few if any changes to data structures, so I'd imaging this round of mapping would be relatively quick.  The automated detection might already be done with a bunch of testing now to make sure that DFHack 0.40.16-r1 doesn't set your computer on fire.

Well I don't know WHAT the hell most of that means but I'll just wait a while.

[Dirst]

Well I don't know WHAT the hell most of that means but I'll just wait a while.

DFHack is a hack: it inserts itself into the DF game by replacing one of the DLL files.  If this DLL was compiled by Toady alongside the rest of DF, it would Just Work.  The reality is that the DFHack team has to poke around inside each new version of DF and find out where everything is stored, a task made a bit more difficult by the security features of Windows, OSX and Linux.  When you hear references to the SYMBOLS table, that is the list of memory locations for game data (the in-game date, the raws, the name of a creature, etc., etc., etc.).

I know that Dwarf Therapist also uses the SYMBOLS table, and a lot of 3rd-party tools (TWBT, Stonesense, Embark Tools, etc.) are DFHack plugins that can't operate without DFHack.

[The Bard]

Had a bit of a reveal mishap. I revealed, let my miners start digging, but now when I unreveal, my dug out squares are invisible, even if the miners dig them out afterward.

[Max™]

^ try tiletypes paint h 0 it will unhide them, if you still can't see them you could try to use paint l 1 and make sure the squares are visible due to being lit.

Also, yeah, the memory mapper folks are wonderful, and should be entombed in molten steel for everyone to admire them eternally appreciated for their hard work getting new versions cracked open for the rest of us.

[lethosor]

Well I don't know WHAT the hell most of that means but I'll just wait a while.

DFHack is a hack: it inserts itself into the DF game by replacing one of the DLL files.  If this DLL was compiled by Toady alongside the rest of DF, it would Just Work.

This is only true on Windows, where DFHack is implemented by replacing SDL.dll. Toady doesn't compile this, but it can safely be replaced (assuming the replacement is built correctly), since it's linked to DF dynamically (i.e. DF doesn't rely on a specific copy of SDL.dll).
On OS X and Linux, DFHack is built as a separate library and a modified launcher script is used to load this library before starting DF.

The reality is that the DFHack team has to poke around inside each new version of DF and find out where everything is stored, a task made a bit more difficult by the security features of Windows, OSX and Linux.  When you hear references to the SYMBOLS table, that is the list of memory locations for game data (the in-game date, the raws, the name of a creature, etc., etc., etc.).

There aren't really security problems, since DFHack and DF run in the same address space (and can access the same memory).
Of the things you listed, the date is the only one actually in symbols.xml (cur_year, cur_year_tick, etc.). If I understand correctly, most other things are located with respect to an offset in symbols.xml and the size of certain structures (for example, "world" contains a list of units, each of which have a name which can be located based on the known layout of a unit).
A lot of addresses in symbols.xml can be located automatically with scripts (i.e. by scanning the executable). Some need to be located when DF is running, which can be done semi-automatically with a DFHack script. A few (debug flags and save_on_exit) need to be located manually. The bulk of the manual work is determining if there are any changes to structures. For example, 0.40.15 added four new types of announcements, which increased the size of the announcement_flags array. It's difficult to say what would have happened if DFHack hadn't been updated to take this into account, but less trivial changes can easily cause crashes.

I know that Dwarf Therapist also uses the SYMBOLS table, and a lot of 3rd-party tools (TWBT, Stonesense, Embark Tools, etc.) are DFHack plugins that can't operate without DFHack.

Dwarf Therapist actually uses a separate configuration format (not symbols.xml) which contains some different data, so there isn't really a single "symbols table". However, a lot of this data comes from the df-structures repo, which is what DFHack uses as well. (It's also possible to generate a DT ini file using DFHack, which I did for 0.40.15.)

[Dirst]

Spoiler: Detailed explanation (click to show/hide)

Well I don't know WHAT the hell most of that means but I'll just wait a while.

DFHack is a hack: it inserts itself into the DF game by replacing one of the DLL files.  If this DLL was compiled by Toady alongside the rest of DF, it would Just Work.

This is only true on Windows, where DFHack is implemented by replacing SDL.dll. Toady doesn't compile this, but it can safely be replaced (assuming the replacement is built correctly), since it's linked to DF dynamically (i.e. DF doesn't rely on a specific copy of SDL.dll).
On OS X and Linux, DFHack is built as a separate library and a modified launcher script is used to load this library before starting DF.

The reality is that the DFHack team has to poke around inside each new version of DF and find out where everything is stored, a task made a bit more difficult by the security features of Windows, OSX and Linux.  When you hear references to the SYMBOLS table, that is the list of memory locations for game data (the in-game date, the raws, the name of a creature, etc., etc., etc.).

There aren't really security problems, since DFHack and DF run in the same address space (and can access the same memory).
Of the things you listed, the date is the only one actually in symbols.xml (cur_year, cur_year_tick, etc.). If I understand correctly, most other things are located with respect to an offset in symbols.xml and the size of certain structures (for example, "world" contains a list of units, each of which have a name which can be located based on the known layout of a unit).
A lot of addresses in symbols.xml can be located automatically with scripts (i.e. by scanning the executable). Some need to be located when DF is running, which can be done semi-automatically with a DFHack script. A few (debug flags and save_on_exit) need to be located manually. The bulk of the manual work is determining if there are any changes to structures. For example, 0.40.15 added four new types of announcements, which increased the size of the announcement_flags array. It's difficult to say what would have happened if DFHack hadn't been updated to take this into account, but less trivial changes can easily cause crashes.

I know that Dwarf Therapist also uses the SYMBOLS table, and a lot of 3rd-party tools (TWBT, Stonesense, Embark Tools, etc.) are DFHack plugins that can't operate without DFHack.

Dwarf Therapist actually uses a separate configuration format (not symbols.xml) which contains some different data, so there isn't really a single "symbols table". However, a lot of this data comes from the df-structures repo, which is what DFHack uses as well. (It's also possible to generate a DT ini file using DFHack, which I did for 0.40.15.)

Thanks for the clarification.  The security feature I meant was the address space randomization, which affects how the memory mapping needs to be set up initially but probably doesn't affect version-to-version updates.  And sorry about the brain-fart conflating df-structures, symbols.xml, and Dwarf Therapist's .ini files.

In any case, great work on the whole enterprise!

[Putnam]

Huh, you can edit stress directly and it'll stick now.

Code: [Select]

local utils = require 'utils'

validArgs = validArgs or utils.invert({
 'unit',
 'amount',
 'adjust'
})

local args = utils.processArgs({...}, validArgs)

local unit = args.unit and df.unit.find(args.unit) or dfhack.gui.getSelectedUnit(true)

if not unit then qerror('No unit was selected or specified.') end

if args.amount then
    if args.adjust then
        unit.status.current_soul.personality.stress_level=unit.status.current_soul.personality.stress_level+args.amount
    else
        unit.status.current_soul.personality.stress_level=args.amount
    end
else
    print(unit.status.current_soul.personality.stress_level)
end

[Rose]

Cheat everyone to have -500000 stress?

[Putnam]

I tested it by doing the opposite, heheh.

But yeah, that's 100% possible now.

[rmblr]

Is there some reason dfhack gui plugins and keybindings wouldn't play well with vanilla macros?

[Roses]

So I am trying to find out more information about the interactions a creature can do. I have written something that will tell me the name of the interactions, but I was hoping to get some more information from the game itself and have some questions that may or may not be answerable.

From what I have gathered in unit.curse there is interaction_id, interaction_time, interaction_delay, own_interaction, and own_interaction_delay. Now I have figured out that the interaction_ fields are for interactions from syndromes and the own_interaction_ fields are for interactions from the creature/caste itself. From what I can gather interaction_time is just the amount of time the unit has been able to do the interaction (the number of ticks since the syndrome was applied), and the _delay is the number of ticks since the unit last used the interaction. The issue comes when trying to identify the individual interactions. The interaction_id doesn't seem to correspond to any identification that I can find, and the own_interaction is reference to the data in creature.caste.body_info.interactions which is listed as userdata.

1. Does anyone know what the interaction_id corresponds to?
2. Is there anyway to access a userdata table?

EDIT: Looks like I found what interaction_id points to, and how to get the information concerning the interactions acquired through syndromes. I am still unable to find any extra information regarding innate interactions.

[expwnent]

Roses: All I know is that I tried very hard to figure that out and I failed. I believe there is a type that hasn't yet been mapped out for innate interactions a caste can do.

[RadonPlasma]

Is there some reason dfhack gui plugins and keybindings wouldn't play well with vanilla macros?

Just curious, but is this in response to something you've experienced?

[rmblr]

Is there some reason dfhack gui plugins and keybindings wouldn't play well with vanilla macros?

Just curious, but is this in response to something you've experienced?

Yea, whenever I record a basic macro (digging designations, placing furniture, hauling route assignment) then play it, crazy things happen. In particular I noticed a small dfhack prompt appearing in the upper left (where the FPS counter goes) and keys being entered there which is quite strange.

[Dragoon209]

While talking with other Web Fortress hosts, we came up with an idea for a Notes browser plugin that would help make community forts much more productive.

When summoned via hotkey, a menu would appear in the Dwarf Fortress game window with a list of all the notes in the fortress, sorted by name.  The player should be able to search the list.  When the player selects a note and hits enter, it should jump to that section of the fort, and open the note in the DF interface so the player can read any additional note text.

Additionally, it would be nice if the list of notes could be exported to a file to allow easy transfer to a community Fort Diary, allowing players who are just observing to get an idea of what is in the fortress. I think a format like this would be helpful:
   
Note Name: Note Coords
    Note Text
Note Name: Note Coords
    Note Text

Super Bonus Time Options:
    When a lever is built, a note is Automatically created at its location with a Name like "Lever-Coords"?

The Plugin would need to be compatible with DF Hack 34.11-R5 (The current supported version of Web Fortress.)

None of us are experienced enough with DF Hack or C++ to write it.  Would someone be interested in writing it?

Additionally, There is some need for a Story Telling Plugin as well that adds events to the log.  For example, when a Forgotten Beast arrives, the contents of the popup in-game should be written to the log for later capture.  The same could be done for arriving migrants, the creation of artifacts, etc.  Please let me know if there is any interest!  You can also find us in #webfortress in webchat.quakenet.org!