Print

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

[FinalSin]

Hello,

I'm new to this modding lark for DF. I've noticed by prodding the tutorials that exist that by 'modding', people mostly mean adding extra content, renaming races and whatnot.

I'm looking at more fundamental stuff (for instance, logging certain events when they occur in-game) which I think would require more low-level access. Is this possible at all? I'm guessing that DF is not open-source, but how deep can you get into the game's inner workings?

[Jerkald]

Ya, its not open source but there have been alternate approaches at getting at the game data.  I'm not an expert on any of this, but I know that you can use DF HACK to get at the memory.  Its used in some of the popular tools out but I don't know if it will give you access to what you're looking for.

http://www.bay12forums.com/smf/index.php?topic=58809.0

[devek]

It is all on a case by case basis, tell us what you are trying to do and we might know how to do it.

[0x517A5D]

Hard.  An advanced project, not for someone getting started.

Were I to want to log events to a file, I would probably restrict this to events which cause a message to be either displayed or put in one of the internal logs.  This could be semi-automated, other stuff would be harder, and would need customized for each specific case.
Have a coprocess running that does all of the file manipulation.  This coprocess would need to have a window, presumably invisible, used as a target for custom Windows messages (WM_USER and above).

I would then search DF for the string associated with each message I wanted to log.  I would replace the call that displays the message with a small 'hook' of custom code.  That code first calls SendMessage with parameters: hardcoded target window handle, WM_USER, hardcoded pointer to the format string, pointer to the actual string being printed (graqbbed from the stack).  Then it jumps to the real display routine.

The coprocess would need to quickly grab anything it needs out of DF and hand that off to a worker thread, because SendMessage is a blocking call, so DF is paused during this action.
Despite the synchronization issues, I think using a separate process would be less complicated than trying to mess with CreateFile and friends in raw machine code, even lower level than assembly language.

[devek]

Hard.

You know, this community sure has a lot of people who know what they are doing relative to how few of us there are in the world