March 6, 2024: Dwarf Fortress 50.12 has been released.
News: February 3, 2024: The February '24 Report is up.
News: February 4, 2021: Dwarf Fortress Talk #28 has been posted.
News: November 21, 2018: A new Threetoe story has been posted.
Forum Guidelines
There doesn't seem to be any tilesets for Classic that I can find.Making a tileset for v50 is at least two orders of magnitude more work than making one for prior versions. There are 256 tiles in a pre-v50 tileset; there are around 5000 in a v50 tileset. The problem here should be obvious.
I can imagine that DFHack is suspicious for the scanner because it is hooking in another app, just like malware would do it.DFHack behaves just like any other DLL. There's nothing in DFHack that will look like malware to a heuristic scanner. DFHack does not "hook" another app, it actually loads as an invited DLL (using the 'dfhooks' mechanism provided by Bay12) and uses Bay12's published endpoints to connect to DF.
I guess it does not work without dfhack either (GLIBC_2.34 is required by dwarfort, not only libdfhack.so). According to distrowatch, Linux Mint 21.2 Victoria (released two month ago) has glibc 2.35. I guess you have Linux Mint 20.3 Una from 2022, it only has glibc 2.31. It's not that old, DF should have been built using an older version.if i understand what i've heard correctly, the dwarf fortress linux builds were built using Ubuntu 22.04, so you need to be at least as new as Ubuntu 22.04 to ride this particular ride.
Edit: Ubuntu 20.04 uses glibc 2.31, so it is older than 2022. Still, it should be the best target version.
DFhack on steam frontpage?Steam's "front page" is dynamically generated by Steam for each user, but yes, DFHack is (now) eligible for consideration in that process and so it is possible that Steam's adaptive marketing system will promote DFHack to people that Steam thinks might be interested.Quote
Doesn't help that the rest of the computer world outside of games still use the arrow keys to move up and down (amongst other options, but it's never disabled by default).This is solely because the arrow keys are to the right of the main keyboard area (overlaid with the numpad on PC keyboards, and in between the main keyboard and the keypad on most AT-standard keyboard layouts), which means that right-hand mousers cannot use the mouse and the arrow keys at the same time without placing their left hand on the keyboard in an odd and awkward position. A righthanded mouse user only has their left hand available for keyboard operations while they're using the mouse at the same time, which means to be non-awkward all keyboard controls that are intended to be used at the same time as the mouse have to be on the left side of the keyboard. If the arrows were to the left of the keyboard, we'd have just used them. For that matter, I suspect that if the function keys, which were to the left of the keyboard on the original PC keyboard, were still there we'd be using those instead of WASD. And yes, I've seen games from the late 1980s and early 1990s that did exactly this, although not many. A keymapping using function keys as arrow/movement keys that was viable on the PC/XT keyboard would be madly awkward on the AT keyboard, and by the mid-1990s practically everyone was on the AT layout or some variation of it. This is all basic human-computer interface engineering, which really everyone who writes UIs should be either aware of or able to figure out fairly quickly, but sadly far too many software developers haven't really put much thought into these issues.
I know the DFHack devs are focusing on .50.xx, but is there any chance you could do a small QoL improvement for those that prefer .47.05 ?It is unlikely that we will make any further official releases for 47.05 for any reason other than to fix a serious bug. We had to significantly redesign our workflow automation to make builds for v50, which means we no longer have the ready means to make release builds for prior versions. Any release for 47.05 would have to be hand-rolled, and we're not likely to go to all the trouble required to do that for anything less than the discovery of a showstopper-level bug.
When a dwarf makes an artifact that's a family heirloom, I put a display case in their room for it. Finding the artifact among the dozens of pages of Non-Sortable artifacts is a real pain that gets more painful as the decades pass... can it be made sortable?
This would really make the game less frustrating and I still love .47.05
Not to mention it's not remotely likely to work with any future linux builds, which will presumably be built with gcc (or perhaps clang) and thus won't have the same optimizer as MSVC.If someone comes up with a patch that works for start dwarf counts less than 7 (such as, oh I don't know, one), that I might be more interested in...
But... you can. I just did it in the debugger. The only trick is, you need to embark with at least 6 animals. (4 purchased animals and the 2 wagon animals.)Poking at it a bit, the obvious solution is to patch n into the startdwarf location and (255-n) in the last byte of the LEA instruction, exactly 16 bytes later.
On inspection, that would work. The limit would be126127 dwarves before the LEA starts adding instead of subtracting.
Fragile as anything, though. There's no telling what the optimizer will do to the code in future releases. I sure wouldn't want to hardcode a 16 byte offset in hopes that it magically will always work.
Thank you for looking at this.
I've found start_dwarf_count for 50.07 Classic.We found the startdwarf location relatively early on in the development cycle (we have a script for it that worked, so it was trivial), but we decided (as lethosor notes) not to publish it because our testing showed that it failed for counts greater than 9. I never investigated deeply to figure out why, since we wanted to get a release out and it wasn't worth blocking for this, and honestly I've never worked back to the problem.
Unfortunately, it's not going to be that easy. Setting it above 9 causes a crash.Quote from: 50.07.text:0000000140CB5976 loc_140CB5976: ; CODE XREF: sub_140CB3AD0+1E35↑j
.text:0000000140CB5976 BF 07 00 00 00 mov edi, 7 ; START_DWARF_COUNT
.text:0000000140CB597B 48 8B 74 24 60 mov rsi, [rsp+2C0h+unit]
.text:0000000140CB5980 4C 8B 75 B8 mov r14, [rbp+1C0h+var_208]
.text:0000000140CB5984 44 8D 67 F8 lea r12d, [rdi-8] ; OKAY! This parameter needs to be set to -1 !
.text:0000000140CB5984 ; That chooses caste at random.
.text:0000000140CB5984 ; If it's >= 0, it selects that caste.
.text:0000000140CB5988
.text:0000000140CB5988 loc_140CB5988: ; CODE XREF: sub_140CB3AD0+1FEB↓j
.text:0000000140CB5988 FF CF dec edi
.text:0000000140CB598A E8 A1 49 3B FF call new_unit
.text:0000000140CB598F 48 8B D8 mov rbx, rax
.text:0000000140CB5992 48 89 44 24 60 mov [rsp+2C0h+unit], rax
.text:0000000140CB5997 45 8B C4 mov r8d, r12d
.text:0000000140CB599A 45 33 C9 xor r9d, r9d
.text:0000000140CB599D 0F B7 15 28 26 15 01 movzx edx, cs:word_141E07FCC ; example value: 23Ch, 572, DWARF. Unit type.
.text:0000000140CB59A4 48 8B C8 mov rcx, rax
.text:0000000140CB59A7
.text:0000000140CB59A7 this call crashes when startdwarf is 10 or higher.
.text:0000000140CB59A7 turns out that's because of the caste flag in r12d
.text:0000000140CB59A7 (passed in r8d, per above code).
.text:0000000140CB59A7 This parameter should be -1. When startdwarf is forced to 10,
.text:0000000140CB59A7 r12d is set to (10-8) = 2, which is a nonexistant caste.
.text:0000000140CB59A7 E8 94 4D 27 00 call sub_140F2A740 ; parameters: rcx=*unit,
.text:0000000140CB59A7 ; dx = creature type index (572=DWARF),
.text:0000000140CB59A7 ; r8w = caste (-1 for random),
.text:0000000140CB59A7 ; r9b flag: set unit 6-byte field @ 0D70h
This excessively-optimized code depends on knowing that EDI is set to 7 as a space-saving way to set R12D to -1, using the calculation (7-8).
R12 is then used to select the caste of the unit being generated. -1 means random; 0 means FEMALE; 1 means MALE; 2 or higher lead to a crash.
We need to enter the call to sub_140F2A740 with R8 == -1. I don't see a way to squeeze that into the current code.
Anyone have thoughts?
In the "test3" version you have, DT tries to restore the value of external_flag when it connects to DF. Since you never set it from DT before, it set it to 0. As you noticed this may break DFHack scripts and plugins, so I changed it in the latest version (no build provided, it's this branch). Now, DT will not set external_flag automatically, but the button is still there to reflect its state and allow manual changes. For setting external_flag on startup, I would recommend using a DFHack script (as you have done) although this is currently broken on classic.You might be interested in https://github.com/DFHack/dfhack/discussions/2901, since it relates to DFHack/Dwarf Therapist interoperability with respect to labor management. It is, of course, exceedingly possible for Dwarf Therapist to communicate directly with DFHack, via DFHack's RPC mechanism.
Does this mean, i should wait for another DF-Hack version and my lua script will work again, or do i have to do other things to get DT to work again? I really can´t think about playing DF without Therapist, thank you for your hard work!That script ought to be working on Steam only, but will not work with Classic because I misunderstood what I was seeing when I did the initial analysis of the 50.07-Classic image and incorrectly concluded that Bay12 had implemented Putnam's "padding proposal" when they had in fact not. If it's not working on Steam, then we've made a mistake somewhere in a manner I would not have expected. That command in Classic will corrupt an address further down in memory with unknown impact on the game (it appears to be used, but for what we don't know at this point).
) but it won't be game, so there will be a (minor) amendment to deal with this.
Despite that, I can still get some data from the Classic version using DFHack, with many things seemingly working (gui/gm-editor, some basic scripts to look at some data of interest, such as units, for instance). I've run a script over the DF data structures to try to find things that I might be able to fix, and after blacklisting parts of it (crashing or running out of memory on "broken" structures) I've been able to go through it, although without finding anything that's within my capability to fix so far, unfortunately.To the best of my knowledge, the only variable that is mislocated due to this issue that is actually used in DFHack is, ironically, the external flag, which is only used at present by autolabor. With this single exception, none of the variables in the "tail" of gamest (the members that appear after mod_manager) that is misaligned due to this issue are currently being used by any tool or script that is being distributed with DFHack.
Still, it's usable as a probe (with extra caution) with Classic, despite there apparently being a big wart on it.
I checked during initial analysis to verify that gamest in classic was _not smaller_ than it was in steam. I neglected to check whether it was _larger_, in part because it didn't make sense for it to be.I figured out my error above: I transposed two digits while manually doing these calculations. The address of game in .07-Classic is 0x141e0ecb0, which is not what I used above.
Sadly, it is. We know that the external flag is the last element in gamest, and so the length of gamest is the difference between the address of game and the address of external flag (plus four bytes). In Steam, this length is 0x141e2554 - 0x141e1adc0 + 4 = 0xa7a8; in Classic this length is 0x141e193d4 - 0x141e0ebc0 + 4 = 0xa818. For some reason that is inexplicable to me, gamest is now actually _longer_ on Classic than on Steam.
I don't have an analyzed 50.05 Classic image handy, but in 50.04-Classic this was 0x141dbf3c - 0x141db4fc0 +4 = 0xa400, while in 50.04-Steam this was 0x141dcb52c - 0x141dc10b0 + 4 = 0xa480.
I honestly do not know what Bay12 is doing here.
PS E:\Kelly\Projects\df_misc> & ruby -I../metasm dump_df_globals.rb --raw 'E:\kelly\df\df_50_07_steam\Dwarf Fortress.exe' | where-object {$_.contains("game")}
Global table starts at 141318080h
<global-address name='game.external_flag' value='0x141e25564'/>
<global-address name='game' value='0x141e1adc0'/>
<global-address name='gamemode_cansave' value='0x141876a15'/>
<global-address name='gamemode' value='0x141319840'/>
<global-address name='gametype' value='0x14131983c'/>
PS E:\Kelly\Projects\df_misc> & ruby -I../metasm dump_df_globals.rb --raw 'E:\kelly\df\df_50_07_classic\Dwarf Fortress.exe' | where-object {$_.contains("game")}
Global table starts at 14130c050h
<global-address name='game.external_flag' value='0x141e193d4'/>
<global-address name='game' value='0x141e0ecb0'/>
<global-address name='gamemode_cansave' value='0x14187e18c'/>
<global-address name='gamemode' value='0x14130d804'/>
<global-address name='gametype' value='0x14130d7dc'/>
steam: game.external_flag - game = 0x141e25564 - 0x141e1adc0 = 0xa7a4
classic: game.external_flag - game = 0x141e193d4 - 0x141e0ecb0 = 0xa724L
two months on and I'm playing more and more 47.05 because it simply flows better. the premium version just kinda hurts to play (literally, the forced mouse interactions are killing me... ) The new game content is honestly great but not worth the switch in UI atm.tbh I have yet to spend any significant time playing v50; while I have to load forts occasionally to test things for DFHack development, between the interactions I've had with the new interface and the reports I've read from the community, I've come to the conclusion that if I find myself wanting a DF fix I'll probably be better served playing 47.05. Unfortunately I accidentally broke my 47.05 installation by inadvertently installing a 50.0x DFHack development build over it, so I can't even play 47.05 right now.