Optional EQLWiki integration — publish observed loot/spawn/faction data to wiki pages

[Frankthetankk]

Summary

EQBuddy already parses a lot of data from the /log file that would be useful on the EQLWiki (item drops, spawn timers, faction hits, zones, etc.). It would be great if EQBuddy could optionally publish that data to the wiki directly, using a linked EQLWiki account, instead of requiring manual copy-paste.

Proposed behavior

Add a way to link an EQLWiki account (API key or login) in EQBuddy settings.
Let the user select which observed data to contribute (e.g., loot drops, spawn timers, faction changes) and generate a wiki-formatted page/edit from it.
Before anything is published, show a diff/preview of the proposed wiki change so the user can review and approve it — nothing should auto-publish without confirmation.
Add a setting/default so that generated pages are published to the user's own userspace page first (e.g., User:/EQBuddy-loot-log) rather than directly editing the main article namespace. Publishing to the main wiki could then be a separate, explicit action.

Motivation

Keeps the "real" wiki pages protected from accidental bad edits, bots, or spam.
Lets EQBuddy users still crowdsource useful data (drop rates, spawn timers, faction info) without needing to manually format and submit wiki edits themselves.
Userspace-first default gives a low-risk staging area, and reviewers/editors could later merge good userspace data into the main articles.

Open questions

Does EQLWiki support API-based edits (e.g., MediaWiki API with OAuth/bot password), or would this need to go through a scraping/manual login flow?
What data fields are actually useful/wanted by the wiki's editors — worth checking with them before building this out, to match their expected page format.

See https://github.com/RealMaeel/seqo for inspiration.

---

EQBuddy 1.41.0 · Windows 19045

[DranakCorps-bot]

Built — the copy/paste half is coming in the next update, and your userspace-first instinct shaped where we drew the line. What ships now:

Drops by Creature knows what the wiki doesn't. Every drop you observe is checked against the creature's eqlwiki page (using the same cached lookups the Loot card already makes — no extra wiki traffic), and an amber ✦ marks anything that's news: an item missing from the page's loot list, a page whose loot list is empty, or a creature with no page at all — the headers say which. That's the "ID via color" piece: you can see at a glance, mid-farm, that you're holding something the wiki has never recorded.

✦ Copy for wiki builds what we're calling a contribution pack: for each flagged creature, a direct edit link to the exact page, plus a paste block in the wiki's own house style ({{:Item}} transclusions, the known_loot list format, a full {{Namedmobpage}} skeleton when the page doesn't exist yet — surveyed from live pages and Help:Contents). Two honesty rules baked in: rarity labels use the wiki's published bands (Always 100% · Common ≥50% · Uncommon ≥25% · Rare ≥5% · Ultra Rare <5%) and are only suggested when you have 10+ kills — thinner samples leave the label to the page's editors; and your observed counts always ride along as a suggested edit summary, denominators included, so reviewers can weigh the evidence.

On the account-linking / auto-publish half: deliberately not yet, and your own open question is the reason — this should be a conversation with the wiki's admins before it's a feature. The copy/paste flow gives us a shakedown period: if the packs EQBuddy generates turn out to paste cleanly and the wiki's editors like what shows up, THAT's the evidence to bring to them for a sanctioned API path (MediaWiki bot passwords/OAuth make the mechanics easy; the blessing is the hard part, as it should be). Your preview-before-publish and userspace-staging ideas are exactly the shape that conversation would start from.

Try it on your next farming session and say how the pastes land — the house-style formatting was built from a survey of existing pages, and real edits will find whatever the survey missed.

[DranakCorps-bot]

Now live in v1.42.0 — open Drops by creature… (right-click menu) after your next farming run and look for the amber ✦. The ✦ Copy for wiki button builds the contribution pack with edit links. Report back on how the pastes land — real edits are the shakedown that decides when we take the auto-publish conversation to the wiki admins.

[Frankthetankk]

I tested out the Copy for wiki link and here is what I noticed.

• For the following I see that on the wiki for the item Packmaster's Lash is already listed as a known loot and EQbuddy caught this as unknown.

=== Packmaster Dledsh — 1 drop not in the wiki's list ===
Edit page:  https://eqlwiki.com/index.php?title=Packmaster_Dledsh&action=edit
Add inside the known_loot <ul> list:

<li> {{:Packmaster's Lash}}</li>

Suggested edit summary: EQBuddy-observed drops — Packmaster's Lash ×1 in 1 kill (100%).

• This is good for NPC edits. We may also need to extend edits for the item pages under the 'Drops from' section. For example https://eqlwiki.com/Packmaster_Lash
• In the Copy for wiki link can you consider adding timestamps from our logs, or a toggle to enable displaying timestamps. This is for our own personal viewing in case we want to go back to search and review our logs.
• This may be wiki related, but some NPCs have a common loot section. for example Packmaster Dledsh. Far as I can tell the wiki doesn't explain the difference on how to use Unique and Common Loot sections. I can assume for rare NPCs Unique loot is for special items and common loot is the vendor type trash, but some NPCs list all of their loot in the Unique loot sections. Once we figure out the difference, consider adding to either the Unique and Common Loot sections.

---

EQBuddy 1.43.0 · Windows 19045

[DranakCorps-bot]

Field report applied — all three actionable items are built, coming in the next update. This is exactly the shakedown the copy/paste phase was for.

The false ✦ on Packmaster's Lash — found and fixed. The page lists {{:Packmasters Lash}}, no apostrophe; your loot line says "Packmaster's Lash". The comparison already folded upgrade tiers and backticks (wikis drop those too — same habit), and apostrophes now join the list. Your example became the regression test.

Item pages' Drops-from — in. Each creature section of the pack now ends with a per-item block: the item page's own edit link plus the * [[Creature]] line for its dropsfrom field (with the zone heading noted). No lookup behind it by design — you eyeball the page the link opens and paste only if the creature's genuinely missing, same review-first principle as the rest of the pack.

Timestamps — in. Each pack now carries a "log reference" line with the last time each flagged item dropped (log time), explicitly marked as for your own records rather than the wiki — so you can jump back to the moment in your log and double-check your own claim before publishing it. If you'd rather have first-seen or every-drop times, say so.

known_loot vs common_loot — you're right that the wiki doesn't define the split. Reading a few hundred harvested pages, your read matches ours: unique/known for the creature's signature drops, common for shared vendor-fodder tables — applied inconsistently by different editors. For now the pack keeps everything in known_loot (an editor can demote a line to common_loot in the same edit), because guessing wrong silently would be worse. This is a good question to put to the wiki's editors when the auto-publish conversation happens — their answer becomes the pack's rule.

[Frankthetankk]

One more ask for the wiki edits: when a page has blank fields, or an entry that doesn't match what we're observing, consider having the pack surface more than just the mismatch flag.

Caution up front on the mismatch case specifically: if an existing wiki value conflicts with our observed value, that shouldn't be treated as "wiki is wrong, overwrite it." Our log sample is limited — a mismatch is just as likely to mean we're seeing one data point in a range the wiki already captured correctly (or vice versa). The pack should probably present these as "observed X vs. wiki says Y" for a human to reconcile, not as a confident correction.

Fields I'd find useful added to the pack:

• Class — especially for difficulty-0 NPCs, where class is often left off the page entirely.
• Level — if kills span more than one level, report it as a range (e.g. 52–54) rather than collapsing to whatever level was most recently observed. A single-level report on a variable-level mob would be actively misleading.
• Zone — straightforward, but worth confirming it pulls the zone at time of kill, not just the last zone the tool saw the player in.
• Respawn timer — to the second if the log timestamps support it. If respawn varies kill-to-kill (which a lot of EQ spawns do), the same range-not-point logic from the level field probably applies here too.
• HP — the trickiest one. If the NPC heals itself or is healed by another NPC mid-fight, the parsed HP total is contaminated and shouldn't be published as-is — better to discard that kill's HP data than publish a bad number. Separately, big nuke/burn damage landing near the NPC's death can also skew the total if the parser is inferring max HP from damage-to-kill. A conservative approach: only trust HP estimates built from steady, low-hit melee-only parses, and until there's enough clean data, keep it as a local range rather than pushing a single number to the wiki.
• Attacks per round — while the NPC is unhasted. I don't think the logs give us visibility into whether an NPC currently has a haste buff active, so this field might need to ship with a caveat noting "unconfirmed unhasted," or it might not be reliably extractable at all — worth checking before building it out.
• Damage per hit — same idea, unbuffed on the NPC's side.
• Faction hit on death — worth recording even when the result is "no faction hit," since a confirmed absence is still useful data and saves someone else from re-testing it.
• Money drops — the wiki already has a dedicated field for this (I checked the stat block on A bandit (Eastern Karana) as a reference, e.g. 0 - 7 Golds, 1 - 16 Silvers), and it's already formatted as a low–high range per coin type. That's a good fit for our data: if only one kill has been observed, report it as a narrow/single-point range (e.g. "5 - 5 Silvers") rather than a fixed value, since one sample can't tell us "always this much" from "got lucky/unlucky once." Same 10+ kill confidence bar as loot rarity would make sense here too before suggesting a wider range with confidence.
• Engage message / death message — there's no dedicated wiki field for this today. Until there's a better home for it, dropping it into the Description field seems like a reasonable stopgap.
• Categories — flag any relevant categories missing from the page, same "surface it, don't auto-apply it" treatment as everything else here.

General note across all of these: given how much of this depends on "how many kills have we actually logged," it might be worth reusing the same 10+ kill confidence threshold that's already gating the rarity labels — anything under that stays a local/internal estimate and doesn't get suggested to the wiki yet.

[DranakCorps-bot]

Your first three items are now live in v1.44.0 — apostrophe folding (your Packmaster's Lash is the regression test), item-page Drops-from blocks with edit links, and last-seen log timestamps in the pack.

On the stat-block spec — this is genuinely good field-by-field thinking, and your "observed X vs. wiki says Y, human reconciles" doctrine is exactly right; it's going on the record as the pack's rule for every future field. Where each field stands honestly:

• Nearly free (EQBuddy already tracks the data per creature): money drops (per-mob coin is already aggregated, and the wiki's own low–high-per-coin-type format fits range reporting perfectly — your "5 - 5 Silvers for one sample" framing included), faction hit on death (including confirmed absence — good call that silence is data), and zone at time of kill (we key per-creature stats by the zone the kill line arrived in, not the tool's latest zone — your caution was worth checking, and it holds).
• Cheap: level as a range from /consider lines (we parse those; multi-level spawns report 52–54 style, never a collapsed point — agreed that a point would be actively misleading).
• Needs care: respawn timer — the new sighting-based learner in 1.44 actually measures cycles now, so ranges are becoming possible; class — we don't currently infer NPC class (spell casts hint at it; melee-only NPCs may be unknowable — likely ships as "when known").
• Your instincts were right to flag: HP (contamination from heals/burst is real; your steady-melee-parse-only rule is the right bar, and until then it stays local), attacks per round / damage per hit (no haste visibility in the log, so at best "unconfirmed unhasted" — may not clear the honesty bar at all).
• Agreed across the board: the 10+ kill confidence gate applies to every suggested field, same as rarity.

This lands as a "stat block v2" iteration of the pack rather than piecemeal — the easy trio first (money/faction/zone), then level ranges, then the careful ones as their guards get built. Keep the field reports coming; two rounds in, this feature is measurably better because you're testing it.

[DranakCorps-bot]

Now live in v1.45.0 — the pack now ends each creature section with an observed stat block: zone at kill time (confirmed: the zone the kill line arrived in, not where you're standing at export), money per kill in the wiki's own low–high format with single samples labeled as such, and faction hits counted against your kills — including "no hits observed across N kills", your confirmed-absence point made policy. Everything says "compare, don't overwrite" right in the output, and the 10+ kill bar gates it same as rarity. Level ranges, respawn ranges, and the careful fields (HP, attacks per round) remain queued behind the guards you correctly said they need.

[Frankthetankk]

Following up on a few items from my earlier field list/questions that haven't come up yet in the v1.44/v1.45 rundown, plus a couple more after digging through the repo/release notes:

• Engage message / death message — still no dedicated wiki field for this that I can find, so my original suggestion was to drop it into the Description field as a stopgap until there's a better home for it. Curious whether that's the right call, or if it's worth holding off entirely until the wiki has a proper field.
• Categories — flagging any relevant categories missing from a page (same "surface it, don't auto-apply it" treatment as everything else in the pack). Wanted to make sure this didn't just get missed rather than deprioritized.
• /consider frequency for level ranges — since level comes from parsing /consider lines rather than kill data, is a single /consider per session enough to seed the level field, or should I be /consider-ing every kill (or at least whenever I'm unsure if a spawn is the same level as the last one) to actually build out a proper range?
• v1.47.0's "Knowledge refresh: eqlwiki catalogs" (Knowledge refresh: eqlwiki catalogs #72) — is this what keeps the cached wiki lookups current for the ✦ flagging/comparison logic? Does it run on a schedule (daily, on-demand, etc.)? Just want to understand how stale the cached catalog could get between refreshes, since a stale cache would produce false ✦ flags the same way the apostrophe mismatch did, just time-based instead of formatting-based.
• Does the 10+ kill confidence gate persist across sessions? The README mentions logs get truncated after 60+ minutes of inactivity (treated as a session boundary). For slower-respawn or less-farmed NPCs, does EQBuddy's per-creature kill count carry over between sessions, or does the counter reset when the log does? This affects whether hitting the threshold on some mobs is realistic in casual play vs. requiring one long sitting.
• Manual wiki cache refresh — if I understand right, the eqlwiki catalog cache updates weekly. Would it be possible to manually force a refresh, either for a single page or for all recently changed pages? Special:RecentChanges on the wiki looks like it'd be a good source for the latter — pull whatever's changed since the last cache refresh rather than needing a full re-crawl. Mainly asking because if a wiki page gets edited mid-week, I'd rather not wait up to 7 days for EQBuddy's comparison logic to catch up and risk a false ✦ (or a missed one) in the meantime.

No rush on any of these — just didn't want them to fall through the cracks since everything else on the list got a clear answer.

[DranakCorps-bot]

Round three, in order — with one built tonight because your question exposed a gap:

• /consider frequency — your premise was ahead of the code: until tonight the pack's level field shipped empty. As of v1.48.0, every /con line feeds a per-creature min–max (the con line is the only place the log ever states a level). Practical discipline: one con seeds a single value; con again when a spawn feels different — each distinct level widens the range, repeat cons of the same level add nothing. The stat block says which you have: "12 - 15" vs "12 (every /con this session agreed)".
• ✦ freshness vs the knowledge refresh — two separate systems, deliberately. The ✦ comparison fetches the creature's page live with a 7-day per-page cache on your machine, so a wiki edit reaches your flags within a week worst-case, immediately for pages you haven't viewed lately. The weekly "Knowledge refresh" PR maintains the embedded catalogs (quest tracker data, fade messages, zone graph). Your Special:RecentChanges instinct is exactly how the refresh works — it pulls only what changed since the last run.
• Manual refresh — for embedded catalogs I can trigger the refresh on demand (it's a workflow button), and yes it's RecentChanges-driven so it's cheap. A per-page "re-check now" button on the item/creature popup for the ✦ cache is a good small ask — queued.
• 10+ kill gate persistence — honest limitation: per-session today. Kill counts live in session stats, so a log split or 60-minute gap resets the denominator. A durable per-creature kill ledger (like the quest ledger) is the right fix and it's on the list — it pairs with the archived-session review feature another player just asked for.
• Engage/death messages — hold off on the Description-field stopgap, in my view: flavor text mixed into a data field is what makes pages unparseable later (see: this whole thread). Better to ask the wiki admins for a dedicated field; the pack will happily fill it the day it exists.
• Categories flagging — not missed, queued: the pack will suggest missing categories with the same surface-don't-apply treatment. Related tonight: Missing Item: Phosphorous Powder, from undead frogs in LGuk. Kind of… #75 found Phosphorous Powder uncategorized as a Quest Item — exactly the gap category-flagging would catch automatically.

[Frankthetankk]

Bug: contribution pack lists the same item multiple times instead of deduplicating upgrade tiers into one wiki entry

The contribution pack's known_loot paste block generates a separate <li> line per upgrade tier observed, but since the suffix isn't actually included in the link text, these come out as duplicate, indistinguishable lines rather than one deduplicated entry. For example, two different tiers of the same base item (base and +1) can produce two identical lines like:

<li> {{:Rusty Battle Axe}} <span class='drare'>(Ultra Rare)</span></li>
<li> {{:Rusty Battle Axe}} <span class='drare'>(Ultra Rare)</span></li>

The edit summary correctly separates these by tier ("Rusty Battle Axe ×47" vs "Rusty Battle Axe +1 ×20"), so the distinction is tracked internally — it just isn't carried into the actual <li> text. But given the wiki's convention against per-tier listings on loot pages, this NPC should really only get one Rusty Battle Axe line total regardless — the tier distinction doesn't belong on this page at all, so it's not just a formatting fix, it's a dedup fix.

This shows up on any well-farmed NPC given upgrade tiers run up to +10 — the more kills logged, the more likely multiple tiers of the same base item get observed, and the more duplicate/inflated the "drops not in the wiki's list" count becomes relative to the actual number of distinct missing items.

Suggested fix: the pack should strip the tier suffix when building the known_loot list and merge same-item drops across all observed tiers into a single line/count, rather than emitting one line per tier. The edit summary can still show the tier breakdown if that's useful for editor review — that part is already correct — but the actual paste block shouldn't propose multiple entries for what the wiki treats as one item.

The same issue likely affects the "Drops from" item-page edit links section, which would currently offer to add the same line (e.g. * [[Creature Name]]) to the same item's page more than once.

A few other things worth fixing while in this area:

• Suggested edit summary is far too long for an actual wiki edit summary field. It currently lists every single item, count, and percentage — useful detail, but a wiki edit summary is meant to be a short one-line description, not a full itemized report. Consider trimming this down to something like "EQBuddy-observed drops (N items, M kills)" or similarly condensed, and let the full itemized breakdown live only in the log reference section (which isn't meant for the wiki anyway) rather than in the field that actually gets submitted with the edit.

• Add a blank line between "Suggested edit summary" and "Log reference." Right now they run together with no visual separation, which makes the block harder to scan, especially once the edit summary line is long.

• Log reference should include the date, not just the time. Right now entries just show a bare time like "last at 13:53:58," with no date attached — if a farming session (or the underlying log) spans midnight or multiple days, there's no way to tell which day a given "last at" timestamp actually refers to. If the date is the same across every entry in a given pack, it only needs to be listed once (e.g. as a header line) rather than repeated per item, to avoid cluttering the block — the current per-item time-only format is fine otherwise.

• NPC name prefixes are being dropped. A pack titled its section using just the base creature name (e.g. "Decaying skeleton," linking to .../Decaying_skeleton), when the actual in-game observed name is "a decaying skeleton," all lowercase, and the wiki page appears to be titled differently as well. The pack needs to preserve the NPC's full name as observed in-game — including any article prefix like "a," "an," or "the" — rather than stripping it, so at minimum the article isn't lost. I'm not sure what capitalization convention the wiki actually wants here — I've seen both exact-observed-case names and differently-capitalized names used on existing pages — so this may need clarification on what the correct target format is before it can be fixed properly. Either way, dropping the article prefix looks like an unambiguous bug regardless of the capitalization question, and it may also affect EQBuddy's own page-matching logic, which could explain some of the "not in the wiki's list" flags if the correct page just isn't being found under the name being searched for.

EQBuddy 1.53.2 · Windows 19045

[DranakCorps-bot]

Fixed — coming in the next update: upgrade tiers now fold to one wiki entry (the {{:Item}} transclusion drops the +N, so base and +1 made two identical lines — your example was exactly right), and the "N drops" header counts the folded list. The edit summary keeps the per-tier counts, which is where that detail belongs. Thanks for the sharp QA, as ever.

[Frankthetankk]

Thanks for the fix on the duplicate tier lines! A few other items from that same report don't seem to have been addressed yet — wanted to make sure they didn't just get lost in the shuffle:

• Edit summary length — still generates a full itemized list (every item, count, percentage) as the suggested wiki edit summary, which is much longer than what a summary field is meant to hold. Would still suggest condensing this to something like "EQBuddy-observed drops (N items, M kills)" and keeping the itemized breakdown in the log reference section instead.
• Blank line between "Suggested edit summary" and "Log reference" — these still run together with no separation, making the block harder to scan.
• Log reference missing the date — entries still show only a bare time ("last at 13:53:58") with no date, so there's no way to tell which day a timestamp refers to if a session spans midnight or the log covers multiple days. If the date's the same across every item in a pack, a single header line would be enough rather than repeating it per item.
• NPC name prefixes still being dropped — the pack still seems to title sections using just the base creature name rather than the full in-game name including any article ("a," "an," "the"). Since I raised this I've confirmed the actual observed name in this case is lowercase ("a decaying skeleton"), though I'm honestly not sure what capitalization convention the wiki wants here — I've seen pages use both exact-observed-case and differently-capitalized titles. The article-dropping part seems like an unambiguous bug regardless of that question, and may also be why some drops get flagged as "not in the wiki's list" if the comparison logic can't find the correctly-titled page.

Also — separate from the above, the comment right after the tier-dedup fix posted as just System.Collections.Specialized.OrderedDictionary[D_kwDOTche5M4AoVn_], which looks like a stray debug object got posted by accident rather than an intended reply.

No rush on any of this — just didn't want these to fall off the list since the tier-dedup fix covered the main issue but not the rest of the report.

[DranakCorps-bot]

All four addressed and live in v1.57.1 — nothing fell off the list, and thank you for keeping it:

1. Edit summary — now exactly your suggested shape: "EQBuddy-observed drops (3 items, 12 kills)." The itemized breakdown moved into the log reference.
2. Blank line — the summary and log reference are properly separated, and the log reference is an indented per-item list rather than one run-on line.
3. Dates — the log reference carries a single day header when every timestamp shares a day ("— Mon Aug 11 2026:") and full per-item dates when a pack spans midnight. Your suggested single-header-when-uniform design, verbatim.
4. Article-dropping — the real bug was upstream: the log reader normalizes creature names by stripping a/an/the, and the pack was titling sections with that stripped name. Sections and item-page [[links]] now use the RESOLVED wiki title whenever the page lookup succeeded (which also answers your capitalization question — whatever the page actually uses wins). For pages that don't exist yet the stripped name is genuinely all we have, so the create-page instructions now say to restore the article the log reader drops. On your false-✦ theory: the lookup ladder already tries the "a "+lowercase and title-case forms plus a fuzzy backstop, so most articled pages resolve — but if you catch a specific mob flagged ✦ whose page exists, paste the name and we'll trace it.

And yes — the OrderedDictionary comment was exactly what you guessed: a scripting slip on our side, not a message. It's deleted, and the tooling that produced it has been corrected. Good catch on every count, as usual.

[Frankthetankk]

Four things from today's testing.

Bug: new-page template pulls the wrong zone for Innoruuk, the Prince of Hate

In a contribution pack where this creature had no existing wiki page, the generated {{Namedmobpage}} template sets | zone = [[Nagafen's Lair - Solo 4 (Refined)]] and closes with [[Category:Nagafen's Lair - Solo 4 (Refined)]] — but the same entry's "drops from" cross-reference links and observed stat block both correctly say zone (at kill time): The Plane of Hate - Solo 1 (Awakened), matching every other Hate-zone creature in the same pack. The zone/Category fields on the new-page template look like they're pulling from a stale or unrelated value rather than the actual kill zone, which would publish a wrong zone if pasted as-is.

Bug: "Innoruuk, the Prince of Hate" flagged as no wiki page, but the page already exists under a different title

The same entry offers to create a brand new page at Innoruuk, the Prince of Hate, but this creature is already on the wiki at https://eqlwiki.com/Innoruuk_(God) — just under a different name. I'd agree the wiki page should probably get renamed/extended to match the observed in-game name, but that's a wiki-side edit for their editors to make, not something EQBuddy should assume has already happened. Until the page is actually moved, EQBuddy's page-matching should know this creature already has a page under Innoruuk (God) rather than proposing a duplicate new-page creation — otherwise this would publish a second, disconnected page for a boss the wiki already documents.

Bug: "Spiroc Lord" edit link drops the article, missing the existing page

Same pack, separate entry: the in-game name and the wiki's own page title are both "The Spiroc Lord" (capitalization matches exactly), but the pack's section header, edit link, and [[Spiroc Lord]] cross-reference links all use the article-stripped form. This is the article-dropping issue from v1.57.1 resurfacing on a page that does exist — v1.57.1's fix was supposed to use the resolved wiki title (article restored) whenever page lookup succeeds, and the stripped name only as a fallback for pages that don't exist yet. Since "The Spiroc Lord" is a real, matching page, this looks like the resolution step either failed to find it or isn't being applied consistently.

Feature idea: "Drops by creature" scoped beyond the current session

Right now the Drops by creature window (and its Copy for wiki output) only covers the active session. Could this optionally run against my full log history — all archived sessions for the same character/server — instead of just what's loaded right now? A lot of my kill counts per creature are thin (1-2 kills) purely because I've farmed the same mob across multiple separate sessions rather than one long sitting; aggregating lifetime kills per creature would let more of these actually clear the 10+ kill confidence bar for rarity labels, faction-hit confidence, etc., instead of staying stuck as "thin sample" forever even after real cumulative playtime. Scoping could be a toggle — "this session" vs "all history for this character" — rather than replacing the current view outright.

---

EQBuddy v1.80.0

[DranakCorps-bot]

Four solid reports again — thank you. Triaging honestly rather than claiming fixes I haven't made yet, since three of these are in the wiki-pack generator and want doing together.

1. Wrong zone on the new-page template for Innoruuk. Accepted as a bug, and your evidence pins it: the same entry's cross-references and observed stat block say The Plane of Hate - Solo 1 (Awakened), while the {{Namedmobpage}} zone field and Category say Nagafen's Lair - Solo 4 (Refined). Two different code paths reading two different sources for the same fact, and the template one is reading something stale. That it would publish a wrong zone if pasted as-is makes it the most urgent of the four.

2. Innoruuk already exists as Innoruuk (God). Also accepted, and your framing is the right one: EQBuddy shouldn't assume a wiki rename has happened, but it equally shouldn't propose creating a duplicate page for a boss the wiki already documents. The page-matching ladder tries article and case variants but has no notion of a creature being documented under a different title. That's a real gap rather than a tuning problem — it probably needs an alias map for the handful of gods and bosses whose in-game name and wiki title genuinely differ.

3. "The Spiroc Lord" — article-dropping resurfacing. This is the one that stings, because v1.57.1 was supposed to have closed it. Your diagnosis is almost certainly right that the resolution step either failed to find the page or isn't being applied consistently across all three places (section header, edit link, [[…]] cross-references) — the fix may have covered one or two of those and not the third. Worth checking whether the lookup succeeded and the resolved title was then dropped on the floor, versus the lookup failing outright.

4. Drops by creature across all history. Good idea and I think clearly right. Your argument is the persuasive part: thin samples that are thin only because they're split across sessions, when the whole point of the confidence bar is cumulative evidence. A "this session / all history for this character" toggle rather than replacing the view is also the correct shape — the session view is what you want mid-farm.

All four are going to David rather than getting a same-day fix from me. Nothing here is a misunderstanding on your part; three are genuine defects and the fourth is a sound feature. You've now caught the article-dropping issue twice, which suggests the first fix needed a test pinning it rather than a code change alone — that's on us.

[DranakCorps-bot]

All three bugs are fixed and shipped in v1.82.0. Details, because two of them are more interesting than "typo fixed":

1. Wrong zone on the new-page template. Exactly as you diagnosed — two paths, two sources. The kill zone was already being computed correctly for the cross-references and the stat block; it just happened twenty lines below the point where the page skeleton was built, so the skeleton used the player's current zone instead. Same entry, two answers. Now computed once, above both.

2. "The Spiroc Lord" — and you were right that v1.57.1 should have caught it. v1.57.1's change was correct: print the resolved wiki title. The bug is a layer beneath it. The API is queried with redirects=1, so asking for the article-stripped "Spiroc Lord" succeeds — it lands on "The Spiroc Lord" and returns that page's content. But the resolver recorded the title it had asked for, not the one it landed on. So the "resolved title" was the stripped name, and the packs printed it faithfully. Your instinct that "the resolution step either failed to find it or isn't being applied consistently" was the right shape — it found it, and then threw the answer away. Lookups now carry the title the wiki actually served, which is the only one safe to put in a [[link]] or an edit URL.

3. Innoruuk. The candidate ladder now tries the base name when a creature is named with an epithet (X, the Y), so "Innoruuk, the Prince of Hate" reaches "Innoruuk" and the wiki's own redirect finishes the trip to Innoruuk (God). Combined with fix 2, the pack now links the existing page instead of proposing a duplicate — and it does so without EQBuddy assuming any wiki rename has happened, which was your condition.

All three now have tests. You've caught the article-drop twice, and a second fix without a test pinning it would just have been waiting for your third report. That one's on us, and it's addressed.

4. Drops by creature across all history — not in this release. It's a good idea and I think clearly right; your argument about samples being thin only because they're split across sessions is the persuasive part, since cumulative evidence is the entire point of the confidence bar. It needs real thought about which archived sessions count (same character and server, presumably, and what happens across a name change), so it's on the list rather than rushed in beside three bug fixes.

Thanks — that's four rounds of genuinely high-quality testing on this feature.

[Frankthetankk]

Circling back on item 4 from my last report (Drops by creature across all history) — this became Ask 2 in #217, which has since been discussed in more depth and is now approved in principle: full history, account-wide, no per-session toggle. Still pending a performance check on large archived histories before it becomes the default.

Since that was the last open item here and everything else in this thread has shipped, I'm going to close this one out and continue following the history/scope question over on #217 instead.