Hi All, Does anyone know how to diagnose why I crash to desktop when selecting a check box, such as always greed for an item in the advanced looter? Cheers, Neb
Ah yeah that happened to me a few days ago. IIRC there were only 3 items in loot window. I reloaded and it was checked and no further problems. Default UI - nothing special.
CTD occurred again tonight. At least 30 things in loot window, was checking a few always greed, then boom CTD. I wasn't master looter for info.
Was able to repeat the CTD by coming back and clicking on a diamond from the arthicrex dropped by a coldain something.
Based on your last comment, I'd venture a guess that you have not stopped the advanced loot window from separating drops by npc name. I would recommend that you do that (bottom left of the window), as I found that to be over-informative at best and a near-sure cause of crashing at worst. I wish that setting was off by default.
/advl-related crashes still happen, but much more seldom than they used to. For me, it always has to do with setting/changing filter settings - though the patterns i had been able to identify and report have all been fixed. Recent crashes did not follow an easily discernible pattern that i could make out, so it's clear that reproducing and fixing the crashes is not easy. However, the most evident (well, in my eyes) "mistake" is uncatched exceptions. I can't think of a reason why anything /advloot-related would HAVE TO crash the client instead of simply popping a dialog-box with relevant info.
I have had CTD issues with the advloot since it came out. Every time I CTD, I leave the devs a constructive note in the feedback section of their CTD pop-up. It started off with info on what was going on at the time of the crash, but for a long time, has simply consisted of "fix your &^%$". FWIW, every time I have ever had a CTD with the advloot system, it's involved me clicking one of the checkboxes for a piece of loot that I was not in range to receive while said loot was still in the group window to be rolled. For example, joining a group and zoning in, you'll see loot that they have in the window. In an effort to get your filters set, you click AG or something. Boom. CTD.
Would really like to fix this, I attempted to fix it once but didn't work out - it is a stale pointer issue when you have many checkboxes in the advloot window.
It may help to consolidate Need and Greed checkboxes to simply "Want". This would reduce the total number of checkboxes as well as reduce the confusion many players experience using the tool.
Perhaps set the timeout to something much shorter. If the setting is to auto-roll, have it roll within two minutes, for example, and if not, have it leave on corpse in five minutes (random numbers pulled out of my fourth point of contact). That should cut down on the total number of items in the window at any given time, while still allowing for a reasonable chance to assign the disposition of loot.
Sorry in advance for the thread necro, but came back to EQ to play a bit and caught up a bit with some of these replies. A comment for Niente, perhaps you could trap the pointer into an exception and just make a statement to the user such as (woops, this won't work right now) rather than CTD. I know that when I handle stale pointer issues, I either redirect via exception or separately track the health of the pointer with another object (and call exceptions on that). This usually alleviates most of the frustration with a complete crash, but the issue can be pretty subtle. CTD still occasionally happens, even with all the tricks that folks have mentioned. Cheers, Neb
Additionally, upon handling the exception, you could also just auto trigger leave on body or some other flush statement. That's better than CTD. Corpse timers would still be active presumably.
You can't catch null pointer exceptions in C++ can you? I'll admit I'm rusty but don't you get an access violation regardless if it's in a try block?
Correct, assuming a C++ environment, the standard try catch doesn't work for the reason you mentioned. There are several workarounds (not saying that they are perfect but they exist) including: try/finally (instead of try catch) and other health checking mechanisms for pointers. Most C++ now tries to avoid getting trapped in the null pointer calling/derefence. Check out the following as an example from MSDN: https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/s58ftw19(v=vs.90) Additionally, there are some extra requirements based upon the C++ build environment. Though this may just end up being a bandaid to a bigger problem. Also, had an additional CTD just now by attempting to loot some mercury object from the hole. Cheers, Neb
Additionally, prior to pointer usage, can always just do a null check first (even if for temp debugging purposes)