Print

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

[Meph]

How would you run points (and startdwarf)  from an init file in that case?  Can you just add it to the onload.init, or do you need to specify when it runs somehow?

[lethosor]

Startdwarf is completely different and will work from anywhere because it patches code, which only needs to be done once.
You could probably run points from onLoadWorld.init, like other things that require a world to be loaded. I'm not sure exactly when that runs, but it should be after world general params are loaded.

[Saiko Kila]

I have an issue with syndrome effect value, specifically with the "end". If I want to show other named value, like "start", I can print for example

Code: [Select]

~df.global.world.raws.syndromes.all[123].ce[0].startHowever, I cannot do it with end, since it's a reserved keyword in Lua (and technically it shouldn't be used at all for names). Invoking this will cause error:

Code: [Select]

~df.global.world.raws.syndromes.all[123].ce[0].end
So, any smart way to list this value with a script?

[lethosor]

Replace .end with ["end"]

[Saiko Kila]

Replace .end with ["end"]

Thanks, it works.

[baldamundo]

Hey guys, longtime player/luker/fan of DF and all her utilities.

Couple questions:

How interested would you guys be in an updated(graded) make-monarch script?
I've used the underlying logic to make the script applicable to all noble positions in entity.positions.own ("MONARCH", "DUKE", "COUNT", "BARON", "DIPLOMAT", "GENERAL", "LIEUTENANT", "CAPTAIN", "OUTPOST_LIAISON") and made it so that you can "demote" a unit without raising another.

Spoiler (click to show/hide)

Code: [Select]

local args = {...}
local argv = # args



function GetPositionID(entity, str)
local POSITIONS = {"MONARCH", "DUKE", "COUNT", "BARON", "DIPLOMAT",
"GENERAL", "LIEUTENANT", "CAPTAIN", "OUTPOST_LIAISON"}
local isValid = false
for i=0, 9 do
if POSITIONS[i] == str then
isValid = true
end
end
if not isValid then
qerror("Noble position '" .. str .. "' is not valid.")
end

for k, v in pairs(entity.positions.own) do
if v.code == str then
return v.id
end
end
return nil
end



function Demote(entity, posID)
for assignID, v in pairs(entity.positions.assignments) do
if v.position_id == posID then
local histFigOld = df.historical_figure.find(v.histfig)
if not histFigOld then
return
end
v.histfig = 0
for k,v in pairs(histFigOld.entity_links) do
local isInstance = df.histfig_entity_link_positionst:is_instance(v)
if isInstance and v.assignment_id == assignID and v.entity_id == df.global.ui.civ_id then
histFigOld.entity_links:erase(k)
return
end
end
end
end
end



function Promote(entity, posID, histFig)
for assignID, v in pairs(entity.positions.assignments) do
if v.position_id == posID then
v.histfig = histFig.id
histFig.entity_links:insert("#",
{new=df.histfig_entity_link_positionst,
entity_id=df.global.ui.civ_id,
link_strength=100,
assignment_id=assignID,
start_year=df.global.cur_year})
return
end
end
end



function Main()
local unit = dfhack.gui.getSelectedUnit()
if not unit then
qerror("Please select a unit.")
end

local histFig = dfhack.units.getNemesis(unit).figure
local ownEntity = df.historical_entity.find(df.global.ui.civ_id)

local posID = GetPositionID(ownEntity, string.upper(args[1]))
if not posID then
qerror("Could not find position ID.")
end

local isDemoting = false
if argv > 1 then
if string.lower(args[2]) == "demote" then
isDemoting = true
end
end
if isDemoting then
if not dfhack.units.isOwnGroup(unit) then
print("Can only demote this fort's units.")
else
Demote(ownEntity, posID)
end
else
Demote(ownEntity, posID)
Promote(ownEntity, posID, histFig)
end
end



Main()


(dead group barons borking my site's progression and "inhereted" barons were the impetus for the script if you were wondering).

I noticed the github repo doesn't have a contributing guidelines, so here I am rather than just doing a PR. Also the original make-monarch doesn't have any licensing attached to it, so while I'd be happy to release under a GNU GPLv3 I'm not quite sure if that's kosher.



With the above script in mind; What do we know about the event(s) concering elevating a fortress (barony/county/duchy)?

Ideally, I'd like to have the script elevate the fort if you assign a position you're not yet on, but I've failed in finding anything relevant.

How would you need to modify this to work with mod added civs with different noble positions?

Have gotten as far as editing the first part so it recognises the position as valid, but then it still throws a "Could not find position ID" error.

[taleden]

Is the 'prospect' command compiled into dfhack or is it implemented (or implementable?) via python or ruby script?

And if the latter, can it be made to run during pre-embark on an arbitrary area of the world, or does it rely on reading memory that the game only populates for the actually currently selected embark zone?

[PatrikLundell]

Is the 'prospect' command compiled into dfhack or is it implemented (or implementable?) via python or ruby script?

And if the latter, can it be made to run during pre-embark on an arbitrary area of the world, or does it rely on reading memory that the game only populates for the actually currently selected embark zone?

"prospector.cpp" (which is the name of the plugin, but not the command it implements) is a compiled plugin, but I don't think there's anything preventing the logic from being implemented in script (I've copied parts of the logic at various time for use in my scripts).

"prospect" has to be run where sufficient context has been loaded for some data to be accessed, but it is capable of running pre embark, where it makes an estimate rather than a tally of what's actually there. However, it's possible to have a script change the context by providing simulated movement key input, causing the region_details structure to load the mid level tile info for the current world tile.

[Quietust]

"prospector.cpp" (which is the name of the plugin, but not the command it implements) is a compiled plugin, but I don't think there's anything preventing the logic from being implemented in script (I've copied parts of the logic at various time for use in my scripts).

Converting the post-embark version of prospector to a Lua script would be a bad idea, because it iterates across every single map tile in order to count up all of the details - it would "work", but it'd take a rather long time to run (i.e. measured in minutes). The pre-embark version, on the other hand, would probably work just fine as a script.

[thefriendlyhacker]

Hello, it is me again. I am having a few problems.

Spoiler: spoiled for length (click to show/hide)

First off, the siege engine plugin is throwing an error.

Code: [Select]

... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:166: Cannot read field unit.relations: not found.
stack traceback:
[C]: in metamethod '__index'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:166: in function 'plugins.siege-engine.getBaseUnitWeight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:174: in function 'plugins.siege-engine.getUnitWeight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:182: in local 'get_weight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:191: in function 'plugins.siege-engine.scoreTargets'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:295: in function 'plugins.siege-engine.doAimProjectile'
[C]: in ?I took a quick gander at the lua code for siege-engine and checked it against the current data structure for units.  It looks like the unit.relations vector and the fields within it were renamed at some point but siege-engine wasn't updated to match.

Second, there is a problem with reaction-trigger.  When a work order is placed (either through jobs/manager or by placing a work order in the individual workshop), commands are not executed/syndromes are not applied unless the reaction is the last one in the work order e.g. if I run the command "modtools/reaction-trigger -reactionName MAKE_PEARLASH -command [ devel/print-args "test" ]", place an order for 3 "make pearlash", the first and second reactions carried out at the kiln will not print anything, while the third will print "test".  I extracted a fresh vanilla df+dfhack copy and did a bit of printlining, and it looks like the function in eventful.onJobCompleted.reactionTrigger is only called on the last reaction in a work order (which would mean that the underlying bug is in eventful).

Thirdly, I am having weird intermittent problems with creating pets via modtools/create-unit.  Sometimes the game will crash shortly after creating a unit.  On one occasion, I also saw a created pet get into a full on fight with a citizen a while after it was created (with attack interactions used by the pet and melee weapons by the citizen).  I made an attempt to reproduce the above bugs by spamming workshop reactions that run create-unit through reaction-trigger (which is how I normally use create-unit), but they didn't happen again.  However, after leaving DF to run for a few minutes while this was going on, the game for some reason decided to consume about 17GB of memory (FYI, I have 16GB of ram), after which I had to kill DF because it was making my operating system unstable.  I have never seen anything like that happen before.

Now, to be clear, I haven't tried testing in vanilla or varying anything to narrow down the problem, and I haven't been able to successfully reproduce any bugs consistently.  Also, the created units are fairly unusual by vanilla DF standards (immobile pet style landmines and interaction equipped robots), so it could be something particular to my mod that is causing this.  I am just putting it out there that I am personally having problems.

Lastly, as a minor little thing I noticed, should the field "maker_race" in items be renamed something else?  AFAICT it just controls the sizing of an item.  The var name maker_race seems like a misnomer when dwarf produced, human sized equipment will have "maker_race" equal to the ID for humans.

Everything above was in DF 44.12 + DFHack 44.12-r1 in win7 64bit, by the way.

EDIT: I tried fixing the error in the siege engine lua code.  There is another error - math.pow on line 175 is throwing an "attempted to call a nil value" error. I just checked using the dfhack console lua interpreter, and the function math.pow doesn't exist.

[Rose]

Is there a list of what body parts have what clothing layers in them, or do I just need to calculate it from the inventory?

[lethosor]

First off, the siege engine plugin is throwing an error.

Code: [Select]

... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:166: Cannot read field unit.relations: not found.
stack traceback:
[C]: in metamethod '__index'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:166: in function 'plugins.siege-engine.getBaseUnitWeight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:174: in function 'plugins.siege-engine.getUnitWeight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:182: in local 'get_weight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:191: in function 'plugins.siege-engine.scoreTargets'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:295: in function 'plugins.siege-engine.doAimProjectile'
[C]: in ?I took a quick gander at the lua code for siege-engine and checked it against the current data structure for units.  It looks like the unit.relations vector and the fields within it were renamed at some point but siege-engine wasn't updated to match.

That was renamed a long time ago. It should be unit.relationship_ids.GroupLeader instead - does that work for you?

Edit: almost 2 years: https://github.com/DFHack/df-structures/commit/25cb373055257532c0a3df2faa7aa68d17f7b853

Second, there is a problem with reaction-trigger.  When a work order is placed (either through jobs/manager or by placing a work order in the individual workshop), commands are not executed/syndromes are not applied unless the reaction is the last one in the work order e.g. if I run the command "modtools/reaction-trigger -reactionName MAKE_PEARLASH -command [ devel/print-args "test" ]", place an order for 3 "make pearlash", the first and second reactions carried out at the kiln will not print anything, while the third will print "test".  I extracted a fresh vanilla df+dfhack copy and did a bit of printlining, and it looks like the function in eventful.onJobCompleted.reactionTrigger is only called on the last reaction in a work order (which would mean that the underlying bug is in eventful).

This is probably because since the new manager in 0.43, manager-created jobs have an "order" flag set on them, and there's just one per workshop (which is done repeatedly until the order is completed), rather than many jobs based on what was requested in the manager. I'm not familiar enough with the script to fix it quickly - any takers?

Thirdly, I am having weird intermittent problems with creating pets via modtools/create-unit.  Sometimes the game will crash shortly after creating a unit.  On one occasion, I also saw a created pet get into a full on fight with a citizen a while after it was created (with attack interactions used by the pet and melee weapons by the citizen).  I made an attempt to reproduce the above bugs by spamming workshop reactions that run create-unit through reaction-trigger (which is how I normally use create-unit), but they didn't happen again.  However, after leaving DF to run for a few minutes while this was going on, the game for some reason decided to consume about 17GB of memory (FYI, I have 16GB of ram), after which I had to kill DF because it was making my operating system unstable.  I have never seen anything like that happen before.

Sounds like something triggered undefined behavior that would usually crash (e.g. reading from a string that isn't actually a string) but you got unlucky.

Are you using the -setUnitToFort argument, or anything else to adjust civ IDs? Better question: how exactly are you running create-unit (what arguments)?

Lastly, as a minor little thing I noticed, should the field "maker_race" in items be renamed something else?  AFAICT it just controls the sizing of an item.  The var name maker_race seems like a misnomer when dwarf produced, human sized equipment will have "maker_race" equal to the ID for humans.

No idea how this stuff works, but if you test other combinations (e.g. human-produced dwarf-size equipment) and they behave the same, feel free to submit a PR or suggest a new name here.

EDIT: I tried fixing the error in the siege engine lua code.  There is another error - math.pow on line 175 is throwing an "attempted to call a nil value" error. I just checked using the dfhack console lua interpreter, and the function math.pow doesn't exist.

Geez, has nobody used siege-engine in the past 2 years? math.pow was replaced with the ^ operator when we switched to Lua 5.3 in 0.43.05 - try that.

[thefriendlyhacker]

...
That was renamed a long time ago. It should be unit.relationship_ids.GroupLeader instead - does that work for you?

Yep, that fixed the error.

math.pow was replaced with the ^ operator when we switched to Lua 5.3 in 0.43.05 - try that.

Ok, did that. There was also one other place where pow was used instead of ^.  After replacing both of them with ^, I fired about 30 ballista rounds at a siege that showed up at the perfect moment without any errors or other problems.  Hopefully that is it for siege-engine bugs.

Geez, has nobody used siege-engine in the past 2 years?

Bear in mind that this doesn't show up if you just play around with siege-engine a bit using unskilled operators.  I tried embarking in vanilla to test a couple of things, lucked out and landed on top of a Roc lair, and fired ballista bolts at both the Roc and a herd of boars for a while without any errors.  I had to dig around in the c++ code to figure out why, but dabbling operators can't aim at specific creatures (only an area), and the buggy code is only executed when weighting targets for the random target creature selection algorithm.  You have to fire a siege weapon with a trained operator at an area containing creatures to get an error thrown.

Are you using the -setUnitToFort argument, or anything else to adjust civ IDs? Better question: how exactly are you running create-unit (what arguments)?

Here are the relevant script calls:

Code: [Select]

foe/reaction-trigger -reactionName DEPLOY_MINE_HE -command [ modtools/create-unit -race LANDMINE -caste HE -domesticate -location [ \\LOCATION ] ]
foe/reaction-trigger -reactionName MANUFACTURE_PROTECTAPONY_MINIGUN -command [ modtools/create-unit -race PROTECTAPONY_MINIGUN -caste NORMAL -domesticate -location [ \\LOCATION ] ]
foe/reaction-trigger -reactionName MANUFACTURE_SPRITEBOT -command [ modtools/create-unit -race SPRITEBOT -caste MALE -domesticate -location [ \\LOCATION ] ]FYI foe/reaction-trigger is literally just modtools/reaction-trigger with bug fixes/expanded functionality (which doesn't matter in this case).  I put the code for it here a couple of weeks back, if you want to take a look.

Now that you mention it, the script call has -domesticate but not -setUnitToFort.  Going by the lua code for create-unit, -setUnitToFort sets the civ and group ID to your fort's, while -domesticate only sets the group ID. I just created a unit to confirm it, and gui/gm-editor says that it's civ_id is -1.  That might be the problem.  I will add -setUnitToFort to my create-unit calls and see if it fixes things.

[Saiko Kila]

Geez, has nobody used siege-engine in the past 2 years?

Bear in mind that this doesn't show up if you just play around with siege-engine a bit using unskilled operators.  I tried embarking in vanilla to test a couple of things, lucked out and landed on top of a Roc lair, and fired ballista bolts at both the Roc and a herd of boars for a while without any errors.  I had to dig around in the c++ code to figure out why, but dabbling operators can't aim at specific creatures (only an area), and the buggy code is only executed when weighting targets for the random target creature selection algorithm.  You have to fire a siege weapon with a trained operator at an area containing creatures to get an error thrown.

I think the most important reason was the long-standing bug which caused crashes when using siege ammo (and weapon traps). It was introduced in June 2016, and fixed only in late November 2017. Most people stopped using siege engines because of that.

[iceball3]

I wonder, is there existing or a possibility of a dfhack command that can work during worldgen or other high-lag states, that allow dfhack to inject a keyboard input on the next frame that DF advances? For instance, allowing one to pause worldgen's time advancement in it's tracks when the worldgen has become laggy enough to start ignoring key inputs. A similar case could be asked in times of extreme DF Fortmode lag, where it's difficult to regain control as the game doesn't seem to like listening for key inputs when a frame is taking more than a few seconds to pass.