ChiselsAndBits conflict
TechnicJelle opened this issue · 9 comments
In my serverlog it says "[chiselsandbits]: Unable to determine blocks eligibility for chiseling" for some of the blocks in the mod.
I read up on the error (ChiselsAndBits/Chisels-and-Bits#49) and it seems it can't be fixed by @AlgorithmX2.
These are the blocks:
net.bdew.lib.multiblock.block.BlockController attempted to load net/minecraft/client/util/ITooltipFlag
net.bdew.lib.multiblock.block.BlockModule attempted to load net/minecraft/client/util/ITooltipFlag
Sounds more like a bug in Chisels and Bits trying to use classes before FML transform them
C&B is not loading the classes before the FML transform.
C&B is having an issue accessing the Block with reflection because said block is trying to load a class that doesn't exist, If a method contains a reference to a class which isn't available for some reason it should be marked with the appropriate @optional or @SideOnly(Side.CLIENT). So that FML can remove any references to them in the class on load.
This has to do with difference between how classes are loaded when using reflection, and when simply executing them.
Essentially java when executing uses a just in time method, only when the method is called does it bother to try to load the method.
When using reflection java has no choice but to load the classes fully, which causes missing classes on the server side for methods that are not marked as client side only with client only classes in them.
When I've a dependency with another mod (for example IC2 energy interface), if I don't mark the method as optional, the class won't load, even if I don't call that method.
So, I'm a bit confused on why it's different with ITooltipFlag here. Maybe the JIT still loads methods referenced internally to that class, if they are available?
I believe that's more or less correct, understanding exactly what the differences between how the JIT works vs reflection is a bit murky. It more or less comes down to what the JIT needs to compile to make the class usable, vs "Full Load" which is required for reflection access.
The differences in how java works in the two situations have caused me a great deal of headaches when I was trying to track down why certain blocks that are little more then textured cobblestone can't be chiseled by C&B.
This is of course why C&B displays these log entries, because they are the only way to know why C&B has marked a block as unsupported, since C&B catches the exceptions that reflection throws when trying to load one of these classes. There is a surprising number of blocks/mods that fall into the trap, since nothing breaks just playing the mod normally by itself.
The message is detailed but without our discussion here, I was confused as a mod author, I can't imagine what a modpack author would think reading those. May I suggest adding a link to a page explaining the issue would help mod authors to fix it?
I'd rather the message be adjust rather then a URL, do you think it would be more self explanatory if it included something like ", Missing @optional or @SideOnly(Side.CLIENT)?"
Or would something else help clarify the details?
Its one of those things where people don't want their logs any bigger than they are already. And adding a URL or something to the message would only add to it. Expecially since the URL would have to be something like "https://algorithmx2.github.io/Chisels-and-Bits/eligibilityError/"
I was thinking about adding a single message at the end if error was occurred. A clear message is required. The URL is to go more extensively, if needed. It could be a simple issue on the mod tracker.
Here my proposal: "If you see "attempted to load" error here bellow, please report to mod authors, they're probably missing a @optional or @SideOnly(Side.CLIENT) annotation. For further information, refer to xxx."
I've decided to just hide the logging by default since in most cases it just clutters the log, and is only useful for determining why a block is not supported.
