Architectury API (Fabric/Forge/NeoForge)

Architectury API (Fabric/Forge/NeoForge)

170M Downloads

IClientFluidTypeExtension for Neo

Soaryn opened this issue ยท 1 comments

commented

I don't actively use Architectury, so determining to whom would need to be handling this scenario is more of a mystery. However assuming it is the side of the registry API, it seems IClientFluidTypeExtension is not initialized for fluids created with Architectury when using Neo from my best guess. It is registered via an event now RegisterClientExtensionsEvent. The way I handle it for all of my fluids is via a ContentMap that just has reference to all of the fluids I register, instead of me specifying one at a time, but for other systems I have opt-in and opt-out since it is what I need.

    @SubscribeEvent
    private static void initializeClient(RegisterClientExtensionsEvent event) {
        for (XyFluidType fluid : ContentMap.getFluids()) {
            event.registerFluidType(new IClientFluidTypeExtensions() {
                @Override
                public @NotNull ResourceLocation getStillTexture() {
                    return fluid.StillResource;
                }

                @Override
                public @NotNull ResourceLocation getFlowingTexture() {
                    return fluid.FlowingResource;
                }
            }, fluid);
        }
    }

As I mentioned, I don't use Architectury, so how it is implemented isn't much of a pain point for me, but there are quite a few mods that seemingly add a fluid with it, that break due to the texture being null incorrectly. If it is up to the modder to register these extensions, you may want to put in some safe guards to inform a dev that they are missing at the very least to try to mitigate the number that slip through.

Example of a mod that has recently come by my issue tracker: st0x0ef/stellaris#17

commented

I haven't worked on Architectury in a hot minute, but from a cursory glance I found out that the mod doesn't seem to actually register fluid types? This should probably additionally be looked at for this issue, since there is a possibility RegisterClientExtensionsEvent needs them to be registered (and they should be! I'm not sure why they aren't tbh)