This patch adds a new tutorial step type and corresponding tutorial
panel labelled "info". It is intended to display steps whose purpose it
is to explain something to the player and give tips -- rather than
just giving instructions and telling the player what to do, like the
instruction panel does.
Also, it can show several related steps at once. To do that, the first
step has to set the 'appendable' flag to true and can also define a
title; then the succeeding steps can then set the 'appendToPrevious'
flag to true in order to do exactly that.
Note: 'info'-type tutorial steps are still supposed to be able to define
triggers, switch to the next step on their own and hide the continue
button on the info panel, to teach the topic interactively, e.g.
"Select a unit by left-clicking on it."
In order to prevent code duplication between `InfoPanel` and
`InstructionPanel` a generic superclass `TutorialPanel` is introduced,
which manages the text, hint, and button objects.
The idea is to add different types of panels to the tutorial in the
future. And the only texts that players might read multiple times are
tips or explanations, which the plan is to display on an entirely
separate panel anyway.
Move the code that checks whether a player command is a "continue
tutorial" into a separate method, so that it never overrides the player
command action of the active tutorial step. This could previously
happen if a step had the showContinueButton flag was set to true (and
a OnPlayerCommand method defined).
Make the naming consistent with e.g. the Triggers Demo map
Remove the "On" at the start, since it's otherwise used for message
handlers, and replace "Trigger" at the end with "Action", since that
more accurately describes what it is.
- Remove the delay functionality from the tutorial. It was unused and
that for a reason. Switching to the next step after a fixed amount of
time is never wanted. It was only used to force-show the ready button
in one case, but a designated bool communicates the purpose better.
- Rename the "ready" button to "continue" as it fits better.
- Rename "leave" to "isLast" as it's more descriptive.
- Rename the "warning" object of the instruction panel to "hint" as it's
not always display warnings, and move its captions to the class
prototype like the coding conventions state.
- Simplify the logic in NextStep a bit to make it more readable.
This patch doesn't add any new functionality and keeps the introductory
tutorial and economy walkthrough as they are. Instead, it rearranges some
code to enable easily adding different types of tutorial steps in the
future. The idea is for each type to be displayed on a different panel
and for the TutorialManager to switch back and forth between them, and
to handle and translate the received messages from the simulation and
pass them along to the active panel. Currently, there are only
"instruction"-type steps, which are handled by the InstructionPanel in
the GUI. But new ones can be added in the future, like information boxes
or bigger objectives.
While it's currently the case everywhere, tutorial "steps" don't
necessarily have to be goals, they could be stuff like tips or info too
in general, if different types of "steps" are added in the future.
WX may still generate mouse events after calling CVideoMode::Shutdown(),
so don't create SDL events triggering assertions.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
If we catch the signal we'd have to communicate that we terminated by
signal, which might depend on shell. There is also the issue of various
dialogs blocking regular quit which we don't want, so that would need
extra work as well.
As such just let the SIGINT/SIGTERM do there default action and forgo
cleanup and let the OS handle it.
Fixes: #198
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Add a fullscreen toggle to the View menu and with a global hotkey,
reusing the default one from the main game.
Unlike the current implementation this one doesn't need the game canvas
to be focused and also works on GTK.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Commit fe192fe58f made it possible for
events to properly propagate to the top window. As on Windows Enter is
also used for navigation, i.e. used to trigger the dialogs default action,
which in our case seems to be quit.
Tell the wxSpinCtrl to fire wxEVT_TEXT_ENTER instead and handle it.
The wxCommandEvent wxEVT_TEXT_ENTER doesn't carry the value, so need to
use dynamic event binding (which is preferred way anyway).
Also show the numPlayerSpinner as a spinner instead of a text field to
match visuals to actual behaviour.
Fixes: #9026
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Use dynamic event bindings allowing to bind all events in all sort of
ways. Addionally no need for subclassing wx widgets.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
The functions were defined on the `Headquarters` prototype. But not all
functions are needed outside of "startingStrategy.js". Also doing it
this way, "startingStrategy.js" and "headquarters.js" had to mutually
import each other.
This adds support for the compilcommands action, which allows to improve
the cppcheck workflow and is a requirement for include-what-you-use.
Also disable unused dependencies like is done for macOS.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
In case of incompatible mods listed on the command line we can't launch
the mod selector from Atlas. Instead list the offending mods and launch
with the default mods.
Fixes: #8852
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Otherwise we might try to render a view when half the infrastructure is
already taken down, which results in segfaults or asserts.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
On request by @nifa add a checked menu item to View menu to set birds eye view.
When game view is focused, the focus which it hogs almost always, then
'B' doesn't propagate properly so use Ctrl+B instead in line with other
main menu shortcuts.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
We have GL_KHR_debug for proper error handling. ogl_WarnIfError isn't
really useful since it doesn't provide per-call granularity and requires
recompilation. So if it'll be really needed we can wrap all GL calls
into a macro like GL_CALL.
Vantha