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
upgradeSword() and upgradeArmour() were near-identical: the only differences
were the AB-tech key prefix ('b' vs 'a'), the building type whose level gates
the research (Smithy 12 vs Armoury 13) and the matching bid building data
($bid12 vs $bid13). Merge them into a single upgradeWeaponOrArmour($get, $type)
parameterised by the prefix, deriving the building type from it, and route both
procTechno() cases through it. Resolves the pre-existing //TODO. Behaviour-
preserving.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
+You can no longer build WW if your and your alliance building plans
aren't active yet
+You can no longer remove the WW from the village if you remove it from
the building queue
+Spies from every tribe will now consume crop correctly, when returning
from a scouting attacks
+Spies from every tribe will now be displayed correctly, in the "Troops"
tab of dorf3.php, when returning from a scouting attack
+Building levels will now not be downgraded by 1 level, when conquering
a Natars' village
+Natars' villages with an artifact inside, will now be deleted if the
artifact is conquered (even if the pop isn't 0)
+Natars will now spawn automatically, you can set how many day should
pass before the spawn of Natars (and artifacts), WW Villages and WW
building plans (Note: WW villages and WW building plans won't spawn
until the creation of the natar account)
+Added 3 timers under the left menu which indicate the spawn of
Natars/Artifacts, WW villages and WW building plans
+Added an option in the installation, to set the resource production of
oasis
+Fixed a bug that didn't permit to add multiple Units, Abtech and tech
rows with one query
+Added a new information to the Artifact of the fool, the next effect
reroll will now be displayed in his informations (in the treasury)
+Fixed a bug that dind't permit the correct timers flow in Dorf3.php
(Warehouse tab), they'll now flow correctly
+Timers and resources percentage of villages with a negative production
of crop will now be marked in red (in the Warehouse tab, Dorf3.php) and
will now be displayed in how much time the granary will be emptied
+Fixed a possible bug that prevented to add raids to farm lists
+Fixed a bug that didn't permit to create WW Villages from the
Multihunter control panel
+Reworked all timers, there will be only one timer field now (in
Session.php)
+Minor bug fixing and optimization
NOTE: To play this version of the game, you need to reinstall the server
OR you can simply add these lines of code into your "config.php" file:
// ***** Natars Spawn Time
define("NATARS_SPAWN_TIME",260);
define("NATARS_WW_SPAWN_TIME",260);
define("NATARS_WW_BUILDING_PLAN_SPAWN_TIME",260);
// ***** Oasis production
define("OASIS_WOOD_MULTIPLIER",40);
define("OASIS_CLAY_MULTIPLIER",40);
define("OASIS_IRON_MULTIPLIER",40);
define("OASIS_CROP_MULTIPLIER",40);
define("OASIS_WOOD_PRODUCTION",OASIS_WOOD_MULTIPLIER*SPEED);
define("OASIS_CLAY_PRODUCTION",OASIS_CLAY_MULTIPLIER*SPEED);
define("OASIS_IRON_PRODUCTION",OASIS_IRON_MULTIPLIER*SPEED);
define("OASIS_CROP_PRODUCTION",OASIS_CROP_MULTIPLIER*SPEED);
P.S: from the next version, the possibility to add manual WWs, WW
building plans and to create the natar account will be REMOVED.
+Fixed an exploit that permitted to starts other players' farm lists
+Fixed an exploit that permitted to save our raids to other players'
farm lists
+Fixed an exploit that permitted to edit other players' farm lists
+Fixed a rounding upkeep bug
+Moved the whole startRaid.tpl to a new method in Units.php
+A lot of clean-up
+Improoved indentation
+In the raid list, the "carry" image will now show to the left of an
attack
+Fixed a bug that displayed the wrong loot to returning troops released
by traps
+General minor bug fixing and improovements
-Deleted a lot of redundant code
+Traps are now repaired (built) in the trapper building, instead of
instantly given after a successful normal attack or a dismiss/releasing
from the rally point
+1/4 of trapped troops are now lost after a successful normal attack
+Traps are now released when troops die from starvation
+If you'll dismiss your trapped troops from the rally point, the gaul
player will be able to only repair 1/3 of the total used traps
+Created a new method to delete some redundant and duplicated code
starvation related
+The effect of WW building plans will be displayed correctly, when
they're active
+Troops related artifacts are now counted when building traps
+Some minor improovements and bug fixing
+Some clean-up
Completely fixed the artifact of the fool and fixed all kind of
artifact:
+Deleted some useless .tpl files and merged into one (Stable)
+The artifact of the fool effect won't be displayed if not active
+Fixed a bug that permitted to have a great and a unique artefacts
active at the same moment
+Big reductions of code in a lot of files
+Created some new methods to support artifacts
+Fixed a bug that prevented the effect of the "Rivals confusion" to work
correctly
+Fixed a bug that prevented "The eagles eyes" artifact to work correctly
for the attacker
+Fixed the artifact of the fool of every kind, now it's calculated with
a new method
+Fixed the cranny capacity when a "Rivals confusion" artifact is active
+Some minor bug fixing , improovements and optimization
+Fixed a bug that selected the capital village instead of the actual
village
+Medals aren't given to
Support/Nature/Natars/TaskMaster/Multihunteranymore
+Fixed a bug in 1.tpl (dorf3.php) that showed tigers instead of traps
while building traps
+Some clean-up in Technology.php
+Part 1 of the starvation refactor, attacking troops will now be killed
+Fixed some errors in Units.php, Technology.php, Battle.php and some
16_incomming.tpl
-Removed an unused function in Database.php
+Fixed a bug that could have destroyed a village after taking an
artefact even if it had more than 0 pop
Added the research loop in the blacksmith and in the armoury, only for
plus users. This was a not coded T3.6 feature.
"Total resources required" (for NPC merchants) are now calculated
correctly in the Armoury.
Some clean-up in Technology.php
Turns out we could conquer a village and then settle a new one without
having enough expansion slots. Thus this is a revert to original state,
where we can't train settlers with chieftain in village or chieftain
with settlers in village, if we don't have enough slots.
Closes#324
It is debatable whether or not to allow this, since chieftan would be of
no use once we have 3 settlers and settle a new village. However, if we
accidentally created a chieftan, we can't train settlers until we send
the chieftan to his death.
I think this move could be a predule to a later game mechanics, where
chieftan could fight (talk, actually) against chieftan, if one is
present in village, so taking a village over isn't so easy.
novgorodschi catalin