carried on from issue comments in #77

the issue is entities, both players and other summons, when freshly spawned behind a wall or after leaving/entering a portal, have a mild chance to never become visible again. this has been present since 1.4.0 and is fixed in 1.3.0

I will upload footage to youtube and send it later, it is easy to reproduce for us

this has been present since 1.4.0 and is fixed in 1.3.0

But 1.16 is at 1.5.2. Also, can you try binding the debug toggle key in the keys screen, and then check if they pop back up?

I'm asking that, because 1.4.0 1.16 has been out for a year now, and after a combined ~3 million downloads since then, you are the only one that seems to have this issue.

Also a bug like this WAS an issue back around the 1.3.0 times.

this has been present since 1.4.0 and is fixed in 1.3.0

But 1.16 is at 1.5.2. Also, can you try binding the debug toggle key in the keys screen, and then check if they pop back up?

exactly, which scares me as to why it hasn't been found yet. might be a mod conflict somewhere down the chain...?

hang on whilst I gather footage and test that debug for ya

for example in my modpack you can place down steak and wolves will find it and eat it immediately. however, when I did this, something ate it, and it was completely invisible. after five seconds, the wolf finally showed up. it hadn't moved since it had done that, but the entirety of the time it chased the beef it only played sounds and wasn't rendering.

worst case scenario it breaks the player, whom is never seen again until the client is restarted

I'm asking that, because 1.4.0 1.16 has been out for a year now, and after a combined ~3 million downloads since then, you are the only one that seems to have this issue.

Also a bug like this WAS an issue back around the 1.3.0 times.

yes however, in 1.3.0, it fixes itself within 1 second or so. in future versions, similar errors never reset at all, or take an extremely long time

#31 is a conflict with Performant for example that I just found on the search. Sounds like your problem?

#31 is a conflict with Performant for example that I just found on the search. Sounds like your problem?

Performant does not exist in my pack

Then idk. Check your logs for a message that the culling thread crashed/exceptions from culling, see if the f3 stats still update, send a modlist or so. Without an error or a way to replicate the issue, I can't do anything.

I mean, footage just helps to confirm that you have the issue, not to resolve it.

just got footage of the issue, uploading now

I mean, footage just helps to confirm that you have the issue, not to resolve it.

I understand that, but seeing as the visual bug is different from the other issue it still helps to show the scenario.

note that the zombie that did this walked around the tree so it was outside of my vision for around 5 seconds at that point

this is what the issue looks like visually, the invisible zombie to my left, eventually starts rendering again. it takes a long time and sometimes this is permanent.

the logs show absolutely nothing relative at this point, seen here: https://pastebin.com/WGfGfqQg

Thats not the full log

Did you maybe mess with the config?

Thats not the full log

I know that, as I told you, nothing else is relevant before that point. I'll send the full log here then.
latest.log

Did you maybe mess with the config?

yes, I changed the trace distance, hitbox limit, and sleep delay, additionally added grapplemod grapplinghooks to the whitelist. here are my settings https://pastebin.com/DJU4Jbxt

  "tracingDistance": 256,
  "debugMode": false,
  "sleepDelay": 5,
  "hitboxLimit": 500,

honestly, don't. Leave the config on default values. "hitboxLimit": 500, makes no sense and bestcase will crash your game/give you a solid 0-1fps.
"tracingDistance": 256, this will eat a solid 2gb of ram and hurt the culling performance a lot.

Good chance it's because of the changed tracingDistance.

It's still stupid, since it will lag out depending on the world and entities. Plus it eats 2gb of ram for no reason.

  "tracingDistance": 256,
  "debugMode": false,
  "sleepDelay": 5,
  "hitboxLimit": 500,

honestly, don't. Leave the config on default values. "hitboxLimit": 500, makes no sense and bestcase will crash your game/give you a solid 0-1fps. "tracingDistance": 256, this will eat a solid 2gb of ram and hurt the culling performance a lot.

wonder why I was getting 1k fps then when uncapped?...with barely any memory changes?

I guess I'll revert it all to default values and see if the issue happens again. I would appreciate better documentation of the config values somewhere, either a git wiki or as comments in the json generated.

I'll revert the config and test now

Fps has nothing to do with this. In the f3 menu you can see how long the last culling task took, since this is happening in a different thread. If it takes like over a second due to the changed distance, then yea, stuff will stay invisible oddly long.

Fps has nothing to do with this. In the f3 menu you can see how long the last culling task took, since this is happening in a different thread. If it takes like over a second due to the changed distance, then yea, stuff will stay invisible oddly long.

no, max it went to was 5ms in my survival testing

understood, won't touch the config in the future I guess. still running the test

If you change the entity view distance to further than 100% and outside of the tracing distance, it will just render them and not attempt to try to cull them(since that would eat more resources than you gain from not rendering).

The mod doesn't have a config screen to mess with these values for a reason 😅

main reason I was trying to mess with trace distance was to allow the game to stop culling entities so that snipers could go all the way to the edges of their chunks

If you change the entity view distance to further than 100% and outside of the tracing distance, it will just render them and not attempt to try to cull them(since that would eat more resources than you gain from not rendering).

ah alright, so that makes my attempts useless. oh well.

I'll just keep the world 6 chunk distance by default since that seems the most balanced between the two on my pack

I just assume it went haywire due to the settings. Trying to wipe a 2gb cache and then do tracing in a 256x256x256 cube for all entities, and that all every 5ms on one CPU thread.

seemingly the issue for entities is fixed now, however, I will need some time to test multiplayer. my friend who helps won't be around for a few hours yet.

to be fair my machine can handle much worse, but I think the issue might be that maybe, just maybe, if garbage collection fires at the same time, the thread hiccups.

additionally maybe having the settings too high was the true cause of a memory leak I had been researching for in my pack...hmmm...

The entire thing is implemented without causing new allocations, so the gc is fine. Also not causing a memory leak, just instantly taking 2gb and then never giving that back due to the range setting.

hmm weird, that's not at all the behaviour i was seeing, though I do have a "lag" issue around 10 seconds after starting a world, where 700MB gets dumped onto the heap whilst the client is frozen, then after a few seconds the freeze unlocks and it never does that again

You can check stuff like that with Spark. I'll close this issue for now since it seems resolved.

I'll reopen if the multiplayer is broken

even with a clean instance of the config, it still happens. Players and I both encountered completely invisible endermen that teleported back to chase us (they did not have the effect otherwise particles would have been showing.

additionally I was able to reproduce the issue the same way as last time

the issue needs reopened and investigated. as usual, downgrading to 1.3.0 fixed the issue

I'm still certain that there is no such bug. Have you tried what happens when you press the debug on/off button when this happens? Do they instantly show up again?

it's going to take ages to test it because we're trying to make sure the issue only occurs in survival, however tonight I can try again with creative. I promise you, there is nothing we have done to doctor this in a way that would fake it.

I'll use the debug button and see what happens

additionally, the debug button is showing numbers in nametags above all entities, which means my players can see entities through walls, and allows them to cheat that way. hence why we haven't really been trying to do it as we considered it cheating

Also bestcase join the discord, github is a bad place to constantly test stuff.

I don't have a link to your discord, would be convenient to paste it here please :)

https://discord.gg/2wKH8yeThf

Creative mode has no special treatment, only in spectator culling gets turned off.

additionally, the debug button is showing numbers in nametags above all entities, which means my players can see entities through walls, and allows them to cheat that way. hence why we haven't really been trying to do it as we considered it cheating

wrong debug button, also this "cheat" gets kinda fixed by this mod. That's the point.

no, it doesn't, because the config is client side, players can just set "cull nametags through walls" back to false and the server won't bother blocking that