Not really sure what the best way to report this is but here it goes:

Opening the backpack in the hotbar - everything works fine
Equipping it and then opening it with the hot key results in a huge client-side cursor lag

Version 0.8 beta.

Assuming from #41 #issuecomment-7350075 that this is fixed? If it is, should close it :).

Not sure which version of the mod im running but got GUI lag

2nd. Also seeing that. Does not seem to matter what sort of operation. Picking up and putting down items stutters oddly and lags.

I noticed that too, albeit late. Only happens when having a bunch of mods, I'm investigatnig why atm. Question is it only client side? hard to spot with only one computer here.

It seems to be completely client side, I haven't seen anything on the server about it. Running approximately 260 mods, playin with it on the server, all clients have the same issue but it does not effect the server.

That's weird and itnteresting

Also: It's only when you use the Backpack UI while wearing it. I put the pack down and interact with the inventory just fine. Which is a handy workaround until sorted.

Lovin the updates. Let me know if you need a more comprehensive list of mods in case it's something interacting. NEI and InventoryTweaks jump to mind as top possible picks.

Same bug, I'm using your mod in my next modpack.

I've tested it on my test server with another player. The TPS isn't affected, the other player doesn't get lag, but with the bandwidth we both have I would be surprised just two players could feel anything (both of us with cable, server is a dedicated).

I'll test for extra network traffic with wireshark later, but if I had to bet... the only difference between having the backpack on or not is the rendering of the backpack and the tool in the special slot. How ofter does that tool info updates to the server (EDIT: or the client itself)?

I send a packet each tick with the info (wich is not big deal actually), but the problem is client side. MY guess is the rendering of the tank values, because it updates everytime the foreground layer is drawn. The onl solution I can see atm is not rendering the tank values at all in the GUI. Looking for a different approach atm.

Closed it by accident :P

Question:

If it was a rendering issue with the tanks would that not effect both the backpacks that are "equipped" into your custom backpack slot and the ones that are opened in the hand? It seems to only be a problem with the backpacks are equipped? Are there any differences in the way these two instances are handled in the code?

EDIT: I am a hobbyist coder but pretty terrible with java so I am just going through my thought process when I debug.

Darkona, when you say it updates the tank, you mean that it checks for the current liquid and fill level and recreates the tank animation in the model and on screen? Wouldn't be better to update when you put a bucket in the fill/unload sockets or when the special backpacks create liquids? That would turn the thing down from once every tick to once every so often...

EDIT: ok, i've tried playing with the I:TankRenderType and the Shift-F3 debug info to look for any difference. Haven't noticed any difference between the 1, 2 or 3, but I noticed when wearing the backpack tick rate goes up to 75%, and the used memory goes up really fast up to about 50%, when it drops back to 20%-ish. So I asume it's some kind of action that takes a lot of memory, or that it takes a little but it's overwrote again and again.

I took a peek at the repository (haven't touched java since 2004, but I still understand the code) and something popped into my eye.

https://github.com/Darkona/AdventureBackpack2/blob/master/src/main/java/com/darkona/adventurebackpack/client/gui/GuiOverlay.java - in line 134 it starts a code block only if it's wearing the backpack, I presume. At line 150 you call a new ResourceLocation( blabla ) with a toLowerCase() call against modinfo.MOD_ID. If I understand this correctly, it's called every time the experience bar redraws and the backpack is on.

From my most sincere non-understanding of Forge api, would it be possible to move this new ResourceLocation to a private or protected object var, up at line 40, so that it's only created on object start and not once every frame?

That's an interesting insight, I'll fiddle with that a bit. Thanks Dan.
Sometimes fresh eyes sincerely help a lot.

You are welcome. I wouldn't call my eyes "fresh", though :P

(PS: lastima que no haya mensajes privados aquí. Tu de Venezuela, yo de España... ¿que hacemos hablando en ingles? xDD )

No creo que haya problema con el idioma, total el que se tiene que enterar de lo que dice aquí soy yo ;P

Det hjälper dem av oss som talar något annat. :D

Lol lets keep it english

I am having the same issue, except for with mine, 1/4 times the jvm gets a pure virtual function call thanks to an exception in the server tick rate. This happens other times also though. Is it just because my CPU cant handle it?

Mrab, from what I remember from university, that virtual call exception it's a call to a function during construction or destruction of an object, that is defined as virtual in the class. Since it's still constructing the object, or there's no object because it's destructing, the jvm tries to call the class defined function, find a virtual function and just goes bananas. Let's just say it's a "dark magic side effects", it may have to do with a list of items from slightly faulty coremods (mods that replace core classes of minecraft) to a faulty virtual machine itself.

Please try and reinstall/update your jvm. If the problem persists, complete the comment with java and forge version, and other mods installed and their versions.

okay, but, is it possible that the reason that it is trying to access a method in an object that is being constructed/decontructed becasue my CPU can't keep up, so by the time the jvm actually runs the method, the object is being deconstructed/the object can't get constructed fast enough before one of its methods is called? I will update my java, and reply again with that info if it still happens. Thanks for the help! Also, java question, is there a simple (well, maybe not simple, but possibly easy to remember?) way to check, and if false wait for, an object to be constructed fully? Don't want that happening with anything I make :P
EDIT: Just a guess, but would it have something to do with accessing an object from multiple threads without syncronizing it? It seems like that could do it.

Sent a pull request with a workaround/new feature. Shift-B either unequips your backpack or equips the backpack in your hand. Didn't do it for the copterpack or steam jetpack, since those dont have the lag issue. Also, they are a bit more complex, so it kindof makes sense that you can't just whip them off of your back :P

I'm worknig on a fix for the GUI lag to terminate it and any possibility of coming back, then I'll add your pull.
I've been a little burnt out the past two weeks so I'm working slowly, but I'll have a new version next week or so. Sorry for the delay guys.

Hey, cutting edge builds, we take the good with the bad. Thanks for your hard work!

Yeah, I have been using my fixed version in my own modpack since I made it, works great. Also, any reason why there isnt insane lag for the backpack's GUI when I was in the dev environment? (I just love that/those words, "dev environment," sends a chill up my spine, but, ya know, the good kind of chill, kind of like instead of saying "rocket science," I say "orbital mechanics.") I could open up the backpack just fine there. When I get back from school I will check and see if the compiled mod is laggy without any other mods. If it isn't, then it could be an incompatability? That seems weird to me that it wouldn't lag in the dev environment, but then again, other things are weird when i run them in eclipse too: when you run your program, it doesn't make a jar file, it just puts everything in the /bin folder, so unless you know that, you might (like me) try to use File objects to get stuff from inside the jar, only for it too not work when you make it a .jar, since you have to use .getResource(AsStream) to get it, which luckily still works with actual files. XD I need to staph ranting on about coding.

also, what do you think about not having the copter/jet pack have the quick (un)equip? I almost feel like you should be able to, but (I assume, unless there is something I don't know) since things like "onKeyPress," when activated, are their own thread, maybe add in a Thread.sleep(1000) in there? then that would mean that you could quick (un)equip them, but it would take 1 full second to do it.

No, because the quick unequip is using the same shift+B as the on/off function for the copter and jetpack

No, thats shift-N
not shift-B
Also, since using the version built from the current source, I have had NO lag when opening the backpack, only tested with 60 other mods, yet to test with 210

Any word on this fix?