Bay 12 Games Forum

we're working on an "items" tool that can filter by properties and make specific changes (like mark for dumping). this sounds like it might be useful to specify filters for in that tool

FWIW, this is similar to the set of features I had in mind when I was referring to the extended stocks screen (https://docs.dfhack.org/en/stable/docs/tools/stocks.html).

The thing is, I was fighting a massive invasion at the time, so the bodies kept pilling up. It's definitely that as the FPS stabilized after it was over. And yes, this is definitely possible with the autodump (used it to teleport bodies to the bridge for atom smashing), but marking all the bodies and other trash for dumping is a hassle, even with rectangle mass marking feature.

Right - my point was that the "stocks" plugin allows (well, allowed) you to search by criteria other than location. e.g. you could select all items with "corpse" in their name and mark them for dumping, then use autodump if you wanted.

I realize now that that "stocks" plugin hasn't been ported to v50 yet, and the "items" tool sounds like a likely replacement for it. So my advice was only really useful for any 0.47 players.

(tested by atom smashing some of them which brought in a brief increase in FPS).

If the increase was only brief/temporary and your FPS dropped back down, there is probably a different underlying cause.

Anyway, I suspect something along these lines may already be possible with "autodump" plus some filtering tool (extended stocks screen?), so that would probably be our recommendation. If there are filters missing that you think would be useful, we're open to suggestions. Generally, for this sort of thing, I'd prefer to extend existing commands over creating new single-purpose ones.

I've reported a great many backs on the mantis site that were all pet peeves of mine, myriad obstacles that languished in the mantis bug tracker until the site wiped, so many of my old personal wishlist items will likely go eternally forgotten.

Which Mantis are you referring to? I don't believe anything was wiped entirely, although some reports are private.

Long version: the "old" tracker (pre-2022/23, on bay12games.com) should have been migrated completely to the "previous" one (mantishub), which should also have been migrated completely to the new one (https://dwarffortressbugtracker.com/). If you're referring to reports on the previous mantishub tracker that you emailed in, those all went to the "Triage" project, which did migrate over, but is private. (Every issue required manual intervention before it could be made public, including removing the reporter's real name and email address, so there are still 414 issues in that project that haven't been migrated yet.)

c and e are the defaults.

Are there plans to upgrade the starter pack to v50 eventually, or are we still waiting for previous versions' features to be migrated over?

See:

Traditionally [old superstition with some basis in fact!] this kind of update would be immediately followed by a DF release, and another round of frantic community patching by all of the many many people who make this possible... and who knows when the Steam release might be?  (not me - I truly don't have any inside info)  When it does though, I'm expecting to "retire": the Steam edition should help beginners appreciate DF better than anything I can cobble together, and that's always been my motivation for this pack.  It's also been going for a long time - next May I'll celebrate ten years of the Starter Pack, with LucusUp's original-flavor LNP dating further back to 2010!

Ladies, gentlemen, dwarves, and other overseers; it is and has been an honour.  Strike the Earth!

What I described is not replacing libc, but installing a new one, specifically for the purpose of running DF with it. I don't think this can cause any problems for your system, at worst your DF will still be not working.

That's exactly what I meant by "replacing glibc" - replacing the glibc that DF is using. Replacing it system-wide would be even worse and didn't cross my mind. I was using the word "replacing" interchangeably - sorry for the confusion:

Dumping a different libc.so into the DF directory is a good way to cause lots of crashes. See e.g. https://stackoverflow.com/q/21190908

Part of the reason this is unsafe, from my understanding, is that glibc integrates tightly with certain system calls. If your kernel provides different system calls than the kernel glibc was built for, bad things will happen.

Less glad to see no mention of bridges and the inability to choose a direction for them in Classic.

My understanding is that you can change that in classic, you just can't see the buttons. Not particularly easy, I know.

libc is a harder problem here.

It should be (theoretically, I haven't tried it myself, and I don't have a buster install to do so) possible to fix this by:

1) download http://ftp.gnu.org/gnu/glibc/glibc-2.34.tar.gz and extract somewhere, for example into df/libc2.34
2) apt install patchelf
3) using patchelf, modify two properties of the dwarfort binary (note that paths _MUST_ be absolute):

Code: [Select]

$ patchelf --set-interpreter /absolute/path/to/your/df/libc2.34/ld-linux.so.2 dwarfort
$ patchelf --add-rpath /absolute/path/to/your/df/libc2.34 dwarfort

As for libstdc++ part of the problem, it should be fixable by downloading the appropriate version of the .so and placing it in the same directory where dwarfort is located.

Or, you could update your Debian 10 to the current stable version (12) and all of this would be fixed.

Replacing libc is what I said would likely be unsafe a couple posts above yours. Also, that archive you linked is just the source - you would also need to compile glibc if you went through those steps.

r1.1 has been put up on GitHub, which fixes a crash on startup with the Windows Itch build of DF. Everything else is identical to 50.10-r1.

GitHub download: https://github.com/DFHack/dfhack/releases/tag/50.10-r1.1

(This release has not been put up on Steam because it doesn't affect Steam DF.)