What about removal of the certain kind of extras? Will the p)illage to remain as it is now, to popup list of pillageable targets when pillageselect is enabled, and to automatically select target when not. What about cleaning of pollution or fallout? (btw. what's the current behavior if tile has both pollution and fallout?)

(Updated from a [http://mail.gna.org/public/freeciv-dev/2012-02/msg00224.html post to freeciv-dev in Feb 2012.)

We now allow rulesets to define arbitrary sets of bases, and from 2.5, roads; we're heading towards all tile "extras" being handled the same way (see comments in patch #2951). However, we only have a fixed set of keystrokes available in the UI, which is going to be an obstacle to ruleset authors making use of this.

For bases, we fudged this for bases with fortress-like / Type A ("F") and airbase-like / Type B ("E"), assigned in the ruleset, but if we're introducing the same generality to much more frequently built infrastructure like roads, we need a better solution, I think.

On the one hand, we don't want to restrict rulesets to having at most one valid road-like activity in a given situation (as with the default rulesets) -- I think ruleset authors should have the freedom to have a unit that can build any of five different road types on a given tile at a given time, if they want. Nor should rulesets be penalised by forcing players to go through menus to select activities if the ruleset differs too much from a traditional one -- activities should always be keyboard-selectable.

On the other hand, available keystrokes are a scarce resource, so we probably can't give ruleset authors free rein over the entire keyboard -- we need the freedom to assign new keystrokes in future (for activities like "convert", or for out-of-game actions). I suspect we'll have to limit all these activities to using R/I/M/F/E.

Here's a sketch of a UI design to deal with this:

• each activity gets a keystroke specified in the ruleset from the limited pool
• each activity within the same keystroke group gets assigned a unique number from 0 to 9 (by the server, or maybe the ruleset)
• if a keystroke is ambiguous -- say, "R" is for both Road and, er, Cycle-path -- then the player can type "R" followed by "1" for Road and "R", "2" for Cycle-path
• the game pops up a little menu after "R" is pressed listing "R,1: Road, R,2: Cycle-path" to remind/introduce the mappings; this goes away when a number key (or Esc) is pressed
• the game tries to spot cases where the keystroke is unambiguous (like today's Road / Railroad -- only one is ever valid, at least for a single unit or units on the same tile) and enacts the relevant activity immediately on pressing "R" (so simple rulesets don't get the penalty of the multi-level selection system)
• keystrokes "0" through "9" do nothing if typed outside of activity selection (so if you type "R,1" where Road was the only option, you end up with what you wanted -- you don't have to second-guess whether you're about to press an ambiguous key)

This satisfies the following criteria:

• Can have lots of activities (up to 10 per keystroke -- still an arbitrary limit, but a much bigger one)
• Keystrokes for a given ruleset are discoverable (through the menu system, or the popup when you press "R")
• But experienced players don't need to use the menus, and keystrokes for a given ruleset can be learned and communicated ("R,1" always means the same thing)

One of the trickier parts of the above system will be the logic to spot unambiguous situations. However, it doesn't matter if it's not perfect.

Would also need to account for "connect-with-X", but that seems do-able as an extension to the above.

The other awkwardness with bringing the existing irrigation and mines into this system is the terrain conversions that the "I" and "M" keystrokes can trigger (e.g., "mining" grassland to forest). So, terrain conversions would need to be pulled into the above keystroke system, or whatever else anyone suggests.

With the above system, there would be no need to restrict given keystrokes to "activity classes" -- R wouldn't have to be only for roads (although ruleset authors may choose to do it that way). That would allow the I/M keys to retain their current behaviour in the standard rulesets (and probably add "O" to the pool of available keystrokes).

(This idea should probably be considered in combination with the ideas in patch #3713 and bug #16905 -- particularly the ideas of non-focus-stealing popups during keyboard action selection, and entering long strings of orders. But there's no particular reason their implementation would have to happen all at the same time, I think.)