[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Marko Lindqvist]

Update of patch #3756 (project freeciv):

  Status: In Progress => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #10:

Handled at hostedredmine: https://www.hostedredmine.com/issues/657403

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Jacob Nevins]

Additional Item Attachment, patch #3756 (project freeciv):

File name: trunk-extra-ui-prototype-r32218.mbox Size:33 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Jacob Nevins]

Additional Item Attachment, patch #3756 (project freeciv):

File name: trunk-extra-ui-prototype-4.mbox Size:33 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Jacob Nevins]

Follow-up Comment #9, patch #3756 (project freeciv):

Rebased on top of current trunk + patch #6475.
No change to functionality.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Jacob Nevins]

Additional Item Attachment, patch #3756 (project freeciv):

File name: trunk-extra-ui-prototype-ter.mbox Size:33 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Jacob Nevins]

Update of patch #3756 (project freeciv):

  Depends on: => patch #6475


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Marko Lindqvist]

Update of patch #3756 (project freeciv):

 Planned Release:   2.6.0 = 3.0.0  

___

Follow-up Comment #8:

It seems the discussion about going forward with this in 3.0 was never
recorded to this ticket.

___

Reply to this item at:

  http://gna.org/patch/?3756

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Jacob Nevins]

Follow-up Comment #6, patch #3756 (project freeciv):

Rebased, and patches now in other tickets removed from stack

Is anyone likely to object if I proceed with this idea?

(file #22736)
___

Additional Item Attachment:

File name: trunk-extra-ui-prototype-bis.patch Size:36 KB


___

Reply to this item at:

  http://gna.org/patch/?3756

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Marko Lindqvist]

Follow-up Comment #7, patch #3756 (project freeciv):

 Is anyone likely to object if I proceed with this idea?

I'm still a bit uncertain, but I'm yet to come up with counter-proposal, and
I'm unlikely to think this a lot before S2_6 has been safely branched.

___

Reply to this item at:

  http://gna.org/patch/?3756

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Jacob Nevins]

Update of patch #3756 (project freeciv):

  Status:None = In Progress
 Assigned to:None = jtn
 Planned Release: = 2.6.0  

___

Follow-up 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
http://svn.gna.org/viewcvs/freeciv?revision=1351view=revision); 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)
___

Additional Item Attachment:

File name: trunk-extra-ui-prototype.mbox  Size:43 KB


___

Reply to this item at:

  http://gna.org/patch/?3756

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Marko Lindqvist]

Follow-up Comment #4, patch #3756 (project freeciv):

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.

___

Reply to this item at:

  http://gna.org/patch/?3756

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Emmet Hikory]

Follow-up Comment #3, patch #3756 (project freeciv):

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.

___

Reply to this item at:

  http://gna.org/patch/?3756

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Marko Lindqvist]

Follow-up Comment #1, patch #3756 (project freeciv):

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

___

Reply to this item at:

  http://gna.org/patch/?3756

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Marko Lindqvist]

Follow-up Comment #2, patch #3756 (project freeciv):

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

___

Reply to this item at:

  http://gna.org/patch/?3756

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3756] RFC: UI for building generic roads, bases, etc

[Jacob Nevins]

URL:
  http://gna.org/patch/?3756

 Summary: RFC: UI for building generic roads, bases, etc
 Project: Freeciv
Submitted by: jtn
Submitted on: Tue Feb 26 23:46:55 2013
Category: client
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

(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.)




___

Reply to this item at: