This patch fixes the TODO comment in playersFinished and moves
all of the calls to handlers. The only reason for adding back the
function `handlePlayersFinished` is to prevent duplication in the "won"
and "defeated" message handlers. In the future, code to execute when
players finish in the future should exclusively be added by registering
new handlers, not by adding it to that function.
966727b52e made the player state an enum and introduced more descriptive
functions to achieve the same thing, but it seems they were forgotten to
be replaced in a few places, which this patch fixes.
If a new tutorial step has already been completed by the player it isn't
skipped, but instead shown with the continue button, so that the player
can manually switch to the next one. However, it wasn't well
communicated to the player that this was the case and why the continue
button was shown at the same time as the instruction. This patch adds a
hint "You have already done this." to explain the this to the player.
This allows the trigger scripts to combine consecutive tutorial steps
that only differ in the `panelData.text` property into a single one that
instead defines a `panelData.texts` array.
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.
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.
It looked ok as long as the window had a 16:9 aspect ratio, however
default window size is 4:3 which squishes the balcony.
Add a horizontal alignment support for background layers, which allows
to fix this issue for any aspect ratio.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
We can render the game only with shaders so we don't need to support
fixed function pipeline as a separate render path. We only need to know
when to warn a user.
Fixes#6244
This patch allows techs to optionally define a property "placeBelow"
specifying a combination of class requirements. The selection panel then
tries to place their research button below the training button whose
unit matches these classes -- if there is only and exactly one.
This is useful for techs only affecting a single type of unit: it e.g.
allows always placing the fishing nets research button below the fishing
boats training button.
To prevent duplicating information in "placeBelow" (e.g. from
"affects"), it can also be set to two magic values: "{AffectedUnit}" and
"{UnlockedUnit}". In practice, many techs use those, but class
combination remain useful for granular control in very specific cases.
Regarding tech pairs, as explained in a comment, their two research
buttons can now be placed in three different arrangements (with
descending preference):
1. Vertically below a single training button.
2. Horizontally below two adjacent training buttons.
3. Horizontally adjacent in the bottom row (below no training buttons).
Vertically in the third and fourth rows (below no training button) --
how it was previously -- is no longer done as it'd conflict with and
doesn't fit the new layout and the clear separation between "generic"
and "specific" techs.
Whenever a research button can't be placed in their preferred location
because it is already occupied, the code simply falls back to the default
position in the bottom row.
This patch also adds a new game option to hide the new small arrows above
the research buttons in order to give more experienced players who already
know the techs well the possibility to reduce visual clutter. By
default, the arrows are shown.
This patch renames the "pair" property of paired technologies to
"partOfPair" for clarity and in the pair parent packs the two techs
(previously "top" and "bottom") into an array called "pair".
This makes the hierarchy more clear in the code and pairs might not be
always placed vertically in the future.
Adjust function arguments to prevent errors when loading/rejoining a game with AI. These occurred due to 2f2cbb96bf not adding arguments for the state/playerID
Fixes: #9001
`this.events` is only valid during one turn. When it is used in the next
turnn it might be outdated. So it makes no sense to keep it alive untill
the next turn.
Previously, TreeSection was drawn before TrainerSection.
Reversing the order ensures TrainerSection layout is resolved first,
which fixes scroll state being computed against an incomplete
structree page render.
Fixes#8893
Instead of storing a single flat list of positions and data per
building, RallyPoint now stores them keyed by player ID. This lets
mutual allies independently set and display rally points on each
other's structures.
The GUI now allows selecting allied buildings with a rally point
and only shows the viewing player's own rally point data.
GuiInterface gets an OnUpdate handler to keep displayed positions
in sync when rally point targets move.
GetRallyPointCommands now takes raw position and data arrays instead
of a component reference. The network command field is also renamed
from "entities" to "structures".
Fixes#3115
getTotalQueueTime(queue) calculates total remaining
queue time of a production building.
getBuildingsSortedByQueueTime(entities), sorts building selection
by their queued training time and filter invalid entities
Removes the resource availability guard from the Training selection
panel onPress handler to align mouse interaction with hotkey behavior
The `closePageCallback` isn't forwarted to the function calling it. Now
it's possible again to continue a saved campaign.
The error was introduced in 76b6725272.
