(4 Kb)
Updated: 12/03/21 06:35 AM
Deadlands (7.2.5)
Updated:12/03/21 06:35 AM
Created:12/03/21 06:35 AM
Monthly downloads:55
Total downloads:622
Version: 1.1.0
by: Schrodi [More]

A libFilter3 based addon that adds a toggle to display/hide two categories of items from your inventory.

1) locked items - items locked using the in-game lock feature
2) consumables - items that everyone carries at all times:
Grand Repair Kit
Soul Gem
buff food and drinks

Usage: To move icons to the desired location on your screen go to addon settings and unlock button positions, move them around and lock them again to save new position.

Full readme: https://github.com/wjtk4444/eso-addons/tree/master/HideInventoryClutter

Optional Files (0)

Post A Reply Comment Options
Unread 04/13/22, 06:57 PM  
Akopian Atrebates

Forum posts: 9
File comments: 214
Uploads: 0
Did this ever get updated? I like the idea.
Report comment to moderator  
Reply With Quote
Unread 12/03/21, 09:01 AM  
Super Moderator
Baertram's Avatar
ESOUI Super Moderator
AddOn Author - Click to view AddOns

Forum posts: 4064
File comments: 4999
Uploads: 71
To keep it more readable here are some other hints to your addon code:

Instead of overwriting the handlers (pelase don't) just use ZO_PostHookHandler or ZO_PreHookHandler.
ZOs provides the hooks so that we do not need to overwrite code, especially in invetory there might else occur error messages like
"called from insecure code" as your manually overwritten functions and handlers taint the original inventory code -> and make it "insecure" (in ZOs words).

So instead of:

local onShowPlayerInventory = ZO_PlayerInventory:GetHandler("OnShow")
	ZO_PlayerInventory:SetHandler("OnShow", function(...)

		if onShowPlayerInventory then onShowPlayerInventory(...) end

	local onHidePlayerInventory = ZO_PlayerInventory:GetHandler("OnHide")
	ZO_PlayerInventory:SetHandler("OnHide", function(...)
		if not (self.bankOpen or self.storeOpen) then

		if onHidePlayerInventory then onHidePlayerInventory(...) end
Try these always first, should work the same:
Lua Code:
  1. --Called after the original handlers
  2. ZO_PostHookHandler(ZO_PlayerInventory, "OnShow", function()
  3. if not (self.bankOpen or self.storeOpen) then
  4.             HideInventoryClutter_ConsumablesButton:SetHidden(true)
  5.             HideInventoryClutter_LockedButton:SetHidden(true)
  6.         end
  7. end)
  9. --Called before the original handlers
  10. ZO_PreHookHandler(ZO_PlayerInventory, "OnShow", function()
  11. if not (self.bankOpen or self.storeOpen) then
  12.             HideInventoryClutter_ConsumablesButton:SetHidden(true)
  13.             HideInventoryClutter_LockedButton:SetHidden(true)
  14.         end
  15. --Now the original handler is called afterwards
  16. end)

You might even just "add" another handler without hooking anything, in some circumstances (e.g. 2 addons that add handlers somewhere).
ZOs added way to e.g. add handlers and then call them after existing ones, if the exisitng ones got a unique name to reference to:
Unfortunately most ZOs handlers do not provide a standard name like "ZO_PlayerInventoryShow" or similar one coudl use to add to So this is more of a usecase for addons, if they need to be combined/made compatible.
Last edited by Baertram : 12/03/21 at 09:08 AM.
Report comment to moderator  
Reply With Quote
Unread 12/03/21, 08:44 AM  
Super Moderator
Baertram's Avatar
ESOUI Super Moderator
AddOn Author - Click to view AddOns

Forum posts: 4064
File comments: 4999
Uploads: 71

your APIversion is very outdated.
Current APIversion is 101032 (it changed from +1 syntax a few patches before Check the apiversion ingame via /script d(GetAPIVersion()) or at the wiki -> https://wiki.esoui.com/APIVersion [should be updated]).

And for new addons please ALWAYS check the current given library version (tag ## AddOnVersion in the libraries's txt file tag).
e.g. LibAddonMenu-2.0 was changed from LibStub usage at version 28, so if anyone got an older version your
## DependsOn: LibAddonMenu-2.0
will eanble it but fail to load if any versin odler 28 is used somehow.
Same for LibFilers-3.0 where there could be missing functions etc.

You can circumvent this by providing the >=<versionNeeded> behind your dependencies, like this:

## DependsOn: LibAddonMenu-2.0>=32 LibFilters-3.0>=322
Versin 32 of LAM 2.0 is the most current one, and 322 is defined in LibFilters-3.0.txt -> ## AddOnVersion

And if you add SavedVariables please think about multi server support (NA, EU) by using GetWorldName() e.g. in your SavedVariables call's parameter "profileName" -> at ZO_SavedVars:New*(....., profile) e.g.
-> Maybe not relevant for this addon here, but maybe others you create.

Else the SV will be the same on all servers and maybe cause problems, especially if not character but account wide.
local savedVariables = ZO_SavedVars:NewAccountWide("HideInventoryClutterPosition", 1, nil, {
			positionLocked     = { top = 1000, left = 1500 },
			positionConsumable = { top = 1010, left = 1520 },
		}, GetWorldName(), nil)
-> You might also use the 3rd parameter which currently is nil. The only difference is that the table saved to the SavedVariables file live/SavedVariables/HideInventoryClutter.lua will be not using ["Default"] then but the server name (e.g. ["NA Megaserver"])

Another thing in your addon code:

The : notation/syntax is used for objects created from "classes". Your global HideInventoryClutter is just a normal table = {}, so better not use :, instead simply use .
function HideInventoryClutter.myFunc instead of HideInventoryClutter:myFunc

Else : makes the reader think it's an object one can reference via self, which is not the case if you do not explicitly create it via ZO_Object:New or similar. And to create an object you'd need a "class" like ZO_HideInventoryClutter or MyHideInventoryClutterClass = ZO_Object:Subclass() first

In your code you even use self to reference HideInventoryClutter, but this is kinda wrong as you never created an object!
It currently is just working because lua does not really create objects and just uses tables to build classes.
And their objects are also tables "referencing the classes" via "metatables".
-> Your addon kinda works. But if ZOs decides to change the class/object code so that self will ONLY work with real ZO_Objects in the future your addons might break, as self is not working anymore then.

So if you do not need to create any object and just need a table o store your global addon data and functions, just use the . nation and do not use self, just use HideInventoryClutter or add a local reference at the top like
local hic = HideInventoryClutter
and then use hic instead of self, as well defining functions -> function hic.myFunc() end
and assigning values -> hic.variable = value
and so on

If you do not understand this at all (no problem, hard for me as well) you might not know object oriented development and just followed an example addon somewhere.
It will work in most cases, either with . or : as long as you do not use ZO_Object or ZO_SubClass or similar. But it somehow "reads" wrong and makes it difficult to find errors if code grews in size and lines.
If you do understand, please think about changing it, if you like to.
Last edited by Baertram : 12/03/21 at 09:03 AM.
Report comment to moderator  
Reply With Quote
Post A Reply

Category Jump: