My disassembly skills are rusty enough that just trying it to see what happens sounds much more fun, and potentially more fruitful. I never did get around to determining how the "xx% done" bit on the bookkeeper settings page gets calculated. (I found the viewscreen variable that caches it, but nothing else holds the same value consistently.)
And I'm not opposed to a few crashes. Even if something goes wrong with the save, I can always git reset.
In all likelihood, random probing of vmethods will be totally fruitless, since even if they don't crash, they may appear to do
nothing at all while instead having some obscure side effect on the game which will ruin any further testing efforts unless you test each one in complete isolation and monitor the entire game's memory for changes, by which point you'd be better off just disassembling it and seeing
exactly what it does.
And God help you if the vmethod you're tinkering with takes a
pointer as a parameter, because you're
never going to figure out what type it is through experimentation. As an example, out of all the known Building vmethods, these are the types of pointers that can be provided as parameters:
* Hospital supply data
* Machine power information
* Machine connection data
* Unit
* Item
* File compressor
* Map viewport
* Map draw buffer
* STL String
* STL Vector of Squad Use information
If you get into Items, you'll get to deal with pointers to Flagarrays, Item Filter specifications, Jobs, Historical Figures, Civilizations, Sites, Wounds, Caravan states, and Squad uniforms. Good luck figuring out which is which without looking at a disassembly.
Oh. So there's no way we can call such a method once the symbols have been stripped?
Non-virtual class methods are infeasible to call on Windows due to
whole program optimization, which stuffs function parameters (including "this") into random registers rather than putting them on the stack (and ECX), making it impossible to just call them as if they were function pointers (as we can for virtual class methods). There's also the issue that the compiler is allowed to
inline non-virtual class methods, so if it's only used in one place (e.g. inside a loop), the compiler may decide to dump it in there exclusively and leave you with
nothing to call (unless you want to do everything else the outer function was trying to do).
You really need to understand that the work done with DFHack is
not just smashing things together randomly until they stick - it's more like carefully cutting the game apart and examining the pieces under a microscope, something best left to people who are experienced in doing such things (or are willing to learn a
lot to figure out how to do it themselves).
Author
Topic: DFHack 0.43.03-r1 (Read 1123853 times)