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.
The functions to set them explicitly are removed. This makes the
interface of `CSimulation2` smaller.
Also serializationtest and rejointest can't be active at the same time.
Add a warning about that and use a `std::variant`.
The test takes about 0.5s in release build and about 2s in debug build,
hardly qualifying as slow. As such enable it.
About the noise, it's of little interest anyway so don't spam.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
The removal of the VFS cache in 89e339dd16
meant there is no longer a user. As such also clean out the generic
parts with the Landlord and a LRU policies.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Bumping the minimum version of macOS to 10.15 for spidermonky [1] also
allows us to use std::filesystem instead of boosts implementation.
[1] f14a98e26f
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
In >=wxWidgets-3.3 there is a new static check for literal message
ids[1] so that xgettext would reliable work to extract strings to
translate. As we don't translate Atlas at all nor use xgettext just
disable the check to allow building against >=wxWidgets-3.3.
[1] https://wxwidgets.org/help/msgid-literals/
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
It's not possible to format warnings. "a hotkey" is used instead.
Also when the hoplite icon is pressed, without using batches, the
warning doesn't restate that the hopplite should be pressed.
Vantha