1. Spies — real bug, found. In calculateBattle, the block that calculates the attack power of spies had the hardcoded condition if ($i == 4 || $i == 14 || $i == 23 || $i == 44). Scouts of new tribes (52/64/74/82) did not enter the branch → attack power 0, so they all died no matter how many there were. Now the condition is in_array($i, $unitsbytype['scout']). With this, all four lists in Battle (cavalry, catapults, rams, scouts on attack + scouts on defense) are derived from unitsbytype.
2. Defender hero. I rebuilt the report CSV with dummy values and confirmed that the indexes in Notice/1.tpl are correct (272 = hero present, 273 = hero dead) — so the problem was that $deadhero was ending up as 0 in the report, even though deadherodef was 1 in the battle result (that's why the hero actually died in the DB). Now $deadhero is taken directly from the battle result ($battlepart['deadherodef']), with $owndead['hero'] only as a fallback.
3. "Free" healing. The code called modifyResource(..., mode 0) exactly like training, so the resources were low — but at 100x speed and full storage (8M/8M in your captures) the difference is instantly invisible. I did find a real bug in this area though: modifyResource caps at 0 instead of failing, so if you don't have resources you heal for free. Now procHeal checks the stock and, if there are insufficient resources, automatically reduces the quantity to what you can afford (or cancels).
NEW TRIBES ENHANCEMENT (Huns, Egipteans, Spartans & Vikings) #327
Please be advised, is not fully tested so if you activate on install maybe is not fully working
The Brewery (building 35, Teuton-only) grants a +1% attack bonus per level
to the whole empire, but only while a Mead-Festival is running (72h), and the
building is capital-only. The attack-bonus block in calculateBattle() ignored
both rules: it read the Brewery level from $AttackerWref (the *launching*
village, which usually has no Brewery) and applied the bonus purely on the
building level, with no festival check.
As a result the bonus never reacted to the festival being started or expired:
attacks with and without an active festival produced identical losses, so the
army appeared unaffected by the festival (issue #294). Depending on whether the
attack was launched from the capital, the bonus was either permanently on or
permanently off, but never gated by the festival.
Read the Brewery level from the attacker's capital and gate the bonus on the
festival being active, mirroring the catapult-randomization gate in Units.php
and the chief-penalty gate in Automation.php. The simulator passes
AttackerID = 0, so it keeps a 0 bonus exactly as before.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
procDistanceTime() multiplied the whole travel distance by the Tournament
Square speed factor as soon as the distance reached TS_THRESHOLD. That
made the trip time jump down at the threshold, so a target just past it
arrived dramatically sooner than a nearer one (e.g. a village 41 tiles
away raided faster than one 18 tiles away).
In T3.6 the Tournament Square only speeds up the part of the journey
beyond the threshold: the first TS_THRESHOLD tiles are walked at base
speed and the remainder at the boosted speed. Split the computation
accordingly so travel time stays monotonic with distance while still
rewarding a high-level square.
This is a long-standing bug, unrelated to the Generator refactor (which
only reformatted the same whole-distance multiplication). The same fix is
applied to the duplicate procDistanceTime() in Admin/database.php used by
the admin troop-return helper.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
novgorodschi catalin