Wiki contribution pack deserves its own home (and full log history)

[Frankthetankk]

Wiki contribution pack: move out of Drops by Creature, scope to full history, and consider a rarity signal from /consider

Where this feature actually stands today

"Copy for wiki" (discussion #65) started in v1.42.0 as a drops export tucked into the live Drops by Creature window. Since then it's quietly grown into something much bigger than a loot feature:

• v1.44.0 added the item-side cross-reference — a "Drops-from" paste line and direct edit link added to each item's own wiki page, so items can point back at every creature that's dropped them, not just creature pages pointing forward at loot.
• v1.45.0 folded in the observed stat block: zone-at-kill-time, money-per-kill in the wiki's own low–high range format, and faction hits (including honest "no hits observed across N kills" reporting).
• v1.48.0 added con-derived level ranges, widening with every /consider.
• Rarity band suggestions have been gated on kill count (10+) since v1.42.0.

So this is no longer a drops tool — it's EQBuddy's whole mechanism for turning what a single player has personally witnessed into wiki-quality data, across three separate content types (creature pages, item pages, and rarity classification). No other EQL companion app does anything like this. The UI just hasn't caught up to what the feature became: it's still buried behind a button in a live loot window, discoverable only if you happen to be thinking about loot at the exact moment you'd want to contribute.

Ask 1 — relocate and rename

Move the entry point out of Drops by Creature and into Data & imports, alongside Import achievements and the gear-list import — the app's existing hub for bringing outside data in and sending observed data out. A wiki contribution pack belongs in that neighborhood conceptually.

Worth renaming too, since "Copy for wiki" undersells what it now does and reads as loot-only. Something like "Wiki contribution pack" would better signal that it covers creatures, items, and rarity together in one export.

Drops by Creature's own live view should stay exactly as-is for in-the-moment farming decisions ("is this trip worth it") — only the wiki-export entry point moves.

Ask 2 — scope to full history, not the current session

Right now the export is locked to whatever's in the live session. Session History already stores everything from past sessions (per STORE-006), so the data needed for a stronger contribution already exists on disk — the export just never reaches it.

This isn't really a "per-session vs. all-time toggle" request. Once full-history is available there's no case where a smaller sample makes a better wiki edit, so I'd propose the wiki-pack generator simply reads across full history by default rather than adding a second mode to maintain. Concretely this fixes:

• Rarity threshold spread thin across sessions. Farm a zone in three 20-minute sessions with 4 kills each and you never cross the 10-kill bar in any single export, even with 12 real kills total.
• Money/faction samples staying "one sample" longer than necessary. Both explicitly print an honest small-sample caveat right now — pooling gets to a trustworthy range (or a confident absence) much faster.
• Level ranges from /consider narrowing slower than they should. A con from three weeks ago is exactly as valid as one from five minutes ago; there's no reason session boundaries should discard it.
• Fragmented contributions. Per-session exports mean submitting several partial edits for the same creature over time, sometimes with contradictory rarity guesses from small samples, instead of one well-supported edit.

This should be a straightforward query-and-roll-up over Session History's existing stored rows rather than new data collection — feels like Core/UI.Shared logic per the shared-first rule, testable with a fixture of several fake archived sessions asserting the pooled counts come out right.

Open questions worth settling in-thread rather than assuming:

• Pool across all characters on the account, or stay per-character with an "include other characters" toggle? (Different characters likely farm different zones, but drop rate/faction/spawn facts are server-wide, not character-specific.)
• Any case for excluding very old sessions (e.g. pre-dating a zone retune) from the pool, or is "since" filtering unnecessary scope creep?

Ask 3 (separate, but related) — a confirmed-rarity signal from /consider

I raised the known_loot vs common_loot question with the wiki admins/editors directly in the community Discord, since it turned out to matter here too. Summary of where that landed:

• Confirmed from the template source itself: Template:Namedmobpage has no enforced logic behind the split — it's purely mechanical (the "Unique Loot" heading only appears if common_loot has any content). The official NPC Page Blueprint doesn't even document common_loot as a field, so editors copying the blueprint have no way to know it exists.
• One wiki admin: the split is deliberately unenforced — "no threshold," and correctly not about drop rate ("common doesn't have anything to do with drop rates" — mesh armor being common_loot doesn't mean it's not valuable). The real test is closer to "is there anything notable about this specific mob," which can include being one of only two sources for a quest item. Explicitly supportive of adding an in-game-sourced rare=true flag off /consider text, and offered to add distinct CSS styling for it once it exists.
• A second wiki admin: hasn't weighed in on the loot-split question yet specifically; currently unavailable and asked to be looped back in simply when able.
• Other community contributors floated related ideas — consolidated drop tables for widely-shared items, renaming known_loot for clarity — but nothing there blocks this ask.

The relevant point for EQBuddy: rarity is currently guessed from kill count against wiki-published bands, but /consider already prints rarity directly. The exact log text is a rare creature — confirmed from my own log, not inferred.

Some background that clarifies why this is a stable signal rather than a fragile one, from the wiki's own Category:Named Mobs page: EverQuest (and EQL) mobs fall into three categories — named, placeholder, and static. Named mobs share a spawn point with non-named "placeholder" mobs, and each spawn at that point has a chance of being either. Static mobs always spawn as themselves. This is exactly the named/placeholder distinction behind the "rare NPC" concept in old EverQuest — a rare drops unique loot uncommon to other NPCs, which lines up with the known_loot (unique) vs common_loot (shared) split discussed above. EQL is reportedly phasing out placeholders in the revamped dungeons specifically (Befallen, Blackburrow, Najena, etc. — the named mob spawns every time there instead of rolling against a placeholder), but the /consider text itself — a rare creature — isn't tied to whether a placeholder mechanic exists behind a given spawn. It's still how the game flags a named mob as one of these historically-rare spawns, placeholder-era or not, so the signal should stay reliable as that phase-out continues.

Proposed handling, following EQBuddy's existing "your own observation beats a heuristic" pattern (typed spawn timers, etc.):

1. Parse the con response for the exact string a rare creature, alongside the level parsing that's already there — same log line, same event.
2. Treat a confirmed rare con as authoritative, overriding the kill-count guess when present.
3. Fall back to the current kill-count method only when no con has ever confirmed rarity either way.
4. Feed into the same full-history aggregation from Ask 2 — one confirmed rare con anywhere in history should settle it, no need to wait for repeat sightings once the game has said so directly.

Worth noting given the wiki-text-fragility problem EQBuddy already hit once (Symbol of Pinzarn, discussion #120 — wrong wiki-stated text meant a spell was undetectable with no error shown): this signal comes from EQL's own client log output, not a wiki-maintained string, so it doesn't carry that same failure mode — it can't silently go stale the way a wiki-sourced landing message can.

Ask 4 (small, separate) — drop the app name from suggested edit summaries for now

Right now the contribution pack's suggested edit summary reads something like:

Suggested edit summary: EQBuddy-observed drops (1 item, 6 kills).

I think we should omit "EQBuddy" from these summaries for the time being. The concern: an editor or admin reviewing edit history later could reasonably read a consistent "EQBuddy-observed" pattern across many edits as a sign of automated/bot editing, even though every one of these edits is submitted manually by a human reviewing the suggested pack first. Most wikis (this one included, presumably) have policies around unapproved automated editing, and a misread here is a real risk to a contributing editor's account — not because anything automated is actually happening, but because the summary text looks like it might be.

We haven't asked the wiki admins about automatic/bot-assisted edits at all yet, and the wiki likely isn't ready to have that conversation until the contribution pack itself has matured (which is what Asks 1–3 above are about). Until that conversation happens and admins are comfortable explicitly labeling EQBuddy-assisted edits, I'd rather the summaries stay neutral — something like:

Suggested edit summary: observed drops (1 item, 6 kills).

Same information, no tool-name flag. This should apply to both the creature-page drops summary and the item-page "Drops-from" summary (v1.44.0), for consistency.

Worth being clear this isn't a permanent stance — once the pack is stable and admins are on board with crediting EQBuddy-assisted edits explicitly (possibly alongside whatever comes out of the Ask 3 conversation about a rare=true flag), attribution could become an opt-in setting rather than staying off by default forever.

This one's a small string-level change, not new logic, so it doesn't need to wait on Asks 1–3 and could ship as its own quick PR independent of the rest.

Why this is worth doing together

EQBuddy already runs a weekly automated inbound wiki refresh. The wiki contribution pack is the only mechanism going the other way — player-observed data flowing back out to the wiki. Right now that outbound path is throttled by both visibility (buried in a loot window) and scope (session-only). Fixing both turns it from a nice-to-have into a real answer to "what's the best way to keep eqlwiki current" — every player's full play history becomes a standing source of corrections and gap-fills, not just whatever they happened to notice in one sitting before remembering the button exists.

These four are a starting point, not the ceiling. As EQBuddy keeps growing, I'd expect the contribution pack to pick up more wiki edit types over time — more cross-referencing between creature, item, and quest pages, more signals the log can confirm directly the way /consider already confirms rarity. This discussion is meant to get the pack's foundation (where it lives, what scope it reads from, how it identifies itself) right first, so whatever gets added next has a solid, well-discussed base to build on rather than inheriting the same discoverability and scoping problems these four asks are trying to fix.

[DranakCorps-bot]

This is the most useful thing anyone has written about this feature, including me. You have also done something I had not: gone and asked the wiki admins what the known_loot / common_loot split actually means, and come back with an answer from the template source rather than an inference. Thank you — that settles a question I would otherwise have guessed at.

Taking the three asks separately, because they have genuinely different answers.

Ask 1 — relocate and rename: yes, and your framing is the argument

The observation that lands is that this stopped being a loot feature several releases ago and the UI never noticed. Creature pages, item pages, con-derived level ranges, money and faction ranges with honest small-sample caveats — that is a contribution pipeline living behind a button in a loot window, findable only if you happen to be thinking about loot.

Data & imports is the right neighbourhood — it is already where the app takes outside data in and sends observed data out. And "Wiki contribution pack" describes what it became. I would keep Drops by Creatures live view exactly as-is, as you say: that answers "is this trip worth it", which is a different question.

This one is a straightforward move and I would treat it as the default plan unless David says otherwise.

Ask 2 — full history: agreed on the substance, with one caveat I would want settled first

Your reasoning against a toggle is the part I want to underline: there is no case where a smaller sample makes a better wiki edit. That is right, and it kills the "per-session vs all-time" switch before anyone builds it. Two modes is two things to keep true.

The four concrete wins are all real, and the rarity one is the sharpest — 12 real kills across three sessions never crossing a 10-kill bar is the feature failing at exactly the moment it should fire.

On your open questions, my read:

• Per-character vs account-wide: pool it. Drop rates, faction and spawn behaviour are facts about the world, not about who witnessed them. The only reason to scope per-character is if the archive cannot tell characters apart cleanly, which is a mechanical question I would check rather than assume.
• "Since" filtering: scope creep, until someone reports a retune that actually poisoned a pool. Building a date filter for a hypothetical costs more than fixing it after the fact.

The caveat: this is a query across archived sessions, and I would want to know what it costs on a large history before promising it reads everything by default. If pooling is slow enough to be felt, the honest answer is "pool, but tell the user what it pooled" rather than a mode switch.

Ask 3 — /consider rarity: this is the one I would build first, and it is cheaper than you think

I checked before answering: EQBuddy already parses /consider. It reads the name and the level out of it for the level-range work you mentioned from 1.48.0. Nothing anywhere reads a rarity word. So this is not a new parser — it is a field we are standing next to and not picking up.

Also worth knowing: n3cr0nk1tt3n independently proposed the same signal in #185 this morning, from the opposite direction (suppressing false-positive spawn timers on townsfolk). Two people arriving at the same log line from unrelated problems is usually the sign it is the right primitive, and it would serve both features from one parse.

Your framing of it — observation beats heuristic, the same rule typed spawn timers already follow — is exactly how I would want it to behave: a con-confirmed rare outranks a kill-count band, and an unconfirmed band stays a suggestion.

What would move it today: the verbatim con line, pasted whole. You quote a rare creature from your own log and I believe you; what I need is where that sits relative to the rest of the line, because the existing pattern is anchored on the trailing (Lvl: N). One real line and I can match the actual string instead of a reconstruction — that is how #192 and #207 went from report to fix in one step.

What I am not doing

Ask 1 is a move I would make on my own judgement. Asks 2 and 3 change what the feature IS and how much it promises, so they are Davids call on scope and order rather than mine, and I have put them in front of him rather than starting. I would rather tell you that than have you assume it is queued.

— Dranak (Claude Code)

[DranakCorps-bot]

Following up on my own comment rather than leaving you to wonder: Ask 1 is built, and David has now ruled on Asks 2 and 3.

Ask 1 — done, and your framing changed the shape of it

It is a Wiki contribution pack window under Data & imports, in both the Windows and the Linux/macOS builds. Drops by Creature keeps its live view exactly as you asked — that answers "is this trip worth it", which is a different question.

But it did not end up being the move I described to you, and the reason is worth telling you because it is really your point followed one step further.

I went to relocate the button and checked what it actually reads first. It builds its export from the current session snapshot and the Drops window's own filter box. So the only thing that ever made its scope legible was that you were standing in front of that list while you pressed it. Fired from a menu, it would have copied a silent scope — the same amount of data, with the one clue about what it covered removed.

So the pack got a surface instead of a new home:

• a headline — "14 items across 3 creatures the wiki doesn't have"
• a breakdown of where the value is — "1 whose page lists no loot · 2 with new drops for an existing page"
• and a scope line that says out loud: "This session only — , since 18:22. Kills from earlier sessions are not counted yet."
• one row per creature, ordered by how much the edit is worth: no page at all first, then pages that record no loot, then pages missing drops
• Copy is offered only when there is something to paste, and looks disabled when there isn't

Which means Asks 1 and 2 were never independent, and neither of us said so. That scope line is the honest version of the feature as it stands today, and it is also the exact sentence Ask 2 deletes. Ask 1 could not be shipped without answering "what does it export when it is not in the Drops window", and the answer for now is "this session, and it tells you so".

One more thing carried across, because it was already the pack's best property and now it is on a second surface: a creature whose wiki page could not be read says "not checked yet" and is kept out of the pack entirely. It is never counted as a contribution and never worded as "nothing new" — those are different facts and telling you the wrong one would send you away from a contribution you actually have. Likewise, if the wiki already has everything you looted, it says so plainly: that is the wiki being in good shape, not EQBuddy finding nothing.

The ✦ markers stay on the Drops rows. Clicking one now opens the pack rather than silently filling your clipboard, and the footer says where the button went, so it is a signpost rather than a disappearance.

Incidentally, your trip to the wiki admins paid off in a place neither of us expected: the parser reads drops out of {{Namedmobpage}}'s known_loot/common_loot and nothing else, and I only got the test fixture right because that split was already settled. Two hours of the build went into a screenshot that looked completely plausible and was a picture of the wrong thing, twice — so thank you again for asking them.

Ask 2 — approved in principle

Pool the full history, account-wide, no per-session toggle. Your argument is the one that carried it: there is no case where a smaller sample makes a better wiki edit, and 12 real kills across three sessions never crossing a 10-kill bar is the feature failing at exactly the moment it should fire. No "since" filter until someone reports a retune that actually poisoned a pool.

The caveat I flagged before still stands and is now the only open question: this is a query across archived sessions, and I want to know what it costs on a large history before it reads everything by default. If it is slow enough to be felt, the answer is "pool, and tell you what it pooled" — which the window can now do, because saying what it pooled is already its job.

Ask 3 — approved in principle, still waiting on one line

A con-confirmed rare outranks a kill-count band; an unconfirmed band stays a suggestion. Exactly the "observation beats heuristic" rule you framed it with.

It is still blocked on the verbatim con line, and it is a smaller blocker than it sounds. The existing pattern is anchored on the trailing (Lvl: N) with a wildcard in the middle. So if a rare creature sits before that tail, it is a one-line change to capture a group that is already being matched and thrown away. If it sits after it, the anchor breaks and it is a second pattern. That is the entire question, and one pasted line answers it.

I would rather wait than reconstruct it. The last time a log line was reasoned about instead of pasted, the fix was written against a string the game does not emit.

No rush, and n3cr0nk1tt3n's line from #185 would settle it just as well as yours — you are both looking at the same sentence from opposite ends.

— Dranak (Claude Code)

[Frankthetankk]

Here's the verbatim con lines for "a rare creature" — every hit across my full log, timestamps kept, nothing paraphrased:

[Wed Jul 29 00:36:02 2026] Unbound Flame - a rare creature - scowls at you, ready to attack -- what would you like your tombstone to say? (Lvl: 25)
[Thu Jul 30 11:30:20 2026] The Kerran Sha`rr - a rare creature - regards you indifferently -- looks kind of dangerous. (Lvl: 22)
[Thu Jul 30 23:49:39 2026] A frenzied ghoul - a rare creature - scowls at you, ready to attack -- what would you like your tombstone to say? (Lvl: 42)
[Fri Jul 31 18:50:28 2026] Raster of Guk - a rare creature - regards you as an ally -- looks kind of dangerous. (Lvl: 35)
[Fri Jul 31 18:51:46 2026] An evil eye - a rare creature - regards you as an ally -- looks kind of dangerous. (Lvl: 35)
[Fri Jul 31 19:08:14 2026] The froglok king - a rare creature - looks upon you warmly -- what would you like your tombstone to say? (Lvl: 47)
[Fri Jul 31 21:21:39 2026] The froglok king - a rare creature - glowers at you dubiously -- looks like it would wipe the floor with you! (Lvl: 47)
[Fri Jul 31 22:59:27 2026] A reanimated hand - a rare creature - scowls at you, ready to attack -- it appears to be quite formidable. (Lvl: 40)
[Fri Jul 31 23:18:52 2026] An evil eye - a rare creature - glares at you threateningly -- looks kind of dangerous. (Lvl: 35)
[Sat Aug 01 00:32:30 2026] The froglok king - a rare creature - scowls at you, ready to attack -- looks like it would wipe the floor with you! (Lvl: 47)
[Sat Aug 01 00:51:02 2026] A froglok noble - a rare creature - regards you indifferently -- it appears to be quite formidable. (Lvl: 39)
[Sat Aug 01 01:07:07 2026] A froglok crusader - a rare creature - scowls at you, ready to attack -- it appears to be quite formidable. (Lvl: 42)
[Thu Aug 06 23:29:34 2026] An undead knight  - a rare creature - regards you indifferently -- looks kind of dangerous. (Lvl: 40)
[Thu Aug 06 23:30:14 2026] An avenging caitiff - a rare creature - regards you indifferently -- You could probably win this fight. (Lvl: 30)
[Thu Aug 06 23:31:03 2026] Ssynthi - a rare creature - regards you indifferently -- You could probably win this fight. (Lvl: 25)
[Fri Aug 07 01:35:27 2026] The Mighty Bear Paw - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 24)
[Fri Aug 07 01:38:48 2026] The Muglwump - a rare creature - regards you indifferently -- You could probably win this fight. (Lvl: 25)
[Fri Aug 07 02:09:54 2026] Rikfeer the Arcane - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 12)
[Fri Aug 07 02:14:31 2026] Aderius Rhenar - a rare creature - glares at you threateningly -- You could probably win this fight. (Lvl: 10)
[Sun Aug 09 01:06:13 2026] Quillmane - a rare creature - glares at you threateningly -- You could probably win this fight. (Lvl: 30)
[Sun Aug 09 01:32:03 2026] The Ishva Mal - a rare creature - scowls at you, ready to attack -- it appears to be quite formidable. (Lvl: 45)
[Sun Aug 09 02:13:47 2026] Lord Grimrot - a rare creature - looks upon you warmly -- You would probably win this fight... it's not certain though. (Lvl: 34)
[Sun Aug 09 12:05:11 2026] Aderius Rhenar - a rare creature - kindly considers you -- You could probably win this fight. (Lvl: 10)
[Sun Aug 09 12:15:45 2026] Packmaster Dledsh - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 16)
[Sun Aug 09 12:17:23 2026] Trainer Daxgrr - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 15)
[Sun Aug 09 12:51:36 2026] Foodmaster Rargnar - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 13)
[Sun Aug 09 12:51:39 2026] Smithy Rrarrgin - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 14)
[Sun Aug 09 13:05:00 2026] A kobold master blacksmith - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 12)
[Sun Aug 09 13:06:56 2026] High Shaman Drogik - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 22)
[Sun Aug 09 13:06:57 2026] King Gragnar - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 24)
[Sun Aug 09 13:08:22 2026] Lorekeeper Roggik - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 18)
[Sun Aug 09 13:08:38 2026] Warlord Drrig - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 21)
[Sun Aug 09 13:15:12 2026] Cave bat lord - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 22)
[Sun Aug 09 13:19:28 2026] Huntmaster Furgrl - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 20)
[Sun Aug 09 13:22:55 2026] Krode the Diviner - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 18)
[Sun Aug 09 13:23:44 2026] Grodl Ripclaw - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 21)
[Mon Aug 10 02:17:26 2026] Spirit of Dessication - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 15)
[Mon Aug 10 02:18:10 2026] Abomination of Ro - a rare creature - scowls at you, ready to attack -- You could probably win this fight. (Lvl: 14)
[Mon Aug 10 02:53:12 2026] Magus Rokyl - a rare creature - scowls at you, ready to attack -- looks like it would wipe the floor with you! (Lvl: 51)
[Mon Aug 10 22:23:32 2026] Ulrik the Devout - a rare creature - scowls at you, ready to attack -- looks like he would wipe the floor with you! (Lvl: 51)
[Mon Aug 10 22:35:15 2026] Irslak the Wretched - a rare creature - scowls at you, ready to attack -- looks like he would wipe the floor with you! (Lvl: 51)
[Mon Aug 10 22:41:13 2026] Niltoth the Unholy - a rare creature - scowls at you, ready to attack -- looks like he would wipe the floor with you! (Lvl: 51)
[Mon Aug 10 22:50:21 2026] Initiate Sirlis - a rare creature - glowers at you dubiously -- looks like he would wipe the floor with you! (Lvl: 51)
[Wed Aug 12 15:32:36 2026] Magus Rokyl - a rare creature - scowls at you, ready to attack -- looks like it would wipe the floor with you! (Lvl: 51)
[Fri Aug 14 03:31:09 2026] King Tranix - a rare creature - scowls at you, ready to attack -- looks like it would wipe the floor with you! (Lvl: 52)

Rarity text consistently sits before the (Lvl: N) tail: <Name> - a rare creature - <emote text> (Lvl: N). Sounds like that's the easier of your two cases.

One important caveat before this gets built, though — "a rare creature" is a confirming signal, not an exhaustive one. There are NPCs with genuinely unique, one-of-a-kind loot whose con text never says "a rare creature" at all. Plane of Sky is the clearest example: bosses and minibosses there drop unique loot and are unique spawns, but their con text doesn't include the phrase — e.g. Noble Dojorn glares at you threateningly -- what would you like your tombstone to say? (Lvl: 63), no rarity flag, despite being one-of-a-kind. Compare that to something like the evil eye above, which does get flagged, in a zone (Lower Guk) where placeholders apparently haven't all been removed yet.

So I'd frame this strictly as a positive override, never a negative one: a confirmed "a rare creature" beats the kill-count band, same as originally proposed. But no con text should never be read as "confirmed not rare" — it should just fall back to the existing kill-count heuristic exactly like today. Wanted to flag this explicitly so the fallback behavior doesn't accidentally get built as "no rare text = confirmed common," which would actually make some genuinely rare NPCs (like Sky bosses) look less rare than they already are with the kill-count method alone.

---

Separately — following up since it didn't come up in your last reply: any thoughts on Ask 4 (dropping "EQBuddy" from suggested edit summaries for now)? No rush, just didn't want it to fall off the radar since 1–3 got such a thorough answer.

[Frankthetankk]

Two follow-ups on the pack, both small.

Clarifying question — "not checked yet" visibility

When a creature's wiki page can't be read, is it actually shown anywhere in the pack window as "not checked yet," or is it silently left out of the list entirely? The earlier writeup mentions both "labeled 'not checked yet'" and "excluded from the pack entirely," and I want to make sure I understand which of those is the actual UI behavior before asking for a change to it.

Assuming it's currently the latter (silently excluded, no visible trace) — could we add a small section near the top of the pack, separate from the main contribution list, listing creatures whose wiki page couldn't be read? Not counted as a contribution, not something Copy pulls into the edit text — just a retained, visible list so this information doesn't disappear the moment the page fetch fails. Right now if a page can't be read, the only way to notice is remembering you looted from that creature and wondering why it's missing.

If it's useful scope for later (not blocking this ask): being able to tell "page genuinely doesn't exist yet" apart from "page exists but the fetch failed" would help a reviewer decide whether they're looking at a new-page candidate or just a transient hiccup worth retrying. No idea if that distinction is even available to the pack right now, so treating this as a nice-to-have rather than part of the ask itself.

New ask — motes shouldn't be suggested as per-creature drops

Checked the wiki's own Mote Guide on this, and it confirms something worth building around:

Motes have a chance to drop from any monster killed. The higher the difficulty of the zone will increase the minimum level of the mote that will drop. Killing mobs of a higher level (yellow or red) will also increase the chance of motes dropping. Additionally, the player's level will affect the level of the motes that drop.

This is different from ordinary common_loot (wolf pelts from wolves, spider silk from spiders) — even generic shared drops are still species-linked; a wolf drops wolf things because it's a wolf. Motes aren't tied to creature identity at all — the specific creature killed is basically incidental to whether one drops. A level 20 player killing anything yellow-or-red in a Difficulty 4 zone has roughly the same mote odds regardless of which NPC it happens to be. Listing "Mote of X" under a specific creature's known_loot or common_loot wouldn't just be noisy, it'd be actively misleading — it implies a specificity (this creature is a source) that doesn't actually exist. That's presumably why the wiki already has a dedicated Mote Guide page rather than trying to enumerate mote drops per-NPC.

So: motes should probably be excluded from what the wiki contribution pack ever suggests as a per-creature drop. I haven't confirmed whether the pack currently surfaces them or not — flagging this preemptively in case it does, or before full-history scope (Ask 2) makes them show up more.

[DranakCorps-bot]

Ask 4 is done and shipped in v1.96.1. The suggested edit summary no longer names EQBuddy:

Suggested edit summary: observed drops (2 items, 12 kills).

David's call on it was short: "sure, drop the name." The reasoning I wrote into the code, so it doesn't get undone by accident later, is that this is the one string EQBuddy puts into text you paste onto someone else's wiki — under your account, in your name. The edit is yours, so the summary should describe what you observed rather than advertise the tool that helped you read your log. If you want to credit EQBuddy, that's yours to say in your own words.

The pack's own header still says EQBuddy — that one is the app titling a document for you to read, not text going onto the wiki. Worth mentioning because my first attempt at the test asserted the whole pack contained no "EQBuddy" and promptly failed on that header, which turned out to be a decent illustration of the distinction you were drawing.

Asks 2 (full-history pooling) and the mote exclusion are still with David — the first is genuinely the same shape as the all-time-stats work in #168/#159 rather than a wiki-pack change, so I'd rather it land there than be bolted on twice.

— Dranak (Claude Code)

[Frankthetankk]

Worth flagging: another player (LeBigNasty) independently raised motes in #226, coming at it from actual daily use rather than a wiki-mechanics argument — two people hitting the same friction point from different angles is a good signal it's worth prioritizing.

Their post also asked for filtering out common drops more broadly (gems, etc.), which I'd flag as a separate and more contentious ask — I don't think that one should apply to what the pack actually SUGGESTS to the wiki, even if it's reasonable as a client-side display filter. I raised the same question with the wiki admins directly and got real pushback there: the general position was against omitting common/low-value drops from mob pages as a category, since "trivial" is entirely dependent on who's asking — a tradeskill farmer and a raider want opposite things filtered. A small set of genuinely negligible items (water flasks, lowest-tier gems) was conceded as a fair exception, but not common drops wholesale.

So: motes, yes, exclude from the pack's suggestions (they're not creature-specific at all). Common drops like gems, no — if anything, that's a hide-from-my-view UI preference, not a change to what gets suggested to the wiki itself.

[DranakCorps-bot]

Two things from your follow-up, both worth pinning down:

The wiki admins' position is now the recorded rule for the pack. You went and asked the people who own the destination, and they said don't omit common/low-value drops from what gets pasted — so that's settled, and it's settled by the right authority. The pack suggests the complete observation. Your split is exactly right and it's how this gets held: a client-side display filter (what LeBigNasty wants for daily use) is a fine ask about our own window; the suggestion to the wiki stays complete because completeness is what the wiki asked for. Two different products, and conflating them is how the pack would quietly start lying to the wiki.

The convergence signal is real and it's been acted on. LeBigNasty's report in #226 led somewhere concrete: the ✦ staleness he was hitting is confirmed as the 7-day per-page cache — the same one from #65 — and the per-page re-check that was queued back then and never built is now written up as a planned item, with the burst-of-requests-at-a-volunteer-wiki concern called out explicitly so the plan has to answer it. The pack's own home (this thread's main ask) is adjacent to that same work; the full-history scope and the /consider rarity idea remain open on top.

So: nothing from this thread shipped this round, but two of the things blocking it stopped being vague. That's the honest status.

— Dranak (Claude Code)

[Frankthetankk]

Glad the admins' answer settled it cleanly — and appreciate you writing the "two different products" framing so precisely, that's exactly the distinction I was trying to get at and you said it better than I did.

Good to hear the #226 staleness work and this thread's foundation are lining up rather than competing for attention. Looking forward to full-history and the rarity signal whenever they're up next — no rush, just flagging I'm still very much invested in seeing this pack become what it could be.

[Frankthetankk]

Now that #185 has shipped the con-rarity mechanism (bjstrange's lines, "a rare creature" overriding the kill-count heuristic) — does that same parsing already satisfy Ask 3 here, or does the wiki contribution pack's rarity labeling need its own separate hookup to it?

Asking because the two are similar but not obviously the same consumer: #185 uses the con-rarity signal to seed a spawn-timer discovery (a different feature, different downstream effect), while Ask 3 here is about what rarity label the pack suggests for a wiki edit. If the underlying parser now exposes "this mob was con-confirmed rare" as a fact EQBuddy holds, it seems like it should be a small wiring job to have the pack check that fact too rather than build its own parsing — but wanted to check rather than assume, since I don't know if the two systems currently share that data or are built independently.

[DranakCorps-bot]

Good question, and the answer is no — and I'd push back on wiring it in even as a small job, because the two "rarities" are different axes.

Mechanically, the fact does exist. The parser captures the game's own - a rare creature - insert from consider lines, so EQBuddy genuinely holds "the game called this one rare". But it's held privately inside the spawn-timer machinery — a session-scoped set keyed by timer key, read only by the named-spawn discovery path. Nothing outside can ask the question yet, so there isn't a fact sitting there waiting to be consumed; it would have to be lifted out first.

That's the smaller half of it, though. #185's signal is about the creature: this mob is a rare spawn. Ask 3's label is about an item: how often it drops from that creature, expressed in the wiki's published bands (Always / Common / Uncommon / Rare / Ultra Rare) computed from the observed drop rate over 10+ kills.

Those two don't correlate. A trash mob can drop an ultra-rare item; a rare spawn can drop its signature piece every single time. So feeding con-rarity into the drop-rate label would make the pack suggest a band the observation doesn't support — which is the one thing this pack must never do, for the same reason the edit summary stopped naming EQBuddy: it gets pasted onto someone else's wiki, under your account, in your name. A label you can't defend from your own kills is worse than no label, and the pack already prefers no label when the sample is thin.

What it could honestly be is a separate creature-page fact rather than a modifier on item rarity — something like "the game called this a rare creature on N of your considers", sitting alongside the level range and the faction hits, which are also things you personally witnessed.

Which raises the question I'd rather ask you than guess at: where would that belong on the destination page? The {{Namedmobpage}} template, as the pack fills it, has no rare-spawn field — name, race, class, level, location, respawn_time, description, factions, opposing_factions, related_quests, known_loot. So it would land in description, or in the edit summary, or nowhere.

You've got a track record of going and asking the people who own the destination, and it worked: the common-drops answer is the recorded rule for this pack because you went and asked. If the admins have a preferred home for a confirmed rare spawn — a field I'm not seeing, a description convention, or "we don't record that" — that would settle the shape of this the same way, and it's a better answer than anything I'd invent from the log side.

Logged as its own item rather than folded into Ask 3, which stays a drop-rate question. No date on it from me.

— Dranak (Claude Code)

[Frankthetankk]

Sorry — that's on me, and it's worth untangling since it changes the shape of this a lot. Ask 3 as I originally worded it said "override the kill-count band," which is the item drop-rate mechanism — but that's not what I actually meant, and I should have been clearer. This ask isn't about item drop rarity at all. It's about recording, on the creature's own wiki page, that the NPC itself was confirmed rare via its in-game /consider text — a fact about the spawn, not a modifier on any item's drop percentage.

A new template field for this makes sense, and I raised it with the wiki admins directly — the response was positive, but it'll take some time on their end before anything like that actually exists. So for now, I think the practical move is a simple description-field mention, the same way existing pages already handle it. Packmaster Dledsh's page (https://eqlwiki.com/Packmaster_Dledsh) already lists "Rare NPC" right in its description — there's precedent for exactly this, just done by hand today. Something like "Confirmed as a rare spawn via in-game /consider" in the description field would fit that same pattern until a proper field exists.

Once the admins land on an actual parameter, that line can move over and description goes back to normal — this is meant as a stopgap, not a permanent home for it.

Appreciate you catching that this could've been read as a drop-rate change — you're right that the two shouldn't correlate, and to be clear, that was never the intent.

[DranakCorps-bot]

No apology needed — the wording did its job. "Override the kill-count band" is what sent me to the drop-rate mechanism, and chasing that is what surfaced the distinction; if it had been phrased the way you've just put it, I'd have agreed immediately and we'd both have missed that the pack could have been wired the wrong way by someone taking the original sentence literally. That's a useful thing to have ruled out in public.

And you've answered the part I couldn't. I said the open question was a destination one — the {{Namedmobpage}} template as the pack fills it has no rare-spawn field, so the fact had nowhere to go — and asked whether the admins had a preferred home. You went and got one. That's twice now (the common-drops ruling was the other), and it's the reason this thread keeps producing decisions instead of opinions.

The Packmaster Dledsh precedent is the part that makes it safe to build. A stopgap I invent is a stopgap that looks like EQBuddy inventing wiki conventions; a stopgap that matches what editors already do by hand is just doing the existing thing consistently. So: a description-field line, in that pattern, when the game itself has called the creature rare in your /consider — and worded so it's obvious where it came from and easy to lift out when a real parameter lands.

Two things I'd rather get right up front than fix later:

It only claims what you personally saw. The line goes in when the game's own - a rare creature - text appeared in your log, for that creature — not inferred from kill counts, not from drop rates, and not carried across from another character's session. Same bar as everything else the pack suggests: it's your observation, going up under your account.

It won't fight an existing description. For a creature that already has a page with prose in that field, suggesting a wholesale replacement would be the pack overwriting an editor's work — so that case gets the line offered as an addition to review, not as a paste-over. New pages get it in the skeleton directly.

Logged as its own item with your admin answer attached, so whoever picks it up doesn't have to re-derive the destination. No date from me — but it's now a build rather than a question, which it wasn't this morning.

When the admins do land a real parameter, say so here and moving it is a one-line change: the fact is the same, only the field name moves.

— Dranak (Claude Code)