1.15.2 Refreshing skull textures

Discussion in 'Spigot Plugin Development' started by dejvokep, Feb 4, 2020.

  1. Hello,

    I'd like to ask how (for example big) servers deal with refreshing skull textures, which are used in inventory menus... By refreshing I mean querying the Mojang website. I thought about a class with map to save the textures by UUIDs and then:
    • If unsaved UUID's texture requested, query the website asynchronously and when it will be ready, insert it in e.g. inventory.
    • If saved UUID's texture requested, respond with the saved texture.
    • Refresh the full Map every X hours (every texture saved in map).
    However, Mojang API has some request limit per hour ...EDIT: 600 requests/10min, but in the Skin/Cape section is: ,,This has a much stricter rate limit: You can request the same profile once per minute, however you can send as many unique requests as you like." - does the 600 request limit apply for this?... , how to deal with this? Anyway, is this approach good?

    Thank you!
  2. What I do is I load them once, and then store them. And from then on just load them from the stored data on every server restart. And why would you need to refresh them anyway? afaik, if someone changes their skin the data Mojang gives will stay the same, and you would only have to update it client-side.
  3. Some servers store them directly onto their web server.
  4. Are you sure that it doesn't change? It doesn't make sense then, when you are setting the GameProfile Property, you need that base64 string... I assume that string gives the information about pixels of the skin - please correct me if I am wrong. But if this doesn't depend on the string, how the server knows how the skin looks?

    Yes, so they save it for use in the future.
  5. Yeah now you say it, that could also make sense. But refreshing everything every hour also seems a bit overkill. You could just refresh everything Async maybe once per day if you really need. But that would still be a lot of requests if there are many skins.
  6. Yes, I know, it was just a example :D Now, when we know that skins need to be refreshed (players may change their skins), does the 600 request limit also apply for skins (and capes), if there's written that you can send 1 request per minute to request certain profile, but you can make as many unique requests as you want?
  7. Bump

    Does somebody know how the limitation works here?
  8. To my understanding, the rate limit is applicable per server, regardless of the user you are trying to retrieve information for. So in your case, say you have a list of 700 skins that you're trying to refresh. You wouldn't be able to do it all at the same time, even async, because you're trying to refresh more than 600 within 10 minutes. I would probably just invalidate the cache after a certain amount of time, a day after it's loaded in or something. Then the next time you need to use the information, it would return the cached value for that time (assuming you need it now and can't wait for an async call to update it) and then asynchronously update the cache to whatever possible new value might be out there.

    This allows you to update your cached values as they are needed, instead of all at once and shouldn't cause any problems with rate limits.

    EDIT: Upon further examination of the documentation, it is 600 requests every 10 minutes for any requests. Not just skin requests. The rate limit on skins/capes is 1 request per profile per minute. That being said, you could request 600 different profiles per minute. But the above would still apply.
    #8 Travja, Feb 6, 2020
    Last edited: Feb 6, 2020