promotional bannermobile promotional banner

Arcadia Lib

Arcadia Lib is the shared foundation required by all Arcadia Pets, Prestige and AH. It provides the database layer, player data management and debug mode.

File Details

arcadia-lib-1.2.7

  • R
  • Apr 28, 2026
  • 2.52 MB
  • 85
  • 1.21.1
  • NeoForge

File Name

arcadia-lib-1.2.7.jar

Supported Versions

  • 1.21.1

Curse Maven Snippet

NeoForge

implementation "curse.maven:arcadia-lib-1493170:8007673"
Curse Maven does not yet support mods that have disabled 3rd party sharing

Learn more about Curse Maven

## [1.2.7] - 2026-04-28 (latest)

### Fixed

- **Daily reward could be claimed once per server in multi-server setups** — `PlayerDataHandler.claimDaily` read `last_claim` from the per-server in-memory cache and the cooldown check was purely local. A player joining all 3 FR servers in sequence (each cache initialized to the pre-claim value) could claim the daily reward 3 times — effectively duplicating the entire reward stack. The MySQL row was the same shared one, but it was overwritten on each claim because no server saw the others' updates. Reworked the MySQL path: the cooldown is now decided by reading `last_claim` directly from the database (bypassing the cache), and the update is a conditional `UPDATE … WHERE uuid=? AND last_claim=?`. If another server advances `last_claim` between our SELECT and UPDATE, the update affects 0 rows and we reject the claim with a race log line. Singleplayer / debug paths keep their existing in-memory logic unchanged.

### Correctifs

- **La récompense journalière pouvait être réclamée une fois par serveur en multi-serveur** — `PlayerDataHandler.claimDaily` lisait `last_claim` depuis le cache local en mémoire de chaque serveur et le check de cooldown était purement local. Un joueur qui se connectait sur les 3 serveurs FR à la suite (chaque cache initialisé à la valeur d'avant claim) pouvait réclamer la récompense 3 fois — dupliquant en pratique tout le stack de récompenses. La ligne MySQL était la même partagée, mais elle était écrasée à chaque claim car aucun serveur ne voyait les updates des autres. Refonte du chemin MySQL : le cooldown est maintenant décidé en lisant `last_claim` directement depuis la base (sans passer par le cache), et l'update est un `UPDATE … WHERE uuid=? AND last_claim=?` conditionnel. Si un autre serveur avance `last_claim` entre notre SELECT et UPDATE, l'update touche 0 lignes et on rejette le claim avec un log de race. Les chemins solo / debug gardent leur logique en mémoire inchangée.