IClientFluidTypeExtension for Neo
Soaryn opened this issue ยท 1 comments
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
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)