I'm sure that it's come up before, but I was thinking about dfhack integration last night. It could work similarly to Isoworld or (non overlay) Stonesense, as a separate program that has information sent to it by a plugin. Some incomplete thoughts
Advantages:
- cuts out issues with implementing found offsets; once dfhack maps are complete it just works again
- avoids issues with ptrace on Linux systems and generally looks less like malware
- having a maintained plugin is basically an API, with all the benefits of that
- generally easier to maintain
Disadvantages:
- requires either dfhack or maintaining the new system as well as the old (though dfhack is nearly standard now)
- refactoring would require a fair bit of work
- slows down this update, but makes future ones easier
Is there some earlier post laying out the reasons not to go down this route? If not, what are they? Or would this be considered?
originally when i started working on DT there were few offsets and it seemed like the extra overhead of adapting everything to rely on dfhack wasn't really ideal.
now though, with the amount of offsets i've added, i'm already pretty reliant on the df-structures to get things sorted out, and add new features. i already use a script to pull the specific offsets that DT requires from df-structures and generate the memory layout files. so there isn't really this issue of hunting down each offset, unless i'm feeling particularly masochistic. going this route would probably allow for other features that haven't been possible (creating squads, assigning uniforms, burrow manipulation, etc.)
the downside is mostly about the rewrite to the back-end, and actually figuring out
how to do it and trying it out.