[1.7.10] Switching dimensions causes Alex skins to permanently be set as Steve until the client restarts
Roadhog360 opened this issue · 5 comments
Steps to reproduce:
Have an Alex skin
Enter or leave a Nether portal
You now have a Steve format skin and it stays that way until restart.
Irrelevant fix information
Suggested fix: My mod, Et Futurum Requiem does not have this issue. Consider borrowing some of my code. https://github.com/Roadhog360/Et-Futurum-Requiem/tree/master/src/main/java/ganymedes01/etfuturum/client/skinsYou want to look at ThreadCheckAlex and PlayerModelManager. I use a Boolean instance so I can have Null instances. The reason I do this is so we can have three states stored for a player's UUID, true, false or null, so we can only run the check when it's null, and setting it to either true or false, where true is Alex.
During the thread I put a false at the end to populate that UUID and prevent the check from running more than once, then when the thread is done it sets the value to true as needed. And there we go, the checks are complete and they will never run again until the client restarts, so go where you might, you're not gonna lose your Alex format!
Waffling
In ThreadCheckAlex I also check Mojang's website JSON data itself for checking if the skin is Alex. I know a handful of 1.7.10 mods check transparency on the player's shoulder to figure this out. This leads to inaccuracy as some Alex skins didn't always have these pixels transparent. I don't know if Ears does this, but if it does I recommend using my code for checking for the correct skin format instead. It's small, fast and doesn't require importing a newer version of the Mojang authentication library to get this data.
Ears does communicate properly with the modern Mojang API as well. In fact, Ears skins will force the unused-on-Alex-skin pixels to opaque with some of the forms of encoding it offers.
I believe this is a dupe of #45 — please include necessary debug information, such as a game log and what version of the mod you are running, instead of pointless waffling that makes bad assumptions.
You are right, I was on an outdated version. My friend compiled this as part of a small pack he made yesterday, so I would have assumed he was using the latest version, it was several versions out of date and this was already fixed. I really should have checked this. I do apologize for not checking the version or providing it, this is my fault. I didn't really know a skin format mod would input anything in the logs, that is an assumption I made, another mistake.
That being said, the only "waffling" was me proposing to use Mojang's API if you don't. Since you do, I guess that could have been considered "waffling", however I don't really understand ASM all that much so I didn't really know how to check for this. I have corrected the "waffling" assumption to correctly be placed over what was actually waffling as if this was still a valid report, it would be relevant information. Additionally, "on death" is not the same as switching dimensions, so even though it was the same bug in the end, I wouldn't have known that because these are two completely different ways of triggering it.
I will be closing this report as it's not valid. Sorry about that.
Dying and changing dimensions both result in recreation of the player object — a respawn. On-death and on-dimension-change bugs are often closely related if not identical, as a result.
It is slightly annoying to receive an issue report from a dev that, rather than providing debug information, makes various deep assumptions on how the mod works. It's also mildly disrespectful to say "use my code instead" — hence the reaction. I understand the temptation to say "here, this is something I know works, maybe you can integrate it" — but our projects are under incompatible licenses, and regardless, I already do essentially the same thing.
The original bug was caused by attempting to reuse 1.7's infant authlib to store information instead of maintaining my own cache, as it works now. In 1.7, GameProfile objects are scoped to the player entity, and a respawn partially destroys information added as attributes to the GameProfile. It's only partial because some parts of the structure are shared between instances (which is a thread safety problem of itself).
Yeah, I was just trying to provide pointers under a scenario where I had somehow wrongly assumed I was on the newest version. Somehow also just assumed a player model mod wouldn't do anything to the logs. I honestly don't really fully understand my thought process here.
Somehow also just assumed a player model mod wouldn't do anything to the logs.
For the most part, you're correct, but if Ears encounters an error it will go to the normal log. Internally, Ears is surprisingly complex and advanced due to how it's abstracted across versions and the way it bridges the modern and legacy rendering APIs. (Ears is internally complex enough that it spawned an entire mod loader based on its common framework.)
Ears even contains its own logging framework for verbose debugging information, activated via -Dears.debug=true (it will write to an ears-debug.log) and should you have been on the latest version, and there were no errors in the main log, I would have asked you to enable that and provide it.
However I don't really understand ASM all that much so I didn't really know how to check for this.
The relevant code is here: https://github.com/unascribed/Ears/blob/trunk/common/src/vlegacy/java/com/unascribed/ears/legacy/LegacyHelper.java
It doesn't involve ASM, and is used in the 1.7 port from https://github.com/unascribed/Ears/blob/trunk/platform-forge-1.7/src/main/java/com/unascribed/ears/Ears.java#L171-L181=
(Granted, Ears has a very tangled and atypical project structure due to the above notes. There are READMEs in various places to try to alleviate this somewhat, but it's complex nonetheless.)