[pull] master from OpenApoc:master #89
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Refactoring vehiclemission and cityview
We were using gcc-13 but that seems to have been removed from the 22.04 image that "ubuntu-latest" actually gave us. May as well move to gcc-14 at the same time.
Move github builder to ubuntu 24.04 and gcc-14
Fix incorrect package name in readme, Tested on Ubuntu 24.04
Add partial clip refilling in battlescape
…ed-ufo-name Issue 1443: Hiding unresearched UFO names
Fix duplicate TU above agents in debug mode
…after-battle Live alien recovery after base defense battle
qt5-15 was removed from appveyor, and as we don't actually use any qt5-specific features we can just move to qt6.
Looks like the RUNTIME_OUTPUT_DIRECTORY property is the "correct" way of doing this now, and the EXECUTABLE_OUTPUT_PATH global doesn't work with qt?
We really should always have the pdb, even on release builds
Gives a chance of actually using them for debugging?
Does the "bare minimum" to pull up the minimum required cmake version Choosing 3.30, as that pulls in the CMP0167 boost changes at least. Also qt-5.15 has been removed from appveyor, so move to qt-6. This seemed to cause some differences to how the local built files pull in required plugins etc. so run windeployqt at build time on win32. Might also be required on macos, but no ability to test right now.
This always was an internal boost detail, and seems to be removed from boost-1.89
Remove Boost_system dependency
Cleans up agent lab assignment, rather than keeping a separate boolean and StateRef<Lab> just use that ref being null to imply no lab assigned.
Tests some cases with agents assigned to labs and serialized in/out, transferred or killed
Not sure why this can't just use the assigned reference list size, leave the counting in and an assert for now to ensure I haven't missed a reason
An agent being added/removed to a lab, or a lab being full, are not a problem so shouldn't be a warning
When playing a playlist and reaching the end of a track, the vorbis decoder was never set to the beginning of the file again for the next loop of a playlist. This meant that each music file would only ever play once, and then when tried to play again be considered at the end and immediately switch to the end. If there are no more valid files in the playlist and all are at the end, this would wedge the audio thread, causing no sound and the next interaction with the audio lock (like, for example, the sfx from clicking a button) would hardlock the game.
Cleans up agent lab assignment, rather than keeping a separate boolean and StateRef just use that ref being null to imply no lab assigned. Though it changes the serialized format - removing that assigned_to_lab flag, it should actually affect backward compatibility with older saves - as that should already be implied by the non-null lab_assigned, and them being out of sync is a failure anyway. At next load, that unused flag should be ignored and future saves will not write it. Compatibility of new saves with old game versions, however, will break.
When playing a playlist and reaching the end of a track, the vorbis decoder was never set to the beginning of the file again for the next loop of a playlist. This meant that each music file would only ever play once, and then when tried to play again be considered at the end and immediately switch to the end. If there are no more valid files in the playlist and all are at the end, this would wedge the audio thread, causing no sound and the next interaction with the audio lock (like, for example, the sfx from clicking a button) would hardlock the game.
Vehicle::currentAgents and Building::currentAgents are recursed to kill any contained agents, but agent->die() removes it from that list, invalidating the current iterator. Make a copy of the set to iterate over, I think this is safe, nothing else should modify the set during this, and agents will be dropped when the copy is destroyed and dropping contained StateRef sp<> refcount
Agent::die should clear the current building and vehicle - though nothing else /should/ be using those values before it's destructed, it could cause a circular reference and leak and is somewhat fragile and risky. Also remove the home building - while I think mostly a building outlives any Agent, and as it's no bi-directional shouldn't /leak/, but it's again unclean and fragile. Manually handle equipment detach at agent::destroy() - creating a stub GameState is kinda crazy, anything that touches it would inevitably try to read a missing object....
Fix some Agent iteration and sp<> cross-reference issues
Pretty much all the strings will be replaced
Moves everything to fmt-style {0} format specifiers instead of
printf-style %s etc.
This has a BIG effect on translations, so do a complete rework of that
at the same time.
The end goal is that all code translated strings (with tr()) will use
numbered fmt format specifiers - e.g "string {0} precedes {1}" so they
can be re-ordered by translations as necessary.
While doing this, rewrite a number of areas that construct strings from
fragments - translations would *much* prefer to be able to
translate/reorder the block as a whole.
All this made the old POT template pretty useless, also not helped by
the fact that seemed to have been "seeded" by dumping the string table
of the original executable - so actually contained a large number of
strings we never used.
Note that forms and "game data" (like names for things) are excluded
from the gettext-based code translation. The goal is to allow form XML
and gamestate to be modified on a per-mod per-language basis. Though
arguably much of the Gamestate is proper nouns - which may not really
require translation.
The idea is that mods can add gamestate patches and append data search directories. The idea is that the *vast* majority of the Gamestate doesn't need translation - proper nouns etc. and the game setting is in an English-speaking country. But I'm allowing that just in case there are things in there that probably should be translated. And the data override allows 2 major things - forms and image replacement. The idea is that a language that changes strings on a Form replaces the corresponding Form XML. This allows rearrangement, reflowing and resizing as necessary. Same with images - as many UI images contain text. This does have a limitation of that only the "latest" in the data stack for each file is read - if two mods modify the same form, for example, only the last in the load order will be visible to the game. Note: we use language codes as returned by boost - that "language_COUNTRY" format - e.g. "en_GB"/"en_US". The idea is that if the country isn't available, it falls back to the parent language - e.g. "en_GB" would fall back to an "en" folder and patch file, if such a things exists.
Mostly enum casts for debug output and transitive header changes
These seem to differ between the clang-format 18.1.8 I have locally And seem to be somewhat weird an inconsistent - different spaces for different constructors? eh, whatever.
I think this may be a cause of a number of "fell out of the world" errors - if a object started the tick close enough to the edge the motion may take it some distance out of the map, so that the "bounce" at velocity/4 isn't sufficient for it to move back in next tick.
I think this may be a cause of a number of "fell out of the world" errors - if a object started the tick close enough to the edge the motion may take it some distance out of the map, so that the "bounce" at velocity/4 isn't sufficient for it to move back in next tick.
Moves everything to fmt-style {0} format specifiers instead of
printf-style %s etc.
This has a BIG effect on translations, so do a complete rework of that
at the same time.
The end goal is that all code translated strings (with tr()) will use
numbered fmt format specifiers - e.g "string {0} precedes {1}" so they
can be re-ordered by translations as necessary.
Much of this conversion was automated using clang-tidy, and was
somewhat tested, but keep an eye out for issues.
While doing this, rewrite a number of areas that construct strings from
fragments - translations would much prefer to be able to
translate/reorder the block as a whole.
All this made the old POT template pretty useless, also not helped by
the fact that seemed to have been "seeded" by dumping the string table
of the original executable - so actually contained a large number of
strings we never used.
Note that forms and "game data" (like names for things) are excluded
from the gettext-based code translation. The goal is to allow form XML
and gamestate to be modified on a per-mod per-language basis. Though
arguably much of the Gamestate is proper nouns - which may not really
require translation, there are some parts that will, ufopaedia entries, for example. Honestly the ufopaedia entry should probably not be stored in the game state, the text itself isn't something anything really depends on or needs to persist changes
To allow this, mods can now add data directories and gamestate patches
on a per-language basis. For example, the modinfo can contain:
<languages>
<entry>
<ID>lang_COUNTRY.UTF-8</ID>
<patch>lang/gamestate/lang_COUNTRY</patch>
<data>lang/data/lang_COUNTRY</data>
</entry>
</languages>
The game tries to match a locale that matches the current set language as
set in the config and launcher. They all are suffixed in .UTF-8, as we only
support that encoding.
First an exact matching language_COUNTRY ID is checked - e.g.
"en_GB.UTF-8" for British English. If no match, the country is
stripped, so it next searches for "en.UTF-8".
Both the patch and data are optional - either leave empty or have no tags
if the mod doesn't require them.
Currently the "first" mod in the list is read by the launcher to populate the
"supported languages" list - that's probably the base mod. So really only
that needs to list every possible supported language, other mods only need
to list those that actually require changes.
Also then updates to fmt 12.1.0, latest tag at time of writing.
Because why not
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )