Print

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

[lethosor]

I get a bunch of messages about plugins not being built for this version, although as far as I can tell they are trival.
Using dfhack-0.47.05-beta1-Linux-64bit-gcc-7.

Glad that a clean install fixed it. I checked the build you downloaded, and all of the plugin versions in it are correct, so my guess would be that you didn't overwrite the existing plugins the first time you installed DFHack. DFHack just looks at the contents of plugins, not their modification times. Also, it's not a "trivial" error, per se - the plugins would be ignored entirely if you see that message. Maybe that message should be clearer that this is the case.

[xordae]

Cheers feelotraveller, I'll probably throw a "nuke" at the problem and create floors, then walls on all z-levels from the bottom up and see if that sticks.

..Well, that unfortunately did not work.

Oddly, constructing floors does not work either. I'm starting to think this is a DF bug and has nothing to do with tiletypes.

[feelotraveller]

I get a bunch of messages about plugins not being built for this version, although as far as I can tell they are trival.
Using dfhack-0.47.05-beta1-Linux-64bit-gcc-7.

Glad that a clean install fixed it. I checked the build you downloaded, and all of the plugin versions in it are correct, so my guess would be that you didn't overwrite the existing plugins the first time you installed DFHack. DFHack just looks at the contents of plugins, not their modification times. Also, it's not a "trivial" error, per se - the plugins would be ignored entirely if you see that message. Maybe that message should be clearer that this is the case.

Hmm.  What I did was overwrite alpha0 with beta1 with a copy-paste replace all.  However I checked after encountering problems and the plugins were those provided by beta1 when I was getting that message, so something else was triggering it.  Given that clinodev experienced the same, or similar, something strange does appear to be going on.  (I'm sure we won't be the last to try the shortcut of overwriting an existing installation.)

[lethosor]

Hmm.  What I did was overwrite alpha0 with beta1 with a copy-paste replace all.  However I checked after encountering problems and the plugins were those provided by beta1 when I was getting that message, so something else was triggering it.  Given that clinodev experienced the same, or similar, something strange does appear to be going on.  (I'm sure we won't be the last to try the shortcut of overwriting an existing installation.)

My next best guess is that your copy-and-paste technique put things into a separate subfolder of the DF folder (e.g. something like hack/hack/plugins/foo.plug.so instead of hack/plugins/foo.plug.so). This would result in a folder that appears to have new plugins but is being ignored by DFHack.

For reference, this is what I ran to check the versions of the plugins in the copy I downloaded. It will probably print a couple garbage characters, but any recognizable version strings should just be the expected DF or DFHack version (0.47.05-beta1 or 0.47.05-beta1-0-g49b6e814 in this case).

Code: [Select]

strings hack/plugins/* | grep '0.47' | sort | uniq

Overwriting an existing installation should usually work (documented here, but not with any more detail than what you described).

[feelotraveller]

My next best guess is that your copy-and-paste technique put things into a separate subfolder of the DF folder (e.g. something like hack/hack/plugins/foo.plug.so instead of hack/plugins/foo.plug.so). This would result in a folder that appears to have new plugins but is being ignored by DFHack.

For reference, this is what I ran to check the versions of the plugins in the copy I downloaded. It will probably print a couple garbage characters, but any recognizable version strings should just be the expected DF or DFHack version (0.47.05-beta1 or 0.47.05-beta1-0-g49b6e814 in this case).

Code: [Select]

strings hack/plugins/* | grep '0.47' | sort | uniq

Overwriting an existing installation should usually work (documented here, but not with any more detail than what you described).

I reproduced the behaviour on my end.  (It was not a file structure problem, although that's a fair enough guess.)
Got the same error message I originally posted for 20 plugins.
After some talking to myself about how the problem was beyond me it turned out to be very simple.

Those 20 plugins don't exist in the beta1 version.  So that's a case covered by the DFHack documentation.  Apologies for taking up your time.  (Although perhaps you could confirm that they were meant to be removed?)

[lethosor]

Those plugins shouldn't have been included in a release at all - they are dev plugins, intended mainly for testing. Did you compile the original build yourself? If not, I'll take a look at our build server settings - it's possible that the non-release builds are including those.

[feelotraveller]

Ah, that makes sense.

No I did not build it myself but got it from buildmaster.  Specifically - dfhack-0.47.05-alpha0-210131001-Linux-64bit-gcc-7.tar.bz2

[lethosor]

Sorry about that, all. I tracked down the logs for that build - looks like Buildmaster is indeed enabling dev plugins for development builds, and not for release builds. It has been a while since the sorts of errors in your log have been reported, so I only downloaded a release build to check, not realizing that none of the plugins in your log were actually in the package I downloaded.

Anyway, ignoring those warnings if you don't want those plugins is fine (they're not very useful for day-to-day use anyway) and it won't affect the rest of DFHack. The best solution here, as you've already mentioned, is to go with the approach of uninstalling the old version of DFHack before installing the new one.

[javascripter]

not sure if good place to ask this, if there is better place let me know and i can move it there.

I've modded a custom race and screwed up a bit in the entity so that my equivelent of militia captains cannot be assigned (forgot to change ID of assigner from dwarfs), and for various reasons including using dfhack I didn't test for a way into making a fort.

Can I with dfhack / lua assign them manually that way? I found a lua script here http://www.bay12forums.com/smf/index.php?topic=121272.0 for assigning monarches, but I've got no idea how to adapt it for nobles with [SITE]. I thought I would just need to figure out what the assignment ID was and insert something to the units entity_links, but it seems [SITE] nobles don't show up searching through the entity list and extrapolating a number from nobles without [SITE] gives no result.

[PatrikLundell]

I believe there assigned roles for entities overlap in a somewhat messy way so that some things are only in the civ entity, while others are only in the site government ENTITY (emphasized, as it's not in the site structure). The way these structures are used differ between the civ and the site government. I have no idea whether hacking dorfs into these structures is sufficient, though (I think there are multiple places where they are, or at least may be, included.

Somewhat vague and possibly incorrect, as it's from my flaky memory of the structures. Regardless, you'll need to familiarize yourself with the entity structure, as you'd have to be very lucky for someone else to have written a suitable script already, so you'd have to expect to do it yourself.

[javascripter]

I can write a script; but is that structure (object, struct, whatever) documented somewhere?

For example, because of previous script I linked I know how to get nemesis record of a unit and insert something into the entity_links of the nemesis record; but I have no idea what a nemesis record is or what entity links is, and google only finds other scripts an no documentation or wherever whoever made the first script using entity_links figured that out from (https://docs.dfhack.org/en/stable/docs/Lua%20API.html has the function for getting nemesis record, but nothing else about it)

I can even print the nemesis record and entity_link (or values for each index since it is array) but it just gives some text that gives nothing useful (I found this https://peridexiserrant.neocities.org/docs-structures-test/docs/_auto/structures/refs.html but it doesn't seem to be very useful for this purpose) EDIT: and some hex, which is even less useful than the text

For example, if I want to find for what values of df.global.ui.xxx xxx is valid, what is best place to look?

[Rumrusher]

Code: [Select]

function Memorypurge()
local adv=df.global.world.units.active[0]
local mem=df.global.world.history.figures[adv.hist_figure_id].info.known_info.known_events
for k,v in pairs(mem) do

if v==nil then break else
mem:erase(k)

end
end
end
Memorypurge()

so currently wrote this WIP proof of concept script to help cut down adventurer Memory bloat it could be optimized a bit to say save certain reports and rumors and possibly cull out seeing a wild animal attack another wild animal, also don't know how to stop it from throwing out an error half the time so shrugs on that bit.

also said script is a revised version of the old gigapurge script that I feel probably the same warnings of be careful on using this.

[PatrikLundell]

df.global.world contains almost everything of interest (there are things outside, like df.global.ui). gui/gm-editor is the standard tool for looking at df structures, but you can also look at the XML source for it (either in a local copy of dfhack if you compile it yourself, or on github (approximately named dfhack/df-structures). The XML has the advantage that there are some comments in there, but gui/gm-editor is usually easier to use because you don't have to guess at the file things are stored in).

Entities are stored in df.global.world.entities.all.

I don't really know what a nemesis record is for, but there are references to them and they, in turn, reference the hist fig targeted, which has been sufficient for my purposes so far.

"gui/gm-editor df.global.ui" will show you the top level of ui, and allows you to traverse further down the tree (when the elements are compound, of course), but, as indicated above, you probably want df.global.world as your top exploration level.

[lethosor]

not sure if good place to ask this, if there is better place let me know and i can move it there.

I've modded a custom race and screwed up a bit in the entity so that my equivelent of militia captains cannot be assigned (forgot to change ID of assigner from dwarfs)
...
I thought I would just need to figure out what the assignment ID was and insert something to the units entity_links, but it seems [SITE] nobles don't show up searching through the entity list and extrapolating a number from nobles without [SITE] gives no result.

If I'm understanding this correctly, this is a position that you want to be able to assign from the "n" screen, but can't due to a mistake in the raws, yes? If that's the case, I would actually suggest trying to change this on the entity level, to allow the position to be assigned, rather than trying to forcibly assign a position that can't be assigned. I think it would be easier and less error-prone to leave the actual position assignment logic to DF.

The relevant data is probably stored at the entity level (e.g. "df.historical_entity.find(unit.civ_id)") but might be stored in the entity raws only instead ("df.entity_raw.find(unit.civ_id)"). Changes to raws (technically the in-memory versions of raws in this case) typically only affect new entities/objects, so I would recommend looking at the entity itself first.

I would recommend making a backup of your save first, in case you corrupt something irreversibly.

As a side note, you can actually drop the "df.global." prefix in both the "lua" interpreter and "gui/gm-editor" for convenience, e.g. "gui/gm-editor world" will work.

For example, if I want to find for what values of df.global.ui.xxx xxx is valid, what is best place to look?

That depends on quite a lot - what type(s) are you asking about here? My best answer is for enums, which would typically show up as numbers in Lua. Editing an enum field in gui/gm-editor would bring up a dialog with each (known) valid value, along with their names, and the enum name itself at the top. You could also track down the field in df-structures, like PatrikLundell mentioned. For scripting, you should always use the name ("df.enum_name.ValueName"), never the number, because the raw numbers can change. Valid values for other fields can vary greatly, and df-structures might have more relevant information on a case-by-case basis.

I can even print the nemesis record and entity_link (or values for each index since it is array) but it just gives some text that gives nothing useful... EDIT: and some hex, which is even less useful than the text

Try printall() (shorthand: "~" in the "lua" interpreter). I'm guessing you were just getting something like "<nemesis_record: 0x25f25a0>", but if not, an example of what you are seeing would be helpful. Note that gui/gm-editor would also make it a bit easier to browse structures.

As for what a nemesis record is, I suppose that is something that could be documented. I would need to track down past discussions on it. Many structures don't have documentation outside of the XML files, because as of 0.47.05, there are 1721 of them, and both writing the documentation and keeping it up-to-date would be a massive undertaking.

[javascripter]

df.global.world contains almost everything of interest (there are things outside, like df.global.ui). gui/gm-editor is the standard tool for looking at df structures, but you can also look at the XML source for it (either in a local copy of dfhack if you compile it yourself, or on github (approximately named dfhack/df-structures). The XML has the advantage that there are some comments in there, but gui/gm-editor is usually easier to use because you don't have to guess at the file things are stored in).

Entities are stored in df.global.world.entities.all.

I don't really know what a nemesis record is for, but there are references to them and they, in turn, reference the hist fig targeted, which has been sufficient for my purposes so far.

"gui/gm-editor df.global.ui" will show you the top level of ui, and allows you to traverse further down the tree (when the elements are compound, of course), but, as indicated above, you probably want df.global.world as your top exploration level.

So, my problem was a lack of understanding of gui/gm-editor, I thought it was only used for editing unit personalities and things like that.

After posting I found the df structures git, but discarded it after not reading enough since it just looked like a massive list of enums and I didn't read far enough to get to the structs.

I've found gui/gm-editor is nice for seeing orders of things, and then when I run into an issue with pointers findstr (grep for linux) is pretty useful with the xml files.

If I'm understanding this correctly, this is a position that you want to be able to assign from the "n" screen, but can't due to a mistake in the raws, yes? If that's the case, I would actually suggest trying to change this on the entity level, to allow the position to be assigned, rather than trying to forcibly assign a position that can't be assigned. I think it would be easier and less error-prone to leave the actual position assignment logic to DF.

The relevant data is probably stored at the entity level (e.g. "df.historical_entity.find(unit.civ_id)") but might be stored in the entity raws only instead ("df.entity_raw.find(unit.civ_id)"). Changes to raws (technically the in-memory versions of raws in this case) typically only affect new entities/objects, so I would recommend looking at the entity itself first.

I would recommend making a backup of your save first, in case you corrupt something irreversibly.

As a side note, you can actually drop the "df.global." prefix in both the "lua" interpreter and "gui/gm-editor" for convenience, e.g. "gui/gm-editor world" will work.

had already started considering this, I found that site nobles are in entity_links, just under a totally different entity_ID, I guess each site gets a separate ID. I was thinking just telling that unit to be a militia captain might not make it possible to actually make a second squad and may just lead to the unit being on duty with no barracks or something unfortunate like that.

That depends on quite a lot - what type(s) are you asking about here? My best answer is for enums, which would typically show up as numbers in Lua. Editing an enum field in gui/gm-editor would bring up a dialog with each (known) valid value, along with their names, and the enum name itself at the top. You could also track down the field in df-structures, like PatrikLundell mentioned. For scripting, you should always use the name ("df.enum_name.ValueName"), never the number, because the raw numbers can change. Valid values for other fields can vary greatly, and df-structures might have more relevant information on a case-by-case basis.

apologies for unclarity, what I meant by that was exactly what gui/gm-editor does; where i can see a list of all the properties (for example, dfhack.units has .isGelded, .isEggLayer, ...)

whoever wrote this utility must be pretty smart person as well, the options for enums works pretty nicely

Try printall() (shorthand: "~" in the "lua" interpreter). I'm guessing you were just getting something like "<nemesis_record: 0x25f25a0>", but if not, an example of what you are seeing would be helpful. Note that gui/gm-editor would also make it a bit easier to browse structures.

As for what a nemesis record is, I suppose that is something that could be documented. I would need to track down past discussions on it. Many structures don't have documentation outside of the XML files, because as of 0.47.05, there are 1721 of them, and both writing the documentation and keeping it up-to-date would be a massive undertaking.

printall is very helpful, again whoever wrote this must be pretty smart person

I think it isn't a big deal if it has explanatory documentation; I just thought from the name it was something that would be somehow more meaningful, while after looking at what it contains it just has stuff about units

What would be cool to have documentation on is what you and patrik just told me; though I guess that probably exists and I just am not great at google and didn't even know what I was trying to find.



EDIT: it seems the raws you mentioned in gui/gm-editors are changed by modifying the txt raws, as they seem to already have the fix

EDIT: found where to solve the problem, was very easy after you mentioned df.historical_entity.find(unit.civ_id) (though I actually changed for the site entity rather than the civilization entity)