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.
Add registerGlobalGuiPageHotkeys() to
common/functions_utility.js to selectively register
GUI page hotkeys
Allow active GUI pages to close using their corresponding hotkey
Move page_hotkeys.xml from gui/hotkeys/ to gui/
Update page_hotkeys.xml references in MainMenuItems and MenuButtons
Add default tipScrolling fallback in TipsPage when no initData is provided
All shaders were selected by context (set of defines) which increases
the number of needed permutations. For example: we don't need to know
about shadows when rendering silhouettes.
We were unnecessary passing all combinations of our scene shader context
even if we don't need it as for shadows and silhouettes for terrain
rendering. Since we only need to draw a solid color.
When the returned value of the compare function is `0` the order is
preserved. Before the sort, the order between joining clients and
non-joining clients differ.
Additionally sorting by name should make the order consintent.
The AI only noticed for changes to `isIdleConfirmed`. That is done to
avoid recursions and don't send to many messages. But when the AI is
deserialized it get's `isIdle` from the simulation. Leading to an OOS.
When the returned value of the compare function is `0` the order is
preserved. Before the sort, the order between joining clients and
non-joining clients differ.
Now everything important (which is used later on) is included in the
comparison. If still `0` is returned it's not importent which element is
taken.
Another solution would be to have one array per category.
The metadata where written every the turn of deserialization. When on
the non rejoining client it was only written when that AI makes a turn
and handles the events.
On a rejoined client the data isn't the same anymore. But it's equal.
Likely this is because the data isn't aquired at the same turn.
This could also be solved more generally by copying all data which is
pushed to the AI. Or by using the same serializer for AI as for the rest
of the simulation.
Clients which didn't late-join only get a change to `uptadeTerritories`
when the ai playes a turn. When joining clients do it at the turn when
they deserialize the ai they might be ahead of the others. That would
lead to an out of sync.
`entityObj` is not available on clients which just have rejoined. As not
all clients have access to it the data shouldn't be used for anything
elaborate.
phosit