Subject: Suggestion: Increasing Stack Count Limits for Modding Flexibility

[Dave91]

Sziasztok, Fun Pimps csapat,


Remélem, mindannyian jól vagytok. Régóta játékosként és szerveradminisztrátorként írok, aki intenzíven dolgozik XML modolással. Nemrég egy technikai korlátba ütköztem, ami sok moddert és játékost érint, és szerettem volna megosztani barátságos javaslatként.


Jelenleg a játékos készletében lévő tárgyak halmszáma 16 bites, nem aláírt egész számként van tárolva, ami az összes halmozós tételt maximum 65 535-re korlátozza. Ez a korlát az ételre, lőszerre, kaszinóérmékre, kézműves anyagokra és sok más kategóriára vonatkozik. Bár az XML magasabb értékeket enged, a játékmotor visszaszorítja a mentés/betöltés esetén 65 535-re, ami akaratlan tárgyvesztéshez vezethet, ha egy játékos nagyobb stacket vesz fel, majd újra logol vagy összeomlik.


Ez hatással van a kovácsműhely belső anyagpufferjére is, amely hasonló korlátot alkalmaz, így még módosítva is megakadályozza a nagyobb kapacitást.


A modding közösség számára ennek a korlátnak a megemelése (például egy 32 bites egész számra) hatalmas életminőségi javulás lenne. Ez lehetővé tenné a biztonságosabb nagy stackeket, rugalmasabb modtervezést, és megakadályozná a túlcsordulás okozta tárgyvesztést. Még a jelenlegi korlát hivatalos dokumentációja is segítene a moddereknek elkerülni a véletlen problémákat.


Köszönöm az idődet, és hogy továbbra is támogatod egy ilyen modolható és kreatív játékot.
Nagyon hálásak vagyunk minden munkát, amit a 7 Days to Die filmjébe fektettek.


Üdvözlettel,
Dávid
Server Admin & Modder

 

[Riamus]

Why are you posting this in the bug report forum instead of Pimp Dreams? A limitation on stack size isn't a bug. The closest it could be to being a bug is that they might add something on loading a mod that prevents a mod from using a value that is too high to prevent item loss, but even that isn't really a bug.

 

[SpiritChill]

Thanks for the suggestion I will be moving this to "Not a Bug" since it does not qualify as a bug! Thank you and I will redirect this to our Pimp Dreams Thread!

 

[zztong]

Currently, the stack number of items in the player's pool is stored as a 16-bit unsigned integer, which is the maximum for all stacking items 65,535 for limit it. This limit applies to food, ammunition, casino coins, craft materials and many other categories. Although XML allows higher values, the game engine pushes it back to 65,535 in the case of save/load, which is unintentional for object loss you can lead if a player takes a bigger stack and then logs or crashes again.


This affects it is on the inner material buffer of the forge also, which applies a similar limit, thus preventing higher capacity even when modified.


For the modding community, raising this limit (for example, to a 32-bit integer) would be a huge improvement in quality of life. This would allow for safer large stacks, more flexible mod design, and prevent object loss caused by overflow. Even official documentation of the current limit would help modders avoid accidental problems.

So this suggestion is about letting a stacking limit go to 2^32 (4,294,967,296 if 32-bit unsigned), apparently for the Forge. Do folks fill forges up with 65,535 of the resources and crave more, or am I missing the point?

 

[Suxar]

Let's say there are 1024 containers in a city located in a forest. Let's say I inspected them all and took nothing. Let's say each container has 16 cells (I know there are more and fewer).
So, we have 1024 arrays of 16 elements, each occupying 2 bytes. This means that the container information alone will take up 32 megabytes of RAM. If we increase the size as you suggest, the information will take up 64 megabytes.

Now calculate how much memory is needed to store container information on a Peregen8k map.

 

[zztong]

So, we have 1024 arrays of 16 elements, each occupying 2 bytes. This means that the container information alone will take up 32 megabytes of RAM.

You mean kilobytes. 1024 * 16 * 2 = 32,768 bytes.

That's also the worst case in terms of memory. The underlying data structure could be something that only allocates memory based on the contents like a linked list, or some Unity object that I think they call a Dictionary.

My guess as to why they used 2-bytes for a quantity is that it pairs nicely with 2-bytes for an object ID.

When I did assembly programming it was on a word-addressable mainframe, so I'd be watching the word sizes for performance. These PC's I'm told are byte addressable and I'm not sure if aligning to word boundaries matters. Though some reading suggests not aligning with 4-byte of 8-byte boundaries can have some affect on how memory is transferred across the bus and the work a memory manager needs to do. We're beyond my knowledge of modern PC architectures here.

 

[Suxar]

You mean kilobytes. 1024 * 16 * 2 = 32,768 bytes.

Yes, I was a little mistaken.

That's also the worst case in terms of memory. The underlying data structure could be something that only allocates memory based on the contents like a linked list, or some Unity object that I think they call a Dictionary.

Every algorithm has its pros and cons. Dynamic memory allocation is good, but it's slower. The game isn't exactly fast as is.

 

[zztong]

Every algorithm has its pros and cons. Dynamic memory allocation is good, but it's slower. The game isn't exactly fast as is.

Yes, though in this case even the arrays will be dynamically allocated. The most likely case being that something like a list or dictionary is created when you open a container for the first time, which lets the game generate some contents. If you leave any of the contents, then it has to keep that data structure around. If you take all of the contents, it gets to forget the reference and let garbage collection reclaim the memory.

Something we haven't covered is the effect on network usage. When the server generates this data, it has to tell the client what the inventory contains. Every bit will have broadcast, propagation, retransmission, and reception delays in addition to any processing the game has to do.

It occurs to me the game probably also rolls these data structures out to disk as you move away from the chunks. That takes time and space too.

 

[Suxar]

Yes, though in this case even the arrays will be dynamically allocated. The most likely case being that something like a list or dictionary is created when you open a container for the first time, which lets the game generate some contents. If you leave any of the contents, then it has to keep that data structure around. If you take all of the contents, it gets to forget the reference and let garbage collection reclaim the memory.

I think they use the following algorithm. While a container isn't searched, it doesn't take up any memory. When it's opened, space is immediately reserved for all the container's slots, and this space is only released when the container is destroyed or discarded. I think this is one of the reasons why there are so many single-use containers in the game (garbage piles, for example).

Something we haven't covered is the effect on network usage. When the server generates this data, it has to tell the client what the inventory contains. Every bit will have broadcast, propagation, retransmission, and reception delays in addition to any processing the game has to do.

The network is a separate issue. Now, when the server is busy, opening a container can be delayed. Sometimes you click on a container, and there's silence. And then, after a while, the container's window pops up, and by then you might have moved 5 meters away from it.