Using the skin from SkinsRestorer, if there's no skin on Ely.by

[Brikster]

Currently Ely.by SkinSystem doesn't work correctly with Mojang skins. When skin is not found, it returns URL for the old version of Mojang API, such as "skins.minecraft.net/MinecraftSkins/%player%.png".

Most of offline-mode servers uses plugins for restoring Mojang skins: SkinsRestorer, Custom Skins Manager etc. They make request to Mojang API and get original skin URL, using network and CPU resources of dedicated server.

Now Ely.by authlib has the following algorithm (will describe partially simplifed):

• If profile recievied from server is empty: Library requests Ely.by skin from chrly. If there's no skin with such name in Ely.by database, client use broken Mojang link. In this case it's normal behavior, 'cause we can't now get skin from Mojang, if server didn't do that itself (#11).
• If recievied profile isn't empty (Profile name is different from player name) Library uses textures, provided by a server (skin restoring plugin). It allows to use something like "/skin set ".
• If recievied profile isn't empty (Profile name is equals to player name) In this situation, library requests skin from Ely.by. And if it's not found, client uses broken Mojang URL, received from chrly.

Since Minecraft launcher "TL" uses Ely.by skin system by default, all the players have broken Mojang skins on offline-mode servers even with installed skin restoring plugin.

Here we can see logs of Minecraft client: https://hastebin.brikster.ru/mocowewato.shell

My player with nickname Brikster has Mojang skin and it was restored by the server. Client got correct Mojang link with my skin texture, but finally chose broken Mojang link, that was returned by Ely.by's chrly.

Possible solution (until #11 will be completely solved): In the last case (when profile, received by client, isn't empty, and player name is equals to name of profile), we can request Ely.by skin from chrly. Then, if chrly replied, that skin is not found, we shouldn't use broken link to a Mojang skin. Instead of that we can use textures, that was provided by the server.

[erickskrauch]

Hello. Thanks for the well described issue :+1:

For internal reasons, the production of the Ely.by is now using Chrly 4.1.1-ely, which still uses outdated and broken links to Mojang skins. In subsequent versions, we have fixed it, but unfortunately, we can't use newer versions yet.

I really need to finalize the event_dispatcher_refactoring branch and fix https://github.com/elyby/chrly/issues/13 to migrate to the latest version of Chrly in our production.

I think I can do it in the next few days. Chrly will no longer use outdated and broken links for the unknown usernames. A little later we'll also restore the proxy of signed skins, so you won't need a skin restorer either.

[erickskrauch]

@Brikster, please check the behavior now. At the moment, the production uses the latest version of Chrly from the master, with all fixes, including the elimination of the old Mojang's API.

[Brikster]

Now on production:

And client gets null textures: https://hastebin.brikster.ru/uqirakivek.shell

[erickskrauch]

:thinking: Ok, I'll investigate it deeper.

[erickskrauch]

@Brikster, we had to roll back the latest version of chrly to 4.1.1-ely because it caused problems with the existing authlib implementation. We have made the necessary fixes and are waiting a week for the update to reach all users. Tomorrow we'll enable the latest version again which will solve the problem.

[erickskrauch]

@Brikster, for now, all TL users should already receive the update. Please check your cases. Everything should work exactly as you described.

[erickskrauch]

I'm gonna close this issue. If there's still a problem, please let me know.