Replies: 5 comments
|
Built and shipped in 1.88.4. You were right that the log already tells us, and that a hand-maintained list will always have exactly the gaps you hit. EverQuest writes trash with an article — "an ogre shaman" — and a named by its proper name — "Chief Goonda". EQBuddy now reads that. Kill a proper-named mob that isn't in the catalog and it starts tracking it, with no countdown, because one kill cannot know the cycle. The second kill measures it, and later shorter gaps tighten it. The row says "Found by EQBuddy" so you can tell it apart from the shipped catalog and from your own entries, and you can type a duration over it or remove it. It is deliberately cautious, because an invented timer that sends you to a camp which isn't up is worse than no timer:
The shipped catalog is still only ever edited by hand — a wrong respawn timer is worse than none — so discoveries live alongside your own learned timers rather than being written into it. The Hole and Chief Goonda should both start behaving on your second kill now. If you find a named this doesn't pick up, that's a case the heuristic is missing and I'd want to see the line. |
|
We need to be mindful that not all mobs that do not begin with a descriptor are not necessarily "named" mobs for the sake of hunting. For example, we don't want a timer chip to pop up for every character in a town just because they have a name without a descriptor. Perhaps it can do this dynamically for when you con a mob and it says that it is indeed a rare creature, then it should be tracked and updated accordingly. Again, this doesn't solve necessarily track the respawn timer inconsistencies because the calculation from time of first kill to second kill doesn't determine the respawn timer's duration; the respawn timer is determined before the mob spawns. This is why you are able to manually set the respawn timer for the mob you are tracking since the last time you killed it up to it's respawn. As the widget says "Double-click one for the full zone list, which follows you zone to zone. We captured the respawn times we could from community sources -- if you notice a discrepancy in game, type over the duration: your number wins and survives updates." At the bottom of the Spawns window, you can manually add a mob that the zone's catalog doesn't have. Perhaps we can have a mega-thread to add and update spawn timers to maintain a bit of continuity where the community logs lack. |
|
Both of your points land, and the second one is sharper than the first — let me take them in that order, with what the code actually does rather than what I remember it doing. "Kill-to-kill is not the respawn timer"You are right, and it is worth being precise about how wrong it is. The gap between your first kill and your second is the respawn plus however long the mob stood there before you noticed and killed it again. So a measured cycle is always an over-estimate, never an under-estimate. That asymmetry is why it is usable, and the code leans on it deliberately: a discovered cycle only ever tightens. A later, shorter gap replaces the stored value; a longer one is ignored as "you were not watching". So the first measurement is an upper bound that converges downward the more you camp it, and it can never drift the dangerous way — long, which would send you to a camp that is already up. It is still an estimate, and it should read as one. Your manual override remains the authority, exactly as the widget says. "Not every article-less name is a named mob"Also right in principle. The guard is narrower than the heuristic alone, though, so the townsfolk case is smaller than it looks — a discovery needs all of:
So the failure you are describing costs a chip that names a townsperson and asserts no timer — until you kill them a second time. Real, but bounded, and cheap to dismiss. The
|
|
Adding a few lines from my log for rare creatures [Thu Aug 06 21:42:47 2026] Magus Rokyl - a rare creature - scowls at you, ready to attack -- looks like it would wipe the floor with you! (Lvl: 51) |
|
@bjstrange — those three lines were worth more than you probably expected. Built and on The First, a bug you accidentally exposed. The consider parser didn't know about the insert, so it swallowed it into the mob's name — "Magus Rokyl - a rare creature -" — which matches nothing downstream. Practical effect: considering the very named you were camping silently failed to count as a sighting for its timer. That's fixed; the name parses clean and the marker is read separately. Second, the feature @elderbit asked for, in its most honest form. Discovery could only trust the no-article naming convention, which is a heuristic — so a named whose name looks like trash ("A ghoul executioner", straight from your log) could never be auto-discovered. The rare insert is the game itself saying the mob is named-class, and that outranks any convention. So now: if you've considered a mob this session and the game called it rare, your kill starts a discovered timer exactly as a proper-named kill does. The conservative rules are unchanged, deliberately — "a wrong respawn timer is worse than none":
@elderbit — this narrows your original gap from "every named the curated list is missing" to "named mobs you kill without ever conning". A camped named almost always gets conned at least once, so in practice the coverage jump should be large. The curated list remains the source for respawn durations; discovery still only measures what it sees. Thanks to you both — a verbatim log line beats a description every time, and this thread is now the standing example of why. — Dranak (Claude Code) |
Uh oh!
There was an error while loading. Please reload this page.
First off, thank you again for building this tool.
The respawn timer feature has genuinely made camping named mobs so much easier, and I really appreciate the work that's gone into it!
While farming Focus Items, I noticed the respawn timer currently depends on a curated list of named mobs, and that list has some gaps. A couple of examples I ran into:
I imagine there are plenty of other named mobs across the game that fall into the same gap, and keeping a manually maintained list fully up to date is probably a never-ending task.
Suggested improvement
Would it be possible to detect named mobs automatically from the combat log text, rather than relying solely on a fixed list? EverQuest has a very consistent convention here: generic ("trash") mobs are always referenced with an article ("a" or "an") before their descriptor, while named/unique mobs are referenced by their proper name without an article.
Example:
An ogre shaman tries to punch YOU, but misses! (Riposte) → generic mob, ignore
Chief Goonda tries to punch YOU, but misses! → named mob, track it
If the tool tracked the timestamp of the first kill for any such "named-looking" mob, and then calculated the respawn interval automatically on the second kill, it could cover every named mob in the game, including ones that aren't in the database yet, without anyone needing to maintain a list by hand. That would make the feature self-completing over time, which seems like a really elegant way to solve this long-term.
Possible edge cases
Pets ("Lonn slashes an ogre shaman for 83 points of damage." / "Gobanab tries to bash a basalt gargoyle, but misses!") might also occasionally appear in logs without an article, so it may be worth a quick check that the auto-detection doesn't pick those up as "named" mobs. Not a blocker at all, just something that might be worth a quick look.
EQBuddy 1.88.3 · Windows 26200
All reactions