All functions had a `LDR_` prefix. The prefix is removed.
Functions and globals which are only used in Loader.cpp are now
contained in an anonymous namespace.
There was a comment implying that `wchar_t*` is more iteroperable then
`std::wstring`. When there is no allocator `std::wstring` won't work,
sure. But when there is no allocator other things in Pyrogenisis will
also not work.
And for the progress there was just no reason to use a return parameter.
Commit b90280855f added support for
multiplayer saved games changing the signature of StartNetworkHost
without updating all callers.
Fixes: #7684
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
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
phosit