The "no tasks" quest mode delivers a Plus + gold shipment on claim
(case '91', and the final case '97'). The reward was granted with a
non-atomic read-modify-write:
$gold = getUserField('gold'); $gold += 15; updateUserField('gold', $gold);
and the quest pointer / timer were advanced unconditionally. Under the
many concurrent ajax requests the game fires, a request that read gold/
plus before the claim and wrote the user row back after it would clobber
the freshly granted reward. The quest_time write (a literal value) still
survived, so the UI advanced to the next shipment countdown while the
player received neither Plus nor gold -- exactly the sporadic symptom in
the report.
Fix: gate the grant on an atomic conditional advance
(UPDATE ... SET quest = 91 WHERE quest = 90) and apply the reward with
in-place SQL increments (gold = gold + 15, plus = IF(plus > now, ...)),
matching the idiom already used in Templates/Plus/*.tpl. This makes the
claim idempotent (duplicate/concurrent requests grant nothing extra) and
immune to the lost-update race. Also fixes a latent case where an expired
Plus timestamp was extended in the past instead of reset to now.
Applied to both quest_core.tpl and quest_core25.tpl.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
fix the resources that were given to give the mission as it gave less than the reward was saying.
Greetings Armando
arregle los recursos que se entregaban al dar la mision ya que se daban menos de lo que la recompensa decia.
saludos Armando
TravianZ Patcher