'typename' disambiguates a qualified dependent name, telling the
compiler that something like T::iterator names a type rather than a
value. Before a plain identifier there is nothing to disambiguate: P1
is already a type, and so is PopupIndex.
The grammar wants a qualified name after the keyword, so clang reports
"expected a qualified name after 'typename'", drops the keyword and
carries on -- 15175 times, since the offending declarations sit in
widely included headers. MSVC accepts them without a word.
Semantics do not change. Both compilers already ignored the keyword,
so the partial specialisations matched before this and match after it.
The diagnostic belongs to no -W group and therefore cannot be switched
off with -Wno-, which makes deleting the tokens the only way to quiet
it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Four string literals carry the bytes A3 A5, which is GBK for U+FF05, the
fullwidth percent sign. All four sit in g_lang == i18n::Lang::zh branches
added by "Chinese specific update (by zww from tbs)", and each has an ASCII
sibling in the else branch using an ordinary percent.
clang-cl decodes source as UTF-8, where A3 is not a valid lead byte:
error: illegal character encoding in string literal
A raw high byte in a literal means whatever the compiler's source charset
says it means, so this text has never been portable. Asking the cl we build
with what it makes of L"%d%<A3><A5>%%" gives a 7-character string whose
fourth character is 163 -- it reads the bytes as Latin-1 and produces two
characters, £ and ¥, not the one the author wrote. The same probe on
L"%d%％%%" gives 6 characters with U+FF05 in that position.
So the Chinese text has been rendering as garbage in any build not made on a
CP936 machine, this one included. Writing the character as ％ says
exactly which character is meant regardless of the compiler's charset, and
restores what the branch was written to display.
The format grammar is untouched. In each of these strings the character is
preceded by a percent, making %<fullwidth percent> an unknown conversion
specification that prints the character following it -- the same trick the
else branches spell as %%. Where a string is formatted twice, once into a
buffer and again as the format argument of mprintf, the doubling in the
sibling literal (%%%%) is what survives two passes; that pairing is
unchanged.
Both files are now pure ASCII:
python3 -c "print(sum(1 for b in open(F,'rb').read() if b>0x7f))"
The parse sweep drops from 5 error sites in 3 files to 1 in 1 -- the inline
assembly in sgp/vobject_blitters.cpp is all that is left.
LoadEquipmentTemplate parsed each line of a saved equipment template like
this:
if ( iss >> num && iss >> (UINT16)node.item )
node.item is already a UINT16, so the cast does nothing except turn the member
into a temporary. The stream then extracts into that temporary, which is
thrown away at the semicolon, and node.item keeps the 0 its constructor gave
it. node.ammoitem, cast the same way on the next line, is lost with it.
This is not only a parse error. The tokens are still consumed, so the line
parses and the node is appended, but every node comes back with item 0. The
consumer skips those:
if ( node.slot >= 0 && node.slot < NUM_INV_SLOTS && node.item != NOTHING )
so loading an equipment template has been quietly doing nothing at all. Only
the attachments, read through a real variable, ever survived, and they were
attached to a node that got skipped.
Removing the two casts makes the extraction write where it was always meant
to. slot is still read through num, as it must be, since it is an INT8 and the
stream would take it for a character.
This changes behaviour: gear templates will start applying. That is the point,
but it is worth knowing before this ships.
Verification:
ninja -C build parse # both Handle Items.cpp sites gone
ninja -C build -k 0 # Release, four applications, green
ninja -C build-debug -k 0 # Debug, four applications, green
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
not is an alternative spelling of ! in ISO C++, so it cannot name a variable:
XML_Char const* not = GetAttribute("not", atts);
MSVC only treats it as an operator when iso646.h is included, so it accepts
this as an identifier and the file compiles. clang cannot parse any of the
three lines that mention it.
Renamed to notOp, matching cmpOp thirty lines above, which reads the "op"
attribute the same way. The attribute name in the XML is untouched.
Verification:
grep -rnE '\*[ \t]*(and|or|not|xor)\b' --include=*.cpp --include=*.h . # nothing
ninja -C build parse # parser-error class gone: 21 -> 17 sites
ninja -C build -k 0 # Release, four applications, green
ninja -C build-debug -k 0 # Debug, four applications, green
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
strstr returns a pointer into the string or NULL, and these four tests compare
that pointer to 0 with >. Ordering a pointer against a null pointer constant
is not something C++ defines; MSVC allows it, clang rejects it.
The intent is plainly "did this attribute name contain the tag", and the
result is the same either way, since the only pointer these can produce that
is not greater than zero is the null one. != NULL says it directly, and reads
like the strcmp(name, "...") == 0 tests it sits between.
strstr rather than strcmp is deliberate here: the attributes it looks for are
numbered, usAttachment1 through usAttachment4 and usResult1 upwards, so an
exact comparison would not match them. That is unchanged.
Verification:
grep -rn 'strstr([^)]*)[ \t]*[><]' --include=*.cpp --include=*.h . # nothing
ninja -C build parse # pointer-ordering class gone: 32 -> 28 sites
ninja -C build -k 0 # Release, four applications, green
ninja -C build-debug -k 0 # Debug, four applications, green
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A braced initialiser does not allow a narrowing conversion unless the value
is a constant expression the compiler can prove fits. Every site here holds a
runtime value: WORLD_COLS is the global guiWorldCols, the laptop screen
coordinates are built from iScreenWidthOffset, the sector limits come from the
externalised options. MSVC accepts all of it silently; clang rejects it, and
it is ill-formed.
Nothing about the generated code changes. MSVC was already performing these
conversions; the casts only say so out loud, at the 73 places where it was
happening implicitly.
The invariant: each site is wrapped in a static_cast to the element type the
initialiser already had, and nothing else is touched. No type is widened, no
expression is reassociated, no value is clamped or checked. static_cast rather
than a C-style cast so that a later reader can grep for the narrowings, and so
that none of these can quietly become a reinterpret_cast if a type changes.
Verification:
# every changed line differs only by inserted casts and their parentheses
git show HEAD -U0 | grep '^[+-][^+-]' |
sed -E 's/static_cast<[A-Za-z0-9_]+>//g; s/[()]//g; s/^[+-]//' |
sort | uniq -c | awk '$1 % 2' # no output
git show HEAD -U0 | grep -c '^+[^+]' # 38 lines, 73 casts
ninja -C build parse # narrowing class gone: 129 -> 91 sites
ninja -C build -k 0 # Release, four applications, green
ninja -C build-debug -k 0 # Debug, four applications, green
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
POPUP_OPTION copies the name it is given -- `this->name = *newName` into a
std::wstring member -- but its constructor took a std::wstring*, so 64 call
sites spelled the argument `&std::wstring( pStr )`. Taking the address of a
temporary is ill-formed, and clang refuses it outright:
error: taking the address of a temporary object of type 'std::wstring'
It happens to work under MSVC because the temporary outlives the call, dying
at the end of the full expression rather than before the copy. Nothing was
corrupt; the code was just spelling "pass me a string" in a way the language
does not allow.
A const reference says what these functions actually want, so the call sites
lose the &, and the two places that allocated a string purely to have an
address to pass -- POPUP_SUB_POPUP_OPTION's default constructor, which carried
a "TODO: possible memmory leak!" saying as much, and a "Dummy generator"
option -- stop leaking one.
Converted: POPUP_OPTION's constructor and setName, POPUP::addOption and
addSubMenuOption, and both POPUP_SUB_POPUP_OPTION constructors. The popupDef
family in popup_definition.* keeps its std::wstring* because it owns what it
is handed and stores the pointer; that is a different design and a different
change. The three calls it makes into the converted API now dereference.
Verification:
grep -rn '&std::wstring' --include=*.cpp --include=*.h . # nothing
ninja -C build parse # no popup_* or SkillMenu sites remain
ninja -C build -k 0 # Release, four applications, green
ninja -C build-debug -k 0 # Debug, four applications, green
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
* Load required mapinfo for checking suitable gridnos
* Modify SOLDIERTYPE::DropSectorEquipment( ) to take an external gridno when placing items into an unloaded sector
"Corpses are not properly shown even if within mercs' vision due to the check only
running intermittently since we're not constantly running the reveal roofs and items
function. In addition, mercs such as Raven who have the quoteexpheadshotonly set to true,
will NEVER reveal any corpses"
Revert "Remove extra line"
This reverts commit 1e1eb88864.
Revert "Move visibility check after already included pCorpse check"
This reverts commit 72e586a378.
Revert "Make 3rd party corpses invisible till they in fov"
This reverts commit 07dbf9c848.
Same logic but cleaned up version of https://github.com/1dot13/source/pull/602 which Tais contributed with Claude Code's help
Most calls to SOLDIERTYPE::IsDragging() aren't supposed to have a side effect of cancelling a drag, being simple queries.
Changing the default to reflect that is right move.
Assisted-by: Claude:
The LayerProp palette lookup was gated on the *filter* attribute instead
of the *palette* attribute -- the filter checks from the line above were
copy-pasted verbatim. As a result, any LayerProp with an empty filter but
a real palette never resolved its palette table: paletteTable stayed NULL
and the layer fell back to the merc's shade table.
The most visible victim is the heli fast-rope arrival layer
(filter="" palette="hats"): rendered with the merc palette, the rope's
pixel indices (45-81, 166-172) hit the merc's unreplaced orange/red glow
ramp instead of the rope's own tan/green, painting orange specks along the
rope. Testing the palette attribute restores the intended "hats" palette
and the correct rope colours; it also fixes any other empty-filter layers.
Co-Authored-By: Claude Opus 4.7
Fixes not being able to take all corpses from one tile, if multiple corpses were stacked on top of each other. With the structure not deleted, the GetCorpseAtGridNo would not find an existing corpse anymore.
* Replaced gCoverViewArea[2000][2000][2] with std::vector that is adjusted to the actual viewport size. Size difference for example in 720p resolution is 8 000 000 vs 3969 elements
* FPS improved in merc view mode 6-8 frames and in enemy view mode 10-20 frames
Emails from new GameDir file TableData/Email/Emails.xml can be added via lua scripting using calls to AddEmailFromXML & AddPreReadEmailFromXML. The order of emails in Emails.xml acts as the index to be referenced and provided when calling lua functions.
An error message will be displayed if an email is added with an out-of-scope index but game will be able to continue.
Localization is supported and was tested on Chinese localization.
steph-pgandAsdow
GreysaandAsdow
noooooo4499andAsdow