patchFreeciv - Patches: patch #3756, RFC: UI for building generic...

Show feedback again

patch #3756: RFC: UI for building generic roads, bases, etc

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Tue 26 Feb 2013 11:46:55 PM UTC  
Category: clientPriority: 5 - Normal
Status: In ProgressPrivacy: Public
Assigned to: Jacob Nevins <jtn>Open/Closed: Open
Planned Release: 2.6.0

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Sun 31 Aug 2014 01:12:46 PM UTC, comment #5:

Here is a very rough prototype of this feature for trunk. I'd be very interested what people think.

Major restrictions of this prototype:

  • Gtk2 only (and other clients are probably broken).
  • Distinction between fortress/airbase UI is lost (both Shift+F/E and menu items do the same thing).
    • If we want to keep this then the distinction has to become an extra_cause, I think.
  • Only covers extra creation, not removal (pollution/pillage etc).
  • Not very discoverable (menu items don't list "R, 3" style shortcuts -- and it doesn't like like GtkAccelLabel can be abused to do so)
  • Pop-up obscures view (just like caravan/diplomat dialog).
    • I think correct fix is to find a solution for all these "choice_dialogs" (maybe an option to put it in the unit display area of the main window? Would only work for large displays)

Discovered consequences of this design:

  • Currently you can use non-keypad number keys to move units (added in r1351); with this design, you won't be able to do that any more (nor can you use keypad to choose extras).
  • With multiple units selected, and "Mine" activity, where some units can build extras and others convert terrain, need to decide how to present this. I've brought conversion into the pop-up menu (special key "0" => mine/irrigation can only cause 9 extras each)
  • Current version complains if you define more extras in ruleset than there are keys available. Alternative is that these are only reachable from menus. (The latter will probably be necessary to enable pillage selection to move to this system, as otherwise it'll likely have >10 options.)

Ways to test without changing rulesets:

  • classic ruleset: Since fortress/airbase are merged, arrange to have Construction+Radio and press Shift+F or Shift+E on suitable unit/terrain.
  • classic ruleset: Select multiple units on different terrains where one has mine extra and other has conversion (e.g. Forest, Hills), press M.
  • alien ruleset: Native Engineer on radiating terrain with Strong Resistance known, press R (choice of Road and Tunnel).

I would have liked to get this in 2.5, but the extra rework on trunk makes it sufficiently much easier that I think it's only going to appear in 2.6 at the earliest. So rulesets with lots of choices of roads won't really be practical in 2.5.

(file #21962)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 07 Sep 2013 09:21:34 AM UTC, comment #4:

UI changes are out of scope of my current gen-extras project. Here is how things should work after gen-extras, from which future UI-projects should pick up.

Extras have "causes" defined. For example any extra with cause "Pollution" can result from city pollution, "Fallout" can result from nuclear explosion. Causes are used for the UI too so that instead of generic "User request" cause there's separate causes "Irrigation" and "Mine" defined. Pressing 'I' will then select extra of cause "Irrigation" to be built. User even hasn't control over what exact extra will be selected (unless we add menus for irrigations and mines like we have for roads) but next_extra_for_tile() is used.

Marko Lindqvist <cazfi>
Project Administrator
Mon 08 Apr 2013 07:15:43 AM UTC, comment #3:

Could some of this be integrated with the concept in patch #2721? Provide, say, 5 keystrokes for players to allocate (e.g. EFIMR), which the ruleset author would then define as different types in the ruleset and provide test labels for use in menus, etc. Depending on the nature of the ruleset, the author would presumably take care to to ensure that the same keystroke was unlikely to do two different things at the same time (by use of a catch-all type="Other" which had been assigned no keystroke). Players needing to build something other than the set of defaults would need to resort to the menus. Shift-keystroke should presumably imply connect-with (connect-with-base seems odd, unless you consider someone attempting to build the great wall, or a ruleset that has implemented mining or irrigation as bases).

So, if I have a complex set of extras, I presumably have a reasonably small number of them that would be sensibly appropriate as a next step, and could overload keystrokes in cases where one depended upon another (e.g. Watchtower, Fortification, Outpost, Base or Track, Road, Highway, Maglev or Irrigation, Farmland). If I have specialised extras for certain circumstances, I should probably be constraining that in the definitions: e.g. Derrick/Pit Mine/Strip Mine/Gold Mine all provide "mine" like effects, but presumably have different conditions under which they are the appropriate sort of mine, so I should do something like not allow Derrick where there is no Oil resource; not allow pit mine on terrains that aren't hill/mountain or places that have no gold; only allow Gold Mine on gold; and only allow strip mine on desert/glacier where there is no Oil.

For the previously mentioned case of Tower/Force Fortress: is it worth having extras have an obsoleted_by concept? I don't think the reqs should enforce that, as then all the old Towers won't meet reqs, and may not survive some operations (like terrain transform), but I agree that it would be nice to be able to indicate that outdated extras should no longer be built. Alternately, perhaps there could be some other sort of overloading: if there are two kinds of Canal, one permitted by adjacent River and one permitted by adjacent Oceanic, it would be nice to be able to specify a preference for the correct one, even if neither is truly obsolete. Maybe a "prefer" vector that indicates that all extras listed there should be built in preference to the one containing the vector when a build request is made?

For the extra special case, the menus are likely sufficient, and I know I'd be happier with single-keystroke orders in the simple case than more complex ones: in the event I need a menu quickly, having keyboard access to the menu seems better than having a popup potentially obscuring vision of the area under consideration.

Emmet Hikory <persia>
Project Member
Wed 27 Feb 2013 08:32:32 PM UTC, comment #2:

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?)

Marko Lindqvist <cazfi>
Project Administrator
Wed 27 Feb 2013 09:53:27 AM UTC, comment #1:

I'll give you one more challenge: It would be great if you can incorporate to your design support (probably controlled by ruleset author) for some automatic decisions even when the keypress would otherwise seem ambiguous.
For instance in the alien ruleset it should always build "Tower" if both "Tower" and "Force Fortress" are possible, as former is improved version of the latter. Currently this is achieved by ordering them in the ruleset so that "Tower" has preference over "Force Fortress" (yes, I've defined and documented (I remember writing it somewhere, but cannot remember where - at worst case to old forums) the base building keys 'f' and 'e' to behave like that so that ruleset authors can rely on this behavior).

Marko Lindqvist <cazfi>
Project Administrator
Tue 26 Feb 2013 11:46:55 PM UTC, original submission:

(Updated from a [ 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.)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #21962:  trunk-extra-ui-prototype.mbox added by jtn (44kB - application/mbox - trunk r26150)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 31 Aug 2014 01:12:46 PM UTCjtnAttached File-=>Added trunk-extra-ui-prototype.mbox, #21962
      StatusNone=>In Progress
      Assigned toNone=>jtn
      Planned Release=>2.6.0
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup