Reassign 'Toggle mouse grab' to F3 to avoid conflicts with gameplay hotkeys
Unassign 'Show status bars' often toggled by mistake by new players and confused for a selection bug
Assign 'Bird eye view' to Shift+Tab
Use futures to spawn several threads that concurrently work through the
active range queries each turn instead of doing everything serially on
the main thread -- similar to how the pathfinder computes pathfinding
requests asynchronously. This significantly increases performance.
Note: It still can't run in parallel to the rest of the simulation update since
the range computations depend on the state of the simulation (like the
position of units).
When a script in "simulation/helpers/" contained an error. Files in
"simulation/components" aren't loaded. The return value of
`LoadDefaultScripts` indicated an error but was ignored. The simulation
still tried to start.
Now instead of returning a ignoreable error code the error is thrown. In
the common path the error is implicitly rethrown to the JS-function
which tried to start the game.
fixes: #8133
It's not permitted to pass a nullptr to the `app_hooks_update`. So a
reference should be used.
CppCheck says one shouldn't take pointer to a temporary.
'StatusName', 'ApplierTooltip' and 'ReceiverTooltip' are attributes of status
effects, which are defined in JSON files (and already extracted
correctly from there), not XMLs.
Add context and comment attributes to all translated XML elements in the
simulation that can specify any string -- unlike "Rank", which has to be
"Basic", "Advanced", or "Elite".
Most of them aren't used right now, but they can be in the
future and by mods, without touching the schemas again.
Fixes#8540
In the (common) case that the player controls all selected units or is
an observer, the 'Selection' and 'Command' panels were set up ahead and
then in the for loop again, which was wasteful.
There are currently 19 entity commands in total, but only the first 6
possible (depends on the active selection, e.g. patrolling isn't
possible if no units are selected) ones are ever displayed as buttons
(defined by g_SelectionPanels.Command.getMaxNumberOfItems) However,
when updating (once per turn or whenever the selection changes),
g_SelectionPanels.Command.getItems always called `getInfo` on all of
them, even though all data computed after the first 6 wasn't read or
used anywhere later. So, stopping immediately after the 6th and never
returning an array longer than 6 saves all of the dead time without
affecting the outcome in any way.
It's important to mention, that this issue isn't exclusive to the
'Command' selection panel: the getItems methods of the other panels can
also return an array longer than their getMaxNumbertOfItems value
(that's why they specify it in the first place). However, for the
command panel this happens for many common selections and seemingly to
by far the largest extent. For the other panels it happens much more
rarely, only for especially large and obscure selections, and even then
does not have nearly as big of an impact. So, modifying the other
getItems methods as well (to never return too many items) is probably
not worth it, and the more robust solution is to instead keep the
safeguard system of getMaxNumbertOfItems.
Commit 3eee3a444d added final keyword to
simulation classes but left virtual keywords in place.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
```
source/simulation2/components/CCmpRangeManager.cpp:1953:18: error: Out of bounds access in 'm_LosRevealAll[MAX_LOS_PLAYER_ID+1]', if 'm_LosRevealAll' size is 16 and 'MAX_LOS_PLAYER_ID+1' is 17 [containerOutOfBounds]
m_LosRevealAll[MAX_LOS_PLAYER_ID+1] = enabled;
^
source/simulation2/components/CCmpRangeManager.cpp:1967:21: error: Out of bounds access in 'm_LosRevealAll[MAX_LOS_PLAYER_ID+1]', if 'm_LosRevealAll' size is 16 and 'MAX_LOS_PLAYER_ID+1' is 17 [containerOutOfBounds]
if (m_LosRevealAll[MAX_LOS_PLAYER_ID+1] || player == -1)
^
```
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Currently we always choose the best device. But it's not always
desirable. A more safe approach is to use the default device (with
index 0). The only downside of that is if a user didn't adjust
settings then the game might run on an integrated GPU instead of a
discrete one. In the future it'll be solved by selecting GPU in
options: #8529Fixes#8455
While "Brogiacos" and "Tegesacos" fit in terms of meaning, they are only
reconstructed words, "Ambactos" on the other hand is attested and
actually historically relevant.
This fixes 7df7566d7c, which added
automatic switching off silhouettes in cinema mode while resetting the
value when leaving cinema mode. Reloading can only be done for a given
config namespace.
Fixes: #7552
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Now it's possible to destroy the old swapchain before creating a new
one. It might make the swapchain creation a bit slower but with a
lower memory peak.
Importantly, the word "Germans" is removed since it is prone to being
translated incorrectly and the other civ bonus descriptions don't
contain the civ's name either.
The names are in Proto-Germanic and mostly taken from Wiktionary.
They can be confirmed by directly searching the individual
Proto-Germanic terms online.
Champion Cavalry: "Aþalaridjô" (noble+rider)
Cavalry Spearman: "Gaizaridjô" (spear+rider)
Cavalry Javelineer: "Skeutaridjô" (quick+rider)
Worker: "Būraz" (dweller, farmer) -- deliberately decided against the most literal translation,
which would be "Arbijaz", because that seems to be more connected to serfdom and the unit
rather represents a generic commoner.
Infantry Swordsman: "Swerdamannaz" (sword+man)
Infantry Spearman: "Gaizamannaz" (spear+man)
Infantry Clubman: "Kulbawigô" (staff/club+warrior)
Infantry Javelineer: "Gaizawerpanaz" (spear/javelin+thrower)
Infantry Slinger: "Slingwanaz" (swinger/slinger)
Scout Ship: "Skeutabaitaz" (quick+boat)
Fishing Boat: "Fiskārijaz" (fisherman)
Fire Ship: "Brandabaitaz" (fire+boat)
Arrow Ship: "Harjaskipą" (army/war+ship)
Wagon: "Wagnaz" (direct translation)
Priest: "Gudjô" (direct translation)
Ram: "Rammabagmaz" (strong+tree/beam)
Trader: "Kaupô" (direct translation, also part of the word used for the market)
Merchant(ship): "Mangārī" (direct translation, very similar to "Kaupô")
The SpecificName tag is meant to contain the name in the civ's native
language, Proto-Germanic for the Germans.
"Kriegsschiff", "Übungsbereich" and "Stadttor" on the other hand are
modern German words.
Dunedan