Bay 12 Games Forum

Not seeing an obvious reason, but I'm not familiar with eventful. What does the 10 argument mean?

Worth noting that pcall will be significantly slower than handling individual types, if that's something you can do, so don't use the pcall approach in anything performance-intensive. I assume there are good reasons for not returning nil for nonexistent fields, although I wasn't around when that decision was made - it's probably better for those accesses to fail early instead of silently succeeding for typos and such.

Worth noting that restarting DFHack is usually overkill. In this case, you might be able to get by with "reload eventful" at the console and/or "reload('plugins.eventful')" in Lua. For most scripts in general (if they're not messing with global DFHack state outside of their own state), clearing or deleting dfhack.script_environment('script_name') will work.

1. If I tie a save file function into the onUnload event should I save to current or the region save file?

That is probably too late to access any world data. It might fire after DF copies the current folder to the region folder too. If you can't do it any earlier, you might have to save to the region folder, but even that name might not be accessible any more. I would experiment with saving something to current and see where that ends up.

2. For the GUI stuff is there a way to distinguish between the arrow keys, numpad keys, and numbers for the keys or are they all treated the same?

You should be using DF's key IDs, which depend on the keybindings that are set. Use STANDARDSCROLL_UP/DOWN. when you're scrolling through a list and CURSOR_UP/etc. when you're moving a cursor (like the X on the map) around the screen. DF and DFHack don't have a way to distinguish between arrow keys and number keys once they've been translated to IDs.

3. Are unit or item ids every reused while playing? I'm guessing historical unit ids are unique, but several of my scripts assume unit ids are also unique.

Don't know about this. They might potentially be reused in different forts in the same world, but I doubt it. Histfig IDs are unique (I'm pretty sure those are the IDs used in the unit-X.dat files in the save folders). If you're concerned, you could tack on the fort/site ID as well for whatever you're doing.

4. There are a lot of great functions available in dfhack.units and the other dfhack.BLANK stuff. If I was interested in porting some of my functions that I currently use that I think other people might find useful from my lua functions to built in functions how should I go about that? (I am familiar with writing C code so that isn't an issue)

Files that need to be changed:
https://github.com/DFHack/dfhack/blob/master/library/modules/Units.cpp (for dfhack.units; other files for other modules, of course)
https://github.com/DFHack/dfhack/blob/master/library/include/modules/Units.h (again, depends on the module)
https://github.com/DFHack/dfhack/blob/master/library/LuaApi.cpp (usually just a WRAP macro works)
https://github.com/DFHack/dfhack/blob/master/docs/Lua%20API.rst
Ideally the changelog too, but that's not as important.

EDIT: Another question I forgot, is there an easy way to detect when custom view screens "turn on and off". My detailed unit viewer currently let's you access the gui/gm-editor for the unit directly for it, but if you change anything in the editor you have to exit out of the viewer and start it again. I was hoping to be able to automatically reload my viewer when exiting the editor but my tests with screen:onShow haven't been successful

Looking at https://github.com/DFHack/dfhack/blob/master/plugins/manipulator.cpp, I think the logic() vmethod gets called periodically when the screen is active (render() should too - logic() might be onIdle() in higher Lua APIs, but render() or onRender() or whatever you're using should work for your purpose). Your screen could set a flag when it opens the screen, and the next time logic() or render() are called, it could refresh itself and reset the flag. "do_refresh_names" is the flag manipulator uses. Does that help?

EDIT2: Do we know the speed change calculations for calculating gait speed based on strength/agility? I wrote a small script to calculate the kph value of a unit based on the gaits file in the raws but it doesn't takes into account and modifiers (the current dhack.units.computeMovementSpeed always returns 0)

Not seeing anything in the XML files about it, sorry. Someone else might know.

Yes, sorry. I meant if the game saves and moves an out of date dat file then updates the dat file in the data/save/current directory but crashes before that can get moved to the data/save/regionX folder.

If the game crashes, the updated .dat file shouldn't get copied to the regionX folder. That's how the current persistent API works as well.

For normal saves this isn't an issue since there is the ON_WORLD_UNLOAD thing, and for autosaves it shouldn't be an issue since they happen at specific times and I can always make sure to get the updated dat file in the /current directory in the correct order. But quicksaves aren't predictable. Luckily it is easy enough to hook into the quicksave script and just make sure that the dat file is updated in the correct order.

Keep in mind that the quicksave script doesn't run on "normal" autosaves so you won't be able to detect those. edit: I guess you can use the fact that autosave times are fixed, yeah.

Again, I'm saying you should write to data/save/current/foo.dat whenever something changes, and you will be fine. You don't need to worry about detecting save events at all. Granted, if you need to write to disk a lot (as in multiple times a second), it would be better to detect saves, and writing only periodically could risk saving slightly stale data. As part of BenLubar's persistent JSON PR, I'll try to make sure scripts have a way to access the save events as well as plugins. But for non-intensive use, you don't have to detect save events.

From the first post of this thread

...
Besides the official download page on DFFD (above), /u/Hecknar maintains df.wicked-code.com, which mirrors every release since 0.40.01!
...

Looks like it has 0.44.09 to me (although I haven't downloaded it myself)

I found I had to load from the main world folder (not /data/save/current) even though I could save to either.

Oh, sorry, I thought that part was obvious. The current folder gets cleared after saving, after its contents are copied into the region folder. Writing directly to the region folder will lead to incorrect behavior if DF quits without saving.