The xmlvalidator logic is only used by the checkrefs.py script, so this
moves it to the same directory to have it co-located and avoid having to
modify sys.path to import it.
By default ruff excludes all files in directories named "dist" from
linting (https://docs.astral.sh/ruff/settings/#exclude). This caused the
Python scripts in `source/tools/dist/` to not get linted. This commit
fixes that and adjusts their style to fit our ruff rules.
Add checks for sprites, styles, scrollbars, tooltips, and colors.
And too for entire objects referenced by the "use_object" attribute.
(even though that is currently unused)
The UPnP implementation included a combination of two subtle bugs, which
resulted in failure to create port forwardings every time after the
first one.
When using UPnP, the internet gateway to create the port forwardings at
needs to discovered. As that takes a while, the its root descriptor URL
was supposed to be cached after successful discovery in the user config
in "network.upnprootdescurl". However, instead of caching the root
descriptor URL, the control URL got cached. That caused following
requests to the root descriptor URL to fail, as they ended up at the
control URL instead. As such requests might also fail when the network
topology changed, the code was supposed to fall back to discovering the
internet gateway again when the cached one didn't work. However, due to
the inner workings of miniupnpc the request using the cached root
descriptor URL didn't result in an error, so the new discovery was never
triggered. As the wrong value was persisted in the user config there was
also no way to get out of this situation again.
This commit fixes both of these bugs.
As far as I can tell these bugs existed since the introduction of the
caching of the root descriptor URL in 0ba25e9968, which means creating
port forwardings using UPnP has been broken since Alpha 15.
When adding a port forwarding via UPnP, pyrogenesis first needs to
discover the internet gateway to create the forwarding at. To do so, it
utilizes miniupnpc to send an SSDP request and waits 10 seconds until it
processes the responses and continues to add the port forwarding.
As that happens asynchronously it means if players hosting games rely on
UPnP for port forwarding and if their pyrogenesis instance doesn't have
the address of their internet gateway cached, it takes more than 10
seconds after starting to host a game, before players can join. However,
waiting for 10 seconds is completely unnecessary, because the internet
gateway responds immediately to the SSDP request. Therefore, this commit
reduces the time to wait for responses from 10 seconds to 2 seconds,
which is the timeout miniupnpc uses internally as well, when discovering
internet gateways.
Up to know the UPnP logic ignored the port a user was hosting a game on
and always added a port forwarding for the default port UDP 20595. This
commit fixes that, so a port forwarding is added for the actual port a
game is hosted on.
As it turns out we don't need that special logic for handling the "long"
locale properly and everything continues to work as before without it.
The only difference is that the number format not being the one from
en_us anymore when using the "long" locale, but the one of the
system-wide configured language, which should be an even better user
experience than before.
The debug serializer currently outputs data even for components where `Serialize = null`.
This leads to useless data being output, especially in OOS debug states which makes diffing more annoying.
Noted in #7634
Gcc-14 triggers a warning for substitute_esc_chars in
json_spirit_reader_template.h if optimizations are enabled.
../../../source/third_party/jsonspirit/json_spirit_reader_template.h:138:62:
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/char_traits.h:427:56: warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 9223372036854775808 or more bytes at offsets 0 and 0 may overlap up to 9223372036854775809 bytes at offset -1 [-Wrestrict]
427 | return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n));
for with lto enabled
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/char_traits.h:427:56: warning: ‘__builtin_memcpy’ specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
427 | return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n));
This looks like another incarnation of bugs like:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
Add quirk to avoid the warning
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
jquery 1 is for support of old version of browsers not even maintained
this days.
Updating prevents occasional hangs for me.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Code within CONFIG_ENABLE_BOOST is required to compile pyrogenesis.
As boost is required in many other places, making it truly optional in
the one case where there is currently a guard is meaningless.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Either a return value or an exception has to be stored. With
`std::variant` it's more explicit.
Also the return value is never empty, so there is no need for
`std::optional` anymore.
When marking a tag dirty, the obstruction manager checks it has not already done so. This is un-necessary when the global state is marked dirty, and this check is rather slow since we do it once per entity, effectively leading to an o(n^2) runtime.
235ea5cfb4 updated the languages supported by 0 A.D., but missed
updating them for the installer. This commit makes up for that and
updates the languages for the installer as well.
This is a workaround to avoid disabling GL storage buffers completely.
Because they might not work or might lead to a decreased performance.
We need to investigate that further when we have a local reproduce.
Fetch third party tarballs for source packages so they will be bundled
in source release tarballs.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This makes using STUN mandatory for games hosted using the multiplayer
lobby. The motivation for that is a reduction in complexity, because
right now if STUN is disabled we use a home-grown STUN-like logic, which
got implemented before Pyrogenesis got STUN support.
That home-grown logic relies on a custom ejabberd module (mod_ipstamp),
which inserts the external IP-address of a host in the response messages
when a host registers a game. Originally mod_ipstamp was also used to
inform all potential players of a hosts IP-address, however that has
already been removed to let hosts to only share their IP-address with
players actually joining their game.
Removing the home-grown logic and instead always relying on STUN removes
complexity in Pyrogenesis and the lobby server and also eases hosting
games for players, as they don't have to figure out anymore whether they
need to enable STUN or not.
These changes shouldn't negatively impact the ability of Pyrogenesis to
handle different types of NAT or broken networks. There is one
difference though: While the custom logic using mod_ipstamp utilized TCP
as transport protocol, the STUN implementation in Pyrogenesis currently
uses UDP. That doesn't allow hosts with UDP-connectivity issues to
resolve their external IP-address anymore, however without
UDP-connectivity they aren't able to successfully host games anyway, as
the actual game updates are transferred using UDP as well.
Reading `second` on the end of the range is undefined behavior. Invoking
`test.find` in the test never evaluates to the past the end iterator.
GCC doesn't know that and issues a "maybe-uninitialized" warning.
GCC thinks `m_Buf + m_BufLen` can be outside the bound of `m_Buf`.
That is because `m_BufLen + len < CHUNK_SIZE` can evaluate to `true`
even if `m_BufLen` is bigger than `CHUNK_SIZE` due to wrapping. Tell GCC
that it's not possible.
This removes Catalan and Scottish Gaelic as supported languages, as they
now both have a coverage of less than 80% and adds Galician and
Portugese which both have 100% coverage right now.
CParamNodes can be quite large, thus we usually cache the JS::Value when
converting them. The AIInterface makes heavy use of it as detected in #7404.
However, the cached values are re-frozen everytime, which is a
significant waste of time on a large number of templates.
This avoids collisions in the user report, fixes#7174.
Update the user report version to account for the new build version
format, fixes#7173.
The build version displayed in the GUI is kept at 5 characters for
main menu clutter concerns.
