The alliance/editAli/delAli pages are linked all over the admin panel
(?p=alliance&aid=, ?p=editAli, ?p=delAli) but were never in
admin_validated_page()'s whitelist, so admin.php fell back to search.tpl and
the pages never showed. Add them to the whitelist plus switch cases for the
breadcrumb (the templates resolve $aid/$alidata themselves from $_GET, like
editSitter/editPassword).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
editVillageOwner, renameVillage, editBuildings and editResources are POSTed
to directly, bypassing admin.php's central csrf_verify(). Add csrf_verify()
(after the admin access check, via the shared GameEngine/Admin/csrf.php) and
csrf_field() in their forms (editVillage.tpl, village.tpl, editResources.tpl).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
addTroops and addABTroops are POSTed to directly, bypassing admin.php's
central csrf_verify(). Add csrf_verify() (after the admin access check, via
the shared GameEngine/Admin/csrf.php) and csrf_field() in their forms.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
On the rally point incoming tab, the number of an incoming unit type is never
revealed: it is always shown as a "?". When that stack is smaller than the
defender's rally point (gid 16) level, the "?" is rendered in solid black
bold, matching original Travian behaviour (e.g. rally point level 20 and an
incoming 19 praetorians shows a bold "?"). The eyesight artifact still reveals
which troop types are present (0 for the absent ones). Scope: village
attacks/raids only.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Extract the per-branch defender target resolution and battle-environment
setup into two private helpers: resolveVillageTarget() and
resolveOasisTarget(). Each returns the target owner (tribe/alliance), map
info, conquest flag and the battle parameters (wall, armory/blacksmith
tech, residence, siege masonry); the village helper also returns the
evasion inputs. Both are read-only (no DB writes).
The foreach body keeps handleEvasion(), buildDefenderUnits() and
buildAttackerUnits() as explicit, ordered calls, so the village and oasis
branches are now symmetric orchestration.
Behaviour-preserving. The building/tech reads now run inside the helper
before handleEvasion(); they read buildings and technology only (never the
troops handleEvasion() may move), so the result is unchanged. A few
dead locals are dropped (playerunit, wallgid, w; the redundant
DefenderUnit/def_ab re-inits).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Extract the per-attack, target-independent context resolution (attacker
village/owner tribe and alliance, war references, base flags) into a
private helper. Read-only, behaviour-preserving: the three repeated
getCachedUser() lookups on the attacker owner are collapsed into one
(the user cache makes them idempotent).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The defender's units were gathered by two near-identical inline blocks
(village and oasis targets). Extract them into a single private method
buildDefenderUnits() returning the defender's own troops (normalised to
non-negative ints), the aggregated reinforcement totals (enforDefender) and
the raw reinforcement rows (enforcementarray).
Pure behaviour-preserving extraction:
- Both call sites assign the returned bundle; all downstream usages unchanged.
- The oasis reinforcement aggregation now uses the same isset-guarded loop as
the village one: identical numeric result, minus a latent PHP 8.3
"undefined array key" notice.
- The dead `$def_ab[$i] = 0` init that lived in the village normalisation loop
is dropped: it was unconditionally wiped by the later `$def_ab = []` before
any use.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The marketplace send tab (17.tpl) was refactored with an empty <script>
block, which dropped the `haendler` (available merchants) and `carry`
(per-merchant capacity) globals that add_res()/upd_res() in unx.js rely on.
Without them `ic = haendler * carry` evaluates to NaN, so clicking the
"(capacity)" link next to a resource (or the resource icon) no longer fills
the input. Restore the two globals so the max-per-merchant fill works again.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The attacking army was built by two near-identical inline blocks (village
and oasis targets). Extract them into a single private method
buildAttackerUnits() that returns the Attacker unit array (u<start..end> +
uhero) together with the catapult / ram / chief / scout unit ids used in the
report. The oasis target keeps its Nature siege/chief slots (37/38/39) via
the $isoasis flag.
Pure behaviour-preserving extraction: both call sites now assign the returned
bundle, so all downstream usages remain unchanged. The unit-id picks are
initialised to null (they are always set for the real attacker tribes 1/2/3/5;
only the unreachable Nature-attacker case differs, which silences a latent
PHP 8.3 undefined-variable notice).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move the ram-damage handling out of sendunitsComplete() into a dedicated
private method applyRamDamage(). For a normal attack (type 3) with rams, it
computes the new wall level, updates it in the database (recounting the
village population when the wall is destroyed), builds the report fragment,
and recalculates the battle when the wall level changed.
Pure behaviour-preserving extraction: the battle-recalc context is passed in
a single $ctx array; the call site keeps the t7 guard and assigns the
returned battlepart / info_ram, so all downstream usages remain unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move the trapper resolution block out of sendunitsComplete() into a
dedicated private method calculateTrappedUnits(). It computes how many
incoming attacker units are caught in the defender's traps (Gaul trapper
or Natar capital), updates the trap counters and the prisoners table, and
subtracts the trapped troops from the attacking army.
Pure behaviour-preserving extraction: the inline `${'traped'.$i}`
variables are rehydrated at the call site from the returned bundle, so all
downstream usages remain unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move the attacker/defender total-population computation (and the two
getProfileVillages() lookups that feed it) out of the per-attack loop into a
dedicated private method. Behaviour-preserving: the method takes the initial
$defpop/$attpop (0 for villages, 500 for the oasis branch) and accumulates onto
them exactly as before, and returns the village lists ($varray/$varray1) used
later for the can-destroy check and handleConquest().
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Follow-up to the unit/tribe rename: a few strings still used the old names.
- MANUAL_UDESC_11: "Les Massues" -> "Les Combattants au gourdin" (U11),
so the in-game manual description matches the unit name.
- TZ_MACEMAN: "Massue" -> "Combattant au gourdin" (used as the U11 label in
the alliance forum troop picker).
- Conquest help text: the loyalty-reduction units listed "COMMANDANTS, CHEFS"
(old Teuton name) -> "CHEFS, CHEFS DE TRIBU", matching Senator/Chief/
Chieftain (Romain/Germain/Gaulois) like the English version.
- Wonder-of-the-World lore: anglicism "Natarian" -> "natarien/natarienne"
(empire natarien, capitale natarienne, menace natarienne), consistent with
the Natar unit names.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The five troop-overview pages hardcoded the English title "Troops (X)",
so the in-game manual kept showing e.g. "Troops (Teutons)" even in French,
inconsistent with the now-corrected unit/tribe names. Replace the hardcoded
titles with the existing TROOPS and TRIBE1-5 constants (consistent with the
#186 manual i18n migration) so the title follows the active language,
e.g. "Troupes (Germains)" in French. en.php already defines all of these
constants as the idempotent fallback, so other languages are unaffected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ferywir