Describe the Bug

If you have activated the entity culling mod and assemble a train, it becomes invisible.

Reproduction Steps

1. Use the Culling Mod.
2. Build a Train and Assamble the Train.
3. 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

Can confirm, isn't caused by OptiFine.
This is probably Entity Culling's fault.

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?

I'm sure it will.
Thanks for the help, and best of luck with your exams 👍

Is this actually fixed?

Is this actually fixed?

Yes

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).