User:FizzleMaster/Sandbox/Itembox

Description

Sandbox redesign of Template:Itembox, matching the in-game tooltip's layout, wording, and field placement rather than the wiki's previous single-column free-text blob. Within each stat column, labels left-justify and values right-justify, matching the in-game tooltip's visual alignment. The box has left/right padding (currently 1.4em) around all content, tuned to visually match the in-game tooltip's own margins.

Important: always enter base (Tier 0) values. EQL's item upgrade system (see Item Upgrade System) lets players raise an item's tier with motes, which increases its stats via a slider — the wiki should record only the base values an upgrade slider derives everything else from, never a specific upgraded copy's numbers.

Note on Class: the Exaltation swap system can change an item's class restriction (e.g. socketing a class-specific effect into an otherwise multi-class item can lock it to that class). Record the item's class access with no swapped-in Exaltations applied — its own original kit only.

Note on Skill: use the exact in-game skill name, e.g. 1H Piercing rather than Piercing — Rogues do not have access to a 2H Piercing skill, so the Backstab logic checks for this exact string.

Ratio shown as an empty visual placeholder: the Ratio row (Base Dmg ÷ Delay) always renders when the item has a dmg value, with its label present but the value intentionally left blank (<span class="itemratio"></span>). This mocks up how the page is expected to look once the item upgrade tier slider is implemented — that tool would compute and fill in Ratio live based on the selected tier, which a static wiki page cannot do on its own for a value tied to a variable upgrade tier. The placeholder just reserves the correct labeled position without guessing at the computation.

Zero-value safeguard: every numeric stat field except Weight is skipped entirely — not rendered at all, with the layout adjusting automatically to close the gap — if the value evaluates to 0. This includes Base Dmg, Delay, Dmg Bon, HP, Mana, Endurance, Strength, Stamina, Intelligence, Wisdom, Agility, Dexterity, Charisma, and all six SV resists. This guards against an editor typing 0 out of habit for a stat that doesn't apply, since with named parameters it's easy to treat this like a form to fill in completely rather than leaving a field genuinely blank. Leaving the field blank works exactly the same way as entering 0 — and so does entering +0, since the check now compares the evaluated value, not the raw typed text (see the plus-sign note below).

Exception: Weight always renders, even at 0. Weight is a real physical attribute (a weightless item is meaningful data, not "not applicable"), so |weight=0 always shows and is normalized to display as 0.0 rather than a bare 0, matching the in-game tooltip's formatting.

Size and Skill always render regardless of value — these aren't numeric bonuses and have no meaningful "zero" state to guard against.

Numeric validation: the following 23 fields must contain a genuine number — digits, an optional leading minus sign for negative stats (e.g. Charisma penalties), and an optional decimal point (e.g. Weight) — or the page displays a short red "⚠ Invalid value" warning in that field's spot instead of a broken parser error or silently-wrong data: weight, hp, mana, endurance, dmg, backstab, delay, dmg_bonus, str, sta, int, wis, agi, dex, cha, svmagic, svfire, svcold, svdisease, svpoison, svvoid, combat_effect_level, click_required_level. Letters, symbols, or text (e.g. five, N/A, ?) all trigger the warning. This works by testing each value through MediaWiki's #expr, which only accepts real numeric expressions, caught with #iferror before it can leak MediaWiki's own longer default error text (Expression error: Unrecognized word "X". — nearly 3x longer than our message and untested against these narrow columns).

Leading plus signs are stripped automatically. If an editor types +5 for any of the 23 validated numeric fields, the page displays 5 — a plus sign is redundant on a stat value, since a number with no sign is already understood as positive. A minus sign is preserved correctly (-30 still displays as -30). This works because every validated field's displayed value is the *result* of running it through MediaWiki's #expr (the same calculation already used to check validity), rather than the raw text the editor typed — and #expr math naturally treats +5 and 5 as equivalent, so the sign disappears as a side effect of evaluating it as a number, with no separate string-stripping logic needed.

Side effect: decimal values also get normalized. Because the displayed value passes through #expr's math evaluation, a value like 3.50 for Weight will display as 3.5 — the trailing zero is dropped, same as how any calculator would simplify it. This is treated as a desirable side effect (cleaner, consistent formatting) rather than a bug, but worth knowing in case an editor notices their exact typed formatting doesn't survive character-for-character.

Effect fields silently accept wiki-link brackets, and even a custom-display-text pipe, stripping down to the plain page name automatically. If an editor types focus_effect, worn_effect, combat_effect, or click_effect as a plain spell name (Unrighteous Bash), wraps it in brackets ([[Unrighteous Bash]]), or pastes a full piped link with custom display text ([[Oathbreaker's Curse|Curse proc spell]]), all three now produce the same correct, working link using the real page name. The template already builds its own [[ ]] wikilink around whatever's entered, so an editor who also supplies brackets — or a pipe — would otherwise end up with a broken link: a literal double-bracketed string in the simple case, or (with a leftover pipe) a malformed three-part link that corrupts parsing of every effect field after it in the box. Both cases are now caught and corrected silently, with no warning shown, since there's no real ambiguity: the brackets are redundant, and any custom display text is simply discarded in favor of the true page name, which the template restyles identically either way via <span class="itemeff">.

Implementation note: this strips brackets one character at a time — replacing every lone [ and every lone ] individually — rather than matching the pair [[/]] as a whole. That's a deliberate workaround, not a stylistic choice: MediaWiki's parser treats a literal [[ sequence as the start of a real wikilink as soon as it's tokenized, even when it's sitting inside a parser-function argument rather than being an actual link — so searching for the two-character pair [[ with #replace doesn't reliably match on this install. Searching for the single characters individually sidesteps that entirely, since a lone bracket isn't link-opening syntax. After stripping, the result is split on the first {{!}} (MediaWiki's built-in literal-pipe magic word, native since MediaWiki 1.24) via #explode, keeping only the portion before it — so any trailing "|display text" is dropped rather than leaking through and breaking the rest of the box.

Backstab Dmg has special logic, not just simple validation: when the weapon qualifies (class contains ROG or ALL, AND skill is exactly 1H Piercing), computed once via #vardefine into box_rogok and box_piercing to keep the nesting shallow and less error-prone than checking both conditions inline (a prior version of this template broke from a brace-count mistake at this exact spot — see the note in git history / discussion thread if this evolves into a real submission):

• If backstab is left blank, it auto-fills from dmg — "Backstab Dmg: [same value as Base Dmg]". This is a real EQL mechanic: Backstab damage happens to equal base damage on many 1H Piercing weapons, so this saves the editor from retyping it, while still being fully overridable (see below).
• If backstab is explicitly given a valid number, that value is used instead of the dmg default — set this whenever Backstab Dmg genuinely differs from Base Dmg in-game (confirmed to happen — do not assume they're always equal).
• If backstab is explicitly given an invalid value, the row shows the "⚠ Invalid value" warning.
• If backstab is left blank AND dmg itself is invalid, the Backstab row ALSO shows "⚠ Invalid value" — even though the editor never touched the backstab field. This is deliberate: since Backstab silently auto-fills from dmg, a broken dmg value would otherwise pass through into Backstab undetected. Two warnings for one root typo (Base Dmg's own row plus Backstab's) is judged better than letting bad data through silently on the second row.
• If the weapon doesn't qualify (wrong class or wrong skill), the entire Backstab row is omitted, exactly as today — no validation runs in this case either, since nothing would display regardless of what backstab contains.

Parameters:

• itemname, lucy_img_ID — same as original
• flags — free text, e.g. Lore Equipped, Attunable, Quest, Placeable
• class, race, slot
• size, weight, skill, delay
• dmg, dmg_bonus, backstab (optional; defaults to dmg for Rogue-usable 1H Piercing weapons — see Backstab section above)
• hp, mana, endurance
• str, sta, agi, dex, wis, int, cha
• svmagic, svfire, svcold, svdisease, svpoison, svvoid
• focus_effect, worn_effect — a linked spell name (brackets and custom display text optional, see note above)
• combat_effect, combat_effect_level — linked spell name + (Req Level X)
• click_effect, click_effect_flag (e.g. Must Equip), click_cast_time, click_required_level, click_cooldown

Deliberately NOT tracked: Exaltation slot contents (which item currently provides each effect) — this is mutable player customization, not base item data. Only record an effect here if the in-game Exaltation slot shows the item's OWN name as the source.

Deliberately omitted: Ratio (Base Dmg ÷ Delay) — client-computed display value, not something an editor enters; reserved for the admins' planned upgrade-tier slider tool (see the Ratio placeholder note above).