Go to Page... |
%AppData%/../Local/Elder Scrolls Online/live/CachedData/GuildHistory
~/Documents/Elder Scrolls Online/live/CachedData/GuildHistory
LibHistoire:OnReady(function(lib) local guildId = GetGuildId(1) local category = GUILD_HISTORY_EVENT_CATEGORY_BANKED_CURRENCY local addonName = "MyAddon" local processor = lib:CreateGuildHistoryProcessor(guildId, category, addonName) if not processor then -- the processor could not be created return end local started = processor:StartIteratingTimeRange(startTime, endTime, function(event) local info = event:GetEventInfo() assert(info.currencyType == CURT_MONEY, "Unsupported currency type") local eventType = info.eventType if eventType == GUILD_HISTORY_BANKED_CURRENCY_EVENT_DEPOSITED then local amount = info.amount local displayName = DecorateDisplayName(info.displayName) ProcessDeposit(guildId, displayName, amount) end end, function(reason) if (reason == LibHistoire.StopReason.ITERATION_COMPLETED) then -- all events in the time range have been processed else -- the iteration has stopped early for some reason and not all events have been processed end end) if not started then -- the processor could not be started end end)
LibHistoire:OnReady(function(lib) local category = GUILD_HISTORY_EVENT_CATEGORY_TRADER local addonName = "MyAddon" local function SetUpListener(guildId) local processor = lib:CreateGuildHistoryProcessor(guildId, category, addonName) if not processor then -- the processor could not be created return end local key = processor:GetKey() local started = processor:StartStreaming(saveData.lastEventId[key], function(event) local info = event:GetEventInfo() if info.eventType == GUILD_HISTORY_TRADER_EVENT_ITEM_SOLD then ProcessItemSold(info) end saveData.lastEventId[key] = info.eventId end) if not started then -- the processor could not be started end end for i = 1, GetNumGuilds() do SetUpListener(GetGuildId(i)) end end)
ConvertArtificialLegacyId64ToEventId
Utility function to convert id64s that have been artificially created by a legacy listener to the new id53 equivalent.Lua Code:
(method) LibHistoire:ConvertArtificialLegacyId64ToEventId(id64: string) -> id53: integer53|nil
Should be used one time only to convert all id64s that have been stored by the addon when switching to the new event processor api, since it's not the fastest operation.
@param id64 — The id64 to convert.
@return id53 — The converted id53 or nil if the id64 cannot be converted.
CreateGuildHistoryListener(deprecated)
This method will be removed in a future version. Use CreateGuildHistoryProcessor instead.
Creates a legacy listener object which emulates the old guild history api. See guildHistoryCache/GuildHistoryLegacyEventListener.lua for details.Lua Code:
(method) LibHistoire:CreateGuildHistoryListener(guildId: integer, category: integer) -> listener: GuildHistoryLegacyEventListener|nil
It's highly recommended to transition to CreateGuildHistoryProcessor instead, to take better advantage of the new history api.
@param guildId — The id of the guild to listen to.
@param category — The legacy category to listen to. One of the GUILD_HISTORY_* constants. See guildHistoryCache/compatibility.lua for details.
@return listener — The created listener object or nil if no caches were found for the provided guildId and category.
See:
CreateGuildHistoryProcessor
Creates a processor object which can be configured before it starts sending history events to an addon. See guildHistoryCache/GuildHistoryEventProcessor.lua for details.Lua Code:
(method) LibHistoire:CreateGuildHistoryProcessor(guildId: integer, category: GuildHistoryEventCategory, addonName: string) -> processor: GuildHistoryEventProcessor|nil
@param guildId — The id of the guild to process history events for.
@param category — The category to process history events for.
@param addonName — The name of the addon that is processing the events. This is used to allow users to identify addons that are registered to a category, as well as to provide better logging.
@return processor — The created processor object or nil if no caches were found for the provided guildId and category.
See:
IsReady
This function can be used to check if the library is ready to be used. It will return true after the INITIALIZED callback has been fired.Lua Code:
(method) LibHistoire:IsReady() -> isReady: boolean
When the library is not ready yet, make sure to register to the INITIALIZED callback to know when it is.
@return isReady — True if the library is ready to be used, false otherwise.
See:
OnReady
A convenience function to execute a callback when the library is ready. When the library is already initialized, the callback will be executed immediately.Lua Code:
(method) LibHistoire:OnReady(callback: fun(lib: LibHistoire))
@param callback — The function to call when the library is ready. It will receive the LibHistoire object as an argument.
See:
RegisterCallback
Register to a callback fired by the library. Usage is the same as with ZO_CallbackObject.RegisterCallback. You can find the list of exposed callbacks in api.luaLua Code:
(method) LibHistoire:RegisterCallback(callbackName: Callbacks, callback: function, ...any)
@param callbackName — One of the exposed callbacks.
@param callback — The function to call when the callback is fired.
See:
GuildHistoryEventProcessor
UnregisterCallback
Unregister from a callback fired by the library. Usage is the same as with ZO_CallbackObject.UnregisterCallback.Lua Code:
(method) LibHistoire:UnregisterCallback(callbackName: Callbacks, callback: function, ...any)
@param callbackName — One of the exposed callbacks.
@param callback — The function to unregister.
See:
GetAddonName
Returns the name of the addon that created the processor.Lua Code:
(method) GuildHistoryEventProcessor:GetAddonName() -> addonName: string
@return addonName — The name of the addon that created the processor.
GetCategory
Returns the category.Lua Code:
(method) GuildHistoryEventProcessor:GetCategory() -> category: GuildHistoryEventCategory
@return category — The event category the processor is listening to.
GetGuildId
Returns the guild id.Lua Code:
(method) GuildHistoryEventProcessor:GetGuildId() -> guildId: integer
@return guildId — The id of the guild the processor is listening to.
GetKey
Returns a key consisting of server, guild id and history category, which can be used to store the last received eventId.Lua Code:
(method) GuildHistoryEventProcessor:GetKey() -> key: string
@return key — The key that identifies the processor.
GetPendingEventMetrics
Returns information about history events that need to be sent to the processor.Lua Code:
(method) GuildHistoryEventProcessor:GetPendingEventMetrics() -> numEventsRemaining: integer 2. processingSpeed: integer 3. timeLeft: integer
@return numEventsRemaining — The amount of queued history events that are currently waiting to be processed by the processor.
@return processingSpeed — The processing speed in events per second (rolling average over 5 seconds).
@return timeLeft — The estimated time in seconds it takes to process the remaining events or -1 if it cannot be estimated.
IsRunning
Returns true while iterating over or listening for events.Lua Code:
(method) GuildHistoryEventProcessor:IsRunning() -> running: boolean
@return running — true if the processor is currently running.
SetAfterEventId
Allows to specify a start condition. The nextEventCallback will only return events which have a higher eventId.Lua Code:
(method) GuildHistoryEventProcessor:SetAfterEventId(eventId: integer53) -> success: boolean
@param eventId — An eventId to start after.
@return success — true if the condition was set successfully, false if the processor is already running.
SetAfterEventTime
Allows to specify a start condition. The nextEventCallback will only receive events after the specified timestamp. Only is considered if no afterEventId has been specified.Lua Code:
(method) GuildHistoryEventProcessor:SetAfterEventTime(eventTime: integer53) -> success: boolean
@param eventTime — A timestamp to start after.
@return success — true if the condition was set successfully, false if the processor is already running.
SetBeforeEventId
Allows to specify an end condition. The nextEventCallback will only return events which have a lower eventId.Lua Code:
(method) GuildHistoryEventProcessor:SetBeforeEventId(eventId: integer53) -> success: boolean
@param eventId — An eventId to end before.
@return success — true if the condition was set successfully, false if the processor is already running.
SetBeforeEventTime
Allows to specify an end condition. The nextEventCallback will only return events which have a lower timestamp. Only is considered if no beforeEventId has been specified.Lua Code:
(method) GuildHistoryEventProcessor:SetBeforeEventTime(eventTime: integer53) -> success: boolean
@param eventTime — A timestamp to end before.
@return success — true if the condition was set successfully, false if the processor is already running.
SetEventCallback
Convenience method to set both callback types at once.Lua Code:
(method) GuildHistoryEventProcessor:SetEventCallback(callback: fun(event: ZO_GuildHistoryEventData_Base)) -> success: boolean
@param callback — The function that will be called for each missed event that was found.
@return success — true if the condition was set successfully, false if the processor is already running.
See:
SetMissedEventCallback
Sets a callback which will get passed events that had not previously been included in the managed range, but are inside the start and end criteria. The order of the events is not guaranteed.Lua Code:
(method) GuildHistoryEventProcessor:SetMissedEventCallback(callback: fun(event: ZO_GuildHistoryEventData_Base)) -> success: boolean
If SetReceiveMissedEventsOutsideIterationRange is set to true, this callback will also receive events that are outside of the specified iteration range.
The callback will be handed an event object (see guildhistory_data.lua) which must not be stored or modified, as it can change after the function returns.
@param callback — The function that will be called for each missed event that was found.
@return success — true if the condition was set successfully, false if the processor is already running.
See:
SetNextEventCallback
Sets a callback which will get passed all events in the specified range in the correct historic order (sorted by eventId).Lua Code:
(method) GuildHistoryEventProcessor:SetNextEventCallback(callback: fun(event: ZO_GuildHistoryEventData_Base)) -> success: boolean
The callback will be handed an event object (see guildhistory_data.lua) which must not be stored or modified, as it can change after the function returns.
@param callback — The function that will be called for each event that is processed.
@return success — true if the condition was set successfully, false if the processor is already running.
See:
SetOnStopCallback
Set a callback which is called after the listener has stopped.Lua Code:
(method) GuildHistoryEventProcessor:SetOnStopCallback(callback: fun(reason: StopReason)) -> success: boolean
Receives a reason (see lib.StopReason) why the processor has stopped.
@param callback — The function that will be called when the processor stops.
@return success — true if the condition was set successfully, false if the processor is already running.
See:
SetReceiveMissedEventsOutsideIterationRange
Controls if the processor should forward missed events outside of the specified iteration range to the missedEventCallback.Lua Code:
(method) GuildHistoryEventProcessor:SetReceiveMissedEventsOutsideIterationRange(shouldReceive: boolean) -> success: boolean
@param shouldReceive — true if missed events outside of the specified iteration range should be forwarded, false if they should be ignored.
@return success — true if the condition was set successfully, false if the processor is already running.
See:
SetRegisteredForFutureEventsCallback
Sets a callback which is called when the processor starts waiting for future events.Lua Code:
(method) GuildHistoryEventProcessor:SetRegisteredForFutureEventsCallback(callback: function) -> success: boolean
@param callback — The function that will be called when the processor starts waiting for future events.
@return success — true if the condition was set successfully, false if the processor is already running.
SetStopOnLastCachedEvent
Controls if the processor should stop instead of listening for future events when it runs out of events before encountering an end criteria.Lua Code:
(method) GuildHistoryEventProcessor:SetStopOnLastCachedEvent(shouldStop: boolean) -> success: boolean
@param shouldStop — true if the processor should stop when it runs out of events, false if it should wait for future events.
@return success — true if the condition was set successfully, false if the processor is already running.
Start
Starts the processor and passes events to the specified callbacks asyncronously. The exact behavior depends on the set conditions and callbacks.Lua Code:
(method) GuildHistoryEventProcessor:Start() -> started: boolean
@return started — true if the processor was started successfully, false if it is already running.
StartIteratingTimeRange
Convenience method to configure and start the processor to iterate over a specific time range and stop after it has passed all available events.Lua Code:
(method) GuildHistoryEventProcessor:StartIteratingTimeRange(startTime: integer53, endTime: integer53, eventCallback: fun(event: ZO_GuildHistoryEventData_Base), finishedCallback: fun(reason: StopReason)) -> started: boolean
@param startTime — The start time of the range (inclusive).
@param endTime — The end time of the range (exclusive).
@param eventCallback — The function that will be called for each event that is processed.
@param finishedCallback — The function that will be called when the processor stops. Only when StopReason.ITERATION_COMPLETED is passed, all events in the range have been processed.
@return started — true if the processor was started successfully, false if it is already running.
See:
StartStreaming
Convenience method to start the processor with a callback and optionally only receive events after the specified eventId.Lua Code:
(method) GuildHistoryEventProcessor:StartStreaming(lastProcessedId: integer53|nil, eventCallback: fun(event: ZO_GuildHistoryEventData_Base)) -> started: boolean
@param lastProcessedId — The last eventId that was processed by the addon or nil to start with the oldest managed event.
@param eventCallback — The function that will be called for each event that is processed. If not provided here, it has to be set with SetNextEventCallback beforehand, or the processor won't start.
@return started — true if the processor was started successfully, false if it is already running.
Callbacks
Stop
Stops iterating over stored events and unregisters the processor for future events.Lua Code:
(method) GuildHistoryEventProcessor:Stop() -> stopped: boolean
@return stopped — true if the processor was stopped successfully, false if it is not running.
Callbacks.CATEGORY_LINKED
Fired when a category has linked the managed range to present events. The guildId and category are passed as arguments.
Callbacks.HISTORY_RESCAN_ENDED(deprecated)
Rescan no longer exists.
Callbacks.HISTORY_RESCAN_STARTED(deprecated)
Rescan no longer exists.
Callbacks.INITIALIZED
Fired when the library has finished setting everything up.
Any calls to the api (aside of registering for the event) should happen after this has fired.
It will receive the LibHistoire object as an argument.
Keep in mind that this may fire before EVENT_ADD_ON_LOADED, so make sure to check if the library is ready before listening to the callback.
See:
Callbacks.LINKED_RANGE_FOUND(deprecated)
Use MANAGED_RANGE_FOUND instead.
See:
Callbacks.LINKED_RANGE_LOST(deprecated)
Use MANAGED_RANGE_LOST instead.
See:
Callbacks.MANAGED_RANGE_FOUND
Fired when a new managed range has been found. The guildId and category are passed as arguments.
This happens when the managed range is established initially or after the managed range was lost.
StopReason
Callbacks.MANAGED_RANGE_LOST
Fired when the managed range has been lost. The guildId and category are passed as arguments.
This could be due to the cache being deleted, the library detecting inconsistencies in its own save data or the user manually resetting the range.
StopReason.ITERATION_COMPLETED
An end condition has been set and the first event outside of the specified range was encountered
See:
StopReason.LAST_CACHED_EVENT_REACHED
The stopOnLastCachedEvent flag has been set and the last cached event was reached
See:
StopReason.MANAGED_RANGE_LOST
The managed range was lost (fires right after MANAGED_RANGE_LOST callback)
See:
StopReason.MANUAL_STOP
Stop has been called by the addon
See:
- sliders to set how long the guild history cache should retain data- fixed managed range reset not working correctly in some cases
- a button to allow resetting all caches at once
- the path to the cache files
- now it will properly explode instead of silently getting stuck when invalid timestamps are receivedv2.2.1
- 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
- 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- fixed legacy listener SetBeforeEventTime, SetTimeFrame and iterationComplete callback behaving slightly different from version 1
- 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
- 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
- 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
- as long as the guild history menu is open, LibHistoire will now prefer requests for the currently visible guild- 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)
- 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)
- automatic removal of old history save data- smart history requests
- removed rescan and force link features
- compatibility layer for old history api
- new api callbacks
- skip requests for categories with no listening addons- new category cache menu
- fetch oldest events first after prolonged absense
- reset linked range button- improved cache status bar
- clear cache button
- request mode setting
- cache segmentation displayv1.5.1
- automated request visualization
- animated progress bar
- zoom level setting (in main menu)
- new colors
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!
- GetKey - returns an identifier which can be used to store the last seen eventId for a listenerv1.0.2
- GetGuildId - returns the guildId of a listener
- GetCategory - returns the category of a listener
- GetPendingEventMetrics - returnsthe amount of stored or unlinked events that are currently waiting to be processed by the listener- SetBeforeEventId, SetBeforeEventTime
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 possiblethese can be used to limit the iteration range and automatically stop the listener when they are passed- SetIterationCompletedCallback
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)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
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 |
Comment Options |
sirinsidiator |
View Public Profile |
Send a private message to sirinsidiator |
Find More Posts by sirinsidiator |
Add sirinsidiator to Your Buddy List |
07/21/21, 10:19 PM | ||
Re: (Reply to sharlikran)
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.
|
||
|
Sharlikran |
View Public Profile |
Send a private message to Sharlikran |
Find More Posts by Sharlikran |
Add Sharlikran to Your Buddy List |
07/21/21, 08:41 PM | ||
Forum posts: 1
File comments: 402
Uploads: 0
|
(Reply to sharlikran)
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. |
|
|
Shadowshire |
View Public Profile |
Send a private message to Shadowshire |
Find More Posts by Shadowshire |
Add Shadowshire to Your Buddy List |
07/20/21, 04:05 PM | |
@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.
|
|
|
Sharlikran |
View Public Profile |
Send a private message to Sharlikran |
Find More Posts by Sharlikran |
Add Sharlikran to Your Buddy List |
07/20/21, 06:55 AM | ||
Forum posts: 1
File comments: 402
Uploads: 0
|
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:
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. |
|
|
Shadowshire |
View Public Profile |
Send a private message to Shadowshire |
Find More Posts by Shadowshire |
Add Shadowshire to Your Buddy List |
07/18/21, 12:38 PM | |
|
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.
|
|
tralce |
View Public Profile |
Send a private message to tralce |
Send email to tralce |
Find More Posts by tralce |
Add tralce to Your Buddy List |
07/15/21, 12:51 AM | ||||
Forum posts: 12
File comments: 26
Uploads: 0
|
|
|||
|
fredd |
View Public Profile |
Send a private message to fredd |
Send email to fredd |
Find More Posts by fredd |
Add fredd to Your Buddy List |
06/27/21, 02:32 AM | ||
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.
|
||
|
Sharlikran |
View Public Profile |
Send a private message to Sharlikran |
Send email to Sharlikran |
Find More Posts by Sharlikran |
Add Sharlikran to Your Buddy List |
06/27/21, 01:28 AM | |
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. |
|
assoui |
View Public Profile |
Send a private message to assoui |
Send email to assoui |
Find More Posts by assoui |
Add assoui to Your Buddy List |
06/25/21, 10:00 AM | |||||
Re: Using on a laptop & PC?
Minimum required
Additional Files
Last edited by Sharlikran : 07/06/21 at 04:18 PM.
|
|||||
|
Sharlikran |
View Public Profile |
Send a private message to Sharlikran |
Send email to Sharlikran |
Find More Posts by Sharlikran |
Add Sharlikran to Your Buddy List |
06/25/21, 09:52 AM | ||
Re: Corrupted MM file
|
||
|
Sharlikran |
View Public Profile |
Send a private message to Sharlikran |
Send email to Sharlikran |
Find More Posts by Sharlikran |
Add Sharlikran to Your Buddy List |
06/25/21, 09:47 AM | ||||
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.
|
||||
|
Sharlikran |
View Public Profile |
Send a private message to Sharlikran |
Send email to Sharlikran |
Find More Posts by Sharlikran |
Add Sharlikran to Your Buddy List |
06/21/21, 08:14 PM | |
|
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. |
|
burito |
View Public Profile |
Send a private message to burito |
Send email to burito |
Find More Posts by burito |
Add burito to Your Buddy List |
06/12/21, 10:51 PM | ||
|
Re: Using on a laptop & PC?
It applies to other addons save variables too. |
|
|
maximoz |
View Public Profile |
Send a private message to maximoz |
Send email to maximoz |
Find More Posts by maximoz |
Add maximoz to Your Buddy List |
06/12/21, 10:38 AM | |
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.
|
|
daemondamian |
View Public Profile |
Send a private message to daemondamian |
Send email to daemondamian |
Find More Posts by daemondamian |
Add daemondamian to Your Buddy List |
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.