Warn when duplicate fluids detected
CitiesXL2815 opened this issue ยท 7 comments
Description of the Bug
steam and creosote broken texture in UI, buckets and tanks
To Reproduce
- placing the fluid show the texture not broken
- n/a
- only seeing in the ui, holding the bucket and looking at fluid in the tank
Expected behavior
n/a
Logs & Environment
latest log
https://gist.github.com/CitiesXL2815/a6ef13c917643de36bff8600f2a8b232
Additional context
it only gives broken texture when EnderIO is installed
I don't think anyone was blaming you. It just remains that the only way I know to make sure this doesn't happen is to disable all but one implementation of a fluid manually. If you don't register these fluids, and no other mods in the pack do either, then I have no idea. But the addition of EnderIO may be enough to create different load orders, and hence different winners, on the client and server (yes, this absolutely happens).
I've had KL tell me it was my fault, followed by telling me to implement it exactly how I've already implemented it. But I've also told him when he designed the system that there weren't enough protections in place to prevent these kinds of issues.
I can't say for sure why it's happening in this case. I'd need to somehow recreate the problem in my dev environment.
Yea found it about IE bc it adds it's own creosote and steam if immersive tech is installed by [Henry Loenwind] finding registering their fluid wrong, so i'm going to close this for now if this is still a problem and you want this open your welcome to reopen it
We might want to add a warning when we detect multiple fluids of the same name defined. I know for a fact that this can break client server sync badly because of mod load order issues.
It's very important that you disable all but one fluid definition in your pack, and if a mod doesn't give you the ability to do this, you must go give them grief about it. It's essential.
Hmm, I don't think it is our job to warn... moreover, as long as textures are present, things are fine.
Well which fluid wins and gets used is still determined by mod load order and the client and server have different mod load orders when client only mods are present. So it's possible for the client and server to be using different implementations of fluids. I've seen it happen.
Ok, to get some light onto this: What usually happens to get this effect is that the fluid that "wins" the registration at startup isn't the same as the fluid that is stored in a world as "active". The fluid that did not "win" will then not register its textures, but---when the world is loaded---the bucket will use that unregistered texture because that fluid is active. That may not even be intentional, as many mods depend on the fluid block to register their fluid textures, but then associate the block with the "winning" fluid instead of their own. (I think Railcraft may be doing this, but it's hard to say from just looking at the code on github.)
If anyone can find any other reason that can destroy textures without registering a fluid of the same name (Ender IO has neither creosote nor steam), please let me know and don't just blame me.