Valora · mise à jour « Forgemagie » v2.1

RS-01 Clés de statistiques non normalisées dans la forge Majeur

Statut

Confirmé par analyse statique — 36 objets sur 78

Portée

Client uniquement

Symptôme

Silencieux : aucune erreur, aucun message

Le moteur maintient deux vocabulaires pour les mêmes statistiques. Un vocabulaire historique — esprit, intelligence, adresse, chance — et le vocabulaire courant — savoir, agilite, flux. La fonction Ot() traduit le premier vers le second :

function Ot(o){
  if(!o) return {};
  const e = {...o};
  return e.esprit       != null && (e.savoir  = (e.savoir ??0)+e.esprit,       delete e.esprit),
         e.intelligence != null && (e.savoir  = (e.savoir ??0)+e.intelligence, delete e.intelligence),
         e.adresse      != null && (e.agilite = (e.agilite??0)+e.adresse,      delete e.adresse),
         e.chance       != null && (e.flux    = (e.flux   ??0)+e.chance,       delete e.chance),
         e
}

Le recyclage l'applique. La forge, non. Les deux fonctions sont voisines dans le même module :

// recyclage — passe par lu(), donc par Ot()
function Lx(o,e,t,i){ … const n = lu(o,t); for(const a of Object.keys(n)){ … } }
function lu(o,e){ return Ot(e ?? S[o]?.bonuses) }

// forge — lit les clés brutes de la définition d'objet
function Eo(o){
  const e = S[o];
  return …: Object.keys(e.bonuses).filter(t => bl(o,t)!=null && Zs(t)!=null)
}
function bl(o,e){ … const t = S[o]?.bonusRange?.[e]; return t ? t[1] : void 0 }

Deux modes de panne distincts

Mode A — clé historique des deux côtés. bonuses et bonusRange disent tous les deux chance ou intelligence. Ils sont cohérents entre eux, bl() répond correctement, mais aucune rune n'est enregistrée sous ces clés : la table xi indexe flux et savoir. C'est le test Zs(t)!=null qui rejette.

relic_whisper  bonuses {chance:14}       bonusRange {chance:[10,18]}       Eo() → []
mystic_ring    bonuses {intelligence:3}  bonusRange {intelligence:[2,4]}   Eo() → []

Mode B — désaccord entre les deux tables. bonuses dit adresse, bonusRange dit agilite. C'est bl() qui renvoie undefined.

veilleur_dagger  bonuses    {attack:16, adresse:34, force:12, crit:.14}
                 bonusRange {force:[9,15], agilite:[25,43], attack:[12,20], crit:[.1,.18]}
                 Eo()       → ["attack","force","crit"]     // agilité absente

Aggravation : l'objet disparaît de la liste

La construction de la liste latérale filtre les objets sans statistique forgeable :

gearCells(e){
  for(const i of this.player.inventory){
    …|| e==="upgrade" && Eo(i.id).length===0 || t.push({…})
  }
}

Conséquence : la Relique du Murmure et l'Anneau mystique ne sont pas affichés du tout dans l'onglet Forgemagie. Le joueur ne voit pas le message ui.runesmith.no_upgradable_stats — il ne voit rien. Cette chaîne est de fait du code mort pour ces objets.

Objets touchés — extrait haut niveau

Les cinq Reliques sont touchées. La liste complète des 36 objets figure en annexe A.

Dommage collatéral

Pour les objets en mode A, la même absence de normalisation touche l'affichage : mi() cherche bonusRange['flux'] sur un jet déjà normalisé, alors que la table dit chance. Ces objets perdent donc aussi leur fourchette (min–max) et leur couleur de qualité de jet, en infobulle comme à l'hôtel des ventes. Le joueur ne peut pas juger si son arme a bien roulé.

RS-02 Le poids de rune s'annule dans la formule de rendement Majeur

Statut

Confirmé dans le code client ; effet réel à confirmer côté serveur

Portée

Aperçu joueur certain ; économie réelle probable

La fonction de rendement du recyclage multiplie puis divise par le même terme :

function Ax(o,e,t,i){
  const s = xi[Zs(e) ?? ""];
  if(!s) return 0;
  const r = S[o],
        n = Math.max(1, Math.floor(r?.levelReq ?? 1)),
        a = e === "crit" ? Math.abs(t)*100 : Math.abs(t);
  return a <= 0 ? 0 : n*a*s.weight*(i.yieldPct/1e4)/(i.levelDiv*s.weight);
}

L'évaluation se faisant de gauche à droite, s.weight se simplifie exactement. Le rendement se réduit à niveau × valeur × 0,015, quelle que soit la rareté de la rune. Or le coût, lui, applique bien le poids (Rx). La rareté ne joue donc que d'un côté de l'équation.

Écart mesuré sur des objets réels du catalogue, en nombre d'objets à recycler pour financer une chaîne complète de la même statistique :

Un facteur 730 entre le flux et le critique de l'Anneau spectral. En pratique : les statistiques principales passent OVER quasi gratuitement — un seul objet recyclé en finance deux ou trois montées complètes — pendant que le critique est hors d'atteinte.

L'or ne rééquilibre rien : les 58 000 or d'une chaîne sont identiques quelle que soit la statistique. Une chaîne de critique et une chaîne de vitalité coûtent le même or, pour un rapport de 1 à 30 en runes.

Note de portée : l'encart « Vous obtiendrez » du panneau de recyclage est calculé côté client par Lx(itemId, $x, rolled), donc avec cette formule. Si le serveur applique une formule corrigée, l'aperçu affiché au joueur est faux — ce qui reste un défaut à corriger, simplement pas au même endroit.

RS-03 La bêta ne permet pas d'exercer la fonctionnalité auditée Majeur

Statut

Observé en jeu — serveur Bêta I, 25 juil.

Portée

Exploitation / conditions de test

Les notes de version annoncent : « Pour cette bêta, tout le monde joue au niveau 100 : tu accèdes directement à la fin de partie et tu testes les nouveaux systèmes sans farmer. »

État constaté des deux personnages disponibles, tous deux niveau 100 :

Or la fonctionnalité exige d'abord de l'équipement à recycler, puis 2 000 or pour le premier palier — le plus modeste. Un testeur qui se connecte pour la fenêtre de 72 h doit donc farmer avant de pouvoir toucher au système qu'on lui demande de tester, ce que la note de version présente précisément comme évité.

Point annexe à vérifier : les deux personnages apparaissent à 1 et 2 points de vie sur 1040 à la connexion, sans avoir combattu.

RS-04 Rune de Précision : valeur marchande à 0 Moyen

Statut

Confirmé — donnée de catalogue

La signature du constructeur d'objets est T(id, nom, rareté, kind, icône, stack, sell, description). Les valeurs marchandes des runes suivent une série cohérente avec leur poids — jusqu'à la dernière :

rune_vigor      poids 0.5   sell 1
rune_might      poids 1     sell 2
rune_ward_*     poids 3     sell 3
rune_power      poids 5     sell 6
rune_precision  poids 30    sell 0   ← rupture de série

La conséquence n'est pas seulement cosmétique. Le prédicat de vendabilité est Pu(o) = fn(o) > 0, et il filtre la grille du marchand :

const t = this.player.inventory.filter(i => { if(!Pu(i.id)) return !1; … });

La rune la plus rare du jeu n'apparaît donc pas dans la liste de vente au PNJ : elle est invendable. L'hôtel des ventes n'est pas affecté — sourceItems() ne filtre que sur quest — donc l'affirmation « Toutes s'échangent librement à l'hôtel des ventes » des notes de version reste vraie. En revanche « la rare Rune de Précision […] vaut plus » est contredite par la donnée.

RS-05 Le gain de critique est invisible à l'écran Moyen

Statut

Confirmé — affichage client

Le critique est stocké en fraction (0,063 pour 6,3 %) et formaté en pourcentage entier :

const h = r === "crit",
      p = b => h ? `${Math.round(b*100)}%` : String(Math.round(b));

Mais le pas de progression vaut 8 % du maximum de base, soit un demi-point de pourcentage sur les objets réels. Deux défauts se cumulent.

a) L'arrondi masque la progression. Séquence complète sur l'Anneau funéraire (max 0,071, pas +0,006) :

0.057 → "6%"   0.063 → "6%"   0.069 → "7%"   0.075 → "8%"   0.081 → "8%"

Le joueur paie 6 000 or et 90 Runes de Précision pour un palier 2 qui affiche 6 % → 6 %. Sur la Relique d'Ambre, trois paliers sur quatre sont invisibles.

b) Le chiffre du gain n'est pas formaté. Le bandeau central utilise la valeur brute, sans passer par p() :

${m > 0 ? `<div class="rd-rs-ba-gain">${F(l("ui.runesmith.stat_gain", {n: m}))}</div>` : ""}

La chaîne ui.runesmith.stat_gain valant +{n}, l'écran affiche +0.006 au lieu de +0,6 pt. Le message de succès (applyUpgradeOutcome) reproduit le même arrondi entier.

RS-06 La progression Runiste ne tient pas sa promesse Moyen

Statut

Confirmé — design / communication

Le texte affiché dans le panneau des métiers (ui.jobs.runist_level_b) annonce :

Le panneau affiche Niveau Runiste {n} / 200 avec une barre calculée sur e/200*100. Or les prérequis de la table de forge sont jobReq: 1, 1, 5, 12, 20 : le dernier palier — le seul comportant un risque de destruction — est débloqué au niveau 20.

La courbe d'XP des métiers d'artisanat est 4n² par niveau, soit en cumulé :

Autrement dit, 0,09 % de la progression du métier débloque 100 % du contenu mécanique. Par ailleurs, jobLevel("runesmith") n'apparaît que quatre fois dans tout le bundle : l'affichage du badge de métier, deux notifications de montée de niveau, et le test G < b.jobReq. Rien d'autre ne dépend du niveau — ni bonus de réussite, ni réduction de coût.

Deux lectures possibles, à trancher côté design. Soit il manque un palier supplémentaire — l'interface l'annonce déjà : ui.runesmith.max_tier_reached dit « Palier maximum atteint · le palier exo arrive bientôt » et exo_soon_body évoque un palier ultime brûlant du $VALORA. Soit le plafond du métier devrait être aligné sur son contenu réel, autour de 20–25.

RS-07 Confirmations asymétriques sur les actions destructrices Moyen

Statut

Confirmé — UX

Deux gardes différentes, aucune des deux alignée sur le coût réel de l'erreur.

// recyclage : confirmation à partir de « rare » seulement
onRecycleClick(e){ this.busy || (St[e.def.rarity] >= 2 ? this.openRecycleConfirm(e) : this.doRecycle(e)) }

// forge : confirmation seulement si l'objet peut être détruit
onUpgradeClick(e,t,i){ this.busy || !i || (i.def.destroyChanceBps > 0 ? this.openUpgradeConfirm(e,t,i) : this.doUpgrade(e,t)) }

Conséquences :

• Un équipement commun ou peu commun est détruit définitivement en un clic, sans confirmation, alors que l'encart du panneau précise « Le recyclage détruit l'objet définitivement. Cette action est irréversible. »
• Le palier 3 — 65 % de réussite, 15 000 or et 5 runes par tentative, échec entraînant une baisse de la statistique — passe sans aucune confirmation, puisqu'il ne comporte pas de risque de destruction. C'est pourtant la tentative la plus coûteuse à rater après le palier 4.

RS-08 Notes de version : noms de runes inexistants ou trompeurs Mineur

La note annonce : « les Runes de Puissance, de Protection et la rare Rune de Précision sont plus rares et valent plus ».

Un joueur suivant la note à la lettre cherchera « Rune de Puissance », trouvera la rune commune de Force, et en conclura qu'elle est rare. Aligner le texte sur les noms réellement affichés en jeu.

RS-09 Erreur trompeuse quand l'objet n'a pas d'instanceId Mineur

La liste latérale accepte les objets sans instance (gearCells ne teste pas instanceId), mais la forge les refuse et réutilise le message d'indisponibilité du service :

if(!this.econ?.authoritative() || e.instanceId == null){
  w.cue("ui_error"),
  this.setStatus(l("ui.runesmith.err_disabled"), "bad");   // « L'Atelier des Runes est momentanément indisponible. »
  …
}

Un objet listé mais non instancié produit donc un message annonçant une panne de service. Soit exclure ces objets de la liste, soit leur donner un message spécifique.

RS-10 Le poids 0.5 de la Rune de Vigueur est entièrement inopérant Mineur

La Rune de Vigueur est la seule à porter un poids inférieur à 1. Ce poids n'a d'effet nulle part :

• au rendement, il se simplifie avec celui du dénominateur (voir RS-02) ;
• au coût, il est écrêté : Rx calcule max(1, round(runeCount × max(1, poids))).

La vitalité coûte donc exactement le même nombre de runes qu'une statistique commune de poids 1. Soit l'écrêtage doit disparaître, soit le poids doit valoir 1 — en l'état la donnée exprime une intention que le code n'applique pas. À traiter avec RS-02, dont il est le corollaire.

RS-11 Code et chaînes résiduels Mineur

• Ix.tiers[0] (succès 100 %, coût nul) n'est jamais atteignable : tc() calcule floor(tier)+1 et démarre donc à l'indice 1. Entrée morte, source de confusion à la lecture de la table.
• Tx(o,e) se réduit à Math.round(o) pour tout o positif, et son second paramètre n'est pas utilisé.
• Deux clés i18n distinctes, ui.runesmith.over_tag et ui.runesmith.overcap_tag, portent la même valeur « OVER » et sont utilisées dans des modules différents. Un renommage de l'une ne suivra pas l'autre.
• Les chaînes ui.runesmith.upgrade_soon_title / upgrade_soon_body (« La forgemagie arrive bientôt ») datent de l'état antérieur et ne sont plus atteignables.

RS-12 Détection OVER impossible sur une fourchette fixe Latent

Statut

Non déclenché aujourd'hui — 235 fourchettes vérifiées, aucune n'est plate

La fonction qui qualifie un jet, et donc décide de l'affichage du marqueur OVER, sort avant d'avoir testé le dépassement :

function Fm(o,e,t){          // o = valeur du jet, e = min, t = max
  if(!(t > e)) return "none";   // sortie anticipée
  if(o > t) return "exo";              // test OVER — jamais atteint si min == max
  if(o >= t) return "perfect";
  const i = (o-e)/(t-e);
  return i >= 2/3 ? "high" : i >= 1/3 ? "mid" : "low";
}

Le jour où un objet à statistique garantie est ajouté — fourchette [5,5] —, la forge fonctionnera mais le marqueur OVER restera invisible partout : sac, hôtel des ventes, échange. Le symptôme sera silencieux et difficile à rattacher à sa cause. Déplacer le test o > t avant la garde clôt le sujet définitivement.