Adds baseRange parameter to parabolic queries for combined
2D + parabolic detection. StandGround and Chase stances now
use attack range (parabolic) with vision as baseRange, allowing
units to attack enemies visible through friendly vision.
Buildings benefit as well via BuildingAI.
Introduce CanEverReachTarget in the Attack component to check whether
a target is geometrically reachable at all, accounting for height
offsets and turreted units inside buildings.
For non-parabolic attacks (e.g. melee), a simple 3D distance check
from the closest approach point is used.
For parabolic attacks (e.g. ranged), the parabolic range formula
is used to determine if the height difference is surmountable
from the closest horizontal distance to the target.
Add GetClosestApproachDistanceToTurretPoint to TurretHolder
to estimate the minimum horizontal distance to a turret point,
using its local offset and the holder's obstruction size.
Passable buildings are not considered obstacles.
Fixes units on the ground trying to attack unreachable units on walls
or towers when the projectile's arc cannot reach the required height.
Wraps RangeManager.GetEffectiveParabolicRange for unified range
resolution. Maintains symmetry with GetRange(), improves readability,
and consistently translates NEVER_IN_RANGE.
Simplifies callers in UnitAI and Attack.
StandGround units now use parabolic range queries to detect enemies,
accounting for terrain elevation and height offsets. This ensures
units on hills or when 'turreted', can detect enemies
that are in parabolic range but outside flat range.
Previously, StandGround detection used flat circular queries,
causing units to miss enemies in their elevation-buffed range.
Other stances are unaffected since they chase targets anyway.
It was removed in dee2b73c7d since it wasn't noticed that it referred to
the number in the top panel. Adding the number should make this more
clear. The color is only applied to the number instead of the whole line
so that it's harder to mistake it with just some fancy formatting.
Fixes: #7851
Since #7786, the GUI tick completed normally after calling
`closePageCallback` instead of being cancelled like previously. Since
`Engine.EndGame` deletes the internal `g_Game` pointer, every Engine call
after it that tried to access `g_Game` caused a segfault.
This patch solves it by moving `Engine.EndGame` to the very end, right
before closing the session page.
In order to follow the convention that only functions directly closing
the page are called `closePageCallback`, that function is in turn
renamed to `closeSession`. Additionally, this allows only resolving
the promise with a bool (`showSummary`) and then only calling
`getNextPageOpenRequest` at the end of `init` for reasons of simplicity.
This patch adds a new type of tutorial steps called "GUI explanation",
with a corresponding GUI panel. The purpose of it is to explain what a
certain GUI element does. To make use of it the trigger script has to
specify the target GUI object's name as well as the side on which to
place the explanation panel relative to the target itself. The panel
then highlights the target object by fading everything else out with
black and also uses an arrow to point to it. Whilever the target GUI
object is hidden, the panel hides the background fade too and shows a
warning message.
Unlike for the other steps, the TutorialManager does not hide the
previously active panel when showing a GUI explanation, but instead
only disables it, since it could contain relevant information and the
GUI explanation panel is visibly placed "above" all other panels (in the
Z axis).
This patch introduces two functions `CompleteTutorial` and
`FailTutorial` for the tutorial steps to call. They can pass a
message to it to be shown on the victory/defeat screen.
`CompleteTutorial` is also called automatically when all steps are
finished, which resolves#8583 and prevents it from happening in the
future.
`FailTutorial` isn't used anywhere at the moment, but it'll be useful
for the future.
Fixes#8583
This patch allows steps to override the default hint caption and button
caption set by the PanelControlSection class. This allows them to better
communicate what the player is supposed to do, e.g. don't show "Follow
the instructions" if the player is only supposed to wait.
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.
