![Create](https://media.forgecdn.net/avatars/thumbnails/393/435/256/256/637588742363737916.png)
Invisible Trains with Entity Culling Mod by tr9zw
Guppy3874 opened this issue ยท 24 comments
Describe the Bug
If you have activated the entity culling mod and assemble a train, it becomes invisible.
Reproduction Steps
- Use the Culling Mod.
- Build a Train and Assamble the Train.
- Look at the Train.
Expected Result
Normal behavior for the train.
Screenshots and Videos
Crash Report or Log
No response
Operating System
Windows 11
Mod Version
0.5.0
Minecraft Version
1.18.2
Forge Version
40.1.60
Other Mods
Optifine
Entity Culling Mod Forge/Fabric
Additional Context
No response
Hi there, i'm playing ATM7 and I'm running into the exact same issue. However, there is no Entity Culling Mod in this pack. And optifine doesn't even work with it right now, so it must be something else
Hi there, i'm playing ATM7 and I'm running into the exact same issue. However, there is no Entity Culling Mod in this pack. And optifine doesn't even work with it right now, so it must be something else
I also came here because of this issue, running it on ATM7 (0.4.20) - there is entityculling-forge-mc1.18-1.5.1.jar
in the mods folder. As soon as I removed that, the train rendered correctly.
Judging from other issues on that mod, I would guess it has to be added to the white list like this:
https://github.com/tr7zw/EntityCulling/blob/1.18/EntityCulling-Shared/src/main/java/dev/tr7zw/entityculling/Config.java#L12
From @tr7zw :
They either need to be added to the whitelist, or Create needs to fix the visual hitbox of the entities(that's probably what's wrong in the first place).
For context: create:rope_pulley
and create:hose_pulley
are already on the whitelist because the rope/hose part is not part of the visual hitbox. So it might be the same kind of issue.
Could it be due to the hitboxes changing their boundaries?
Both the pulleys and the carriage entities provide the standard aabbs used in vanilla's culling, but they might not be accurate if their initial extents are being cached externally
Hi there, i'm playing ATM7 and I'm running into the exact same issue. However, there is no Entity Culling Mod in this pack. And optifine doesn't even work with it right now, so it must be something else
I also came here because of this issue, running it on ATM7 (0.4.20) - there is
entityculling-forge-mc1.18-1.5.1.jar
in the mods folder. As soon as I removed that, the train rendered correctly.Judging from other issues on that mod, I would guess it has to be added to the white list like this: https://github.com/tr7zw/EntityCulling/blob/1.18/EntityCulling-Shared/src/main/java/dev/tr7zw/entityculling/Config.java#L12
Could someone tell me what exactly to whitelist? Is ist "create:train" or "create:train_controls"? So i can at least fix it for my server on my own for now
@ToastiMan create:carriage_contraption
I believe.
Could someone tell me what exactly to whitelist? Is ist "create:train" or "create:train_controls"? So i can at least fix it for my server on my own for now
If you look at something with F3 open, it will tell you the Block or Entity name on the right side that can be added to the whitelist. If this fixes the issue please report the used name, I'll include it in the next release.
Could someone tell me what exactly to whitelist? Is ist "create:train" or "create:train_controls"? So i can at least fix it for my server on my own for now
If you look at something with F3 open, it will tell you the Block or Entity name on the right side that can be added to the whitelist. If this fixes the issue please report the used name, I'll include it in the next release.
@ClaytonAstrom was right, it is indeed "create:carriage_contraption". I got it to work.
@tr7zw I added the config.java to this post, i just had to change the filetype to post it here
Config.txt
Ehhh I hope for your testing you just added it to the config file and didn't go through rebuilding the entire mod :D It will be in the next releases.
Edit: Also note for the title: tr9zw is just because Twitch fucked up and locked me out of my own tr7zw account. That will be changed as soon as CurseForge has its own user management.
Ehhh I hope for your testing you just added it to the config file and didn't go through rebuilding the entire mod :D It will be in the next releases.
Well, seems like my fix would have been too easy. Trains that are already built can now be loaded by restarting your game, but newly build trains won't render in. Seems like as soon as i disassemble one train, the rendering of them all stops. Only solution is restarting the game.
@simibubi Seems like it would be smarter to fix this on create's end.
Edit: Ok, something i more than off. When multiple trains are rendered and another one is newly assembled the new one doesn't render, but the existing ones do. If the existing ones get disassembled and reassembled they also disappear.
Adding
create:carriage_contraption
to the entityWhitelist did the trick for me. Does this mod have a maven?
Modrinth maven/cursemaven should do the trick. It's not explicitly deployed to another maven like codemc.
Adding create:carriage_contraption
to the entityWhitelist did the trick for me.
Does this mod have a maven?
Gotcha. I tried the two, but those do not seem to allow me to inspect/debug the source beyond just having the mod load on launch.
The source is over here https://github.com/tr7zw/EntityCulling . The important call is here https://github.com/tr7zw/EntityCulling/blob/1.19/Shared/src/main/java/dev/tr7zw/entityculling/CullTask.java#L134= to entity.getBoundingBoxForCulling();
(Mojang mappings). My guess is that this function returns some odd values.
Note to self: refactor that class for better readability.
The values I'm seeing returned from that method in the contraption entity look perfectly normal.
Far as I know these aabbs are required to be accurate for vanilla rendering to work aswell, is that right?
Except for one case, vanilla culling box == hit box, so I'm not too sure how well vanilla differentiates between them. Currently studying for exams, I'll throw together a debug build later to check what's going on.
I believe I found the problem. Looks like the mod takes not yet visible entities out of the tick loop aswell.
Carriage contraptions, before they return true
in shouldRender()
, need at least one entity tick to figure out their orientation and such. This tick never occurs with entity culling active, for hidden entities are never allowed to tick ๐
I can move the check out of shouldRender()
and into render()
to avoid this from happening
Ah yea that makes sense. This kind of logic doesn't occur in vanilla(there, client ticks just process movement, visual updates, and some probably incorrect logic like cramming), so haven't seen it causing such a state. I guess fixing this might also fix some issues with mods that might freeze ticking like carpetmod/replaymod?
For future reference: In the next release, I've added that the entity noCulling
field gets respected correctly(same on the Block Entity side with the shouldRenderOffScreen
method in BlockEntityRenderer
). So without any hacky workarounds, (block-)entities can exclude themselves(also temporarily) from the culling logic(my bad that this was missing in the first place).