Attempt to work-around bug #18637, where planning moves on planned recruits results in a crash (because get_unit() is null when move::init() is called).
This isn't a comprehensive fix because clicking on a planned recruit will still result in the usual display feedback for planning a move. The difference here is that attempting to place a planned move will result in nothing happening when the mouse button is clicked (as opposed to the assertion failure or crash which happens currently). It is better than nothing, I believe, unless there are negative side-effects of which I am unaware of.
As per the bug report, the ideal solution is to either get planned moves on planned recruits working properly, or disallow this movement altogether.
Check IDs match before re-using an existing fake_unit. IDs can be different in the situation described by bug #20299, where the user selects the next unit while planning a move.
Back-port of PR #523.
Bug report refers to a more thorough patch #3972 which seems to have never been accepted. All I'm trying to do here is add the file_exists check which fixes the hanging while minimising the changes needed.
(MSVC debug mode still fails due to a vector assertion failure (teams vector reference), which makes testing/debugging the editor difficult.)
If anyone feels like adding all the error messages/handling included from the patch, go right ahead.
This is an extension of #450 and a correction of #470. The sdl2 branch already contains a superset of the improvements made here and will eventually be merged into master, thus overriding this work. So only include these changes in the current 1.12.x release branch.
To ensure we don't have a repeat of the mistakes in #470 I tested the following combinations (mostly Windows, some in Linux):
letter (a, b, c, etc)
punctuation (;, ., etc)
function (F1, F2, F3, etc)
Shift+letter
Shift+punctuation
Shift+function
Ctrl+Return
Ctrl+Enter
Ctrl+j
Ctrl+m
Ctrl+function
Ctrl+`
Ctrl+Shift+2 (@ on US keyboards)
Ctrl+;
Ctrl+Shift+; (colon on US keyboards)
Ctrl+Tab
Ctrl+PrintScreen
Ctrl+Pause
Ctrl+Insert
Ctrl+Delete
Ctrl+Home
Ctrl+End
Ctrl+PageUp
Ctrl+PageDown
Ctrl+Alt
Ctrl+Ctrl
Ctrl+Space
Ctrl+Alt+Space
Ctrl+direction
Ctrl+Shift
Ctrl+CapsLock
Ctrl+NumLock
Ctrl+ScrollLock
Revision of notes from #470:
Instead of specifically checking for Ctrl+j and Ctrl+m, I now make this a general check: that letters should match their respective key codes. This will still cover the Ctrl+Return/Enter combination fixed in #450, but also some of the combinations noted by others testing that PR.
Ctrl+Tab was one combination noted to not work in Linux (though it did in Windows) as it was being mis-read as Ctrl+i. Ctrl+Tab will now work correctly in Linux.
Strangely, Ctrl+Scroll Lock and Ctrl+Pause (while working in Linux) were both being mis-read as Ctrl+c in Windows. This change will cover Ctrl+Scroll Lock but Ctrl+Pause will also be read as Ctrl+Scroll Lock, because of the key code SDL detects. Similarly, Ctrl+Num Lock becomes Ctrl+Pause instead. I don't think this can be resolved because the key code is simply being read incorrectly (this includes SDL 1.2 and SDL 2.0 in Windows).
Unfortunately, I cannot test whether there will be any improvement or regression in OS X.
With hot-key handling being rewritten for SDL2 this change may seem moot, but it will still improve things for the current 1.12 release. This change also resolves concerns some have had regarding the special-case nature of the Ctrl+j/Ctrl+m check previously used.
Otherwise we build a bogus "terrain/.png" file path and produce spurious
`error display: could not open image 'terrain/.png'` messages in stderr.
Although this is primarily an issue found with certain special overlay
terrains such as ^Xo (Impassable Overlay), this fix covers base terrains
as well.
This reverts commit 5bd79efa8b.
The patch turns out to break some hotkeys such as the command box (:,
which is shift+. on Latin American keyboards). The author suggests
focusing on the hotkey system rewrite that's part of the SDL 2 port
effort rather than trying to patch the old one on 1.12.
This is an extension of https://github.com/wesnoth/wesnoth/pull/450.
Instead of specifically checking for Ctrl+j and Ctrl+m, I now make this a general check: that letters should match their respective key codes. This will still cover the Ctrl+Return/Enter combination fixed in PR 450, but also some of the combinations noted in that PR.
Ctrl+Tab was one combination noted to not work in Linux (though it did in WindowS) as it was being mis-read as Ctrl+i. Ctrl+Tab will now work correctly in Linux.
Strangely, Ctrl+Scroll Lock and Ctrl+Pause (while working in Linux) were being mis-read as Ctrl+c in Windows. This change will cover this hot-key as well.
Unfortunately, I cannot test whether there will be any improvement or regression in OS X.
With hot-key handling being rewritten for SDL2 this change may seem moot, but it will still improve things for the current 1.12 release. This change also resolves concerns some have had regarding the special-case nature of the Ctrl+j/Ctrl+m check previously used.
File paths are recorded into the game preferences up to a (currently
hardcoded) limit of 6 and opening or saving maps adds or bumps existing
entries to the top. We may allow users to change the MRU limit in
Advanced Preferences in a later commit.
Adds two translatable strings.
In order to fit file paths in the menu without filling up the whole
screen sideways, we use only the file names for now. Because identical
file names could prove to be an actual issue later, I intend to look
into ellipsizing paths correctly in a later step.
(Note that I'm piggybacking on the crummy submenu support we already had
in the themable UI so that this can be safely backported to 1.12. It's
decidedly not optimal usability-wise, but it'll have to do for now.)
