user-85f14

@Moesh the function displayed at the top is badly implemented that is the bugreport (it is actual mc code)

So the bugreport is: Please decide what the function should support: "Nulls or not Nulls" because right now it does both at the same time leading to undefined behavior if someone uses it.

Eh, not really a insult or even a attempt, just a hint that your input is as wanted as that comment.

And the code quality dropped massively since 1.18 (When i noticed it) so that explains it really well thank you!

Funny thing is, that stance is one of the reasons why mojangs code quality is at the level it is at.
But yeah I managed to register a custom stat and successfully create it, and then managed to (without anything i wrote) to make it be deleted and then create a crash because a Stat that wasn't registered anymore couldn't be recreated because the one function that could recreated it would crash if the function received a null from it, but not because the function was supposed to be crashing, nah it was supposed to handle the case but horrible mojang code => yeah this is normal xD

Also @Dhranios do you see the bug in the code provided?
if not then you clearly need to get glasses

While the crash might be invalid the bug will persist because some dev can't really implement 1 function xD

(When I registered my stat I did it exactly like mc did, but when i requested it the game said nope doesn't exist so we crash because we can't create it, even so it was already created)

After looking deeper into it, this is not reproduce able since advacements can not create stats, though if it ever was this would crash since this function accepts nulls but can't process nulls.

Though it is interesting that a Stat can be null in the registry after it was registered in the init phase.

> How? Unless a bug has actual gameplay impact in vanilla, Mojang resolves reports as invalid (they've done so several times before).
 
How this was triggered was by Using a custom Advancement tester that was using a ID to detect the current value of the stat that should be tracked.
And just that test was causing a crash even so the stats were properly registered. To be more specific it is the stat that command blocks can register on their own.
And since you can  easily create custom stats with command blocks or DataPacks you can easily run into that if anything fails, because this is only an issue since 1.19, older versions were fine. 
 
Thats why datapacks can easily run into it because it is a feature datapacks can use.

Also their Development tools should yell at them to fix such things. (Because they are programmed to yell at such things)
This is one of the most common ways bugs are created in a game...

Edit this might be confusing for anyone watching from the outside.

The Crash is my bug yes, but the code snipped (from mojang) is missleading to say the least.

The function says it supports null inputs but if you do that the game will crash. And that is mojangs bug, not mine.

Can be confirmed for 1.19-1.19.1 Snapshots of all types.

Also Pois only need to be saved if they are changed which vanilla already checks.
And the loading speed of Pois is actually quite fast. You can load like 50k pois within a second or less because they contain very little information to begin with (or are empty)
(Also if pois loading is slow then server restarts should lag servers really badly)

The main issue with pois is that they limit the total size of the world before you need to delete them/restart your server.
If your world gets like 10000 x 10000 you will need multiple gigabytes just for them because you have tens or hundreds of millions of them loaded until the server restarts.

While for small servers this isn't an issue for large servers this require a lot more ram to deal with, slowing the JVM down even more because garbage collection has to deal with these things too.
And Minecraft already runs very badly to begin with. (1.7.10 worldgen is roughly 5-10 times faster then 1.18-1.19 worldgen and that is running on a single thread while 1.19 runs on 2 dedicated threads)

Anyhow unloading pois only gets bad if you are unloading them to aggressively, which can be prevented by having like a 2-3 extra chunk radius around the loaded chunks loaded with them. Which is anyways done with how chunks have to be loaded anyways.

But yeah still and issue and this will limit how many chunks can be ever loaded between server restarts without running out of ram.
Ticking timebomb that is lovely.

Edit: Bot this is known to be not addressed yet so its accurate. xDD yes I complain against bots because its fun.

> This is a sort of feature suggestion. Thank you, though!
 
Yep it is, but it is so deep into the engine that it wouldn't make sense to go to "feature" suggestions, because these include gameplay.
I hope that at least gets considered in some areas of the game.

Yes it would if you check for a specific slot. But Item saving itself wouldn't change. Only the slots would be compressed to reduce memory usage.
And on top of that this would only apply if there is duplicates single items or items with different NBT wouldn't merge and still support the old format.

On the other hand this would help a lot with world sizes since chests are usually bulk storage based or have exact duplicates allowing to save a lot of space.
And since its backwards compatible and only affecting duplicates it would only affect certain cases.

I wonder if a optional setting would be interesting since its backwards and technically forwards compatible. On top of that entities could only save for the final storage like that and not for commands.

Technically this would not break every command that checks player inventories because the compressor I am suggesting would only compress NBT.
And player inventories are not "serialized" during a inventory check command.

Unless you want to look directly into shulkerboxes contents while they are in Item form.

Sorry for the long delay. I have been working on other projects.
Just this week ported my mod to 1.16 and just ran a WorldGeneration task through it.

And yes this bug still exists. the "PointOfInterestManager" still does never unload any Points of Interest.
Yes the instances of each PointofInterest can get removed but the "Chunk Instances" of these PointOfInterest do not cleanup.

Here is a bit of imagery:

javaw_2020-12-06_01-43-56.png (would be the specific one)

This is a freshly created world that has just started a worldgen task.

Next Image:

javaw_2020-12-06_01-49-56.png (would be the specific one)

After generating 35.299 Chunks 175.904 Points of Interest objects have accumulated in the pointsOfInterestMap.

the "POI" variable is referencing the field "field_219121_b" which is in the RegionFileCache (which i know is a custom mapping from forge)

Now this is right now a mass-gen tool that tells mc to generate chunks. But all this is easily replicate able with just walking around in the World. Now 35.000 chunks seems like a lot, but it honestly isn't if you think about 10-15 people playing on a server.
And if that small small amount is already causing 176k instances what happens if you have a million chunks (16k x 16k worldmap) generated by the game and haven't restarted like every 24 hours the game. This is at a point where this empty references cause so much overhead that we talk about Gigabytes of RamUsage just for storing nothing. A PointOfInterest ChunkInstance should delete itself from the PointOfInterestManager if there is nothing stored in it. That way you only keep what is present. This is exactly  the same issue that "Structures" had before the 1.14 update. (Maybe 1.13 too but i haven't checked that code)
This is a confirmed 1.14.x-1.15.x-1.16.x bug. And I bet this is still an issue within 1.17.Snapshot.

Honestly a Reflex.
But if you want any source examples on my methods or something, private is a requirement on my side.
(Since I had already a couple projects almost stolen. I rather keep my work protected as much it is possible within Java without Obfuscation)

Reason for this bug is actually because the ItemEntities get spawned on the client somehow and are only visible to the player. A video by Ilmango shows that they can be only destroyed (as know so far) by lava. Maybe by void too.
This is a clear indication that the Item Entity is only present by the client side (not on the server) because the Item Entity handles Lava damage by itself.

Maybe a "world.isRemote" check missing?

That may happen because of the TileEntityModel defaulting to that texture.