enhancement: stackable item despawn timer changes

[WeylonSantana]

Description

When resource drops are stackable they will never disappear even after their spawn time has passed.

Steps to Reproduce

1 - Create a stackable equipment
2 - Create a resource and put as drop the item above
3 - Keep taking down the resource and see the bug

Expected outcome: The oldest uncollected drops should disappear by following the item's spawn timer.

Version with bug

v7.1.22

Last version that worked well

Unknown

Affected platforms

Windows

Did you find any workaround?

none so far

Relevant log output

no logs but a video:

032.mp4

Duplicate Bug Check

• This bug report is not a duplicate to the best of my knowledge.

[Arufonsu]

Tested, reproduced thus, verified 👍🏽
Stackable items should indeed follow the item's spawn timer and disappear one by one stack by stack as their timer finishes.

Changed the format of the report a bit so the video shows up in git, also fixed the title's grammar a bit 👍🏽 thanks for reporting!

[lodicolo]

I will be moving this to a discussion because this is definitely not a bug.

Tracking partial stack despawn timers is a denial of service attack waiting to happen.

In the optimal scenario where it's just some mob drops accumulating this isn't a big issue... but

What happens if a user realizes what is going on and how it can be manipulated?

To provide an example, what happens if someone has 1 billion of the in-game currency and they drop 1 coin at a time? Each coin would have a separate despawn timer unless the logic got really complicated to condense things, and we could end up with best case hundreds or thousands of timers in a single stack, and worse case hundreds of thousands, millions or the entire stack.

I don't know at what point it would cripple a server, but it's good opening for malicious users to bring a server to its knees doing legitimate actions.

We need to just decide how to process stacks timers, and create some basic cutoffs where a new stack will be created instead of continuously updating the stack timer (or allow this if it's desired, it's a valid option).

In the case of creating a cutoff beyond which new stacks would be created instead of updating the timer it would at most include 2 timer values per stack which is much more reasonable. It's not infinitely granular, but it is not reasonable to be that way.