-
-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixin Changes + Compatibility With my Mod #155
base: main
Are you sure you want to change the base?
Conversation
…enderer. Formally, this was done by injecting into Minecraft's PlayerRenderer#setModelProperties. There was a concern that "Somehow [injecting into the constructor to add the CustomLayerFeatureRenderer] in 1.16.5 is a bit unpredictable, [and that] only late adding layer works well," but my testing has shown there are no prevailing issues.
PR Summary
|
Oh, and a version bump because this would be considered a bug fix? 1.6.4 -> 1.6.5? Although I think I will leave that up to you because you have a better understanding of the gradle tools you use for your projects 😅 |
Hm seeing this pr, I'm really not sure. This might break the mod with other mods(the initial reason on why the late init was done in the first place, but don't ask me which mods exactly were the reason). |
Can you give me some of the mods where these problems take place? If I am being completely honest, it would be on these other mods to make them compatible with this mod IF you were adding this render feature in the constructor, not you making your mod compatible with other mods by adding the I made my mod compatible with this mod by changing the priority of my mixin to be loaded later than what is being done in this PR. |
All this PR changes is the location the renderlayer ends up in the render layer list, that's it. So "technically" it shouldn't change anything(if mc wasn't buggy). The incompatibility with your mod is an issue with minecrafts vertex sorting messing up. Doing this order change here in 3d Skin layers may fix the rendering for your mod, but in turn, suddenly render the 3d skin layers above armor, held items, cosmetics from mods like essential etc. That's why I'm hesitant to do this change, as it might screw up a lot of other things(I sadly don't remember why I moved it to be added to the very end of the list by adding it later at runtime, maybe the commit back from 1.16? times has an issue related to it, idk). Thats why I don't want to merge something that would change the render order from 3d skin layers to everything else and potentially open Pandora's box of bugs. Sodium with CaffeineMC/sodium-fabric#2016 should render in the correct order I assume, no matter the order(since your mod isn't public from what I can tell, I can't test anything). |
Reason for Change
As expressed in a Discord thread, this mod, for some reason, would cause rendering issues for one of my mods which adds a feature renderer. The solution to the problem, as documented here and tested on the
1.20
branch, shows that injecting into thePlayerRenderer
constructor with the annotation ofwould, for some reason, cause my mod to have rendering issues. Changing it to
fixes the rendering issues.
Changes
Because I initially tested this on the
1.20
branch, I was not aware that themain
branch had a different method for adding theCustomLayerFeatureRenderer
. Upon looking at thePlayerRendererMixin
, theCustomLayerFeatureRenderer
was adding by injecting into Minecraft'sPlayerRenderer#setModelProperties
. The change log is as follows:Changed how the
CustomLayerFeatureRenderer
was added to the PlayerRenderer. Formally, this was done by injecting into Minecraft'sPlayerRenderer#setModelProperties
, but is now injecting into the constructor.There was a concern that "Somehow [injecting into the constructor to add the CustomLayerFeatureRenderer] in 1.16.5 is a bit unpredictable, [and that] only late adding layer works well," but my testing has shown there are no prevailing issues.