50.07 #2841
Replies: 10 comments 19 replies
-
|
Actual crash? Or did it just display a message that DFHack doesn't support the installed version of DF? There are no DFHack builds for 50.07 yet. See also: https://docs.dfhack.org/en/stable/docs/Installing.html#requirements
|
Beta Was this translation helpful? Give feedback.
-
|
I get frozen process when I launch the game, gets to loading then hard freezes and process has to be manually killed. |
Beta Was this translation helpful? Give feedback.
-
|
No errors displayed. Just refuses to let the game load. |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible that there is an error dialog behind your DF window? It should look like the one in this reply: #2841 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
I can't reproduce this. I just get the error dialog (as expected) and DF continues loading vanilla style |
Beta Was this translation helpful? Give feedback.
-
|
Same issue. When I close out of the DFhack error the game continues to load as per usual without dfhack. Text of stderr.log: PS: Also, while I'm here... Thanks so much for supporting and upgrading DFHack for the new steam release. I'm new to DF and totally hooked, though I imagine I'd be much less so without the tools that DFHack provides! |
Beta Was this translation helpful? Give feedback.
-
|
Same issue as Absurdities. |
Beta Was this translation helpful? Give feedback.
-
|
see my comment below and it should fix this issue for you |
Beta Was this translation helpful? Give feedback.
-
|
is it possible that ya'll have the SDLCompat replacement SDLReal/SDL file installed? I had this issue but was able to resolve it by deleting the SDL.DLL that DFHack installed and renaming SDLReal.DLL to SDL.DLL |
Beta Was this translation helpful? Give feedback.
-
|
as ab9rf mentioned DFHACK doesn't currently have a build for 50.07 yet. You are probably getting the error because steam updated your game to the unsupported version. You need to revert back to a supported version of Dwarf Fortress like 50.5. You can do this by: I recommend adding it as a desktop shortcut so you always have 50.5 or some other supported version w/ DFHack despite steam updating the game. Cheers and hope this helps |
Beta Was this translation helpful? Give feedback.
-
|
Yes. Make sure they are in different file locations though. Get different versions by changing the manifest id to the version you want when using the command v50.7 = 6567995891833238700 (ex. download_depot 975370 975371 6567995891833238700 ) You can find the manifest ids for different versions here https://steamdb.info/depot/975371/history/ |
Beta Was this translation helpful? Give feedback.
-
|
To expand on that answer a bit, DFHack needs to sync with DF on three dimensions: memory structure layouts, memory offsets, and game behavior. A release of DFHack can support multiple DF versions' worth of memory offsets, but it can only really support one layout configuration and one game behavior. As long as the layouts and game behavior (that DFHack depends on) don't materially change, then a new DFHack version can continue to support old DF versions. Since memory offsets always change with a new DF version, an old DFHack version can never support a new DF version. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, folks! Much appreciated. I want to keep up with the new version of DF when it makes sense, but every now and then I know I'll probably need some cleanup help from dfhack. |
Beta Was this translation helpful? Give feedback.
-
|
Is there anyway to uninstall for the time being? Just delete the files? |
Beta Was this translation helpful? Give feedback.
-
You just verify the local files here in steam & it will just get the one that DF Hack over writes |
Beta Was this translation helpful? Give feedback.
-
|
Can I possibly suggest making it so that the Version of Dwarf Fortress supported is read from a file rather than compiled in. Then add a notation that the X version of DFHack Currently supports X version of Dwarf Fortress. Changing version manually is a use at your own risk type thing. That way people can still try to run DFHACK on the current version of Dwarf Fortress if they choose and whether or not it breaks something in their game would then be on them, rather than the developers of DFHack. |
Beta Was this translation helpful? Give feedback.
-
|
It actually is read from a file. However, I'm not going to tell you what file, or how to go about changing it, because while it is possible for you to change this file in order to defeat the safety check mechanism, doing so is absolutely guaranteed to cause DFHack to badly misoperate, almost certainly causing an almost immediate crash of DFHack (and thus DF), unless you also change that file to reflect all the various data that we gathered about that version of DF during reverse-engineering in order to make DFHack work with that version of DF. This process is not entirely automated, and even if it were entirely automated, we'd still have to figure out a way to perform it at launch, which (at least in my opinion) is not a particularly valuable use of developer time. |
Beta Was this translation helpful? Give feedback.
-
|
There are very rare cases where this is possible - specifically, cases where the global offsets and memory layouts don't change between DF versions. In practice, this only happens for some quick hotfixes, such as 50.06 to 50.07. If we had somehow managed to produce a release of DFHack for 50.06 in the few hours that it was current, then 50.07 could probably have been supported with a single-line change to our config files. As it was, we had barely enough time to even complete an initial analysis of 50.06 before 50.07 came out. (Now, if Toady had gone on vacation for a week immediately after releasing 50.06, we probably could have produced a release for 50.06, and maybe even fixed the embark bug... but that didn't happen.) There's absolutely no hope of a single-line change to 50.05 DFHack enabling support for 50.07 or 50.06, though. If you are lucky, making such a change will crash your game immediately. If you're less lucky, it could permanently corrupt your save. |
Beta Was this translation helpful? Give feedback.
-
|
To expand on this and refer back to myk's comments earlier in this discussion, we can accommodate a change of memory offsets relatively easily. If the only changes in DF between two versions are small changes in the code, resulting only in changes in the memory offsets without a concomitant change in memory structures, that we can accommodate fairly quickly and could probably even fully automate. However, this happens very rarely, and when it does, we can, and generally will, release a new DFhack, typically within hours of when such a version of DF itself is released. So while we could make the process of determining these memory offsets something that end users could (easily) do, the time it would take for us to implement that is not worth it: the tiny benefit it offers is dwarfed by the opportunity cost for the DFHack team to produce and maintain the mechanism for doing it. In addition, while we can automate most of the process for recovering the memory offsets, we don't even have good automation for telling if the memory structures that thees offsets point to have changed, let alone what they've changed to. That process relies on manual inspection, and while in theory anyone can do it, in practice it requires considerable accumulated knowledge of how DF (and DFHack) work to do it well. All of the core DFHack developers have years of individual experience with both DF and DFHack. In case you're still curious, the tools we use to produce offset maps, and more generally to gather the information we need about a version of DF to make a corresponding version of DFHack, are in the df_misc repository. None of our processes are a secret, although I will gladly admit that our new-release process is not nearly as well documented as it perhaps should be. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly - I was referring just to cases where offsets don't change. If offsets change but structure layouts don't, that requires a few hundred lines of config changes/additions per DF executable, but all of those changes are automated. i.e. it wouldn't technically be a "single-line change", but it would be just as fast as one. (But again, this is uncommon.) |
Beta Was this translation helpful? Give feedback.
-
|
Fascinating. Awesome to get some insight into a tool like this; it's a bit out of my own wheelhouse but maybe I should take a look through things when I have some time. |
Beta Was this translation helpful? Give feedback.
-
|
how hard would it be to automate new version compatibility changes? |
Beta Was this translation helpful? Give feedback.
-
|
Extremely. We have some parts (global offsets) automated, but pretty much everything else requires manual research. |
Beta Was this translation helpful? Give feedback.
-
|
often lots of manual research |
Beta Was this translation helpful? Give feedback.
-
|
50.07-alpha1 has been released, which adds support for DF 50.07 Steam and Classic (and drops support for 50.05) |
Beta Was this translation helpful? Give feedback.
-
Current version released (50.07) today causes crash with Alpha 3.1
Beta Was this translation helpful? Give feedback.
All reactions