the villagers from the MCA Reborn mod selected by the Scout's Distillation have no textures.

[CoreanXka]

Modloader

Fabric

Minecraft version

1.20.1

Hex Casting version

0.11.2

Modloader version

Fabric Loader 0.16.10 + API 0.92.3

Modpack info

No response

The latest.log file

No response

Issue description

During the casting process, the villagers from the MCA Reborn mod selected by the Scout's Distillation have no textures.

Steps to reproduce

No response

Other information

No response

[gamma-delta]

I think this is actually an Inline issue (thanks object for pinging Sam).

[SamsTheNerd]

it's primarily an inline issue but the fix i have in mind will likely involve tweaking some stuff in hex.

[SamsTheNerd]

ok so actually this is kinda more of a hex issue too sorta kinda. joint custody of this issue if you will, it can maybe probably be mostly handled on inline's side but some stuff would need to be changed on hex's side too probably.

What's happening is that when we send stack info to the client's spellcasting gui (and in fact when we send iota info to a lot of places on the client), we serialize the iota into some representation of the data and let the client display the iota based on the serialized form.

For entity iotas, this means we attach the UUID to represent the entity (which, to my knowledge, the client cannot use to find the entity) and then also attach a display Text/Component with the entity's name and some inline data approximating that entity.

Inline currently has 3 ways to represent an entity (they're called Cradles in the code, they're designed specifically to be serializable and safe on server and client):

• player cradle: holds a gameprofile, client can find the skin from this
• nbt cradle: holds an entity's nbt data and caches the entity that results from it. Entity NBT data can be big! and we don't necessarily want to be sending all that to the client always.
• entity type cradle: stores just the entity type and creates a new entity instance from it to render.

Entity iotas will always use the separate player face inline data type (not player cradle!) if the entity is a player, otherwise if the iota is just being displayed, it will use the full Nbt Cradle which to my knowledge only happens in base hex on mishaps and reveals? those still get serialized since all text gets serialized of course, but that happens less often and the data sticks around for a short amount of time, so the larger data size is probably fine (is sending the entity nbt to the client always fine? idk! ). If the iota is being serialized though we want to avoid attaching the entire nbt data, since this happens often (especially when staffcasting), and the data may stick around for a while in a focus or spellbook.

Which brings us to the cause of this issue (and #825 and probably partially #784), entity specific data is lost with the entity type cradle. So we get no texture attached to the mca villagers, no itemstack attached to item entities, etc. I don't think there's gonna be a one size fits all fix here unfortunately. But some partial ideas:

• an entity ID cradle: I didn't know about entity IDs (separate from UUIDs!!) before but they're generally used for referring to entities during networking. The issue here would be that I'm not sure they're persistent, so might not be suitable for saving iotas to foci or wherever, and the client may not know about distant entities (iotas can travel! especially with addons but even in base, consider two distant players reading/writing to a shared library via sentinel)
• specific overrides: allowing mods to register overrides for what data to display for specific entity types. ex: item entities -> item stacks (although those can also get big NBT!, consider writing a spellbook reference to itself repeatedly), mca villagers -> their own specific minimal nbt cradle?, etc. issue with this is that it's not a general solution and it's unreasonable to expect other mods to explicitly include inline interop or for inline to manage interop with all other mods.
• Opt out entity tag or other data/resource pack-based indicator: this would be easier to manage than code-interop with the argument that showing nothing is better than showing something broken.
• Serialization be damned, shove the whole nbt through
• datapack solution that allows specifying specific NBT fields that should be serialized through?

Note that a lot of these solutions could be primarily implemented in inline with minimal changes in hex, but which direction we go should likely be informed by hex. There's also no reason that this has to be fixed in inline, it could be better to try to find a hex specific fix rather than sticking to inline's entity setup.

Or we just ask MCA to put a reasonable default fallback texture on their villagers and call it a day idk.