mirror of
https://github.com/Mezeporta/Erupe.git
synced 2026-05-06 22:35:11 +02:00
4ad0012f62
Live-server testing via protbot surfaced an inconsistency between GetBoostTimeLimit and GetBoostRight: on the same character, the former reported a far-future boost limit (2288912640 = year 2042) while the latter correctly reported "expired / available". The two handlers read the same boost_time row and disagreed. Root cause: GetBoostTimeLimit was doing a naked uint32(int64) cast on boostLimit.Unix(). The test character's boost_time was actually year 1906 (a pre-1970 sentinel left behind by the pre-#187 bug), whose negative int64 Unix timestamp wraps through uint32 to a huge positive value the client interprets as a permanently active boost. Harmonise the guard with GetBoostRight: return 0 whenever the stored boost_time is not strictly after TimeAdjusted(), covering both the pre-1970 wraparound and the "already expired" case. Add a healing migration (0011_fix_stale_boost_time) that NULLs out any boost_time column older than 1970 or more than 10 years in the future, so affected characters recover on upgrade without waiting for a fresh boost start. Regression test uses the exact year-1906 value observed on the live frontier.mogapedia.fr test account.