Print

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

[PatrikLundell]

Not quite the place to do this, I know, but could the self-closing tag stuff be related to some of the problems that have arisen, or not? *

(*Exibit 2.)

Legends Viewer hasn't been updated to parse things that export differently from before. The tool can handle a certain amount of things it can't recognize (according to my experience), but when the amount is too large it goes belly up. Changing types from boolean to tag present/absent is one of the things the tools does not recognize (it can be noted that Toady uses "self closing tags" in his standard exports, so the export-legends changes were made to use the same logic while also cutting down on the amount of useless fluff exported [all of those tags that were previously False are now simply not present]).
That change is in addition to things that is exported differently because the mapping of DF structures has progressed.

As far as I understand, Legends Viewer is a bit on the back burner because Real Life is making demands.

[iii22]

I noticed that dfhack has a new "unretire-anyone" script. It sounds pretty crazy, since you could unretire necromancers or werebeast or something. Has anybody experimented with it?

[Kromtec]

Not quite the place to do this, I know, but could the self-closing tag stuff be related to some of the problems that have arisen, or not? *

(*Exibit 2.)

Legends Viewer hasn't been updated to parse things that export differently from before. The tool can handle a certain amount of things it can't recognize (according to my experience), but when the amount is too large it goes belly up. Changing types from boolean to tag present/absent is one of the things the tools does not recognize (it can be noted that Toady uses "self closing tags" in his standard exports, so the export-legends changes were made to use the same logic while also cutting down on the amount of useless fluff exported [all of those tags that were previously False are now simply not present]).
That change is in addition to things that is exported differently because the mapping of DF structures has progressed.

As far as I understand, Legends Viewer is a bit on the back burner because Real Life is making demands.

Haha, yeah I had a lot of things on my plate the last few month.
But I am currently working on making Legends Viewer compatible to the new changes in the exportlegends script.
Expect a new version this week.

[Atomic Chicken]

I noticed that dfhack has a new "unretire-anyone" script. It sounds pretty crazy, since you could unretire necromancers or werebeast or something. Has anybody experimented with it?

I'm the author of that particular script, so I'd say I've experimented with it quite a bit. It enables you to play adventure mode as any living (or undead) historical figure with the exception of deities (as they currently lack physical manifestations). This includes necromancers, werewolves, fortress citizens, random villagers, nobles, important animals, forgotten beasts, various other monstrosities, and anyone else mentioned in Legends mode (as well as a number of unlisted individuals who wouldn't have done anything noteworthy yet). People will interact with you as appropriate, and you should have access to whatever powers and knowledge the figure possesses (as well as their limitations; it turns out that cats aren't very good at opening doors). That said, be aware that this won't give you a whole lot of additional functionality beyond that which the game normally provides; playing as a monarch, for example, won't enable you to do anything especially significant with your status at present.

[Asendre]

Hello!

Not sure if this is the right place to post this, but the plugin that allows you to load/save stockpile settings seems to have broken for me as of 47.04-r2.
Saving works fine, but attempting to load any settings crashes the entire game. I wasn't having this problem at all before (in the previous version), so it must be somehow related to the new version.

I'm not sure how to collect crash logs and whatnot from DFHack, but if anyone is interested in having a look at it i'll gladly follow instructions and share whatever can help fix the issue.

[lethosor]

Thanks for the report - I was able to reproduce with a pretty simple stockpile, so I made an issue here for it. It should be fixed in r3, which I hope will be within a couple weeks. I'll update this with whatever I find.

(To answer your other questions - the issue tracker, which is linked from the first post of this thread, is a better place, although it does require a GitHub account. When it comes to forum threads, this is definitely the appropriate thread to post something like this. There typically isn't a way to get much of a useful crash report in situations like this - on my end, I'm building the plugin with debug symbols and attaching a debugger to figure this out.)

Update: it was a pretty simple fix. There were a couple values recently added to an enum, which were already present in DF, but this broke some code in the stockpiles plugin that assumed the size of this enum would never change. It looks like this issue just limited to loading stockpiles with any sort of food enabled - other types seem to be unaffected.

Once the build is done, you can extract a fixed plugin from the latest unstable build at https://dfhack.org/builds.

[Rumrusher]

I noticed that dfhack has a new "unretire-anyone" script. It sounds pretty crazy, since you could unretire necromancers or werebeast or something. Has anybody experimented with it?

I'm the author of that particular script, so I'd say I've experimented with it quite a bit. It enables you to play adventure mode as any living (or undead) historical figure with the exception of deities (as they currently lack physical manifestations). This includes necromancers, werewolves, fortress citizens, random villagers, nobles, important animals, forgotten beasts, various other monstrosities, and anyone else mentioned in Legends mode (as well as a number of unlisted individuals who wouldn't have done anything noteworthy yet). People will interact with you as appropriate, and you should have access to whatever powers and knowledge the figure possesses (as well as their limitations; it turns out that cats aren't very good at opening doors). That said, be aware that this won't give you a whole lot of additional functionality beyond that which the game normally provides; playing as a monarch, for example, won't enable you to do anything especially significant with your status at present.

you could probably get deities if you give them a nemesis id which just fully gives them a unit when they load in so with a few pokes and prods you could probably play as any historical figure in the game. which from what I can tell form testing legit gives them a body based off their historical figure descriptions.
which means a cat god will look like a cat, and a goblin god will look like a goblin.

[Roses]

Thanks all for the answers to my previous questions, I've got a couple new one now. Does ``dfhack.job.removeWorker(job,timeout)`` add a timeout to the worker stopping them from picking up the job again, or does it put the cooldown on the job, stopping all units from picking up the job again?

[lethosor]

Thanks all for the answers to my previous questions, I've got a couple new one now. Does ``dfhack.job.removeWorker(job,timeout)`` add a timeout to the worker stopping them from picking up the job again, or does it put the cooldown on the job, stopping all units from picking up the job again?

It calls setJobCooldown internally, which either creates or updates an entry in job_claim_suppress. Looks like it prevents the unit from picking up a job at that workshop for the specified cooldown period. From the API docs, I can see why it wouldn't be clear that removeWorker uses the same logic, so I'll update that.

(By the way, you can use [tt] on the forums to get preformatted text, like this)

[Roses]

Thanks all for the answers to my previous questions, I've got a couple new one now. Does ``dfhack.job.removeWorker(job,timeout)`` add a timeout to the worker stopping them from picking up the job again, or does it put the cooldown on the job, stopping all units from picking up the job again?

It calls setJobCooldown internally, which either creates or updates an entry in job_claim_suppress. Looks like it prevents the unit from picking up a job at that workshop for the specified cooldown period. From the API docs, I can see why it wouldn't be clear that removeWorker uses the same logic, so I'll update that.

(By the way, you can use [tt] on the forums to get preformatted text, like this)

Thanks for the answer (and the tip!)

EDIT: Follow up question. I know I can use dfhack.matinfo.decode (or find, I always forget which one until I look it up) to turn something like INORGANIC:SLADE to the correct mat_type and mat_index. Is there something similar to change something like SHIELD:ITEM_SHIELD_BUCKLER into the correct item_type and item_subtype?

EDIT2: Follow up, follow up question. All of my old scripts that use dfhack.maps.spawnFlow require using an inorganic for flows. Is that an old requirement (I don't see it mentioned anywhere in the documents), or did I just randomly make that a thing?

[lethosor]

This is what createitem uses (but it's written in C++). Looks like there are findType and findSubtype wrappers available to Lua (e.g. dfhack.item.findType("SHIELD:ITEM_SHIELD_BUCKLER") == df.item_type.SHIELD) but they're not in the API docs. That should probably be addressed. Some of the docs aren't in sync with the Lua API, unfortunately, because they're manually-updated.

I don't see anything in spawnFlow that requires inorganic materials, but I don't know what would happen if you used something else.

[goldenvixen]

I cannot for the life of me, get the exportlegends.lua to work properly on linux. It exports everything properly right up until we get to legends_plus xml in which it gets an error, saying simply "exportlegends: Could not move into the save folder." I'm guessing its something involving the feature of moving the legends into a folder instead of just plopping it in the dwarf fortress directory. I wish I could give more of an error report, but this is all I get when I export legends:

Spoiler (click to show/hide)

Code: [Select]

[DFHack]# exportlegends info
Writing all files in: legends-region1-00150-01-01
    Exporting:  World map/gen info
    Exporting:  Legends xml
    Exporting:  Extra legends_plus xml
exportlegends: Could not move into the save folder.

[lethosor]

I cannot for the life of me, get the exportlegends.lua to work properly on linux. It exports everything properly right up until we get to legends_plus xml in which it gets an error, saying simply "exportlegends: Could not move into the save folder." I'm guessing its something involving the feature of moving the legends into a folder instead of just plopping it in the dwarf fortress directory. I wish I could give more of an error report, but this is all I get when I export legends:

Spoiler (click to show/hide)

Code: [Select]

[DFHack]# exportlegends info
Writing all files in: legends-region1-00150-01-01
    Exporting:  World map/gen info
    Exporting:  Legends xml
    Exporting:  Extra legends_plus xml
exportlegends: Could not move into the save folder.

My best guess is that this has something to do with permissions - can you run these two commands?

Code: [Select]

:lua print(dfhack.getDFPath())
:lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))
The first should print the path to DF - you don't have to include its output if it contains anything personal, but try creating a file in that folder and see if you're able to.
The second should print either "true" or "false", and I'd like to know what it says.

The strange thing is that the code that's failing in this case has already run once, before the "Exporting:  World map/gen info" message, so I'm not sure why it would fail when run a second time.

Some other things to check would be whether you can create a new file in the "legends-region1-00150-01-01" folder, and whether you have any free disk space on whatever disk that folder is on.

You can also pass a directory as the second argument to exportlegends, so as a possible workaround, "exportlegends info ." should avoid changing directories at all. I'd still be interested in getting to the bottom of this, if you don't mind. I've been testing on Linux and have yet to reproduce this issue (with either "info" or "custom").

[goldenvixen]

My best guess is that this has something to do with permissions - can you run these two commands?

Code: [Select]

:lua print(dfhack.getDFPath())
:lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))
The first should print the path to DF - you don't have to include its output if it contains anything personal, but try creating a file in that folder and see if you're able to.
The second should print either "true" or "false", and I'd like to know what it says.

The strange thing is that the code that's failing in this case has already run once, before the "Exporting:  World map/gen info" message, so I'm not sure why it would fail when run a second time.

Some other things to check would be whether you can create a new file in the "legends-region1-00150-01-01" folder, and whether you have any free disk space on whatever disk that folder is on.

You can also pass a directory as the second argument to exportlegends, so as a possible workaround, "exportlegends info ." should avoid changing directories at all. I'd still be interested in getting to the bottom of this, if you don't mind. I've been testing on Linux and have yet to reproduce this issue (with either "info" or "custom").

I tried running both! Here's what I got:

Spoiler (click to show/hide)

Code: [Select]

[DFHack]# :lua print(dfhack.getDFPath())
/media/insertusernamehere/68B292FFB292D144/DwarfFortress/df_47_04_linux
[DFHack]# :lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))
true

I doubt it's a permission errors, I am able to create folders and files just fine within the directory and the "legends-region1-00150-01-01" folder. Space isn't the problem either, the hard drive currently has 114.7GiB of available space left. I keep my games and distro on separate hard drives if that helps in some way! I've been strictly using the "info" and I haven't tried custom yet. How exactly can I pass a directory as the second argument to exportlegends? It's currently very late over here and my mind is a blank on how to do that. lol

[lethosor]

How exactly can I pass a directory as the second argument to exportlegends? It's currently very late over here and my mind is a blank on how to do that. lol

I gave an example, although it may have been hard to read with the quotes. Here it is again but with code formatting:

Code: [Select]

exportlegends info .
(the dot at the end is the second argument)

For more troubleshooting, can you try these commands?

Code: [Select]

:lua print(dfhack.filesystem.chdir("legends-region1-00150-01-01"))
:lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))
You could run them a couple times, and each command should print "true", as long as you run them in this order. You should end with the last one to be safe - if you don't, you'll leave DF in a directory it doesn't expect, which will probably cause it to crash. (Maybe do this without a save loaded... it shouldn't make a difference, anyway.)
This is essentially what the script is doing when it prints the error message. If this doesn't print "false", I don't really have other ideas.