Print

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

[expwnent]

https://github.com/expwnent/dfhack/commit/596ab0e1b85dff4107a65847247d4b7ec1eafa12

All the scripts I've added are in there. They should be safe for the current version. There are a lot of them, so go check them out! I also added a few convenience things like the "repeat" command / repeatUtil / etc.

I added an onReport event that happens when a combat report happens (much more often than you think: it doesn't have to be visible to the user). More exciting is the onStrike event which triggers when any unit hits another. For convenience, it also tries to compute whether they hit the target with a weapon or with a unit attack. It needs testing, so let me know how it goes.

Having a problem running growthbug with the new repeat command. osx, dfhack-r5 Here is what I did:

• save growthbug.lua to hack/script
• save repeat.lua to hack/script
• save repeatUtil.lua to hack/lua/plugins
• add to dfhack.init: "repeat enable 1 months growthbug now"

...and dwarf fortress becomes unresponsive immediately, tried letting it run for 5 minutes to see if it returns, but no luck.

EDIT: same result with feeding-timers. Even trying to run "repeat enable" without arguments in the console freezes the game.

https://github.com/expwnent/dfhack/commit/66098c2bb4a12016e2623b2b3814ff1890b935ab

The documentation was wrong. I changed the syntax of the repeat command and forgot to document it properly. It should work now. Also there was a minor error in removewear which I fixed.

edit: https://github.com/expwnent/dfhack/commit/61d73cc6c28477eca81dda79b8ea14994a098ed9

Another tweak to prevent the infinite loop in the repeat script if you use the wrong syntax.

edit2: I didn't document this, but it should also be possible to call DFHack plugins from lua using the repeat command if you want.

[fricy]

/snip
The documentation was wrong. I changed the syntax of the repeat command and forgot to document it properly. It should work now. Also there was a minor error in removewear which I fixed.

Thx for the fix, it works now. However the growtbug.lua script throws this error message if run from the dfhack console

Code: [Select]

..._8.6/Macnewbie/Dwarf Fortress/hack/scripts/growthbug.lua:19: attempt to index field 'units' (a nil value)
stack traceback:
..._8.6/Macnewbie/Dwarf Fortress/hack/scripts/growthbug.lua:19: in main chunk
(...tail calls...)and this, if run in the onload.init:

Code: [Select]

..._8.6/Macnewbie/Dwarf Fortress/hack/scripts/growthbug.lua:19: attempt to index field 'units' (a nil value)
stack traceback:
..._8.6/Macnewbie/Dwarf Fortress/hack/scripts/growthbug.lua:19: in main chunk
(...tail calls...)
[C]: in function 'runCommand'
./hack/lua/dfhack.lua:384: in function 'run_command'
...bie_8.6/Macnewbie/Dwarf Fortress/hack/scripts/repeat.lua:70: in function 'func'
./hack/lua/plugins/repeatUtil.lua:27: in function 'helper'
./hack/lua/plugins/repeatUtil.lua:30: in function 'scheduleEvery'
...bie_8.6/Macnewbie/Dwarf Fortress/hack/scripts/repeat.lua:69: in main chunk
(...tail calls...)
The command is the same both times: repeat -time 1 months -command growthbug

And another question: is there any reason to be careful with the repeat commands? I'm thinking adding cleanowned, build-location, perhaps stuckdoors to be run on a 1 month interval. Should I expect slowdowns from these calculations, or is it negligible? Does dfhack run on the same core as df, or are these scripts run on a different one?

[expwnent]

For now you should add it to onLoad.init in your raws folder, not dfhack.init. The problem is that it was running before your world loads.

These scripts should be light on your FPS, so that shouldn't have any noticeable effect.

[fricy]

For now you should add it to onLoad.init in your raws folder, not dfhack.init. The problem is that it was running before your world loads.

That was my idea as well, "cleanowned scattered x", feeding-timers, build-location work, but growthbug doesn't. Check out the second error message, that's from running it with the onLoad.init.

These scripts should be light on your FPS, so that shouldn't have any noticeable effect.

Cool, one month it is!

[expwnent]

Oh, that should be df.global.world.units.all instead of df.world.units.all.

[fricy]

Oh, that should be df.global.world.units.all instead of df.world.units.all.

Perfect!

@Peredexiserrant:

Spoiler: These are the fixes I'm adding to onLoad.init, and I'm moving all the UI and game logic tweaks as well: (click to show/hide)

Code: [Select]

##############################
#  Run fixes at game load    #
##############################

#automatically resets the feed and water counters of prisoners, patients, babies
repeat -time 1 months -command fix/feeding-timers

#automatically fixes the issue where units don't grow
repeat -time 1 months -command fix/growthbug

#Fix invalid buildlocation/worker occupying site bug
repeat -time 1 months -command fix/build-location

#Fix doors that are stuck in an open state
repeat -time 1 months -command fix/stuckdoors

#Confiscate scattered worn clothing every season
repeat -time 3 months -command cleanowned scattered x

#Run population check every season
repeat -time 3 months -command fix/population-cap

#Stop caravans from bringing blood, ichor, goo
repeat -time 3 months -command fix/blooddel

Plus I have a question about item-occupancy.lua: What does it do, should I run it with repeat, or at all.

[ag]

Plus I have a question about item-occupancy.lua: What does it do, should I run it with repeat, or at all.

That script is an extremely slow process intended to diagnose and fix corruption from buggy scripts or plugins teleporting items around. It should only be used if you encounter problems like dwarves claiming there is an item in a tile when there is none. It's somewhat similar to programs like chkdisk that fix your filesystem.

[fricy]

That script is an extremely slow process intended to diagnose and fix corruption from buggy scripts or plugins teleporting items around. It should only be used if you encounter problems like dwarves claiming there is an item in a tile when there is none. It's somewhat similar to programs like chkdisk that fix your filesystem.

Thx, noted, deleted from onload.
One more: I tried running the blooddel command to test if it works, and it won't delete blood barrels from an already arrived caravan. Is it intended behaviour? Is it only effective on future caravans?

[PeridexisErrant]

Nice. 

The thing I'm grappling with is that (as I understand) there's a separate Onload.init for each save, which creates some issues for people who move old saves over to a new pack and probably a support headache when someone changes settings and it doesn't behave as they expect. 

My plan was to find someone who can make this happen, and basically just run a few things from there - recreating all such files each time a setting is changes.  It would be simple enough to make a monster-option for all bugfixes with multicmd;;;;;;; - but I probably won't move anything I expect people to leave on unless it can't be done from dfhack.init.

[fricy]

The thing I'm grappling with is that (as I understand) there's a separate Onload.init for each save, which creates some issues for people who move old saves over to a new pack and probably a support headache when someone changes settings and it doesn't behave as they expect.

Two solutions come to mind:
1. You already have a script to help migrating saves, add a line to copy onload.init to the individual saves
2. Add a copy of onload.init to the raw folder of every graphics pack, and tell the players to always reapply the graphics settings before playing. That's what I'm going to do.

A setting manager is not a bad idea, but it's not an immediate solution.

[PeridexisErrant]

I had thought of the first, and I plan to do this eventually - but it's a real pain, with way more special cases than I want to consider.  The second could work - I'd have to check how selectively the windows GUI copies those folders over.  On the other hand, it makes all the issues with propagating settings even worse if I want to use it for more that always-on bugfixing. 

Serious questions to dfhack people:  how hard would it be to have a single Onload.init in the same place as dfhack.init? 

This would be a huge plus for my setup in the Starter Pack.  If keeping the current function is desired, it could be overridden when an in-save-folder init file is found. 

[Meph]

Wouldnt that create the same issue? Players load an old save with specific settings, and it doesnt behave like it did when they created it.

[lethosor]

Serious questions to dfhack people:  how hard would it be to have a single Onload.init in the same place as dfhack.init? 

You can probably do it fairly easily by calling "script onload.init" whenever a region loads.

[PeridexisErrant]

What I'm after would basically fake having a single simple file; if you mean a save from an older pack I already reset dfhack.init by default so that any new items will usually make it through.  There's no perfect solutions, so I try to make the default work for the minimum-effort newbie.  It seems to work out pretty well for most

You can probably do it fairly easily by calling "script onload.init" whenever a region loads.

I'll look into this if I have a day free sometime, but that might not happen for a while. 

[lethosor]

This should work in dfhack.init:

Code: [Select]

:lua dfhack.onStateChange.onloadscript = function(state) if state == SC_WORLD_LOADED then dfhack.run_command('script onload.init') end end
If you want output to be displayed, use this instead:

Code: [Select]

:lua dfhack.onStateChange.onloadscript = function(state) if state == SC_WORLD_LOADED then print((dfhack.run_command('script onload.init'))) end end