I’ve always wondered why items in Minecraft despawned after a few minutes. In many other games they simply stay where they are till you pick them up or something else happens to them. The tick system of minecraft would of course make it difficult to simply stop items from despawning since after a while there would be tons of item entities all counting down their ticks, and even if the despawn counter would be reset to a certain number after a while, the item’s ticks would still need to be calculated.
However wouldn’t it be possible to completely exclude the item despawn counter task from the tick count cycle?
Normally each tick the game checks for all kinds of things that happen/could happen in the world. Couldn’t you just disable the item despawn part and leave all other entities, redstone, etc untouched?
If i understand this right, this would make item entities as laggless as normal blocks, since they require just as many calculations = practically none. This way the server would have a lot less work to do, and all the client would have to do would be to render the entities as it normally would. I’m not sure though whether the client also counts the despawn ticks/recieves them form the server/ignores them, depending on this there might be the need for a client side mod for full potential.
Any thoughts about this? Would this be possible to make? Is there anything i didn’t consider?
The items despawn because otherwise it is way to easy to just build up items and overload the game server
This is actually extremely easy to do in forge, I might add it into a mod for ‘ShitsNGigs’
You can stop de-spawning in vanilla, using custom NBT tags on a /summon command
See Item Entity NBT data for all it’s attributes.
A certain PR by a totally unrelated author adds methods for this to the API 
Not possible, there will be issues when enough are present
An overflow of any resource on any platform will cause performance issues. The server can’t just stop ticking the items; then there is no way for the items to be updated. At all. You would in effect create ghost items that just took up more memory space, provided the Java garbage collector didn’t sweep them up because they weren’t being referenced anymore. Yes, you can go in and make items never despawn, but when a handful of mischevious players find out item drops aren’t despawning, and each drop an entire inventory into a 1x1 block space at the bottom of your world in an impossible to find hole, good luck getting your TPS back to a normal level.
Edit: fix typo
Blocks are entirely different than entities are,as far as I’m aware, they are static objects that don’t need really need to be processed by the server after it loads, unlike most entities and some tile entity blocks(like hoppers, and furnaces.).
It wouldn’t really matter if the items are underground, out of the players sight, it would still have a hit on the server with them there, as the server still has to process those items.
You have the item stacking and item despawning in Minecraft so stuff like this doesn’t lag the server for very long.
@Kevin96AT
Blocks aren’t ticking 20 times a second each like entities are. They wait until the server says “hey you, this happened, do something about it” and the block says “yeah ok then I can do that” and does its thing.
You might have heard of a BUD switch - Block Update Detector Switch. When a block update occurs (when a block’s state is checked or updated by the game), it also checks the state of neighboring blocks (hence how cactus and sugarcane collapse when their base is knocked out, also how BUD switches end up working).
If blocks ticked like entities, Minecraft would require multiple supercomputers all bridging their CPUs and GPUs together.
Underground items would not be rendered visible on the client side, yes, but for both the client and server, these entities still exist, and will take up memory space, and on the server, CPU time to update.
If you REALLY wanted to go out of your way to make it possible, you could tear apart ( “tear apart” might be an understatement; haven’t used MCP to play with the game code since 1.7.2) the actual game code and make item drops static objects that require some sort of update event like blocks do (this is all theory in my head, don’t ask for anything on paper, I don’t have that level of programming skill). The downside is that you would lose some of the functionality that being an entity provides. I am by no means a coding pro, so I do not know of any feasible way of doing such a thing with a plugin or Forge mod.
@Kevin96AT Forge already has an event for this called ItemExpireEvent.
Currently there is no counterpart to this in our API but I suppose we could add one.
What you are essentially describing is a deathchest just rendered differently, It seems like a lot of work to make items into block/tile entities that still get sent to the client as items considering that rendering too many items can lag out your users connected to the server.
You could do some on block change notify nearby entities stuff, so that items removed from the entity ticking loop could still be updated, but you would still need to worry about players activating their pickup.
Long story short it starts to sound like major surgury for something that can be fixed by using deathchests/gravestones/insert mod here.
It’s not possible, either the items are included in the physics and ticking updates and causing lag, or they are not.
If you want to exclude them from ticking, you need to reintroduce some other way for them to be updated.
You could just make it so they are ticked half as often, or that players update the closest entities to them (entity activation range patch from spigot) or that they arn’t ticked unless a block update happens near them, but all this is rather heavy handed changes to vanilla.
If you want to prove me wrong, I’m welcome to see a solution that solves it.
Looking at the code, you could stop them from ticking completely, but that would stop them from merging with other items, stop them from dying in fire/lava, make them float in midair if there is no block supporting them, they would still be a loaded entity taking memory space, would still need to be tracked in the entity collections.
However they would still be able to be picked up by players. so there is that. all that checking is done by the player when they move, but the items would still need to be in the entity collection for this to happen.
I will be adding support for entity activation ranges to function similar to Spigot but with a few adjustments to support Forge mods. More info on how Spigot handles it can be found below.
http://www.spigotmc.org/wiki/spigot-configuration-spigot-yml/
entity-activation-range
Default: (animals: 32, monsters: 32, misc: 16)
Type: Integer
Description: Controls the range in blocks that entities will become “activated” - entities outside of this range will tick at a reduced rate to prevent server lag. When changed, these numbers can adversely affect gameplay, so edit with caution.
Lowering these values can give a major boost to performance, but at the cost of affecting gameplay behavior. Lowering these might impact item and monster farms, but should have little impact to normal behavior
The nolagg plugin did have the item buffer feature to it, where it would buffer items when they spawn so they don’t all spawn at once, if it was over a certain configured amount of items for a chunk(This was a bit buggy with the item stacker in minecraft though.).
Configuration of this is built into the Sponge API. Travel to:
[your server directory]/config/sponge/global.conf
Look at line 34, you can change the item despawn rates in ticks!
Could you possibly set the timer too 0 to remove the tick calculation? 