View Single Post
04/29/24, 11:44 AM   #40
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 665
What is strange to me is that I don't need disable sales tracking for TTC nor do I need to have TTC completely disabled. I have sales tracking for TTC disabled at the moment because I requested that for other users to try and I'm just doing it as well. However, I don't think I had any issues with it enabled recently after the second incremental patch and it was enabled for several days after the last patch.

So not disparaging any mods but I have listed the mods I found (looked pretty thoroughly today) that use guild history whether or not they use LibHistoire. The reason Tamriel Trade Centre isn't listed as using LibHistoire as an optional dependency is because it doesn't set up a listener.

I can't say what would cause different users to have different situations. Obviously I only use MM and AMT and even then I only use MM on one character normally. I also don't know which mods use Legacy Listeners as opposed to processors. MM and AMT still use legacy listeners.

I don't experience any broken categories, nor do I see the spinning wheel endlessly, and I'm not told that I can only request data every 2 seconds unless I press E too soon.

There is something I feel is important when it comes to the information sent to LibHistoire that I don't think other mods take into consideration. In my personal opinion it seems to work better if you update your recent Timestamp or EventID in SavedVariables only when GetNumGuildHistoryEventRanges() returns 1 when the callback is used to record guild history data.

For example I could log in and out several times over the course of 3 days and my tracking variables are not updated at all. Next time I log in then the Timestamp or EventID used with LibHistoire is still from 3 days ago. LibHistoire is probably smart enough to work without doing that but to me it works better and is just common sense. Because if your tracking variable for LibHistoire is from a sale or bank deposit from 10 hours ago, but GetNumGuildHistoryEventRanges() returns more than 1 then you have multiple event ranges and if you are missing 72 hours of data but you tell LibHistoire the last event or timestamp was from 10 hours ago I don't see how that makes sense to do that.

Dan has mentioned that mods should not (in theory) cause issues that would place the ZOS Guild history on some kind of a cooldown or global cooldown, whatever it is referred to. When GetNumGuildHistoryEventRanges() returns more than one an issue was addressed already where guild history would not be properly merged or displayed in the vanilla UI. So in essence history should display and you should see E Show More and mods should not break the ZOS cache.

The fact that some people continue to have issues is a concern but I don't think there is any easily reproducible scenario. The fact that people still use a workaround to disable mods except LibHistoire and then enable mods after they have the history is also intriguing. Because I don't have to do that.

Some of the people with issues say that if they wait a short amount of time, less than a minute or even less than 30 seconds then they can't request data. I don't have that issue. Some people say with TTC disabled or all mods disabled then everything works better.

The only thing I do differently from what I read other people doing is that I only use MM, AMT, and TTC. I don't use any of the other mods listed. The only reason I feel that may have a different impact is that various mods send a Timestamp or EventID however they see fit to setup the listener and not after GetNumGuildHistoryEventRanges() is equal to 1.

MM and AMT register different categories. When you have more than one mod setting up multiple requests through LibHistoire regardless of how intelligent it is at using CreateGuildHistoryRequest() and RequestMoreGuildHistoryEvents() how many mods setting up a listener does it take before the ZOS API has enough requests that LibHistoire may receive confusing information from that ZOS API. Even if LibHistoire doesn't receive confusing information how does multiple requests affect the functionality of the vanilla API for guild history?

Every user is different. Some may be a GM and some may be an officer or some are just curious and want extra information the mods offer. Some also want MM and ATT running at the same time because of any preferences they have using ATT.

For those with any current lingering issues with guild history, what happens if you test with only MM, AMT, and TTC active? Disabling the sales tracking feature for TTC that I show above. Does that allow you to get guild history for a few days in a row without issues? To reiterate without ATT or any ITT mods or anything else listed below that isn't MM, AMT, or TTC.

If so then the current ZOS API could still be fragile enough that more than one mod using using LibHistoire for the same category, or mods not using LibHistoire but instead using CreateGuildHistoryRequest() and RequestMoreGuildHistoryEvents() directly, creates an unnecessary cooldown from mods that breaks things.

Using LibHistoire

Master Merchant (Updated in 2024)
Arkadius' Trade Tools (Updated in 2024)

Advanced Member Tooltip - LibHistoire (Updated in 2024)
ITTs Roster Bot (Updated in 2024)
ITTs Donation Bot (Updated in 2024)
Guild Taxes (Updated in 2023)
Guild Tickets (Updated in 2023)
GuildSummary (Updated in 2023)
FCO Guild Lottery (Updated in 2023)
Marcus' Guild Management Tool (Updated in 2022)
Guild Member Manager (Updated in 2022)
Guild Bookkeeper (Updated in 2022)
GuildBankLedger - Updated (Updated in 2021)
Guild Tools By Fen (Updated in 2021)

Not using LibHistoire

Shissu's Guild Tools : but it's broken and people are not using it or using a version that doesn't really request history
Tamriel Trade Centre: Checks for the presence of LibHistoire, and does not auto request data when detected. (As far as I can tell)
Raffle Gold (for Update 41)
Bank Data Exporter

LibHistoire (optional dependency)

Eso-Hub

Last edited by Sharlikran : 04/29/24 at 12:22 PM.
  Reply With Quote