Print

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

[myk]

There are a lot of changes in where data is stored. Most viewscreens have been merged into dwarfmodest. Zones are very different, as is the labor system. All graphics-related structures have seen significant changes. The set of available keybindings is very different.

Not sure how much any of that affects what you want to do, but those are the changes that have jumped out at me so far.

[PatrikLundell]

And, obviously, all UI you may need will have to be different. I don't know how much change there is to the scripter if you just want to throw up windows with info or queries but don't care about alignment, though. I don't even know if that functionality works decently currently or if it has to be modified to work properly, and how the call profiles will have to be modified to deal with the different grids used, for cases where you actually want things placed precisely.

When it comes to key bindings we ought to expect DF to gobble up more keys than those used currently when keyboard support is restored in coming versions, so anything you define may need to be adjusted.

[Roses]

Thanks, makes sense that any UI related information will be different, I think I will hold off on trying to do any of my previous UI work as I can foresee that changing a lot with the new graphics stuff. Where information is stored is too be expected I suppose as it usually changes somewhat every DF release. I guess I will have to just see what might have been impacted with what I use, but at least it seems like, beside the UI stuff, I can still work with what I was doing prior to my hiatus.

On the DFHack side of things, has there been (or are there any plans to) changes to the persistent storage stuff? Previously I was using that heavily, but I moved to mixing it with writing/reading a basic JSON file when the game was saved/loaded. Wondering if I should keep doing that or if I should go back to using the persistent storage, or if I should use a completely different system?

[ab9rf]

On the DFHack side of things, has there been (or are there any plans to) changes to the persistent storage stuff? Previously I was using that heavily, but I moved to mixing it with writing/reading a basic JSON file when the game was saved/loaded. Wondering if I should keep doing that or if I should go back to using the persistent storage, or if I should use a completely different system?

We implemented a persistence API some time ago (in DFHack 0.44.12-r3), using JSON written to a cosave file in the game folder.

[myk]

Yes, internally, DF works about the same (for the most part).

Regarding DFHack, persistent storage itself hasn't changed much, but the way plugins and scripts keep state has changed a bit. There is a much stronger push for tools to persist the state that players set while playing. The rallying cry is "initless", since the idea is to allow players to use DFHack tools effectively with zero init file editing (though init files still work if that's how the player wants to do things). As part of this effort, scripts have gained a way to automatically re-enable themselves according to their saved state. Before, a player would have to explicitly run a script (either manually or from an init file) before the script would have a chance to check any saved state. This prevented scripts from automatically reloading their state and continuing where they left off.

Now, scripts have a standard way to load state and set hooks at DF startup like plugins have always enjoyed: https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#enabling-and-disabling-scripts

In UI news, the DFHack widget library is getting an overhaul. Two overhauls, actually. The current widget library is getting a lot more mouse support, like dragging, resizing, and being able to scroll the widget under the mouse cursor with the mouse wheel.

We're also working on an entirely new widget API that will allow much more "professional" UIs. This is still in the experimental phase, but it's coming along nicely.

Another big advancement is the DFHack overlay, which allows you to easily inject information and functionality into existing viewscreens. See https://docs.dfhack.org/en/latest/docs/dev/overlay-dev-guide.html

So, fun times ahead for modders : )

[Roses]

On the DFHack side of things, has there been (or are there any plans to) changes to the persistent storage stuff? Previously I was using that heavily, but I moved to mixing it with writing/reading a basic JSON file when the game was saved/loaded. Wondering if I should keep doing that or if I should go back to using the persistent storage, or if I should use a completely different system?

We implemented a persistence API some time ago (in DFHack 0.44.12-r3), using JSON written to a cosave file in the game folder.

Awesome, sounds like it basically just does what I was doing already, so it's nice that there is an API for it now.

Yes, internally, DF works about the same (for the most part).

Regarding DFHack, persistent storage itself hasn't changed much, but the way plugins and scripts keep state has changed a bit. There is a much stronger push for tools to persist the state that players set while playing. The rallying cry is "initless", since the idea is to allow players to use DFHack tools effectively with zero init file editing (though init files still work if that's how the player wants to do things). As part of this effort, scripts have gained a way to automatically re-enable themselves according to their saved state. Before, a player would have to explicitly run a script (either manually or from an init file) before the script would have a chance to check any saved state. This prevented scripts from automatically reloading their state and continuing where they left off.

Now, scripts have a standard way to load state and set hooks at DF startup like plugins have always enjoyed: https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#enabling-and-disabling-scripts

In UI news, the DFHack widget library is getting an overhaul. Two overhauls, actually. The current widget library is getting a lot more mouse support, like dragging, resizing, and being able to scroll the widget under the mouse cursor with the mouse wheel.

We're also working on an entirely new widget API that will allow much more "professional" UIs. This is still in the experimental phase, but it's coming along nicely.

Another big advancement is the DFHack overlay, which allows you to easily inject information and functionality into existing viewscreens. See https://docs.dfhack.org/en/latest/docs/dev/overlay-dev-guide.html

So, fun times ahead for modders : )

Interesting, so it sounds like I should do some real digging into the changes, from a cursory glance it seems a lot of the more esoteric things I was doing are now available through actual hooks and API interfaces. Should greatly simplify a lot of things, and hopefully make what I was doing more consistent.

The widget library overhaul also sounds very nice, so I am definitely just going to scrap all the stuff I was doing that was UI based, and come back to it once the changes move out of the experimental stage (or maybe I'll play with the experimental stage a bit).

Guess it's time to dust off the ol' lua scripting hat

[Clément]

I started looking at invalid offsets in Dwarf Therapist. Are you interested in me reporting my issues for df-structures or are you busy enough right now?

[myk]

The conversation for that is happening on the DFHack discord in the #reverse-engineering channel. Your input would be appreciated there, I think.

https://dfhack.org/discord

[lethosor]

Issues on GitHub are welcome too, although there is some risk of duplicating work there (we're trying to get PRs up for changes within a reasonable time, but it doesn't always happen)

[Clément]

I prefer asynchronous discussions. I'll create a github issue.

[ab9rf]

Issues on GitHub are welcome too, although there is some risk of duplicating work there (we're trying to get PRs up for changes within a reasonable time, but it doesn't always happen)

we are definitely behind in merging structures updates, but this isn't really surprising given that (a) it's been holidays and (b) there is a lot going on right now

[Gamerlord]

I would quite literally KILL for a script to run that creates individual work details for every labor and sets them all to Only Selected. I spend 5-10 minutes just setting that shit up every damn time I play.

[Putnam]

I would quite literally KILL for a script to run that creates individual work details for every labor and sets them all to Only Selected. I spend 5-10 minutes just setting that shit up every damn time I play.

Better yet, just play the game as designed until the utilities come out which are actually designed to do this and use the global flag that turns off the work details system completely, instead of repeatedly banging your head against the wall to get a system to do something you don't want it to?

[FantasticDorf]

I would quite literally KILL for a script to run that creates individual work details for every labor and sets them all to Only Selected. I spend 5-10 minutes just setting that shit up every damn time I play.

Better yet, just play the game as designed until the utilities come out which are actually designed to do this and use the global flag that turns off the work details system completely, instead of repeatedly banging your head against the wall to get a system to do something you don't want it to?

Without trying to wade in, that's partially what DT is for. Even in 47.x there were things doable with therapist that couldn't be accessed elsewhere or really had time to be acknowledged as features. Giving semi-intelligents additional labors for instance, than just what the default ambusher skill does for vanilla gremlins + hauling etc was unrecognised gameplay advantages it offered.

DF does figure in a lot of repetitiveness in 50. for turning off tutorial menus/preferred stockpile (barrel/bins constantly reset and default rather than stay 0) / and labor settings because of a lack of persistency. A DT that could automatically work with the squad system with some advanced commands (ability to draft anybody in) and pre-set uniforms/script written uniform templates would be the same vein as the original comment.

[lethosor]

New pre-release for 50.05! See the release announcement for details: https://github.com/DFHack/dfhack/releases/tag/50.05-alpha1