Jump to content
  • 0

Lag When Opening Inventory..


Question

Posted

Hello,
I am currently using Mobius 2.8 Seven Signs (Subscriber Version).
I have increased the inventory capacity from 80 slots to 500 slots.
The problem is that when the number of items exceeds 200, opening the inventory causes a delay of about 1–2 seconds.
If the inventory is empty or contains only a small number of items, there is no lag at all, but when the item count goes over 200 or 300, the delay increases accordingly.

 

Is there anyone who could fix this issue?

4 answers to this question

Recommended Posts

  • 0
Posted

i think it's the auto sorting of the interface that sucks, check InventoryWnd script in interface.u, or completely disable the request item list packet when toggling the inventory window (also in InventoryWnd script or similar name)

  • 0
Posted

1. Optimize Packet Serialization

  • Look in ItemList.java or wherever the inventory packet is constructed.

  • Instead of building the packet with inefficient string concatenation or repeated allocations, use a preallocated buffer and avoid creating new objects for each item.

  • Mobius sources are Java-based, so profiling with something like VisualVM or YourKit can help see where most time is spent.

2. Avoid Sending the Full List Each Time

  • Modify the server to send only changed items (diff packets) when the inventory window opens.

  • Some newer forks implement this as “lazy loading” or paged inventory so the client only loads e.g. 100 items at a time.

3. Limit the Inventory Size Per Page

  • Instead of showing all 500 slots at once, split the inventory into pages/tabs (100 slots each).

  • When the user switches a tab, send only that page’s items.

  • This requires some client-side editing, but it’s the most user-friendly long-term fix.

4. Database & Cache Optimizations

  • Ensure your items table is indexed by owner_id to make the query for player items fast.

  • Cache item templates and static data so they are not reloaded every time the inventory is shown.


⚠️ Things to Keep in Mind

  • Increasing slots from 80 → 500 does not just change a number — it multiplies the workload for packet building and UI rendering.

  • You can’t fully avoid some extra cost with 500 items, but you can keep it under a few milliseconds if you optimize how and when the data is sent.


 

 

  • 0
Posted

1. You where subscriber 3 years ago.
2. There is no current L2jMobius 2.8 Seven Signs version. Subcriber or not.

3. You have your answer from multiple forums that more items is more delay.

 

  • 0
Posted (edited)
On 9/16/2025 at 2:37 AM, borinet said:

Hello,
I am currently using Mobius 2.8 Seven Signs (Subscriber Version).
I have increased the inventory capacity from 80 slots to 500 slots.
The problem is that when the number of items exceeds 200, opening the inventory causes a delay of about 1–2 seconds.
If the inventory is empty or contains only a small number of items, there is no lag at all, but when the item count goes over 200 or 300, the delay increases accordingly.

 

Is there anyone who could fix this issue?

 

Probably due to poor choice of container handling items, you should test other types.

 

If it's not due to container, it can be whatever method impacting inventory, such as sort/filter/integrity checks. Bad synchronization can also grealty impact performance.

 

Another thing to check is about packet sending, you should use L2PHX to explore what is actually sent.

Edited by Tryskell

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...

Important Information

This community uses essential cookies to function properly. Non-essential cookies and third-party services are used only with your consent. Read our Privacy Policy and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..