Recount or Details style in game DPS parser

World of Warcraft has a really nice very user friendly addon called Recount and Details combat meter. Fits right inside the game, window ajdustable, very little setup and has very colorful bar graphs and about a million stats you can pull out of it. Can even put it up on World of Logs for public inspection. Why can't EQ have something like that ? This is the link. https://wow.curseforge.com/projects/details It was updated 21 hours ago. Is it EQ backend server tech or programming that prevents such a nice and colorful, intuitive addon ?

Lol

WoW has a robust add-on framework. By placing the add-on files in a particular directory, they will be read when the game starts, and result in the nice interactive UI elements you mentioned.

What allows them to get the data that drives that UI is the (really, quite extensive) API that the game makes available. The API is basically functions that the add-on can call, or places where it can register to hear when things happen (on damage taken, on damage done, etc).

Everquest does not offer these things at all - the only parsing possible is by external programs reading the game's log files.

https://forums.daybreakgames.com/eq/index.php?threads/gamparse-2-0-0-x-beta.253869/ is what you get. It's actually quite good even if it's not as simple to use as Recount.

Hopefully I don't get in trouble for posting this (my own opinion only, not a policy).

It isn't really a good idea for us to add an in-game parser to EQ. EQ's (32 bit) client already has a ton of stuff in it - the more things that can exist to the support the game, but not be in the client, the better. Adding an in-game parser was my #1 most wanted to do thing when I started. Instead I have been making logging changes to make parses more accurate.

The more things we add, the worse client performance gets. If you want a really good example of this, turn off logging during a raid - the game runs significantly more smoothly (you can also do /loginterval 1 for a passable improvement while losing < 1s accuracy).

It would be a big chunk of time to add an in-game parser, and the opportunity cost between adding something totally new vs. what is already offered to players outside of EQ (gamparse) doesn't seem good enough at this time.

You seem to help a ton with stuff lately is there any chance of getting you to assist aristo to finish up dot revamps in an intelligent way? Then assist Dzarn with fixing scent of Terris? Both in terms of pending time on the docket or time spent nerfing years old changes should put them far ahead of anything going on or some of the last hundred changes we have seen over the past three years instead.

The 32-bit client is the enemy here. Not DBG. WoW's 64-bit game client was made available in 2012. Something that should be simple to becomes a Herculean task do in a game client that, for all intents and purposes, no longer fits inside it's maximum memory allocation.

The improvements in logging are no small feat in themselves. Once Beimeth irons out the details in GamParse, we'll have a very robust combination for parsing that should last the duration of the game.

I appreciate the OP's intent. I've long desired an in-game parser. However, the reality is such that it's not in the cards for this iteration of EverQuest.

Pretty sure Ninente works on the code side of EQ and not the design side which is where the work for the spells and AA items you are asking about would be done.

IMO updating the log file output was a required step before even considering a necro DoT revamp. Without having accurate data we'd have little way of knowing whether any potential changes unbalance things or not. Just look at how poorly it went with druids and shamans and their situation was far less complicated.

I've never used those WoW tools but I would be interested in hearing about any specific feature that people find the most useful. Then you can see how complicated it would be to implement, if there's interest by others, and if more changes would be needed to the log output to support it, etc.

It went poorly with shaman and druids because all they did was wing it. They took dots multipled by 6 or more in some cases and ignored the tools they had. Same mistakes he made for every single dot revamp. Nobody wants anything like that for necromancers. We want no bonus damage just the damage we already stack reduced into fewer casts. And even then a reduction in total dot stack power on the later dots to even out some of the sped up front loading. This has been explained in detail by many people for years now and been ignored. We didn't need revamped logs and parser to handle it. We don't need massive changes to other things like AA, items, focus mods and all the other nonsense I have seen suggested.

You take 18 casts and get it down to 9-10. You take what was say 100,000 in base damage from those 18 casts and make it 90,000 and revisit if needed, with the difference coming off the increases from dots 5-10 so the first few are more front loaded.

Definitely if I had to pick between the two accuracy for parsing is better.

If you already did all this work then why not continue? List the spells you want cut. Show us a list of all the spells to keep with their new damage values and cast times. Then some math to show estimated DPS at different time intervals and taking into account your normal ADPS. Then some parses of your current DPS to show where things lineup. What you described sounds pretty OP but if you think it would work you should really provide more details.

Would recompiling the client to be 64bit be possible ? Would it have any significant improvement ?

No specific knowledge here, but it's a pretty safe bet that it's not just a matter of compiling it with a different switch set for 64 bit. Otherwise, I have to think they would have already done this.

In many cases, EQ uses pointer math to build/read packets. In 32 bit C/C++ a pointer is 4 bytes, but in 64 bit pointers are 8 bytes. We would have to update all the packet sending/reading to newer code style that doesn't use pointer math (or at least update the pointer math to do +8 instead of +4) and also test those changes. For reference to how much work that would be, EQ has more than 1500 unique messages (not all of them use ptr math).

Pointer math is the devil.

What about non-file based IPC? I think the biggest issue with the log function (performance wise) is opening, closing, and flushing the file (I could be wrong)

I can't speak for gamparse, but I suspect they do something similar (or better) than my parser... When opening in "watch" mode you actually just seek the position of the file-descriptor to the end of the file and track it from that, so you are only ever reading and parsing new data.

If you are really looking to improve your parsing speed, check into "RamDisk" tools that allow you to create a virtual filesystem in memory and mount it to your logs directory. Doing this removes any hard drive time from the equation. Or get one of those new fangled M.2 solid state drives, the throughput numbers I've seen make me all hot and bothered.

The reason I use my own parser (other than the fact that it's just fun and I like to tinker) is that I find gamparse has kind of poor performance, my suspicion is that it is related to whatever storage mechanism is being used. It feels like a kind of "saving to a sqlite database with .net watcher UI system over it" that really just falls short of being able to handle lots and lots of data imo. To be fair, my parser is not general use... the gui consists of a couple web pages and a REPL. But I can search for anything in my log files from years and years back incredibly fast and make my own analyzer reports and such.

I've looked into trying to do things similar to FFXIV's ACT plugin, but as niente and klanderso pointed out, it's kind of a pain to be rummaging in memory and it all has a tendency to change in little ways each patch that require considerably more time than checking the patch notes and strings databases for updates. The EQ logging system is actually pretty cleanly parsed and the developers do a great job letting people know what they are changing, not all games have such solid logging facilities with the kind of performance you can get from EQ.

I have forgotten my point, other than to say EQ is pretty awesome and I appreciate the effort that has gone into the logging system over the years.