Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mifki]

I wrote a script for helping to create twbt override. When Meph tried it on a custom workshop, it found the buildings_other_id "WEAPON_UPRIGHT". The script is not very good at choosing the best ID but it should choose at least a valid one. Do you see an issue with my script? Or does this category really contains custom workshop and is not well named?

Just to confirm, you are not using DFHack 0.44.02-alpha1, correct? That version had an issue with buildings_other_id.

I'm pretty sure it's all good in 44.03.

[Clément]

Given Meph's later answer, I think it was 44.02.

[lethosor]

Oh, different thread. But there were two DFHack builds for 0.44.02 (alpha1 and beta1), and only the former had the issue. (Edit: yeah, sounds like alpha1.)

[iceball3]

How is the current build alpha? Are there some usable features, or should I wait before using it for anything besides directly development?

[lethosor]

The only way to know for sure is to test it - that's why it was released! That said, most things should work. I haven't had any issues myself, but I don't use a lot of DFHack tools on a regular basis. If you're willing to report issues that you run into, then feel free to download it and play around.

[iceball3]

The only way to know for sure is to test it - that's why it was released! That said, most things should work. I haven't had any issues myself, but I don't use a lot of DFHack tools on a regular basis. If you're willing to report issues that you run into, then feel free to download it and play around.

Ahh, fair enough! Best i set autosave to seasonal, then, before i get started. Perhaps with backups enabled for once!

[lethosor]

I put up a new release with a few fixes, mostly to new structures that few people were likely using (but a couple bugfixes too). It's at https://github.com/DFHack/dfhack/releases/tag/0.44.03-beta1. Currently there aren't any binaries, but I need to sleep, so hopefully they'll be uploaded in the next hour or so (assuming it works this time, which it appears to be doing).

Edit: it broke again. Sorry, all. I'll see if there's a way to restart it.

[Max™]

Kanil: I'm having trouble figuring out the "names" script - have you used it before? Do you know what it's supposed to do in various situations? It looks like it's supposed to open the custom name screen, but I'm not seeing how that could end up changing a unit's name. Did you just find it in the documentation? I'm inclined to remove or rewrite it.

I've got a new version with fixes for various bugs and whatnot up with a pull for it and the various format/random missed spaces/trying to include the --[[blah]]-- documenation properly that seems fine according to travis.

You are right that it pulls up the custom name screen to access the native interface options there. Upon confirming/leaving it sets the unit/artifact name to the custom name shown.

[Rumrusher]

so setting an adventurer in Fort mode(using a switch adventurer script) seems to crash the game, which is really really weird. but I guess given the whole army arc there been some changes.

[lethosor]

Binaries for beta1 are up now.

Max - cool, I'll look at it.

[iceball3]

In the alpha, I'm trying to save and exit but it's stuck at the save menu.

Not sure what exactly is causing it. I'm near the end of the first year. I would've expected it's just a slow save, but it's been really long now.
Is there anything I could mess around with in the dfhack console to get it moving again?

[Max™]

devel/pop-screen

[iceball3]

I just figured it out, and I will provide insight on what I think happened.
How I got it unstuck: I pressed the enter key in the DFHack menu.

What I think happened: I had earlier typed "ls" so i could see the command list. The command list was printed, and the line immediately after was blinking _, as what I would normally expect.
When i tried saving, the game got stuck in not-responding, and DF was using no processor resources. I was a bit confused, so I waited a long while with no progress.
I then pressed enter in the DFHack window. This caused the display to change as so:

My deduction here is this: the "ls" script continues running until after enter is pressed again. This prevents "clearing animal hospitals" or any other number of "it's time to save" subroutines from going through. This stalls Dwarf Fortress itself from performing any saving.
Luckily, I didn't close DF before I figured this out, so my save is safe!

Question though, can I safely paste the new DFHack version over my DF Folder that has the alpha version on it? This experience has made me crave some of those new bugfixes.

[PatrikLundell]

I think I've sort of replicated iceball3's behavior using 0.44.02-alpha1 (built locally with some changes that were underway, rather than downloaded):
Pressing control-s (XOFF) while s was doing it's output during fortress loading resulted in a blinking underscore halfway through, BUT NO DFHACK PROMPT, and it seemed the fortress got stuck on loading when it should start the screen display. A return in the DFHack window caused the halted output to resume, a couple of DFHack loading commands to be performed, and the fortress to be brought up. Also, pressing control-s when ls has been typed but return isn't pressed causes up arrow to be gobbled up (probably activating an XON) with a second up arrow to go back in the command history.

It should be noted that I had to try a fair number of times before I managed to suspend the ls output halfway through, but loading of that fortress took a fair while, so there was enough time...

I've got no idea how you'd accidentally get an XOFF signal to the DFHack window without doing it manually, though.
A question for iceball3: Which OS are you using? There's one DFHack console window version for Windows and another for other OS' (I'm on Windows).

Control-s in the DFHack command window (just on an empty line) and then trying to save DF resulted in the DFHack prompt disappearing, but DF itself being stuck on the command screen. A return in the DFHack console window caused "Clearing all animal hospitals" (and the DFHack prompt) to appear, as well as the game saving to progress. I suspect any input in the command window would dislodge XOFF, but haven't tried.

[Clément]

Using 0.44.03-beta1, I have a bug in the identity structure. I have a vampire pretending to be born the 24th of Opal in 118. Dwarf Therapist was showing it much too old, so I looked at DFHack:

Code: [Select]

<identity: 0x7fffa854edb0>
id                      = 7853
name                    = <language_name: 0x7fffa854edb8>
race                    = 572
caste                  = 0
histfig_id              = -1
unk_4c                  = 33318
birth_year              = 0
birth_second            = 118
anon_1                  = 363899
anon_2                  = -1
anon_3                  = -1
anon_4                  = -1
anon_5                  = -1
anon_6                  = <vector<identity_unk_94*>[0]: 0x7fffa854ee30>
anon_7                  = <vector<identity_unk_94*>[0]: 0x7fffa854ee48>birth_year and birth_second are off by one field (histfig_id too, it is 33318).