renbear

Sorry, I didn't mean for it to sound like everyone should do that. It sounded like Art has possibly installed it to the wrong folder, or in a sub-folder, and "deleting the GaranStuff folder" is a sure-fire way to expose that.

You are, of course, correct that it would screw up other plugins, if he had more of yours installed.

My apologies.

Garan

Actually, in the case of my plugins, you are usually safer leaving the existing files and just extracting over them. There was one exception to this, the thumbs.db file that got accidentally included in the zip files while I was temporarily publishing from a laptop when my regular dev machine died and required the users to remove the file before extracting. You also shouldn't remove the entire GaranStuff folder if you are running more than one of my plugins. You would at most want to delete the AltInventory folder inside the GaranStuff folder. Usually the simplest and safest way to update is using Lunarwater's Plugin Compendium.

As to the current round of crash reports, they seem to be occuring with people that are using more memory, other large plugins, larger texture caches, etc. so that is where I am focusing my testing efforts.

Artisez

I went through and completly removed all Alt Inventory. Re-installed the plugin and now the client crashes when I attempt to log in a toon.

Will chase down more infor on my syatem and get back with ya.

Artisez

Will give it a go again. Thought I had removed it all but found another folder.

Thanks

Art

renbear

Artisez,

Are you sure you have installed 2.11b? You might want to delete the old GaranStuff folder first to be CERTAIN you're not running the old version.

As far as I can tell, the old crash-on-logout problem is gone in 2.11b.

renbear

There is a known* issue with Rohan and 32-bit installations of Windows. Something Turbine has done in that region causes an almost immediate crash upon entering it, but only on 32-bit XP, Vista or 7.

When trying to debug people's problems with your plugin, make sure the 32-bit problem isn't really the issue, and is thus completely outside your control.

Once again, Garan, thanks for all your work.

* Known to us, anyway. The developers haven't acknowledged it yet, but it's been verified by many people, and can be worked around with a boot.ini modification. Unfortunately, said modification often destabilizes the computer for other applications. :-( Even with the fix, LotRO will eventually crash.

Garan

Client crashes are due to bugs in the underlying Lua implementation and its interaction with the game client. This makes tracking down the bugs and creating work arounds (we can not actually fix the bug in the client, only Turbine can do that) very difficult. I have already isolated one condition that was causing many log out crashes and implemented a work around. Unfortunately, many of the remaining crashes seem to be more of a function of the amount of memory in use and the memory leaks in the current client being compounded by the amount of memory which plugins use. The client runs fine for me with no crashes since the 2.11b update so I am having some difficulty replicating the crashes that others are reporting which is quite common with memory issues.

It would be helpful to know some more information from those reporting crashes, including operating system version, client language in use, other plugins in use (even if they are unloaded prior to the crash, they could impact memory usage if they were loaded in the same game session).

Artisez

Since RoR every time I load Alt Inventory it will crash or lock up the game on logging out a toon. I was happy to see you updated Alt Inventory and was hopeful I would not have the same problem.

I loaded the plugin and it seemed fine up til the point I logged my toon out. It crashed the first time and on the second attempt of logging out a toon it froze the game up.

Any ideas?

Garan

Thanks for reporting that. Definately a bug and it will be fixed in 2.11c
For now, do not use the options panel to move the icon, rather hold the Ctrl key and use the mouse to drag the icon where ever you want it on screen.

Gaelwing

I've upgraded to 2.11b, and went to make an adjustment to the positioning of the icon (I load AltInventory minimized). I had it set originally to L: 40 and Top: 1011, and I wanted to adjust it slightly. There seems to be an issue with the positioning now though, as it won't accept numbers within the range specified. Every time I've tried to position it, it defaults to 0, 0 (top left corner). It looks like it saves the entry, but then once I close the window, the icon appears at the top left. I can live with it there for now, but wanted to pass the info along.

Thanks for a great plugin - just wish I could do a control-click to check out clothing items I have stored on my mule toon, just found out yesterday that it doesn't allow me to do that.

Garan

Thanks for the feedback.

That's yet another bug introduced by attempting to rollback my 2.12 changes

Fortunately, this one is also simple to fix. If you want to fix your copy before I get the next update out, just find line 607 in EquippedItemsPanel.lua and change it from:
to
This is already fixed in 2.11c (I wasn't going to publish another interim release before 2.12 but there were enough bugs in 2.11b to probably warrant it).

renbear

FYI, I'm getting the following error whenever I switch crafting tools (tailor's tools for forester's axe, etc)

...ugins\GaranStuff\AltInventory\EquippedItemsPane l.lua:607: attempt to index field 'inventoryWindow' (a nil value)

I believe I came across other errors on the same character before that one, but I can't remember what triggered them. I'll post again when I find them.

Unfortunately, I'm also using SortBag, so that may be getting in the way. Let me know if you need me to disable all other plugins, or if that error is informative enough.

PS: Thanks for making the effort to work around the Turbine-caused unload issue! It's good to have AltInventory back.

Garan

Ah. Sorry.

To fix this immediately, you can edit the EquippedItemsPanel.lua file in the "My Documents\The Lord of the Rings Online\Plugins\GaranStuff\AltInventory" folder.
Find the line: and immediately after it, add the lines:If you are uncomfortable editing the file, I will have another small update available in a couple of days.

red_st_angel

I updated to 2.11b and now i get

...ugins\GaranStuff\AltInventory\EquippedItemsPane l.lua:205: attempt to index global 'equipmentLayout' (a nil value)

failed to load

basically im not crashing but it wont load anymore. I don't know if its a problem on my end, but any advice would be appreciated.

magill

I'm now retired after 30 years as a System Administrator of Virtual Memory Operating Systems -- RCA's VMOS, VAX VMS, and many flavors of Unix -- and am quite familiar with the infamous explanation: "the problem is caused by X because if you eliminate X, then Y doesn't crash". More often than not, in fact X was not the CAUSE of the problem, but simply the catalyst, and that Y really did cause the crash.

Is there any evidence that any actual crash is directly attributable to Alt Inventory or any other plugin?

So far, the only crashes I have seen are directly attributable to memory management issues... what have been called "Memory Leaks" but which are really the result of a 32 bit application attempting to address more than 4GB of memory.

I have no idea how the API for Luas is Coded from the Turbine Client point of view. One assumes that the memory used collectively by all Plugins is subtracted from that same 4GB of memory available to the Client. That being the case, it is "obvious" why Turbine demands that you NOT use plugins when reporting a Crash to them... Turbine knows that they are skating on thin-ice with the Client -- extremely close to the 4GB memory utilization limit and that any "extra" memory used by Plugins reduces that "margin of safety" sufficiently that the Client crashes.

All that being said, it is also clear that both Alt Inventory and the Compendium are large users of memory.

So I would not get terribly worked up over the fact that crashes still occur when any Plugins are loaded!

I have been fascinated by the vehemence with which Sapience and Mirthgar demand that crash reports NOT include any use of Plugins. To me it says that there is an internal conflict raging over the mere existence of Plugins.

We found out yesterday that Turbine was "having difficulty" with the Mac Client for use with Bullroarer. As Xraina posted:
One wonders what that problem is... I and quite a number of others, have been able to use the Mac Client from the RoR beta with no problems. However, just as there have been a significant number of reports about problems downloading and using the "live" Mac Client, one suspects that this same "distribution" issue is true with the Beta Mac Client -- it is a SINGLE 17.74GB down load -- no Torrent, No Pando, no Happy Cloud involved.

I've been a networker since the days of the ARPAnet, and while the modern Internet is "much better," is is anything but "flawless." While a multi-gig-a-byte movie download will have a few random pixels missing and black spots flicking by as a result of "cosmic ray hits" (yes, they do happen), the flipping of a single bit in an application program will be disastrous. And that is exactly what appears to be happening to the downloads far too often -- the MD5 checksums don't match implying that the 17.74GB file is corrupt and the result is exactly that error message - the file is corrupt.

Oh well, the ball is in Turbine's court.