Feature Description: For a long time now, dynmap supports SkinsRestorer plugin. Despite some people underestimating this integration, it's actually so so so so great!!! When running server in offline-mode, it provides integration into providing user's skin into web version of dynmap, making everything look nice and Steveless 😅. With the current look of code, that won't be true after March 16th, when SkinsRestorer updates onto v14 API. Due to the nature of SkinsRestorer updates, there is no way to avoid it, as even with auto-update turned off in config, SkinsRestorer often updates anyways. Please please please please, update this code. SkinsRestorer works all the way to 1.8 Spigot and they all run the same Auto-Update script, so most (if not all) of your users will loose this integration after March 16th. From what they say, it should be pretty easy update, including just renaming of some classes, but honestly, I am no programmer, so there might be complications I don't see and you do. Please, include this in one of your future updates.
Thanks <3

• Additional context:
• Disclaimer - I am no programmer at all and I have just a basic knowledge, take following with reserve
• SkinsRestorerAPI wiki and API Files
• Where you use skinURLProvider and getSkinUrl
• This is where you do stuff with SkinsRestorerAPI, needs update - here

I am actually working on it. I'll send PR soon. Just have to test compatibility.

Hey there, SkinsRestorer dev here.
We use an auto updater for our plugin, so issues will occur rly fast after set date March 16th
Changes can be found here in our example: https://github.com/SkinsRestorer/SkinsRestorerAPIExample/pull/1/files
If you have any questions, please let me know!
~ Skinsrestorer

@stepech I've been working offline for a while on asynchronous functionality for Dynmap and I was wondering if I could merge your changes into my branch so that we can knock out two birds with one stone once the time comes? Obviously I'll point out that you did that work, but I think it would be easier to have it all in one pull (I have a similar thing going on in the Overviewer repo).

hey, idk how much you know mikeprimm or not, or how big controll you have over the project, but contributing guidelines contain something regarding pushing as few updates in one pull request as possible, to make it easily editable/refuse just one feature at a time. There is also no real need to do it your way, as in the end, we both push into v3.0 branch and this way, mikeprimm has better control over it.
As far as I am concerned, I don't care as long as the update gets to the users in time. I don't care if someone uses my edits in their repos, etc, it's just change of 5 lines, anyone can do it. If you need these chnges in your branch, feel free to merge it, but be ready that if I have anything wrong, it will sink you too. Also if you get anything wrong, it will delay the whole update, and this needs to get approved pretty fast.

Yeah that's a good point, I forgot about that section in the contributing guidelines until after I commented so, no harm done.

Pull request closed, it will be delivered #3307