Re: [Wesnoth-dev] issues document

[ott]

On Fri, Sep 16, 2005 at 07:47:02PM -0500, David White wrote:
> I really think we should consider resolving this by choosing different 
> shortcuts. Perhaps ctrl+c for command and ctrl+f for 'find' (if they're 
> not already used).

Ctrl/Cmd-f would be nice for find, and would probably tie in with
existing UI guidelines.  This is currently used for fullscreen, which
would need another hotkey.  Ctrl/Cmd-c is hardcoded (for copy) elsewhere
in the code, although Ctrl/Cmd-a and Ctrl/Cmd-v both have two different,
context dependent meanings, so this is probably OK.

What about 1-7, which are hardcoded (and therefore broken for French
keyboards, where 1-7 are shifted)?  And Alt-Space for endturn, which
conflicts with some window managers?

Here is the summary of keys currently defined in game.cfg and several
others which I recall from the code; use a fixed width typeface to see
the table properly.  For Mac OS X, for Ctrl substitute Cmd, and for Alt
substitute Option.

       a b c d e f g h i j k l m n o p q r s t u v w x y z / ; F1 ' ' 1-7
       - - + + - - - - - - - + + + - - - + - + + - - + - + + -  +  +   *
Shift  - - - - - - - - - - - - + + - - - $ - - - - - - - - - +  -  +   -
Ctrl   2 + * + * + + 0 - + + - / + + + + + - + * 2 0 0 - - - -  -  -   -
Alt    - - - - - - - - - - + + + - - - - + + - - - - - - - - -  -  +   -

-: not used
+: defined hotkey
$: Cmd+Shift
*: not a hotkey but hardcoded elsewhere
2: both hotkey and hardcoded (context dependent)
0: should be defined according to (at least some) human interface guidelines
/: should be defined according to HIG, but is used for a hotkey

> >14409: broken user MP map pack stops MP being playable
> I have resolved this. :)
> >11797: new campaign images are not shown until the game is restarted
> This was probably the worst outstanding issue, so I resolved it.

Great!

> >10962: a unit does not level up in a replay if that is the last action
> Probably one of the nastiest outstanding bugs.

Alas.

> >11364: unit description of modified unit shows unmodified stats
> I think this is really a WAD too. "Unit Description" goes to the help 
> page for that type of unit. It doesn't document any characteristics 
> specific to this instance of the unit, such as traits, current 
> hitpoints, etc. At the worst, one could say that we should rename from 
> "Unit Description" to something more like "Unit Help".

Have modified, see the ISSUES file in CVS.

> >13313: subdirectories are not shown in save and load dialogs
> This also is a WAD/feature enhancement request. Basically I think WADs 
> like this should perhaps go in the document, but in a different section 
> to genuine issues.

Ditto.

> >13391: at night, it can be difficult to distinguish selected castle hexes
> If an artist wants to work at it, they could try to fix this before release.

I think this was actually caused by a layering issue.  Ayin rejigged
the graphics layering to fix the problem with trees obscuring the hex
mouseover info, can someone actually try to reproduce this issue?

> >13895: in Northern Outpost one can undo searching the villages
> If this is considered a bug, I think Turin should be able to fix it 
> without too much trouble. Just make it so moving into a village causes a 
> trivial event, and it will disallow undoing.

Unfortunately, Turin has stated not having time to fix this until
after 1.0.

The code in Crossroads precomputes the random village events and sets
up the events at the beginning of the scenario, using the "[event]
name=moveto" construction.  This combination seems to get around this
issue.  However, Turin uses the "[event] name=capture" construction
with random numbers generated on the fly as villages are flagged, which
seems to avoid being flagged as non-undoable.  I can't follow exactly why
this is, but one way to work around this would probably be to add a new
[disallow_undo] tag and use this in the scenario.  This tag would be a
counterpart to the existing [allow_undo] tag.  This is about two lines
of code.  An alternative would be to review and revise which events are
regarded as non-undoable.

> I think caches are alot like random numbers: people are suspicious of 
> them, and when things go wrong, the first thing they blame is bad 
> caching. I would have to unnecessarily inflame such fears by putting a 
> note about it in our issues document unless we are sure this really does 
> occur.

Good point, removed.

-- address@hidden