Cache SkinTextures instances & fix toggle menu #121
Conversation
|
|
...unfortunately, that was me! |
|
this expects the url to be null if the cape type is disabled, so I suggest moving isCapeTypeEnabled into the enum itself and checking if its enabled before getting the url
and this sometimes crashes the game if you disable a cape type while in multiplayer due to not checking if cape type is null |
|
I fixed the possible crash you were talking about. |
I don't see why it would. It would be just for convenience so you could call CapeType#isEnabled instead of isCapeTypeEnabled(CapeType), and it would also allow it to be called from anywhere (like on the setCape method) instead of just the one Mixin class |
|
If we block setCape, doesn't that prevent the cape from ever downloading at all? If that happens, then the toggle menu would have to re-download the capes. |
it should only prevent downloading capes that are disabled, like a simple return false at the beginning of the setCape method if the cape type its trying to set is not enabled |
|
If we block the capes from being downloaded, then the toggle menu would have to redownload them when we re-enable the cape type, as opposed to being instant. |
|
A little late, but now, capes will no longer be downloaded if the cape type is disabled, and |
|
I haven't been really able to work on modding recently due to some personal things, but I do plan on merging this eventually so don't worry about that |
In
MixinPlayerListEntry, rather than making a newSkinTexturesinstance each time skin textures are requested, we cache an instance of our modifiedSkinTexturesto supply. This requires us to refresh the list entry when we make a change (e.g. vanilla skin finished loading), which is handled inListEntryAccessor. Lastly, this also makes the toggle menu and client cape type update instantly in-game, instead of having to leave and rejoin. This also removes the bug fix inCapeFeatureRenderer, as this is now fixed in vanilla.