Garan

This is a bit peculiar. The most likely culprit is another plugin conflicting with AltInventory by re-enabling the bags even though you have the "Replace Bags" option set to true. Are you running any plugins on your Warden that you do not run on your other characters? If so, then you will have to make sure that the AltInventory "Replace Bags" option is set to false or stop using whichever other plugin is conflicting or accept the odd behaviour.

You can verify this fairly easily. First, open AltInventory on your warden and check the options to see if "Replace Bags" is selected. If it is not, then there is some other problem. If Replace Bags is selected, then try unloading all plugins with "/plugins unload" and then manually loading ONLY AltInventory with "/plugins load AltInventory" and checking your bags. If AltInventory displays instead of your bags then the Replace Bags option is working correctly and the odd behaviour is the result of another plugin re-enabling the bags after AltInventory loads. If the odd behaviour (both the plugin and the bags displaying when you open the bags) continues then there is some other problem and we have to dig deeper.

Note, each character currently has their own settings so one character can use Replace Bags while others may not. This will change in a future update when users will be allowed to choose which settings are per character and which are per server or per account. That way you can turn some options on or off for all characters while maintaining other settings separately for each character.

xaero

I've noticed that when I open my bags on my Warden, AltInv also opens, is this expected/desired behavior because it doesn't do it on my Champ... which is what struck me as odd. if it's not, how to fix it?

xaero

In retrospect, I was able to reproduce this problem with a different plugin, but using the same method Dag is. When I investigated, it was due to a file having a system attribute, in this case, it was being +s (system bit.) No idea why it was there, but it was not marked +r, so I don't know why Plugin Compendium couldn't overwrite it, making it -s fixed the issue though.

Garan

As Xaero already responded, you can simply delete that file. It started getting included when my dev machine crashed and I had to package the plugin from another computer. It has been removed from my current machine and shouldn't be in any future archives.

xaero

Just delete that file... it's not important and windows will turn around and generate a new one when it feels the need to.

Dag

When updating this plugin via the Plugin Compendium, I get a popup window with this error message:

Problem while installing plugin Alt Inventory

Access to the path 'C:\Users\Me\Documents\The Lord of the Rings Online\Plugins\GaranStuff\AltInventory\Resources\T humbs.db' is denied.

It's not a huge issue, since after I click on the "OK" button the installation continues without a problem. I'm guessing that, when you are packaging up the files, your Thumbs.db file is being included in the Zip file. I'm guessing that's a system file, so Windows won't write to it.

Vald

This is a wonderful plugin that I really appreciate. One request to make it better... Please lock the icon.

Many of the plugins that have in game icons have a method of locking the icon. Some require the standard CNTRL+/ to move them, others require holding down the shift button while dragging, etc. The problem with icons that don't lock is that they get "bumped" a lot while trying to click on them. I am constantly shifting it slightly while clicking on it. I want to be able to put it where I want it and have it stay there.

I asked for the same thing on Horsey - Dhor's Patch:

http://www.lotrointerface.com/downlo...nfo.php?id=712

He was able to lock it, so it may help to look at the code.

Thanks!

Garan

I have temporarilly disabled the Item Tracking feature (existing items will be viewable but I disabled the context menu so new items can not be added). I am in the middle of fixing the data format bug that was corrupting the tracking data whenever characters were deleted from the plugin. This feature should be available again when version 2.12 gets released (no time frame).

Garan

EDIT:
After getting sufficient sleep and taking a fresh look at this I realized I had made a huge mistake. The ItemAdded event was firing just fine. Yours truly had simply failed to update which object was being passed to the AddCallback function when I moved the functionality to the inventory panel from the main window. Moral of the story, don't write code in your sleep, it will turn into a nightmare...

Garan

Argh! I miss my dev box Yep, the chest headers are getting repeated. I'm not sure why yet, but I'm looking into it...

EDIT: I just realized what I did. While fixing the sort to make the items unique I forgot that the Vault table has to preserve the chest order - that is, all sorts must include Chest # as their first criteria. Gah!... *bangs head into desk* ...ok... deep breath... I'll get this fixed in the AM. It shouldn't take too long to unravel.

K1R4D3L

Is the only symptom of this that it appears that there's nothing in the backpack? All method calls work, no errors, they just don't return any items (e.g. if you see that there are items in slots 1 and 2, can you swap their places without error even before initialization is complete?)? GetSize() returns the correct number before initialization is complete? And ItemAdded doesn't get called on initialization, I'm assuming. Do the slots get initialized in order (i.e. if you see something in the last slot, would that mean that it's done, or would trying to access the last slot prior to initialization being complete cause an error)? Pretty sure I know the answers to these based on your solution....

I hope you don't mind all of the technical questions, but I'm using this as an opportunity to learn from one of the masters.

Vinny

The version 2.10 vault display worked well for me, but when I updated it to 2.11 the content display became fragmented with the chest names being repeated over and over. Is anyone else having this problem?

Garan

Version 2.11 is strictly bug fixes, most notably, the initialization bug when loading with the Turbine Plugin Manager. This also fixes the related bug originally reported by RJFerret with Load Minimized option not initializing.

The only reliable workaround that didn't impact performance that I was able to implement for the Plugin Manager initialization bug required the use of timed periodic checks of the backpack. Since there is no indication (without user intervention) of when the backpack is fully initialized and it can be accessed by Lua when either not initialized or only partially initialized (so testing for a single item existance was not sufficient) it was necessary to poll the backpack every few seconds for the first few minutes. I finally settled on every 5 seconds as it gave a resonable opportunity for the plugin to initialize without significantly impacting frame rate. I let the Update poll continue for up to 10 minutes but disable it as soon as any user inventory interaction occurs (such as looting, buying, selling, moving items, etc.) since the backpack is always initialized by the time the user can interact with it. While it is still possible for the user to be on a login screen for more than 10 minutes, this should be an extremely rare exception and if that happens, you will simply have to unload and reload the plugin and it will fix itself.

Obviously the correct fix for this is for Turbine to either delay loading plugins until the backpack and barter wallet (the barter wallet has the same problem) objects are actually initialized or to add an event which plugins can respond to when those object become initialized. Until such time as Turbine does fix this, the workaround should be sufficient without negatively impacting performance.

Garan

I know I created a thread a while back on the Turbine forums when I first encountered the issue when adding the Barter Wallet currencies to the Wallet plugin. I also know other people had run into similar issues due to the backpack not being loaded when they initialized their plugins - at the time the work around was to not load those plugins by the Plugin Manager. I had thought that the issue was fixed back in Update 6 but because the old version of AltInventory rebuilt the item display every time it was accessed it was a non-issue for me. So, either I was incorrect and the issue was not addressed in U6 or Turbine has broken it again. Either way, it is broken as of U7 and I will be filing another bug report on it.

K1R4D3L

Is there a thread about this somewhere? Curious what all is affected....