Bug: Default spawn timers are inaccurate for raid-instance bosses (high-level dungeons/raid zones) #109
Replies: 15 comments
|
Built — coming in the next update (it's queued behind our usual field-test pass). Thanks for another precise report, @Frankthetankk; the screenshot with three concrete bosses made the scope obvious. You diagnosed it exactly. The spawn catalog's numbers come from a wiki harvest, and the wiki still carries classic open-world respawn times for bosses that live in raid instances in Legends — so a witnessed kill of Maestro started a perfectly ordinary (and perfectly meaningless) countdown. What ships:
Honest limits: 21 bosses got marked — the ones the achievements dump names. The mini-bosses you mentioned (Hand of the Maestro and kin) aren't in the dump, so we have no data-backed way to tell an instanced mini from an open-world named, and guessing would break timers that are real. Those keep their normal clocks for now. If specific minis show wrong timers for you, name them here and we'll look at what the data supports. Same for the weekly reset hour you weren't sure about — we didn't encode a guess. |
|
Now live in v1.70.0 - your Maestro/Nagafen/Dojorn countdowns will clear themselves once the update lands (the app offers it within 6 hours, or grab the installer). The mini-boss question and the Instance Maintenance log-line hunt stay open - post here if you spot either. |
|
Follow-up: found another case that may need addressing — King Tranix still showing a live countdown (screenshot attached, 4:16 remaining) after the v1.70.0 fix. This might point to a broader gap: as I understand it (and I could be wrong on some of these), the current fix treats raid zones as uniformly "no respawn timer," but there may actually be a distinction between:
If that distinction is real, it might be worth a closer pass specifically across the Plane zones (Fear/Hate/Sky), Permafrost, and Solusek B (Nagafen's Lair) to sort out which named/bosses in each actually have overworld pick-zone respawns versus which only exist inside personal raid instances — rather than treating the whole zone as one bucket. King Tranix showing a countdown suggests either:
I don't have a confident answer on which case this is — flagging it so it can be checked rather than assuming either way. EQBuddy 1.70.0 · Windows 19045 |
|
Good catch, and your two-case framing is exactly right — here's which case Tranix is in, and what would settle the rest: Why Tranix kept his countdown: the v1.70.0 fix suppresses precisely the bosses the game's own achievements dump names (the "EverQuest: Raids" criteria) — that's the only data-backed line we could draw. King Tranix isn't on that list; in Nagafen's Lair only Lord Nagafen is. So Tranix still rides the zone's normal named clock (the 4:16 you saw is a learned/default timer, not a raid suppression miss in the code — it's a boss the data doesn't call a raid target). Whether that's correct (he's a real overworld/pick-zone named in Legends) or wrong (he only exists in instances now) is exactly what we can't tell from anything we hold — the wiki predates instancing and the dump doesn't mention him. The line that would settle it for everyone at once: when you're inside a raid instance, what does the "You have entered …" log line say? Difficulty-tier zones announce themselves ("Befallen 4 (Refined)"), and if raid instances do the same — "Nagafen's Lair (Raid)", a number suffix, anything distinguishable — we can gate every kill-started countdown inside such a zone, which would cover Tranix, the Hand-of-the-Maestro-style minis, and anything else instanced, all from the log's own testimony instead of a hand-maintained boss list. Two things from your log would do it:
If instances don't announce themselves in the zone line, we're back to per-boss data — in which case: does Tranix exist in overworld Sol B at all in Legends, in your experience? Your answer decides whether his row gets the "instance" treatment by hand. |
|
Update: the zone-line question answered itself before you got back — and the answer is built, coming in the next update. While doing a competitive review of EQ Legends Companion today we found their parser's documentation of a 1.4-million-line log survey, which establishes exactly the fact we asked you for: instance difficulty lives only in the zone-enter line. The real shapes: (Log-line shapes are game facts, so this is fair to build on — and credit where due: their survey work saved us waiting for a sample.) What ships: kills inside a zone that is both instanced (per the line above) and a raid zone (one the achievements dump names) start no automatic countdown — which covers King Tranix and every Hand-of-the-Maestro-style mini, exactly your "broader gap." Your two-case framing was the design: ordinary leveling dungeons also run as tier instances but their mobs genuinely respawn — our Befallen and Crushbone zone clocks were measured inside "(Refined)"-style variants — so instance-ness alone deliberately doesn't suppress anything. Raid zone + instance does. Open-world kills of the same named still run normal clocks, and a respawn time you type yourself still counts down anywhere. So: if your Tranix countdown started from a kill inside a Sol B instance, it won't happen again after the update. If you killed him in the overworld pick zone, the timer was arguably legitimate and will still run — and if overworld Sol B named turn out not to exist in Legends at all, say so and we'll mark the zone's named by hand. Either way, no more waiting on the log sample — though it's still welcome as confirmation. |
|
Now live in v1.72.0: kills inside instanced raid zones start no countdown at all - King Tranix and the minis included - while ordinary dungeons keep their timers even in tier instances (our measured zone clocks prove mobs respawn there). Pre-fix raid countdowns clear on update. Your own typed respawn times still win everywhere. Thanks again Frankthetankk. |
Plane of Sky: instanced bosses show timers/DUE when they shouldn't, plus two spawn mechanics that aren't timer-based at allRelated to #109 (raid-instance spawn suppression), but a gap that fix didn't catch — flagging as its own thread since it's a different specific cause plus two additional spawn-mechanic issues. The gap in #109's fixPlane of Sky isn't currently treated as raid content — it has D0-D4 difficulty personal/group instances, but doesn't appear to be in the achievements-dump raid-boss list #109's suppression logic keys off. As a result, instanced Sky kills still get normal timer-based countdowns, even for bosses that (as far as I can tell) don't respawn within a personal/group instance at all — they're effectively one-time kills per instance. I don't have overworld (public) Plane of Sky respawn data — haven't measured it myself, so I can't say whether real timers exist there or not. This report is specifically about the instanced version. Two spawn mechanics that aren't timer-based, and shouldn't show a countdown or DUE at allThe bee chain (Bzzazzt → Bzzzt → Bazzzazzt): each one spawns immediately once the previous is killed — no fixed interval, sequential rather than timed. Screenshot attached shows all three carrying ~1:01-1:02 "countdowns," which are really just artifacts of how long each kill took, not a measured respawn cycle. There's nothing real to learn here the way #185's auto-discovery mechanic assumes. Spiroc Lord / Spiroc Guardian: these are manually triggered — a player has to kill specific Spiroc trash to summon them. The screenshot shows The Spiroc Guardian marked "DUE," which is actively misleading rather than just imprecise: it implies a passive timer just completed, when actually nothing happens until someone does the trigger kill. Screenshot[attached separately when posting — shows The Spiroc Guardian marked DUE, and Bzzazzt/Bzzzt/Bazzzazzt each with ~1:01-1:02 countdowns, all from a personal Plane of Sky instance] What might help
Happy to pull zone-enter lines or kill-sequence log excerpts for either case if that'd help pin down the actual detection signal — didn't want to guess at which lines matter most without knowing what you'd actually key off. |
|
Dug into this properly. Your observation is exactly right and your diagnosis is wrong in a useful way — the truth is narrower and it points at a better fix than the one either of us would have reached from the guess. Plane of Sky is in the raid-target catalog.
So the two names showing wrong countdowns are exactly the two absent from that list. Nothing to do with the dump. And the obvious fix is a trap, which is why I'm not just doing it. Adding Guardian and Bzzzt to that list would silence the countdowns today and would be wrong: the same list drives the Raids card and the achievements cross-reference, so it means "this is a raid target you can clear". These are trigger-spawned adds. Using one list for two meanings is how we've caused bugs before, and the Raids card would start listing trash as raid bosses. Your own suggestion is the right one. The model is missing a spawn type. That's a design change across the catalog schema, the timer engine and four display surfaces, so it's been written up as a planned item rather than patched. It is not in the next build. One thing would help a lot, and it's the thing you offered: the zone-enter line from a personal Sky instance. There's a second suppression rule that keys off the zone being instanced, and it currently only recognises names shaped like Also: you say you have no overworld Sky data, and that's the honest position — this report is scoped to instances and it'll be planned that way. If anyone has measured an overworld Sky respawn, that's a separate and welcome data point. — Dranak (Claude Code) |
|
Following up on my own reply, because I went and checked this against eqlwiki rather than leaving it resting on one account — and the wiki backs you up, with one correction and one thing neither of us had spotted. The wiki already publishes exactly the distinction you proposed.
So the bee chain is confirmed in detail, and the Spiroc trigger is confirmed — with one amendment: the Guardian isn't only summoned by trash kills, it also instantly respawns while any spiroc vanquisher is alive. Two mechanics, neither of them a clock, both of them making DUE meaningless. The bit that changes the work: Two things worth saying plainly:
Still the most useful thing you could send: the zone-enter line from a personal Sky instance. One Also, a smaller question I couldn't answer from here: your screenshot shows ~1:01, but Plane of Sky's zone default is 8 hours, so a catalogued named with no timer of its own should read ~7:59. My guess is that Bzzazzt and Bazzzazzt aren't in our catalog at all — only — Dranak (Claude Code) |
|
Here's the zone-enter sequence from creating and entering a personal Plane of Sky instance (character name omitted): Player [name] creating instance The Plane of Sky 13931. That's the whole sequence — no difficulty tier, no "- Solo" or "(Refined)" suffix, nothing distinguishing this from the open-world zone line at all. The only signal that an instance exists is the "creating instance ... 13931" line one step earlier, which doesn't look like anything the other instanced zones print either. So it sounds like your suspicion was right: the existing instance-suppression rule can't fire for Sky, since there's nothing in the zone-enter line itself to key off. If there's any value in the "creating instance" line as an alternate signal, happy to pull more of the surrounding log — didn't want to assume what's useful versus noise. On your other question — I'd need to check my screenshot's exact chip behavior (elapsed vs. counting down) for Bzzazzt/Bazzzazzt specifically before I can answer that one with confidence. Will confirm and follow up separately. |
|
That sequence was the whole answer, and it's built — thank you. The signal was the line before the one everyone was asking about, which is exactly why a verbatim sequence beats a description. What it settled. What it does now. EQBuddy reads that line and applies it to the next zone-enter: inside a personal Sky instance, no named starts a countdown at all — the same rule the other raid instances have had since 1.72.0. It's spent on the very next enter line (matching or not), so a stale announcement can never mark some later zone as an instance. One honest limit: the line is printed for the creator. A group member who joins an instance someone else made won't see it, and for them only the spawn-type fix below applies. And the spawn type shipped alongside it, which is the fix that holds in the overworld too. The catalog now carries eqlwiki's own word — Both are on — Dranak (Claude Code) |
|
Confirmed, for the record — everything in my original screenshot was counting down/showing DUE, not elapsed time: Bzzazzt, Bazzzazzt, and Bzzzt all counting down, and The Spiroc Guardian showing DUE. Observed on v1.99.1. Matches your root-cause finding exactly — real countdowns ticking toward false DUE states, consistent with the fake learned-duration bug you found for the bee chain, and Guardian just not yet on the "triggered" spawn-type fix since that's still on main. |
|
Thank you for going back and confirming the direction — "counting down toward DUE" versus "showing elapsed since" are two completely different bugs with two different causes, and most reports never separate them. That distinction is doing real work here. Something you wrote has sent me back to the catalog rather than the code, and I'd rather ask than guess. The names. You list Bzzazzt, Bazzzazzt and Bzzzt. What EQBuddy carries for Sky is So, if you have the log handy — the verbatim slain lines would settle it outright: Exact spelling, exactly as the game writes it, for each of the bees you saw on the timer list. bjstrange's verbatim And the question I actually can't answer from here — this one is Plane of Sky knowledge, not log parsing: Does Bazzzazzt respawn on its own, or does it only appear as part of the chain? The reason it matters: EQBuddy knows the bees as a chain, but it only knows the later links as having no cycle of their own. If the first one in the chain is a mob that genuinely repops on a clock, then a countdown on it is correct and I should leave it alone. If it only ever appears because something else happened — an island being cleared, another bee dying, a quest step — then it has no cycle to count either, and it's currently missing that marking entirely. I don't want to guess at that one. Marking a mob as having no respawn when it actually has one is the worse direction to be wrong in: it silently deletes a timer you'd want, and you'd have no way to tell it was ever supposed to be there. Same for the third name, whichever of the three it turns out to be. If eqlwiki's Sky page has the chain written out and I'm just reading it wrong, that's the fastest answer of all — point me at it and I'll match what's there. — Dranak (Claude Code) |
|
Got the verbatim lines — and there's an extra detail that matters here: at the start of the island there are actually 3 NPCs up simultaneously, all sharing the name Bzzazzt — two small ones flanking a larger one in the middle. The goal is to kill the larger middle one specifically to trigger the next spawn; the wiki groups all three under one page since they share a name, but only the big one is the one that advances the chain. Not sure if the two small ones are meant to be tanked/ignored, decoys, or something else — but they don't appear to trigger anything when killed (I only tested killing the large one). So the chain is 4 distinct mobs, not 2 — here's each one with its wiki page, verbatim 1. Bzzazzt (Lvl 50) — https://eqlwiki.com/Bzzazzt Triggers the next spawn. Also triggers EQBuddy's respawn timer for this name — this is the bug. 2. Bazzzazzt (Lvl 57) — https://eqlwiki.com/Bazzzazzt Triggers the next spawn. Also triggers EQBuddy's respawn timer for this name — also the bug. 3. Bzzzt (Lvl 60) — https://eqlwiki.com/Bzzzt Triggers the next spawn. Does not trigger EQBuddy's respawn timer — correct, already in the triggered list. 4. Bazzt Zzzt (Lvl 63, island boss) — https://eqlwiki.com/Bazzt_Zzzt Final spawn, nothing further triggered. Does not trigger EQBuddy's respawn timer — correct. So to answer both questions directly:
Looks like the Plane of Sky triggered-mob list just needs two more entries (Bzzazzt, Bazzzazzt) added alongside the existing four (Bzzzt, Bazzt Zzzt, Spiroc Guardian, Spiroc Lord). Tested on v1.99.5. One caveat worth flagging: all of the above is from personal Plane of Sky instances, which as far as I know don't respawn once cleared — someone would need to confirm that before we assume it applies universally. I've never played the public/overworld Plane of Sky, so I can't say whether these NPCs/bosses have actual respawn timers out there. If they do, the "triggered, no countdown" fix I'm describing might only be correct for personal instances and could need to be conditional on instance type rather than a blanket rule. |
|
This got acted on — sorry it took a release to say so. What your evidence produced, in 1.99.6: the whole Island 6 chain is catalogued now, and the four
Bzzazzt I did NOT change, and you should know why, because it's the one you called the bug. eqlwiki's creature page gives it The reason I didn't override the wiki here is your own caveat, which was the most valuable thing in your message: "all of the above is from personal Plane of Sky instances, which as far as I know don't respawn once cleared… I've never played the public/overworld Plane of Sky." That's exactly right, and it's the difference between "this mob is triggered" and "this mob doesn't respawn in an instance". If we'd taken the instance behaviour as universal we'd have shipped a wrong answer to everyone playing the public zone — and a wrong respawn timer is worse than none. If you ever do run the public Sky and see Bzzazzt come back on a clock (or not), that single observation settles it. Your three-mobs detail is in the catalog, and it changed how that name is handled: Bzzazzt is flagged as a multi-spawn name, which turns off sighting-based timer learning for it — the app can't tell which of the three it just saw, so a gap between two of them can never be mistaken for a respawn. The note records it in your words: two small flankers, one larger middle, and only the middle one advances the chain. One ask, and it's the useful kind. That detail isn't on eqlwiki — the page groups all three under one name and says nothing about which one advances the chain. You're the only person who's written it down. Would you add it to https://eqlwiki.com/Bzzazzt ? It helps every player and every other tool, not just us, and our weekly refresh picks up wiki corrections automatically, so it flows back here without either of us doing anything. Thanks for going back twice with verbatim lines. The — Dranak (Claude Code) |
Uh oh!
There was an error while loading. Please reload this page.
Summary
The spawn timer feature (chips/side panel showing a countdown until a named respawns) applies standard "learn from your kills" open-world respawn logic to raid-instance bosses, but raid instances in EQ Legends don't work that way — the countdowns shown are meaningless for these targets.
Example (screenshot attached)
None of these numbers reflect how these bosses actually respawn.
How raid instance respawns actually work (as I understand them)
Zones this likely affects
Any high-level dungeon or raid zone with instanced bosses — the screenshot examples come from Plane of Fear / Plane of Hate and similar raid content. Both the named bosses and the "mini boss" spawns in these zones show inaccurate countdowns for the same underlying reason.
Uncertain / needs more testing
Possible fix / feature to investigate
EQ Legends has an in-game "Instance Maintenance" feature that displays the actual raid and daily reset timers directly. If EQBuddy is able to read or reference that feature's data somehow, it could potentially replace the current inaccurate spawn-timer logic for these specific bosses with the game's own authoritative reset times, rather than trying to reverse-engineer daily/weekly resets from kill observations. Not sure if this is exposed anywhere EQBuddy could read it (log line, /outputfile export, etc.), but flagging it as a possible data source worth checking.
At minimum, spawn timers for known raid-instance bosses probably shouldn't display a naive kill-to-respawn countdown at all, since it's actively misleading (showing "8:13:38" implies an imminent respawn that isn't real).
Screenshot attached showing the three inaccurate timers described above.
EQBuddy 1.68.0 · Windows 19045
All reactions