squashed into a single commit because doing it in steps that all
compiled involved a lot of boilerplate that is pointless to commit to
the repository. GH still has the PR for reference.
g_lang, MAX_MESSAGES_ON_MAP_BOTTOM, and GetLanguagePrefix() were
compile-time constants selected by the ENGLISH/GERMAN/... build
define. They're now runtime, defaulting to the same per-exe value the
define used to pick, and overridable at startup from [Ja2 Settings]
LANGUAGE in Ja2.ini.
-
XMLTacticalMessages is filled at runtime from NewTacticalMessages.xml,
never from compiled-in per-language data: all 8 per-language definitions
were the identical all-zero { L"" }. Delete them and define one shared
buffer in Utils/XML_Language.cpp (the loader) instead of pointer-rebinding
it like the static tables — this drops 9 dead 800KB zero-buffers (8
namespaced copies in LanguageStrings.cpp plus the standalone one) and
leaves no bind-ordering hazard for the XML load path.
-
ExportStrings.cpp privately recompiled one language's full text table
by #including the raw _<LANG>Text.cpp inside namespace Loc, keyed off
the exe-level ENGLISH/GERMAN/... compile macro (whichever the build
happened to select). That's redundant with the pointer globals every
other subsystem already uses (Text.h / LanguageStrings.cpp).
Drop the private copy; the unqualified table names in Loc::ExportStrings
now resolve to the global pointer externs, which BindLanguageStrings has
already rebound to the runtime g_lang by the time this runs (EXPORT_STRINGS
ini flag, checked after GetRuntimeSettings in sgp.cpp). gs_Lang (used only
by Loc::Translate for the Polish/Russian byte remap on raw .edt exports) is
now derived from g_lang via ToLocLanguage, so the export always matches
whatever language is actually active instead of a compile-time pick.
-
Editor/popupmenu.cpp and Strategic/Scheduling.cpp kept their own
call-site extern of gszScheduleActions as CHAR16[NUM_SCHEDULE_ACTIONS][20]
after the real definition changed into a rebindable pointer
(CHAR16 (*)[20], LanguageStrings.cpp). MSVC decays the outer array
dimension when mangling globals, so both declarations produce the same
symbol (?gszScheduleActions@@3PAY0BE@_WA) and the mismatch linked
silently -- but the array-typed TUs then indexed the 4-byte pointer
slot itself as string data, so the editor schedule popup and the map
schedule message text read garbage.
-
add text.def to be single-source of truth on symbol names and use it
.much simpler, less error prone if adding more strings
-
add pseudo interface for language state. MAX_SAGES_ON_BOTTOM must always
change in lockstep with g_lang. this isn't foolproof but better
---------
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
requires clang/lld or mingw, obviously
just make sure the MSVC_DIRECTORY env variable points to valid Visual Studio Build Tools directory
and do: `cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=clang_or_mingw_toolchain_file`
a recent Visual Studio update introduced an error unless there is a
CMakePresets.json file present, completely blowing up the previous
setup.
after this commit, you should either delete the CMakeUserPresets.json
file from your root or add it to your system - NOT repo! - excludesFile:
https://stackoverflow.com/questions/7335420/global-git-ignore
* Use a modifiable user-preset sample for VS 2022/2019
Customizing a repo-tracked preset file doesn't work:
Type in your gamedir for debugging, or toggle verbose mode for the build, or configure Chinese
UB MapEditor: you now have an unstaged `CMakePresets.json` change in your working directory.
very annoying.
Also, Visual Studio 2022's preset support has a bug: if you have a `CMakePresets.json` file,
no matter in which file (user or repo) the preset you have selected is defined, if you click
"Manage Configurations..." it will always open `CMakePresets.json` for editing, setting the
user up for failure and editing the commited-to-repository file.
Having just the `CMakeUserPresets.json` file also sidesteps another poor Visual Studio 2022
decision: hiding in Folder View files that are .gitignore'd (like `CMakeUserPresets.json`).
In the absence of a `CMakePresets.json` file, selecting "Manage Configurations..." will open
the right file for editing.
The workflow is then:
Copy `CMakeUserPresets.json.sample` into `CMakeUserPresets.json` _once_, then customize
that to your heart's content without git bothering you and accidentally adding an
unwanted change to a patch. Or make your own.
* Added auto-copy of profile template.
* declutter things a bit
move function out of root cmakelists.txt file
move user preset template to a presets directory
this is horrible and I hate it
Co-authored-by: CptMoore <39010654+CptMoore@users.noreply.github.com>
* simplify the language/executable validation function
removing the 'ALL' corner-case so that the default behavior is to configure all valid languages and applications allows to simplify this function quite a bit
* keep the CMakePreset.json options listed for ease of use
Tried to stay as close as possible to ja2_2019.sln
On Visual Studio 2022 just Project -> CMake Settings for Ja2, add
the x86 configurations you want and press F7.
Below shows how the -DLanguages -DApplications switches work, If you don't
set them, the CMakeCache.txt of them will be set to ENGLISH and JA2,
respectively:
cmake [...] // nothing set, configure just JA2_ENGLISH.exe by default
cmake [...] -DApplications="JA2UB" // configures just Unfinished Business
cmake [...] build -DApplications="JA2UB;JA2UBMAPEDITOR" // Unfinished Business and UB Map Editor
cmake [...] build -DApplications="JA2UB;JA2MAPEDITOR;ALL" // ALL is in the list, configures every application
cmake [...] build -DApplications="JA2MAPEDITOR;DeathStranding" // fatal error: DeathStranding not an application
cmake [...] -DLanguages="GERMAN" // configures just German targets
cmake [...] build -DLanguages="GERMAN;ENGLISH" // German and English
cmake [...] build -DLanguages="GERMAN;ENGLISH;ALL" // ALL is in the list, configures every language
cmake [...] build -DLanguages="ENGLISH;ESPERANTO" // fatal error: ESPERANTO not supported
Marco Antonio J. Costaandmajcosta
