Help Lag When Opening Inventory..

[borinet]

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?

[ratchet]

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)

[Atom]

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.

---