Print

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

[Dr. Hieronymous Alloy]

Yeah, it might make sense to "fork" DFhack into two branches, one for steam workshop and one for Classic.

Some feature triage might also make sense -- e.g., a working quickfort function for basic functions like dig, build ramps, etc. might be achievable a lot more quickly than one that implements every furniture type in the game etc.

[myk]

I don't believe there will be a functional difference between Classic and Premium, at least as far as quickfort is concerned.

Good idea to break down the tasks for triage. Let me list the tasks out that I already know need to be done, organized by quickfort blueprint mode. Keep in mind that I don't know whether memory layouts have changed, and game behavior may have changed in subtle ways that we need to adjust to.

Also, fair warning (teaser?) -- I'm planning on combining gui/quickfort, gui/blueprint, gui/mass-remove, gui/stamper, and the functionality from the dig plugin (e.g. circle designations) into a unified interface called gui/designer, which will support interactive copy-paste and a host of other map design/designation tools. I might choose to not release any of those named tools and instead bring them back piece by piece as we can get it working with the steam release.

Dig

This mode is likely to work with minimal modification and can get out quickly. If nothing else, quickfort could be initially released with just digging support. The game now calls marker mode "blueprints" which is a very unfortunate clash of terminology. Not sure how we can clarify the difference between manually designated marker mode "blueprints" and quickfort blueprints (which can also be applied in marker mode).

Build

- buildingplan needs compatibility testing, needs updates if the way items are associated with unbuilt buildings has changed.

After an initial release, there are also many things that need to be done to ensure that quickfort and buildingplan are following game rules when they assign building items:
- building item mapping database in library/Lua/dfhack/buildings.lua needs to be verified
- algorithms for matching items to building filters (isSuitableItem() and friends)
- review the building metadata in internal/quickfort/build.lua

buildingplan will also need a new UI for configuring materials. The old UI was based on the sidebar, which doesn't exist in the new DF interface. Maybe the gui for buildingplan could also be integrated into gui/designer?

Place

- review stockpile metadata in internal/quickfort/place.lua
- stockpile configuration currently happens by invoking a dynamically-generated query blueprint. this will depend on query mode working, or if that proves difficult, we will need to write direct memory initialization routines

Zone

zones have been rewritten from the ground up in the new DF version. DFHack will need a corresponding new access layer for zones. This might prevent zone mode from working right away

- zone metadata in internal/quickfort/zone.lua
- underlying zone creation API in DFHack Core

Query/Config

These modes are tough since they involve actual keystroke playback. Old query and config blueprints are unlikely to work since the keys in them will simply be wrong for the current UI. If a query blueprint uses only library aliases, then it might continue to work after we update the library aliases.

- total rewrite of the blueprint alias library. we should take this opportunity to rewrite it to use interface keycodes as well and not have *any* keyboard keys. this will make the quickfort blueprint library immune to customized keybindings. this has always been a problem with quickfort, and we should solve it here before it becomes a bigger issue
- documentation in the alias guide about how to find the right keycode for the operation you need, test that they're correct, and in general, add warnings about *not* using directly keyboard symbols (e.g. letters) unless you're actually filling in a string field

Orders

Currently, generating orders from a blueprint is part of quickfort code. I'm thinking this should be moved to buildingplan so it can be used more generally. Plan a building? Get a manager order to build the pieces automatically. Buildingplan can be smarter about it than quickfort is, scanning for existing stock or in-progress manager orders and only adding a new order if needed. It would also be one fewer thing to have to do manually when applying blueprints. Orders for non-building (e.g. wheelbarrows and containers for stockpiles) could be done by default when applying the blueprint (disableable with a flag). then we can get rid of the "orders" quickfort command entirely.