1.11 optifine - resources aren't loaded and crashes in dev environment

[Barteks2x]

Apparently it's not optifine issue, so reporting it here.
sp614x/optifine#766 (comment)

[octarine-noise]

Yep, it's not. My bad.

Something must have changed after 1.10.2 (dunno what yet), and the generated jars for 1.11.2 and 1.12 are not viable. 1.12 looks the same (magenta-black test texture everywhere), except it doesn't crash. Lots of FileNotFoundExceptions in the log, and if I throw in other deobfed mods as well (tested with Forestry and TechReborn) it crashes during startup. Something to do with missing and/or invalid resources again.

I never noticed the bug because of how I develop BetterFoliage: I usually work on the 1.10.2 branch, and merge my changes downstream. Since there weren't any OptiFine-related breakages in 1.11.2 and 1.12, I never even made dev versions for those (I've just noticed this now).

I'll have some time to tinker tomorrow, but if it's not something easy to fix, it'll be weeks until I can devote time to the issue. If you have a 1.10.2 version of your mod, I recommend you fix the OptiFine-related stuff there, it'll probably be fine for later versions too.

To answer your question on the other thread: yes, simpledeobf is still maintained - technically. In practice, since it did all it had to do (I use it regularly), and there was nothing to add, there were no commits for a long time.
Until now :)

[Barteks2x]

I already did what I needed to do with this barely-functional version of optifine in dev environment. Since it normally wouldn't even get to showing the game window, getting it far enough to show a missing block ingame was enough to get it working.

[octarine-noise]

I figured out a workaround for now: additionally delete all net/minecraft/client/renderer/block/model/ModelBakery*.class files from the deobfed jar, so the originals will be used.

The problem lies with the modified model bakery adding models/ to the start of model resource locations, so it tries to load them from DOMAIN:models/models/WHATEVER which will obviously fail. I didn't figure out why it happens in the dev environment and works fine in production, but if you're not debugging any extensions OptiFine adds to model loading, this will get you going.

[Barteks2x]

Further testing with the workaround showed that there are also lighting-related issues in dev environment (might be with just my mod, but it doesn't occur outside of dev environment, it seems as if it asn't possible to actually set any light values, or something went wrong in setBlockState, but I'm not exactly sure). While I do have functional optifine outside of dev environment, debugging any further issues with it isn't going to be possible. And as I don't have a real 1.10 version of my mod now, without a fix it will be impossible to debug any other optifine issues. And those lighting issues are severe for me, because they cause awful performance issues. And if I can't trust the code, it makes anything much harder to do.

[Barteks2x]

I think I found the cause of this issue. I still have the strange issue with light spreading just plain not working, together with a lot of other strange issues but the model loading issue is gone after my fix.

I have no idea what causes this, and debugging doesn't give me much insight into the issue:

The models issue seems to be with making everything public. You probably did it to workaround IllegalAccessError crashes that you would normally get. They are caused by forge AT not being applied, and it can easily be added by adding forge_at into Optifine's jar META-INF and adding the appropriate FMLAT entry in MANIFEST.MF. Doing that and creating dev jar ithout making everything public makes the models issue go away.

I'm still investigating the issue with lighting and block updates.

[Barteks2x]

I figured out the issue, and this is DEFINITELY optifine bug:

[12:21:03] [main/WARN] [Config/]: [OptiFine] (Reflector) More than one method found: net.minecraft.block.Block.getLightOpacity
[12:21:03] [main/WARN] [Config/]: [OptiFine] (Reflector)  - public int net.minecraft.block.Block.getLightOpacity(net.minecraft.block.state.IBlockState,net.minecraft.world.IBlockAccess,net.minecraft.util.math.BlockPos)
[12:21:03] [main/WARN] [Config/]: [OptiFine] (Reflector)  - public int net.minecraft.block.Block.getLightOpacity(net.minecraft.block.state.IBlockState)
[12:21:03] [main/WARN] [Config/]: [OptiFine] (Reflector) More than one method found: net.minecraft.block.Block.getLightValue
[12:21:03] [main/WARN] [Config/]: [OptiFine] (Reflector)  - public int net.minecraft.block.Block.getLightValue(net.minecraft.block.state.IBlockState)
[12:21:03] [main/WARN] [Config/]: [OptiFine] (Reflector)  - public int net.minecraft.block.Block.getLightValue(net.minecraft.block.state.IBlockState,net.minecraft.world.IBlockAccess,net.minecraft.util.math.BlockPos)

[octarine-noise]

Yes, you're 100% right about the AT stuff. That's why I did it, and using the transformer makes for a much better dev jar overall. I didn't think of that - just went for the easy way out right away.

Seeing the logs you posted, I had a snap theory about the lighting, but I see you've already confirmed my suspicions over in the Optifine repo. I hope this is the last hurdle, and when sp614x makes the necessary adjustments, you'll have a fully functional jar so you can keep working.

Thanks for all the work you put into this!