The goal of the feature is to improve support for custom Minecraft auth, skins and capes API servers

More context about custom API servers

Custom API servers are used to provide more granular control over the authentication, skins and capes of players. This is usually achieved by using a tool known as authlib-injector, which is a java agent that replaces Mojang's API URLs with some custom values during runtime of the server/client. When a mod uses a 3rd party API provider - the authlib-injector fails to intercept calls to such APIs, causing the issue of auth/skins/capes not working as intended

The issue occurs when using Player Entity element with Copy Client Player set to true - the player skin will not load when using a custom API server. It would be really convenient to have some option (either in config or directly in the UI) to prioritize Mojang API over the currently preferred MineTools API

If you'd consider adding this feature, I could make a PR with the changes from a patched version of the mod I'm currently using

It should already use Mojang API as fallback when it failed to get the profile via MineTools, if I remember correctly.
I originally only used Mojang API for getting skins and that was just bad. It failed to get the skin so often I had to use a 3rd-party API again.

I think it is possible to improve the fallback logic then? I noticed that, in such a case, the minetools API fetches an incorrect UUID - resulting in the empty texture Map, may be it is possible to check whether the texture Map is empty, and fallback to Mojang API? But it is also possible that this behaviour is intended for accounts with no custom skin at all - I'll look into this further when home

As far as I understand the logic of fetching player's skin goes like this:

1. Fetch player's profile information by their nickname from MineTools API
2. Use player UUID from the fetched profile to get player's skin from Mojang Sessions API

The issue with authlib-injector can occur in 2 different circumstances:

• If the player uses the name that DOESN'T have a Mojang/Microsoft account associated with it - then the MineTools API will straight up return an error, but, as of now, we don't check whether the UUID is null, so the fallback logic won't run.

This can be fixed by simply adding a UUID null check after a call to MineTools API and fetch profile from Mojang's API if the check fails.

• If the player uses the name that has a Mojang/Microsoft account associated with it - then some UUID will be fetched. This UUID will not be the UUID from a custom auth server, since authlib-injector fails to intercept request to MineTools API, and thus, when we try to fetch the skin - the custom skin API will return an error, and the resulting texture map will be empty. There is a chance that the fetched UUID will be present on the custom server, resulting in a texture most likely from a different player - we can't determine if the fetched skin is correct or not, but the chances of two UUIDs matching are so astronomically low, that we can simply ignore this case imo.

This can be fixed by implementing extra fallback logic - fetch the textures with the provided UUID, if the resulting texture map is empty - fetch profile information once again, but with the Mojang's API, which will allow for authlib-injector to intercept the request and fetch the correct UUID, resulting in the successful texture fetch afterwards.

What do you think? If you are ok with the proposed solutions - I could make a PR for this issue, or you can implement it yourself if that's what you prefer