Bay 12 Games Forum

Thanks lethosor for pointing out both that I was barking up the wrong tree, but that barking would have ensued even if I'd found the right one.

Also thanks to Bumber for the suggestion, although it didn't work.
In the past I've used the fallback of the Powershell command prompt when .bat files started directly from the File Explorer failed to work, and I've tried that here as well. I believe I've found the tool Bumber refers to (rather different path on my system, but it seems to be the same tool, which can also be invoked from VS itself), but unfortunately that doesn't help cmake find the version it's looking for. It was worth trying, however.

if you have more than one version of VS installed, cmake may not find the one you want (it picks one "at random"). You need to tell cmake which version you want it to use by setting the CMAKE_GENERATOR_INSTANCE variable. See https://cmake.org/cmake/help/latest/variable/CMAKE_GENERATOR_INSTANCE.html

Quote from: ab9rf on December 22, 2022, 12:59:52 am

no it's still there; that code is computing a cube root and there is not much the compiler can do to optimize it away.

It should be able to optimize trunc(pow(70000.0, 0.333) * 10.0) to 410, provided those functions are constexpr. (All values are being loaded from rdata into xmm, DF 47.05 Windows.)

For materials where the values are runtime (loaded from RAWs,) obviously it can't. I was just thinking that this might be typical in other avoidable places, v141_xp toolchain being what it is.

all of the values that particular code runs on are from raws or calculated at run time, so of course it can't reduce them at compile time. also DF has _never_ used v141_xp; it was v140_xp for 43.05 through 47.05, and v143 for 50.xx.

While this is all very fascinating, you'll probably find it a whole lot easier to just use DFHack's Lua scripting engine once DFHack is ready. The process that your approach takes 28 minutes can be done in a matter of milliseconds and with far less guesswork.

#1 was actually map block processing, which included spatters and... temperature.

contaminant processing has been known to be a lag source for a while now, and i suspect it actually drags more than temperature, since temperature is just two ints in the map data block, while contaminants are vectors of pointers so there's not going to be any cache coherency

Y'all don't need specialized shearers no matter what you think ANYWAY

Unit labors are still functional just as they were. They're overwritten any time any work details change at all, including adding new ones or unrelated changes to them. Work details live in what DFHack calls ui.hauling.work_details, which in 0.50.03 is at 141E283F. It's a vector. You can delete all of them by just resizing the vector to 0 and it'll cause no issues that I can see and after doing so you can manually reassign labors at will, as long as you set unit->military.pickup_flags.update for woodcutters/miners. With all this info, I think Therapist should be doable this very moment?

no way that address is correct, first of all it's too short (DF addresses on Win64 are always _9_ hex digits starting with 0x14) and second it ends with F and MSVC always aligns vectors on 8-byte boundaries so it has to be either 0 or 8.

- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.

I'm pretty sure that logs cannot be placed in bins.

It's possible that the job cancel bug I discovered the other day is involved here. My current test fort, which is running using the new job cancel method, does not exhibit the behavior that is being reported here; rather, it works as expected, autodesignating every tree on the map, and then undesignating them as soon as enough trees are cut down, as expected. But if the jobs are not cancelling properly (as I was seeing in my prior test fort), then it might continue to chop even though autochop tried (but failed) to cancel the jobs.

I don't think there is a thread just for labormanager... but just have one small request.... that it be able to be disabled on a per-dwarf basis (by something simple like ignoring dwarfs that have the unused "Alchemist" labor set.)

Assigning a dwarf to a burrow (even if the burrow covers the entire embark) will cause that dwarf to be entirely ignored by labormanager (see https://github.com/DFHack/dfhack/blob/develop/plugins/labormanager/labormanager.cpp#L1333). I had no reason to remove that behavior (which I added to autolabor many many moons ago: https://github.com/ab9rf/dfhack/commit/78fc850ce20e14d7a37e44c18dc4486ee61796b4) when I forked autolabor to make labormanager.

I don't want to use the ALCHEMY labor for this purpose; there are other people who are using it for incompatible purposes, and, as lethosor points out, "tweak block-labors" prevents toggling the ALCHEMY labor.

Thanks ab9rf.
Given that the github structure has one structure for DFHack and another for DF structures, I never considered that the off site organization might somehow pull the apparent separate DF structures entity into the DFHack one, although I was aware that there are a lot of things I could never find in the online DFHack file structure.
Given your comments, I managed to get git to tell me there's a "git submodule status" command, and that command shows there is indeed a "library/xml" submodule, which looks to be very similar to the df structures one (i.e. it should be the one). This means it should be reasonably easy to have a "complete" dfhack structure whose purpose is to support df structures work as you said.

library/xml is df-structures. It's a subrepo, and if you go into it's a full repository that you can manipulate in the same manner as any other repository. If you change the commit to which that repo points, the parent repository will track that as a change as to which commit the parent repository will track. This is, in fact, what you basically have to do if you make a change to dfhack code that relies on a newer df-structures release.

There are a lot of gotchas, caveats, and non-obvious best-practice advice for dealing with subrepos. DFHack has five or six subrepos now (and some of them have subrepos of their own, as I recall), so if you're going to be a serious DFHack developer, you kinda have to have at least some understanding of this.