DiscordSRV

DiscordSRV

86.8k Downloads

SkinRestorer/offline skin support

dadcuy opened this issue ยท 6 comments

commented

Hey developers first of all thanks for building this amazing service for us can you guys add a way to show offline players skin or any player skin that would be great thanks and sorry if i did something wrong to post this here i am new to github

commented

Not possible.

  1. No publicly available endpoint for skins
  2. Assuming 1 is no longer true, there is no publicly available endpoint for helms, only the full skin
  3. Assuming 2 is no longer true, this is already possible by adjusting your avatar URL accordingly
commented

Came here to ask the same thing, looks like they're working on it in their api according to this open issue. Hopefully sooner than later as I have GeyserMC players, would be nice if we can get their skinrestorer skins skulls shown in the discordsrv pics. :)

SkinsRestorer/SkinsRestorer#182

https://github.com/SkinsRestorer/SkinsRestorerX/wiki/SkinsRestorerAPI

commented

Hey @Scarsz ,

After some digging i noticed that Dynmap was able to do this , i've tested it at least with GeyserMC players and as you may know GeyserMC players using Floodgate won't have any mojang approved java UUID/usernames yet Dynmap can grab the player's avatars with skinrestorer skins. Even my own Java Players avatar heads are updated to whatever skinrestorer is using in Dynmap.

Not sure if this is apples to oranges with Discordsrv or maybe im misunderstanding something but i did find the original commit for this work , hopefully it helps.

https://github.com/webbukkit/dynmap/commit/578c66e2fe6de9e83f9e9ad1b8508a1def97aae1

This is in Dynmap's configuraiton.txt section, thought it may be helpful.

# custom-colors-support: if true, Custom Colors in texture packs is enabled (default)
custom-colors-support: true

# Control loading of player faces (if set to false, skins are never fetched)
fetchskins: true

# Control updating of player faces, once loaded (if faces are being managed by other apps or manually)
refreshskins: true

# Customize URL used for fetching player skins (%player% is macro for name)
skin-url: "http://skins.minecraft.net/MinecraftSkins/%player%.png"

# Enable skins via SkinsRestorer plugin instead of internal legacy implementation (disabled by default)
skinsrestorer-integration: true
commented

Hey Scarz,

Thanks for the reply man , i appreciate your time. Forgive me as im no a java guru, im a systems engineer so im more on the IT systems side of things then a programmer, but i know enough to be dangerous and kinda sound like i know what im talking about ... sometimes XD.

Anyway I sent this ticket at like stupid late at night so i forgot to include the second part which is how I think dynmap handles getting the player's heads after getting the skin from skinrestorer.

https://github.com/webbukkit/dynmap/blob/578c66e2fe6de9e83f9e9ad1b8508a1def97aae1/DynmapCore/src/main/java/org/dynmap/PlayerFaces.java

There seems to be some momentum in either crafatar or Skinrestorer that might make this easier in the future. If you noticed i link a mention from this ticket to Skinrestorer's github themselves here's what the dev responded with.

image

So it looks like they are working to making it easier so there's less heavy lifting on 3rd party plugins to get this kind of data. No eta obviously but sounds like they want to do it. Maybe we can collab to make sure whatever they're developing will work well for Discordsrv in the future?

I believe skinrestorer uploads the texture for the custom skin via dummy profile for java as they do exist in https://api.mojang.com/users/profiles/minecraft/usernameorUUID. For example Skinrestorer creates a custom file with a .skin file type that encodes the string in a base64 format and has the following information, very similar to what getting profile info is from mojang.

{
  "timestamp" : 1613440348380,
  "profileId" : "7382ddfbe485455c825f900f88fd32f8",
  "profileName" : "Ioyal",
  "signatureRequired" : true,
  "textures" : {
    "SKIN" : {
      "url" : "http://textures.minecraft.net/texture/194b9b428c1b76e72e85fc7081060496bac520a479fb52dd016d5766185cea7f",
      "metadata" : {
        "model" : "slim"
      }
    }

If you go to the textures url its to a custom skin that i had uploaded but if you try to get the profile's skin "loyal" it'll show up completely different from mojang api.

I think that http://textures.minecraft.net/texture/ is what xknat is referring to exposing in his statement.

the .skin file for example:
shawty.zip

Also a better detailed process of this by Skinrestorer themselves:
Custom-Skins#skinfile-generator-for-dummys

P.S. Thanks for your time again, really enjoy what you and your team are doing with Discordsrv , adds a lot of value and community building. I appreciate the hard work man. Anything i can do to help test or make it better lmk.

commented

While that's certainly something to reference if this ever does get implemented, on its own this isn't helpful for the reasons I mentioned originally.

Even if the SkinRestorer plugin itself has a Bukkit API to get the skin data, that does nothing to help Discord receive those skins. It has to be a publicly available (to the entire Internet) endpoint. Not only that but it needs to also provide a method for getting only the head/helm & not just the entire texture.

There's an open issue for Crafatar to render heads for a given texture by ID which would be greatly helpful but there's no telling when/if that will be added. crafatar/crafatar#54

commented

I did a bit of searching and found that https://mc-heads.net/ actually supports using Minecraft texture IDs to render avatars. I don't really have any experience with it, so I can't say if it's reliable or not.
I set up the following AvatarUrl and it works perfectly with GeyserSkinManager and presumably any other plugin that modifies player skins, like SkinsRestorer: AvatarUrl: https://mc-heads.net/avatar/{texture}/{size}.png
For others looking to try this out: you'll want to be running the latest DiscordSRV development build, because c695e98 fixes an issue I found during testing where the {texture} value wouldn't work for non-'slim' skins.