I have a modpack running the following relevant mods, understanding of what they do is necessary for the context of this issue:

• campanion
• sodium
• indium
• applied energistics 2

On realizing that tents stored the contents of all of the blocks within them perfectly, one of my SMP server members decided to put a basic ME system with autocrafting inside, and break the tent - immediately putting their client in a crash loop. You can find the crash report, with further information about mods, and versions and such here, but the gist of it is the "Crafting Storage" block from AE2 really didn't want to be rendered in hand.

I could throw this issue at Indium but I've already given that mod enough trouble (comp500/Indium#55,) so I thought about some alternative solutions. The immediate one was a destructive operation - the tent bag is in their main hand so I could just clear it, at the cost of a good chunk of their resources stored in the ME system. I'd hate to do that, since that's over 24 hours of work on their end just gone. The next one that I realized was the potential for a client config option disabling that whole fancy in-hand rendering going on. The particular user that ran into this issue has a PC that suffers badly without sodium and indium, so keeping those mods in the pack would be a best case. I checked the config only to find it empty, and the code didn't seem to show any option either. Hence this request. If the tent item just rendered as a bag like it does in the inventory, in theory my friend would be able to rejoin the server with no problem.

The issue causing the crash here is actually that Campanion's FakeWorld class doesn't implement RenderAttachedBlockView - so AE2's Crafting Cube model fails to get the metadata it needs (in this function). This should be fairly trivial to implement, as you're rendering on the main thread, so it'd just be a matter of using the default implementation from Fabric API (which is normally applied to the world class through a mixin).