Bay 12 Games Forum

Those are the tiles that are specified in the raws for those gems. If those aren't the tiles you see in-game, are you using TWBT? We likely wouldn't be able to support tilesets that require TWBT in this particular screen, unfortunately.

There isn't much we can do about that, unfortunately. dfhack-run itself hasn't changed very much in recent years, so this is almost certainly an issue with antivirus definitions.

I would be curious to know if 0.47.04-r3 also triggers the same detection, though. If it does, and 0.47.03-beta1 does not, then it could be related to the color change from March. Otherwise, my reasoning above would still apply.

-rate 0.25 resets to default fps instead, making game to run at 1x speed.

Okay, I see the relevant code now, although it's right after the snippet you posted - if you comment out the "rate = 1" line (add "--" to the beginning of it), does that do what you want?

I'm using some older version, but it works very well

If my suggestion doesn't work, it would be very helpful to know where you got this older version from (or to have a copy of it).

Anyway, I'm having crashes in DF by totally different reasons now:
Class not in symbols.xml: 'viewscreen_unitlaborsst': vtable = 0x7fedc200ff0

The message you pasted is a harmless diagnostic message that is not related to the crash. It's in stderr.log because it's occasionally useful for development. Is there any way we could make it clearer that it is not an error? Would having something like "INFO:" prepended make it clearer?

This happens when I try to manage labour and enable herbalist job for my dwarves.

I'm having trouble reproducing this. I was able to enable herbalism on around 100 dwarves across two forts with no crash.
Does it happen exactly when you press "Enter" with herbalism selected for a dwarf, or at some later time? Are you able to reproduce it consistently? Does it only occur for specific dwarves? Are you using any mods?

find() takes the ID, which would be passed to my-script.lua by the modtools/item-trigger command when a matching event occurs. You wouldn't need to check for "onEquip" in the script itself - armorType couldn't be equal to "ITEM_ARMOR_HELM" and "onEquip" at the same time, and modtools/item-trigger would already only run your custom script for equip events of the "Worn" mode.

I guess I was thinking something along these lines for my-script.lua (which can be renamed, of course):
local args = ...
local item = df.item.find(args[1])
local unit = df.unit.find(args[2])
-- do stuff with unit, item

I'm not sure if there are any existing examples for what you want to do - have you written a Lua script before? If not, https://www.lua.org/start.html has some resources that might be useful for Lua in general.

Thank you for replying! Can you tell me how I can adjust armor attributes beforehand?

Well, it depends on what you want to do. I was thinking just modifying the raws would work for some changes to armor, if you want them to always be in effect. I'm also not very familiar with how the combat system works in general, so other people might have better ideas.

Edit: thanks, Uthimienure!
My understanding is that modifying some traits in the save-specific raws would affect all matching items in-game, but some (e.g. the initial state of certain values) would only apply to new items. Adding new items wouldn't work in an existing world, though - this thread in the modding forum goes into some detail about it.

We've only included timestream.lua since 0.47.04-r3, which is currently the latest version. It is a heavily modified version of a script originally by IndigoFenix, though - were you using that? I didn't think it worked in 0.47.04 as-is. If not, where did you get timestream.lua from previously?

We could try adding that feature, but since I'm not aware of it being intentionally removed, I'm not really sure where to look. Are you asking for something like "-rate 0.25" to work? From looking through the code briefly, I think that should work as-is (at least, I don't see anything actively preventing it from working).

ok just now notice my copy of advfort isn't working with buildings and just realize it's because someone changed the module stuff to be a dfhack_flag. check in advfort_items.
odd time to realize there been a revamp to the code structure but I hope I don't have to like edit some important dfhack file to connect a different script to advfort_items, or dummy out that line of code in advfort_item?
edit: it seems the 'require' code got changed to reqscripts .... so I dread if I have to rewrite a whole bunch of my scripts or just the scripts that touch dfhack stuff.

Could you clarify exactly what is broken? Is advfort.lua in the DFHack repository not working, or is this your own copy? If it's your own, is there any particular reason you're maintaining your own copy? Are there changes that you would like included in DFHack's version?

I did change how advfort_items needs to be imported in https://github.com/DFHack/scripts/commit/ad67c79f8074a491c144144b2825cd05c80a2236 - it was previously the only script in the scripts repo to use mkmodule() and work with require(), so I changed it for consistency. This did also require changing the require() calls in two places in advfort.lua (see the diff for exactly what changed) - those should be all that you need to change on your end, unless you've added more. advfort_items should still be able to be used in exactly the same way, but let me know if there are other issues.

Edit: oh, I think you might have figured it out already. The recommended way to share functions/etc. between scripts is to use reqscript() or script_environment() along with a module check - see the diff above for examples. There is no hard requirement to do it this way for scripts outside of the DFHack/scripts repo, and advfort is the only one I know of that changed recently.

A heads-up: I'm planning to do another release soon (maybe in a week? real life things have caught up to me and delayed this a bit)

It would be great to have people test it out beforehand - there are lots of buildingplan and quickfort changes, thanks to Myk. I'm reasonably confident that they work, but more eyes on it would always be appreciated. As usual:
- Nightly builds can be found at https://dfhack.org/builds
- Issues can be reported here or at https://github.com/dfhack/dfhack/issues - if you're using a nightly build, please include the exact version number (as reported by the console, e.g. "0.47.04-r3-92-g3aa902bd") or build number