Figure out hotkey-agnostic language for quickfort

[myk002]

The main problem is to figure out what to do about the changes in hotkeys. Up to now, you have specified what you want the blueprints to do by writing the hotkey sequence associated with that thing or action. This made it obvious what the meaning of the blueprint cell is. Also, in the original out-of-process quickfort, the sequences were actually played back verbatim as keystroke input.

Nowadays, all blueprint modes other than config and query are not keystroke based. Dig, build, place, zone, etc. all interact directly with memory structures and don't play back any keys. This means that the strings that identify things on blueprints are arbitrary and we can decide on a vocabulary that is independent of the in-game keystrokes. If we want to, that is.

Do we want to? If we stick with hotkey sequences, we have the advantages of sticking with quickfort precedent and having the sequences easily discoverable on the wiki (and in-game if the player stuck with the default keybindings).

However, those sequences may be confusing for those who have changed their DF keybindings. This wasn't as big a problem in the past since most people used the default keybindings, but the new keybinding scheme seems much more controversial and we may have greater variation in the future. Moreover, Toady may respond to complaints and change the default hotkeys again. We don't want to end up making old blueprints unusable every time default keybindings change!

Another complication is that in the new UI there are no hotkeys for individual stair shapes. Blueprints need to be defined tile by tile. Even if we use hotkeys to denote other things, we'd have to come up with something else to denote stairs.

What are the alternatives? Well, maybe it would help to define the ideal qualities first. We want a blueprint language to be:

• easy to read in a truncated grid (i.e. the contents of different cells should be easily distinguishable by the first few letters that show when you make all the columns very narrow in an online spreadsheet)
• robust against changing default and custom keybindings (so changes to the game config don't break existing blueprints)
• easy to remember what to write in a cell to get what you want

[ab9rf]

my feeling is that we just freeze the language in its current state, based as it is on the current default keybindings. if and when situations arise where the blueprint language fails to conform with default df keybindings, we note this in documentation (maybe with emphasis so readers will not fail to note)

we'll have to revisit the blueprint language whenever toady adds a new feature anyway, so we'll have to return to this from time to time

[lethosor]

I am inclined to agree, given the number of hotkeys that changed (or were removed entirely) in 50.x