Download
(139 Kb)
Download
Updated: 03/30/24 03:21 PM
Pictures
File Info
Compatibility:
Scions of Ithelia (9.3.0)
Updated:03/30/24 03:21 PM
Created:10/25/20 04:32 PM
Monthly downloads:14,338
Total downloads:955,592
Favorites:319
MD5:
Categories:Libraries, Data Mods
9.3.0
LibHistoire - Guild History  Popular! (More than 5000 hits)
Version: 2.3.0
by: sirinsidiator [More]
New guild history
The original guild history API was written more than 10 years ago and never had any of the things addons (ab)use it for in mind.
A few years ago in 2020 the amount of requests generated by addons reached the point where it destabilized the game servers and as a result the API was even disabled completely for a while, until ZOS implemented limits on how many requests can be sent.
This was when I wrote the first version of LibHistoire to provide a cache for guild history data, which different addons could use to avoid sending unnecessary requests to the server and avoid even more restrictions for addons.

Starting with Update 41 in early 2024, the game finally received its own guild history cache. Due to that the library won't need to store event data any more and instead just offers features to inspect and manage the ingame cache as well as a compatibility layer to make transitioning old addons to the new API easier.
Any data that was collected by old versions of LibHistoire in the past will be deleted the first time you log in with version 2 enabled, in order to improve loading times.

Currently the game stores its cache files outside of the usual live folder and they can be found in the following location:
Windows:
Code:
%AppData%/../Local/Elder Scrolls Online/live/CachedData/GuildHistory
MacOS:
Code:
~/Documents/Elder Scrolls Online/live/CachedData/GuildHistory
You should always back them up together with your LibHistoire saved variable file to ensure proper operation.
The cache is stored per account, so data received for a guild on one account currently won't be shared with another who's in the same guild and will have to be requested again from the server.

The new API allows to receive up to 500 events (from previously 100) with each request, but at the same time the cooldown for addon requests has been increased to 2 minutes (from 30 seconds).
This means automated requests will be effectively 25% faster for busy categories, but may currently take a bit longer overall to finished for all categories.
Depending on how well the new history performs on the server, this cooldown is subject to change and we may see less waiting time between requests in the future.

So what is this library for now?
The main purpose of the library is currently to coordinate server requests and event processing between different addons via a common interface, to reduce waiting time and improve game performance.
It also provides a variety of functions and settings for users to see what is going on in the background and to interact with and control the cache behaviour.

Dependencies
The following dependencies are required by LibHistoire:
  • LibAsync - to minimize fps loss while processing history events
  • LibCustomMenu - for the options menu of the status window
  • LibDebugLogger - for logging useful debug information in case something goes wrong
  • LibAddonMenu-2.0 - Provides settings menus for addons

User Interface

The status icon on the bottom right of the guild history symbolizes the link status of the currently viewed category in the selected guild. On hover it will show a tooltip that gives information about the stored history and unlinked events.


The new guild history status panel will provide an overview of the cache status for each guild and category.

On the left side it will show each guild and the overall progress, on the right side it will show the individual categories for the currently selected guild.
Clicking on a guild or category will update the selection in both the status window and the guild history menu accordingly.

The category status bar shows all the time ranges which are stored in the cache, as well as queued requests and currently processed events. It also uses different colors to symbolize different states for each segment.

Guild status colors:
Pink - Waiting for server requests to finish
Red - No more requests queued, but not everything is linked
Yellow - Processing events
Green - Everything is linked up

Category status colors:
Blue - Linked range, but has not been connected with newest events yet
Red - Events after the linked range, but not connected to the linked range
Green - Linked range is up to date with newest events
Dark green - Last part of the linked range which does not contain any events
Grey - Events before the linked range, or events in a category with no listeners or which is forced off
Purple - Pending server request
Pink - Part of the request range which already contains events
Yellow - Already processed events
Dark Yellow - Events to be processed

Examples for all the colors:
Warning: Spoiler


When you hover over any of the entries, a tooltip will show you the same information as the tooltip in the guild history menu.
The category entries also offer a menu with some options.
On the bottom of the panel you can see an icon which symbolizes the overall state and gives some general information about what is happening when you hover over it.
The cog button on the top right will open a context menu with an option to unlock the window so it can be moved and an option to hide it (same as the button on the bottom left of the guild history)

Special Thanks
FooWasHere who helped me test how the history behaves on rank and permission changes
ZOSDanBatson and ZOSSethL for answering my many questions about the history API
Everyone else who helped me test this and gave me feedback

For Developers
Why should you use it?
  • It minimizes the cooldown for server requests sent by addons to the absolute minimum and if every addon starts using it, everyone gets their data faster.
  • It takes care of all the complexity that comes with requesting the history. There are many special cases you probably didn't even think about. The lib will handle them all for you.
  • It makes it easy to process a specifc time range, or continuously follow the history in chronological order.
  • It automatically spreads out event processing over multiple frames via LibAsync, so you don't have to worry about fps impact.

How does it work
The library keeps track of which events have already been sent to listeners and ensures that it doesn't skip anything in case newer events are received before it caught up.
When a listener starts, it will first iterate over available "linked" events, then wait for "unlinked" events to get linked before it iterates over those and finally start passing along newer events whenever they arrive. This is all done via LibAsync, so you will only get as many events per frame as you can safely process without affecting performance.
To ensure an addon only starts processing from where it left off, it offers ways to select a starting point either by specifying an eventId or a timestamp.

If you find a problem, feel free to open an issue over on github, or leave a comment here on ESOUI.

Migration Guide
Here is a short guide on how to migrate your addon to the new processor api.

The GUILD_HISTORY_* and GUILD_EVENT_* constants used by the old history api are not compatible with the new processor api and need to be replaced with the appropriate new constants.
You can use the mapping for the legacy listener api found in compatibility.lua as a starting point to figure out what to replace them with.

The new processor class is very similar to the legacy listener class, but has a few key differences:
  • You now have to specify an addon name which is shown in the status UI and debug information to help identify who is registered to a category.
  • SetBeforeEventTime has been changed to exclude the specified time. Keep that in mind when updating code that uses this function directly.
  • The iterationCompletedCallback has been removed in favor of a new onStopCallback which passes a StopReason to inform you why the processor has stopped.
  • SetStopOnLastEvent has been renamed to SetStopOnLastCachedEvent to better communicate what it does.
  • A new registeredForFutureEventsCallback was added to inform you when the processor has finished passing all cached events and is now waiting for new events to arrive.
  • A new receiveMissedEventsOutsideIterationRange flag was added to give you a way to listen to incoming events that are not included in the specified iteration range.
  • SetTimeFrame was removed in favor of StartIteratingTimeRange which simplifies configuration and directly starts the processor.
  • A new StartStreaming function was added to simplify the most common use case of processing cached events since the last time the addon was loaded and then waiting for new events to arrive.
  • The event callbacks now directly receive the new event objects specified in the ingame ui code. These are shared between all addons and can point to a different event after the callback has ended, so make sure you do not modify or store them and instead extract the information you need in the context of the callback.
Check the examples and the API reference section below for more details on how you can use the new processor api.

In case you have stored any eventIds received via the legacy listener api, you will also want to convert these the first time a user starts the new version of your addon.
You can use the new LibHistoire:ConvertArtificialLegacyId64ToEventId() function to attempt converting id64 eventIds to the new id53 values.
Keep in mind that the original id64s from the old history api cannot be mapped to the new id53s, so the function may return nil for values that are not produced by the legacy listener api.

The library now also offers a new OnReady function which simplifies ensuring that it has fully loaded before you start using it.

There are now also new callbacks for when the library has linked a category to present events, as well as when the managed range has been lost, or a new managed range has been established.
Check the MANAGED_RANGE_LOST, MANAGED_RANGE_FOUND and CATEGORY_LINKED callbacks in the API reference section below.

Examples
Iterating a specific time range
This example outlines how a processor can iterate over all currently cached events in a specific time range. It will automatically stop in case the time range is not fully cached, so make sure to handle early stops as needed.

This could for example be used together with LibDateTime's GetTraderWeek function to iterate over all donations in a specific trading week and do something with them.
Lua Code:
  1. LibHistoire:OnReady(function(lib)
  2.     local guildId = GetGuildId(1)
  3.     local category = GUILD_HISTORY_EVENT_CATEGORY_BANKED_CURRENCY
  4.     local addonName = "MyAddon"
  5.  
  6.     local processor = lib:CreateGuildHistoryProcessor(guildId, category, addonName)
  7.     if not processor then
  8.         -- the processor could not be created
  9.         return
  10.     end
  11.  
  12.     local started = processor:StartIteratingTimeRange(startTime, endTime, function(event)
  13.         local info = event:GetEventInfo()
  14.         assert(info.currencyType == CURT_MONEY, "Unsupported currency type")
  15.  
  16.         local eventType = info.eventType
  17.         if eventType == GUILD_HISTORY_BANKED_CURRENCY_EVENT_DEPOSITED then
  18.             local amount = info.amount
  19.             local displayName = DecorateDisplayName(info.displayName)
  20.             ProcessDeposit(guildId, displayName, amount)
  21.         end
  22.     end, function(reason)
  23.         if (reason == LibHistoire.StopReason.ITERATION_COMPLETED) then
  24.             -- all events in the time range have been processed
  25.         else
  26.             -- the iteration has stopped early for some reason and not all events have been processed
  27.         end
  28.     end)
  29.     if not started then
  30.         -- the processor could not be started
  31.     end
  32. end)

Listening to all events in a category
This example shows how to use the new processor api to start a processor for each guild and process guild store events starting from the last time the addon was loaded and without an explicit end.

The processor may still be stopped in case the user does something that requires to evaluate how to continue without data loss. You can either handle that case by registering the onStopCallback before calling StartStreaming, or just ignore it and let the addon resume the next time the user logs in.
Lua Code:
  1. LibHistoire:OnReady(function(lib)
  2.     local category = GUILD_HISTORY_EVENT_CATEGORY_TRADER
  3.     local addonName = "MyAddon"
  4.  
  5.     local function SetUpListener(guildId)
  6.         local processor = lib:CreateGuildHistoryProcessor(guildId, category, addonName)
  7.         if not processor then
  8.             -- the processor could not be created
  9.             return
  10.         end
  11.  
  12.         local key = processor:GetKey()
  13.         local started = processor:StartStreaming(saveData.lastEventId[key], function(event)
  14.             local info = event:GetEventInfo()
  15.             if info.eventType == GUILD_HISTORY_TRADER_EVENT_ITEM_SOLD then
  16.                 ProcessItemSold(info)
  17.             end
  18.             saveData.lastEventId[key] = info.eventId
  19.         end)
  20.         if not started then
  21.             -- the processor could not be started
  22.         end
  23.     end
  24.  
  25.     for i = 1, GetNumGuilds() do
  26.         SetUpListener(GetGuildId(i))
  27.     end
  28. end)

API Reference
You can also use the api.doc.lua file in the addon folder to get autocompletion with IDEs that support it.
Warning: Spoiler
v2.3.0
- added new LibAddonMenu settings panel with
- sliders to set how long the guild history cache should retain data
- a button to allow resetting all caches at once
- the path to the cache files
- fixed managed range reset not working correctly in some cases
- fixed assertion errors during processing not getting displayed
- now it will properly explode instead of silently getting stuck when invalid timestamps are received
v2.2.1
- fixed error when resetting managed range while a legacy listener is registered

v2.2.0
- re-enabled the selection of guilds and categories via the status window, now that the game has been fixed
- NOTE: switching guilds and categories via the status panel won't send requests automatically. You'll have to manually hit E or use the ingame ui to do so
- added new entry to status window menu to show debug information
- added new API callback "CATEGORY_LINKED" for when a category has been linked to present events
- added new API functions "IsReady" and "OnReady" for easier initialization
- added new guild history event processor API
- NOTE: it's still a bit experimental, so let me know if you encounter any issues and be prepared to update your code if necessary
- check the addon description for more information and a migration guide
- there is also an api.doc.lua file which can be used with language servers to provide autocompletion without having to include the full source code
- fixed legacy listener SetBeforeEventTime, SetTimeFrame and iterationComplete callback behaving slightly different from version 1
- fixed default position for status window

v2.1.1
- made status window more compact
- fixed link status icon being rendered behind the background
- fixed logout dialogue unintentionally showing up in some cases when it should not
- added workaround for error in ATT until it can be fixed properly

v2.1.0
- renamed "linked range" to "managed range" and "listener" to "processor"
- NOTE: legacy listeners will continue to be called just that
- changed exit warning dialogues to show up less frequently and be more clear about why you should care
- added exit warning dialogues to slash commands and gamepad mode logout
- added assertion to check incoming events for invalid timestamps
- NOTE: everything will explode for now when it happens. Please make sure to report it, so I can get an idea when and how often it occurs and decide what to do about it
- added shift modifier to pagination buttons in the vanilla history UI to allow jumping to the first or last page quickly

v2.0.7
- improved warning text for "reset linked range" and "clear cache" actions with some explanations
- fixed automated requests not getting discarded when they already got their range received via manual requests
- fixed errors after restoring a backup of the cache without restoring a backup of the library save data
- fixed incorrect zoom mode getting used when linked range is reset
- fixed status bar not properly showing progress when processing events older than the linked range

v2.0.6
- added version label to status window
- fixed a case where automated requests did not properly fill in gaps
- fixed automated requests getting discarded too early in some cases

v2.0.5
- fixed automated request getting queued for categories that are forced off
- fixed categories not getting linked properly in some cases
- fixed problems when switching between different accounts that share one or more guilds
- fixed incorrect status color for linked range that has not been connected to latest events yet
- fixed and improved information shown in status tooltip

v2.0.4
- fixed error while processing events

v2.0.3
- added request prioritization to prefer sending requests that matter the most first
- as long as the guild history menu is open, LibHistoire will now prefer requests for the currently visible guild
- other than that it will prioritize requests by how many listeners are registered for a category as well as a base priority (trading > bank gold > bank items > roster > others)
- further reduced amount of automated requests by not sending them to categories that won't produce any events (e.g. guild without bank or store)
- fixed various cases of automated requests getting stuck
- fixed an issue where requests used the wrong time range when the game has just been started
- fixed requested time ranges not showing correctly in the category status bars
- fixed how linked status is determined for categories
- fixed no new linked range getting selected on reset
- fixed linked range getting lost on login when the game has pruned data from the cache

v2.0.2
- fixed error when listener tries to iterate over a range without any events
- fixed "missing range" zoom mode not showing the intended range, making it appear as if there is no data stored at all
- fixed request time optimization producing incorrect time ranges
- reduced how often empty categories are requested to once a week

v2.0.1
- added option to delete all pending automated requests
- temporarily disabled the selection of guilds and categories via the status window
- fixed manual requests getting stuck with the addon cooldown of 2 minutes
- fixed automated requests blocking manual requests
- removed some unused code

v2.0
- rewrite for the new history api (check this post for more details)
- automatic removal of old history save data
- removed rescan and force link features
- compatibility layer for old history api
- new api callbacks
- smart history requests
- skip requests for categories with no listening addons
- fetch oldest events first after prolonged absense
- new category cache menu
- reset linked range button
- clear cache button
- request mode setting
- improved cache status bar
- cache segmentation display
- automated request visualization
- animated progress bar
- zoom level setting (in main menu)
- new colors
v1.5.1
- fixed issue that prevented other addons from receiving data

v1.5.0
- added warning about upcoming changes
- added code to disable current library version in update 41
- updated for Secret of the Telvanni

v1.4.1
- fixed progress bar not updating when linking starts

v1.4.0
- fixed history rescan not updating the status window
- added rescan progress metrics in tooltip
- improved rescan speed dramatically (~100 times faster)
- added warning on exit and UI reload when events are currently being processed
- updated for Necrom

v1.3.0
- fixed error due to unused event types being removed in the latest game update
- fixed HISTORY_RESCAN_ENDED callback not firing when no events are detected during a rescan
- added stopOnLastEvent flag which makes the library stop the iteration when the last stored event is reached, instead of waiting for new events to appear
- updated for Firesong

v1.2.2
- fixed error when serializing unexpected event types

v1.2.1
- fixed an error preventing events from getting stored for new users or when joining a new guild
- fixed progress bars flickering yellow on initial load
- fixed event listener getting stuck in a loop in some cases
- fixed game freezing when storing missing events during a rescan in categories with lots of stored events
- fixed typo in logout warning dialog

v1.2.0
- fixed an issue that would cause some players to get kicked from the PTS (public test server)
- fixed progress bar not immediately filling to 100% when the last batch of missing events are received in a category
- fixed a rare error that could occur when stored data is deserialized and added some assertions to find the underlying reason
- changed progress bars on status window to show in a red color while events are missing and yellow while events are being processed
- added a confirmation dialog when trying to logout or quit the game while history events are not yet linked, which will send players to the history menu
- updated api version

v1.1.3 (dedicated to Sharlikran who found all these problems)
- fixed codec storing item links in an uncompressed form
- fixed several codec bugs that caused item links to get decoded into invalid links
NOTE: No data was lost and I believe I've found and fixed all incorrect cases and added unit tests to guard against regressions. As an additional measure the lib will now also throw an assertion error if it encounters links that cannot be decoded. Please make sure to report these so I can add them to the test cases and fix them!

- fixed several more bugs in the new GetPendingEventMetrics function

v1.1.2
- fixed error when rescanning a category

v1.1.1
- fixed error in new GetPendingEventMetrics function

v1.1.0
- improved event decoding speed
- changed some logging to reduce log spam
- fixed afterEventTime not returning the correct event when multiple events have the same timestamp
- fixed status tooltip not updating when linking process begins
- added progress info to tooltip while linking
- added log warning when trying to start a listener without an event callback
- added new functions to EventListener API
- GetKey - returns an identifier which can be used to store the last seen eventId for a listener
- GetGuildId - returns the guildId of a listener
- GetCategory - returns the category of a listener
- GetPendingEventMetrics - returns
the amount of stored or unlinked events that are currently waiting to be processed by the listener
the average processing speed in events per second or -1 if not enough data is yet available
the estimated time in seconds it takes to process the remaining events or -1 if no estimate is possible
- SetBeforeEventId, SetBeforeEventTime
these can be used to limit the iteration range and automatically stop the listener when they are passed
they will also ensure the correct data is returned by the GetPendingEventMetrics function when only a subset of the data is requested (otherwise it will consider all available events)
- SetIterationCompletedCallback
when an end criteria is set, this callback will fire when the listener has stopped automatically
- SetTimeFrame(startTime, endTime)
a convenience method to specify a range which includes the startTime and excludes the endTime
v1.0.2
- added new callback for when Histy is ready

v1.0.1 - initial release
Optional Files (0)


Archived Files (26)
File Name
Version
Size
Uploader
Date
2.3.0
137kB
sirinsidiator
03/28/24 01:58 PM
2.2.0
137kB
sirinsidiator
03/27/24 01:58 PM
2.1.1
128kB
sirinsidiator
03/23/24 07:40 AM
2.1.0
128kB
sirinsidiator
03/21/24 05:53 PM
2.0.7
127kB
sirinsidiator
03/17/24 12:11 PM
2.0.6
127kB
sirinsidiator
03/16/24 10:48 AM
2.0.5
127kB
sirinsidiator
03/15/24 05:02 PM
2.0.4
126kB
sirinsidiator
03/15/24 06:05 AM
2.0.3
126kB
sirinsidiator
03/14/24 07:24 PM
2.0.2
126kB
sirinsidiator
03/13/24 07:20 PM
2.0.1
126kB
sirinsidiator
03/12/24 07:06 PM
2.0.0
124kB
sirinsidiator
03/11/24 04:49 AM
1.5.1
120kB
sirinsidiator
11/02/23 11:51 AM
1.5.0
120kB
sirinsidiator
11/01/23 03:20 PM
1.4.1
118kB
sirinsidiator
06/14/23 12:54 PM
1.4.0
118kB
sirinsidiator
04/19/23 12:44 PM
1.3.0
118kB
sirinsidiator
11/01/22 08:16 AM
1.2.2
118kB
sirinsidiator
04/25/21 06:41 AM
1.2.1
118kB
sirinsidiator
04/24/21 03:01 PM
1.2.0
118kB
sirinsidiator
04/22/21 01:22 PM
1.1.3
119kB
sirinsidiator
12/12/20 11:12 AM
1.1.2
118kB
sirinsidiator
12/05/20 02:33 PM
1.1.1
118kB
sirinsidiator
12/05/20 09:47 AM
1.1.0
118kB
sirinsidiator
12/04/20 07:01 AM
1.0.2
115kB
sirinsidiator
10/31/20 05:32 AM
1.0.1
115kB
sirinsidiator
10/25/20 04:32 PM


Post A Reply Comment Options
Unread 07/22/21, 06:05 AM  
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view AddOns

Forum posts: 1579
File comments: 1132
Uploads: 41
Re: Please clarify the Logout Notification

Originally Posted by Shadowshire
(1) What does the message signify by close the game now?
It means either you completely close the client to go back to the desktop, or you log out to the title screen. Character select is actually fine, but I don't have a way to show the message there in case you were to log out or quit and at the time I added the dialog it seemed more reasonable to show it on log out instead of having people who close the game from the character select screen complain why their data is missing.

Originally Posted by Shadowshire
(2) If a player does not cancel the log-out, then will Guild Store sales data be irretrievably lost, or corrupted?
As stated above switching characters is fine, although it will waste some CPU power to re-scan the already loaded data once you log in on a character.

Originally Posted by Shadowshire
(3) What happens when a player Reloads the UI while playing a character, for example, after a UI Error occurs? It seems to me that the outcome should be the same as when a player logs-out of a character, then chooses to play the same character again from the Select Character dialog screen.
Exactly. There is basically no difference in regard to LibHistoire.

Originally Posted by Shadowshire
In the first sentence above, it appears to me that "(future to past)" should be "(present to past)" instead, and that "(past to future)" should be "(past to present)". It does not seem likely that data about future Sales are provided by the mega-server. But I could be wrong.
Never underestimate the powers of a mega-server. In reality ESO is a single player game and everyone else is just simulated, thus it already knows what happens next. :P (Jokes aside, English is not my first language, so you'll have to excuse mistakes like that )

So to reiterate, logging out of one character and into the next is fine, logging out to character select and then quit or log out of the account from there is not fine.
Regarding your suggestion, I still have some reservations about it, but I may just try it in the next version to see how it works out. Should the amount of people who complain about missing data rise again, I'll add it back though.

Also keep in mind that there are several easy ways how power users can relog chars without triggering the dialog mentioned in the comments below.
Report comment to moderator  
Reply With Quote
Unread 07/21/21, 10:19 PM  
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view AddOns

Forum posts: 666
File comments: 2024
Uploads: 15
Re: (Reply to sharlikran)

Originally Posted by Shadowshire
LibHistoire cannot always accomplish its work without player participation.
This is the part I have the hardest time getting users to understand. People see it as an inconvenience when it has nothing to do with sirinsidiator or myself. Nor does LibHistoire lack functionality.

I understand users want an answer I really do. However, I see it as an act of futility to ask mod authors why things are the way they are. Because it is ZOS users should be asking because only they can provide the answer or make any changes.

I do hope you get a response other then mine but in the event you don't, I hope the functionality sirinsidiator has created helps you maintain your sales information as it really is the best approach given the circumstances.
Last edited by Sharlikran : 07/21/21 at 10:26 PM.
Report comment to moderator  
Reply With Quote
Unread 07/21/21, 08:41 PM  
Shadowshire

Forum posts: 1
File comments: 402
Uploads: 0
(Reply to sharlikran)

Originally Posted by Sharlikran
@Shadowshire Thank you for taking the time to share your thoughts with the author so that after he reads everything if he could clarify anything, he can do so in a future version.

....

.... Don't consider LibHistoire to be lacking functionality. The game itself must have the sales (know as Events) loaded into memory before they can be scanned by LibHistoire or any other sales related software.

Anything you do to interrupt LibHistoire such as reloding the UI or logging out to log into another character, (don't get nitpicky about wording) means that progress will be lost. Unless ZOS changes how guild history functions, the circumstances are not within the control of the mod author.
You are welcome, and I look forward to sirinsidiator's response.

In my experience and observation, after I use the Show More key on the Guild History > Sales > All page, for each guild for which events are pending, LibHistoire has acquired all of them from whatever source it does so. Then I can log-out of the character which I am playing (or reload the UI) and LibHistoire will not be affected. The Notification warning will not be displayed. When execution of LibHistoire resumes, ordinarily it will proceed with any events which remain to be "linked".

For what they may be worth, I have made sequences of screenshots which show LibHistoire's progress as it occurred over the span of playing each of six characters in the course of several hours.

As far as I can determine, there has not been any loss of data. For example, there are no gaps on the MM tooltip Histogram shown for items for which there are dozens of sales per day. Also, the number of Sales which Master Merchant currently retains continues to increase, until the criteria for deleting records take effect.

Nonetheless, sometimes I have reasons to suspect that LibHistoire might have one or more bugs. Collecting evidence can be difficult and time-consuming. But I've set myself the task of doing what I can to see whether I can obtain information which the developer will need to correct any evident error.

As to being "nit-picky about wording", at present, the LibHistoire Notification lacks clarity in the context in which it is displayed. The confusion it creates inspires the complaints and "rants" which players post. The ZOS design characteristics aside, unfortunately, given the performance problems of the game client and mega-server system -- among other potential sources of problems -- LibHistoire cannot always accomplish its work without player participation.

Again, in my experience, after I use the keybind for Show More until there are no more events to "show", the LibHistoire Notification will not be displayed thereafter. Sometimes I play the first character that I chose long enough that apparently LibHistoire acquires all "events" which would be obtained if I used the Show More feature on each of the respective Guild UI Sales History pages. Which is to say, when I log-out of the character, its Notification warning is not displayed. But when it is displayed, I Cancel the log-out and access the Guild UI to effect the process of retrieving all past unlinked events.
Report comment to moderator  
Reply With Quote
Unread 07/20/21, 04:05 PM  
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view AddOns

Forum posts: 666
File comments: 2024
Uploads: 15
@Shadowshire Thank you for taking the time to share your thoughts with the author so that after he reads everything if he could clarify anything, he can do so in a future version.

I did delete the comments you left in the MM comments section because I felt they were asked and answered and really only pertained to what you wanted to know.

The section What is being scanned is not very verbose and I don't feel it needs to be. The first sentence states that LibHistoire only has access to what is loaded into memory. As you know from reading my previous comments, that happens either by automatic requests or because you manually press E.

I won't comment more and wait for sirinsidiator because he will probably be more concise. However I did want to reiterate the theme of my responses to your concerns. Don't consider LibHistoire to be lacking functionality. The game itself must have the sales (know as Events) loaded into memory before they can be scanned by LibHistoire or any other sales related software.

Anything you do to interrupt LibHistoire such as reloding the UI or logging out to log into another character, (don't get nitpicky about wording) means that progress will be lost. Unless ZOS changes how guild history functions, the circumstances are not within the control of the mod author.
Last edited by Sharlikran : 07/20/21 at 11:01 PM.
Report comment to moderator  
Reply With Quote
Unread 07/20/21, 06:55 AM  
Shadowshire

Forum posts: 1
File comments: 402
Uploads: 0
Question Please clarify the Logout Notification

The following dialog message is displayed almost every time when I log-out of the first character which I have chosen to play:

LibHistoire has not linked your history yet! If you close the game now, you will lose any progress and have to start over the next time.

(1) What does the message signify by close the game now?

The context is that I am logging-out of a character with which I have been playing TESO. Doing so displays the Select Character dialog screen afterward, and the game client continues running. Does simply logging-out of playing a character cause LibHistoire to lose any progress, so that it must "start over next time"?

(2) If a player does not cancel the log-out, then will Guild Store sales data be irretrievably lost, or corrupted?

(3) What happens when a player Reloads the UI while playing a character, for example, after a UI Error occurs? It seems to me that the outcome should be the same as when a player logs-out of a character, then chooses to play the same character again from the Select Character dialog screen.


On the ESOUI LibHistoire Addon Info tab:
Right now the game provides the history in an inverse order (future to past) of what addons actually try to use (past to future), so before the library passes any events to addons, it will attempt to load the full time range since you last played the game. During this time, it will keep them in a temporary "unlinked" state and only when it encounters the last stored event, it will save them and start sending events to listening addons. If you quit the game before that happens, all progress will be lost and it will have to start over from the beginning the next time you log in.
In the first sentence above, it appears to me that "(future to past)" should be "(present to past)" instead, and that "(past to future)" should be "(past to present)". It does not seem likely that data about future Sales are provided by the mega-server. But I could be wrong.

The last sentence states "If you quit the game before that happens, ..." But ordinarily I am not quitting the game before LibHistoire completes its task. Rather, the Notification is displayed after I chose the ESC menu Log Out option to return to the Select Character dialog screen. That said, if a player does choose the Quit option from the ESC menu while logged-in to play a selected character, then displaying the Notification certainly appears justified.

So: I suggest that you change the LibHistoire design -- if that is possible -- so that the Notification will be displayed only when it has not completed linking the Sales events and the player has chosen to Quit the game. That is, if logging-out of a character to the Select Character dialog screen does not disrupt the operation of LibHistoire, which can resume after the same or another character is subsequently selected.

There are two optons on the UI which a player can use to stop playing the game. As noted above, one is the Quit option on the ESC menu, shown while the player is currently logged-in to a character. The other is by using the Back option on the Select Character dialog to return to the primary account/game log-in dialog screen. The game client continues to run while that dialog is shown, until and unless the player chooses the Quit option shown in the upper right-hand corner of its display.

However, no add-ons remain loaded. They are loaded only after a player selects which character to play, and they are unloaded when the player chooses to log-out of that character (or to Quit the game while logged-in to a character). On the face of it, LibHistoire must start afresh if the player does go Back to the primary account/game log-in dialog, then subsequently logs-in to resume playing TESO. So, displaying the Notification is justified after the player uses the Back option on the Select Character dialog screen.

Thank-you for your time and attention to this matter. Thank-you also for all of the time and effort which you have applied to developing LibHistoire. May peace be with you.

Report comment to moderator  
Reply With Quote
Unread 07/18/21, 12:38 PM  
tralce
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 96
Uploads: 2
Any way to purge out data older than x days, or purge out data from guilds I'm no longer in?
Last edited by tralce : 07/20/21 at 09:35 AM.
Report comment to moderator  
Reply With Quote
Unread 07/15/21, 12:51 AM  
fredd

Forum posts: 12
File comments: 26
Uploads: 0
Originally Posted by jayman10000
Originally Posted by lnfinity
whats your solution? i do crafting writs daily on 11 chars and this is so annoying
.
Yeah me too the solution was I found a solution through an addon that offers a keybind for quitting, when using that the quit feature from libhistoire wont trigger. I found out you can actually also just type /logout (or /quit) in the chat field, as that is what the addons do, and then libhistoire wont complain.

This is a nice solution I think, that way both features can work for us; if you use the menu to quit/logout you get warning from lihistoire which is actually a good feature. But if you deliberately use /logout or /quit then you KNOW what you are doing it doesnt have to bug you with the message about missing history data getting lost (and you can also copy/paste those commands it so it will be almost more easy than using menu).


If you need an addon for it I know T.O.M. has keybinds for quitting.

Originally Posted by Sharlikran
That makes no sense. The nag as you and others call it isn't so that you leave the game running. You press one single (but yes additional) key to log out, or request your data. Because again, the server won't give you sales any faster then the server wants to. If you want to maintain you sales later that's fine press alt and log out.
Thank you Sharlikran for your wonderful work; my personal wish is that the above functionality can be left as it is now to support both, so we still get warning when using menu to logout or quit, but when using /logout or /quit from chat there will be no warning!
Hi what is T.O.M please I can't find this on ESOUI what does it stand for? thx
Report comment to moderator  
Reply With Quote
Unread 06/27/21, 02:32 AM  
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view AddOns

Forum posts: 666
File comments: 2024
Uploads: 15
Originally Posted by assoui
Thank you for this addon. Just one query, is this addon required by any other addon other that Master Merchant?

Because I have alot of addons and this addon seems to want to scan my guild history even when I disabled Master Merchant so I am checking if any other addon could be invoking it. I usually leave library addons alone in my Cyro addon profile as they don't [usually] do any activity unless used by another non-library addon.

If it does do something on its own without invoking from a main addon, I would suggest removing the lib from the addon name as it may cause confusion when optimizing addon loading.
Version 3.1.0 of MM would have done the same thing. The server decides how often to send new events but it does not disable that if you are in Cyrodiil. The Library is responding to the server not that the library has a fault to it.

So if you are in Cyrodiil and you want to disable MM (which makes sense) then disable LibHistoire as well.

Caution though. Many people dislike that the server does not send events quickly enough. If you disable LibHistoire when you have unlinked events it will interrupt that. So I suggest fully linking all events before you disable LibHistoire.

Once you enable LibHistoire and MM again then it will pick up where you left off as if you had been logged out for the day.
Last edited by Sharlikran : 06/27/21 at 02:47 AM.
Report comment to moderator  
Reply With Quote
Unread 06/27/21, 01:28 AM  
assoui

Forum posts: 0
File comments: 28
Uploads: 0
Thank you for this addon. Just one query, is this addon required by any other addon other that Master Merchant?

Because I have alot of addons and this addon seems to want to scan my guild history even when I disabled Master Merchant so I am checking if any other addon could be invoking it. I usually leave library addons alone in my Cyro addon profile as they don't [usually] do any activity unless used by another non-library addon.

If it does do something on its own without invoking from a main addon, I would suggest removing the lib from the addon name as it may cause confusion when optimizing addon loading.
Report comment to moderator  
Reply With Quote
Unread 06/25/21, 10:00 AM  
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view AddOns

Forum posts: 666
File comments: 2024
Uploads: 15
Re: Using on a laptop & PC?

Originally Posted by maximoz

Yup ... that's what i am doing for my pc and laptop all these while.

It applies to other addons save variables too.
Originally Posted by daemondamian
Hi folks, is it possible to use the addon on a laptop & pc intermittingly without having to use "show more" to update the guild history?

In particular would copying the LibHistoire addon folder from the most recently used device - say the laptop - to the pc and overriding the files on the pc work?
When creating a backup or when copying file between computers keep all the files together. They contain tracking variables that need to mach the data in the files. Like a matching pair of dual channel Ram.

Minimum required
LibHistoire.lua
MasterMerchant.lua
That would make it such that you don't need to use Show More except from the few hours difference there may be. If you don't copy both the tracking variables in the MasterMerchant.lua file will not be able to accurately tell LibHistoire which events you have. So it may cause LibHistoire to loop over more events then needed.

Additional Files
MM00Data.lua
<< up to >>
MM16Data.lua
That would not only have the LibHistoire data but the sales data as well.
Last edited by Sharlikran : 07/06/21 at 04:18 PM.
Report comment to moderator  
Reply With Quote
Unread 06/25/21, 09:52 AM  
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view AddOns

Forum posts: 666
File comments: 2024
Uploads: 15
Re: Corrupted MM file

Originally Posted by Pelikito
One of my MM0x files somehow got corrupted. I managed to get a backup of my savedvariables folder from 2 days ago. But now I have a 2 day hole date on my sales data. Is there any way o force LibHistoire to go over the sales data of the last few days again? Or if it has the data stored, to re-send it to Master Merchant so it populates the files with the missing data? Thanks for the help.
You would use the slash commands in the sticky post for MM, in the exact order they are shown. Then click the Refresh button in the MM window located in the lower right corner.
Report comment to moderator  
Reply With Quote
Unread 06/25/21, 09:47 AM  
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view AddOns

Forum posts: 666
File comments: 2024
Uploads: 15
Originally Posted by Akbar
So first off, to the dev: Thank you, I recognize the current issues with it being very slow are outside of your control, and this is a useful addon that does its best to not exacerbate that exact issue.

It has, however, gotten almost unusably slow.
As you have mentioned, the author can not do anything about that. It is ZOS controlled depending on server load and whatever criteria they have in place. It's not information available to authors.

Originally Posted by Akbar
If I don't force-link, I exacerbate my problem by now having two days to catch up on. If I force link, I'm missing about half a day's worth of sales.
That is not what I have in the MM documentation.

Originally Posted by Akbar
You've mentioned that you can speed things up by requesting the data manually. I can't figure out how to do this.
The documentation can be accessed from in game by opening the MM settings and clicking one of the grey (?) symbols. It will open a browser.

The specific section you need is Update Your Guild History Each Day. However, you should probably take the time maybe on the weekend when you have more then 40 minutes to play and do a Ten Day scan so you have no gaps for at least that amount of time. The server only stores 10 days.

If you do a Ten Day Scan and then keep the data up to date you won't have to do another Ten Day scan because MM and LH would just be examining sales and then skipping them because they would be duplicates of what is already stored in the data files.
Last edited by Sharlikran : 06/25/21 at 10:05 AM.
Report comment to moderator  
Reply With Quote
Unread 06/21/21, 08:14 PM  
burito
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 4
Uploads: 1
Interfering with the logout process is an abhorrent behavior. I'm surprised ZO permitted it at all.

Any library that displays a dialog, or outputs any text at all, has utterly failed at its one job, being a library.

It can return error codes that the thing using the library can interpret and choose to display a message about, but a library? Absolutely not.
Report comment to moderator  
Reply With Quote
Unread 06/12/21, 10:51 PM  
maximoz
AddOn Author - Click to view AddOns

Forum posts: 4
File comments: 30
Uploads: 3
Re: Using on a laptop & PC?

Originally Posted by daemondamian
Hi folks, is it possible to use the addon on a laptop & pc intermittingly without having to use "show more" to update the guild history?

In particular would copying the LibHistoire addon folder from the most recently used device - say the laptop - to the pc and overriding the files on the pc work?

Thanks
Damian.
Yup ... that's what i am doing for my pc and laptop all these while.

It applies to other addons save variables too.
Report comment to moderator  
Reply With Quote
Unread 06/12/21, 10:38 AM  
daemondamian

Forum posts: 0
File comments: 16
Uploads: 0
Using on a laptop & PC?

Hi folks, is it possible to use the addon on a laptop & pc intermittingly without having to use "show more" to update the guild history?

In particular would copying the LibHistoire addon folder from the most recently used device - say the laptop - to the pc and overriding the files on the pc work?

Thanks
Damian.
Last edited by daemondamian : 06/12/21 at 10:38 AM.
Report comment to moderator  
Reply With Quote
Post A Reply



Category Jump:

Support AddOn Development!

You have just downloaded by the author . If you like this AddOn why not consider supporting the author? This author has set up a donation account. Donations ensure that authors can continue to develop useful tools for everyone.