RETESTING-

UPDATE: I believe this may have been fixed while resolving another issue earlier this week, but I still need to test. I haven't forgotten.

Thanks!

FIXED-

Well, I've learned a few interesting things over the past week or so:

1. There wasn't a memory leak, but memory usage was really aggressive. This is being addressed with the next release.
2. The Lua garbage collector configuration set by ESO (idle=1,step=0.1) under-performs if you run memory intensive add-ons, running the game with an increased memory limit does not solve the OOM event, it merely delays it (and for many people it delays it sufficiently that it appears to fix the problem.) This is also being addressed with the next release.
3. Closures in Lua appear to be more wasteful than the cost of a declared function that does the same thing, this is more of a problem when you're creating and discarding closures at a rate faster than the GC is configured to collect. Where it makes sense I've converted code to use one-time allocations for functions and state objects for more DFA-like behavior.

The net effect is it appears there is a memory leak if you run with the default 64MB memory limit, even though there is not.

I'll have a new set of packages published Friday (tomorrow) that solve the memory issues you've experienced. In my testing it looks like if you run only X4D Add-ons ESO's Lua footprint normalizes at around 25-30MB (which is less than half the default memory limit.)

SOLVED-

It would seem an add-on created a global variable named "max" which caused a conflict with the BigNum code.

I've fixed the issue on my end by local scoping the methods, but this would suggest there is some other addon that is defining a global variable named "max".

Since this doesn't seem high-profile I'll pend updating packages until Sunday, since I just published, no sense in having everyone re-pull updates if they should be fine.

Thanks for the report!

PLANNED-
I was able to optimize the bulk of bag access, but there is still a hit when refreshing the 'Bank state', especially if you have a large bank.

During normal operation bag state is maintained by various add-on code mitigating the need to constantly refresh 'Backpack state.'

The 'stutter' during bank trade is caused by the fact that the code makes protected calls against the UI to perform pick-up/drop operations between bags. My running theory has been that this means the operation occurs over a single thread which is also responsible for HUD/UI updates, and so it's more noticeable by users.

There is an outstanding issue where if you xfer too much too quickly you get bounced off the server for flooding. I do plan on tackling this issue, and when I do it will provide an opportunity (nay, it will require me) to restructure code so transactions occur over time, rather than all at once.

That said, I imagine the code within X4D_Bags could be optimized further. I will give it some TLC and see if I can't get something lean out early next week.

Thanks

INVESTIGATING-

X4D scans and caches a view of the bags. In then performs differencing as changes are reported via game events.

Ultimately there will be limits on how quickly anyone's computer is going to perform.

I have two options at this point in terms of code changes:

1. Implement a coroutine to spread the cost of item scanning over time, we will call this "Deferred Bag Scanning"
2. Implement persistence so the cost of item scanning only necessarily occurs the first time you visit a bank, and then forever forward maintain a persistent view of bags.
a) there are cases where bag state must be reset, and so a deferred bag scan may still be necessary.

Any preferences?

INVESTIGATING-

I'll add some FPS logging to the debug mode logs this weekend so I can get an idea of what game performance is like when certain things are happening. Hopefully. I will also run through all of the add-ons and ensure features within Core are only activated when an addon 'requires' it. For now you might use the -debug slash-command and see if the memory usage is any way correlating with the jitter.

I assume this jitter happens when simply moving through the game world and/or when standing still doing nothing. Is that incorrect?

I only use Skyshards and Zgoo myself, but so far have not noticed a problem.

Oh no. I hope there isn't a conflict, maybe there is some resource contention occurring and we'll only have to optimize our code a bit. I have not used Wykkyd's framework, nor looked at the code, I believe it's a large add-on even though I've no idea what it does. It's hard for me to have any opinion.

This is probably true, and one of the changes that went out with my last update to X4D Core was to auto-manage garbage collector. So if you have a habit of running out of Lua memory (and it does happen) X4D will reconfigure the garbage collector to collect sooner and/or more often.

:!: Have you tried editing your game config file to increase the memory 64 MB memory limit?

There is a `/x4d -debug` slash-command you can use to enable debug logging, it will show memory usage. This is the same stat which is displayed if you load up the X4D_UI Add-on (it is reported as "ADDONS:" next to the "FPS:" and "PING:" stats.) but if you don't have that Add-on loaded you wouldn't normally see it.

* How much memory does your computer have for ESO/Gaming?

* What are your CPU specs?

* What about your GPU?

* Is the 'jitter' affect the HUD only, or does it affect the 3D environment?

* Does it affect audio?

Thanks.