Create key bindings for zones

[definability]

Make it possible to trigger the creation of specific zones using the keyboard. For example, zo for office, zm for meeting zone, and so on (z is the default key for zone type selection).

The game has key bindings for buildings but lacks hotkeys for zones. For example, bpr initiates a door spawn, and bfb initiates a bed placement. When the zones pop-up is active, users must use a mouse or trainers (memory hacks) to choose the zone to create; moreover, hotkeys are not locked in zone selection mode, which makes it trickier to implement from scratch.

The variables for the current pop-up window and zone types seem to be 4-byte integers and have constant addresses (at least in the Windows Classic version binary). The game interface reacts immediately when the values are changed in memory. Such behaviour makes this feature feasible to implement, but may be problematic to support because the address can change with any release.

I discovered DFHack/df-structures/symbols.xml, which contains a massive base of addresses. I suppose this may have been automatically created from RTTI. Maybe the addresses for the zone type choice are part of some entities that can be discovered using automatic search, and thus, they are possible to implement without manual overwrite on each game release.

Please share your thoughts on the possibility of implementation.

[SilasD]

Not an expert here. Possible, maybe?

Finding the addresses is pretty much a solved problem. They're all fields in giant objects, the objects themselves can be located fairly easily, the field layout doesn't change all that often, and there's automated tools that do a lot of the work.

For instance, you can tell if the game has the Zone popup open by testing if
df.global.game.main_interface.bottom_mode_selected == df.main_bottom_mode.type.ZONE.
Which is a mouthful, but that variable can be auto-located and that constant won't likely change.

This is implemented to the point that DFHack keeps track of 'focus strings' that tell you what mode the UI is in, and can even trigger callbacks when the UI changes to or from a specific state. When the Zone popup is open, the relevant focus string is dwarfmode/Zone.

I think trapping the o part of zo might be the sticking point. Maybe an invisible overlay could be created when the Zone popup is open, that could trap keys and change the right variable? I don't really know how to use the DFHack overlay system.

The target variable looks like it might be df.global.game.main_interface.civzone.adding_new_type, but changing that from e.g. -1 to 93 (Office) does not change to the "click in the play area to paint the zone" popup.

In general, changing UI state is a huge, huge problem for DFHack. As in, we generally can't do it. That may kill this idea right there.

Maybe the best we could do is try to feed a mouse-click to the exact right screen location? That's really, really not a good way.

[definability]

Thank you for the clues!

Regarding changing the zone choice menu to the zone painting mode: Right after the ZONE constant, there is an enumeration item (constant) ZONE_PAINT, which activates the zone drawing. Thus, the key binding activation code should also change it, not only zone_name:

function on_initiate_zone(zone_type)
  if df.global.game.main_interface.bottom_mode_selected == df.main_bottom_mode_type.ZONE then
    df.global.game.main_interface.bottom_mode_selected = df.main_bottom_mode_type.ZONE_PAINT
    df.global.game.main_interface.civzone.adding_new_type = zone_type
  end
end

Are there documentation parts providing information regarding these enumerations, or should I lurk through the source code and ask people? 😅

Another thing is to ensure that the hotkeys are active only when the ZONE pop-up is active. Potentially, I would like to load the plugin only when ZONE is active, and unload it in the other cases.

Next, I see two solutions:

1. Assign unused hotkeys so they do not interfere with the other bindings. For example, Ctrl-o for offices, Ctrl-b for bedrooms, and so on. Considering the DFHack ecosystem, this may also be challenging.
2. Find out how the other pop-ups lock the hotkeys. For example, df.main_bottom_mode.type.BUILDING blocks the other hotkeys; digging and gathering also do (but they belong to other enumerations, not main_bottom_mode), to get rid of at least some default hotkeys like b, n, o, p, and so on.

[definability]

To conclude this discussion.

I created a script zone-bindings. I am not sure whether it is worth adding to the official repository, so I leave the link here.
Thanks, @SilasD, again for his help on the main script checks.
Another puzzle piece was using keybinding with dwarfmode/Zone context, and keep in mind that all derivative contexts are also whitelisted (only prefix is checked), so the script must check the precise context anyway. I described the use in the script documentation