This plug-in requires a server resourcepack to work completely. Currently, we ask each individual user (server admin) to manage their own hosting and we recommend dropbox for this. This has lead to countless support requests on the discord server (the resource-pack-url is not a direct download url, the resource-pack-sha1 is not filled in, which would prevent minecraft clients from updating it...). Thus, it would be great if we could make our own hosting solution (and make it easy to use).

When we would manage our own resourcepack hosting, there are generally 3 problems:

• We need a webserver that runs 24/7 and can dynamically accept new resource packs. This will probably cost us money periodically.
• This webserver will have to accept resourcepacks from all our users. So, the more people use this plug-in, the heavier the load will be. More load generally means more money, so the more people use our plug-in, the more we have to pay.
• This resourcepack host would be a single point of failure: when the resourcepack host is overloaded or attacked, all servers using this plug-in would suddenly lose their textures.

The best idea that comes to my mind (even though it suffers problem the problems mentioned above) is to create a new minecraft plug-in whose only task is to manage the server resourcepack. The flow should be like this:

1. The server admin installs the resourcepack plug-in.
2. The server admin puts the resourcepack (generated by the Editor) on the server file system (probably plugins/ServerResourcePack folder). Note: this might not work on Aternos servers because they don't allow uploading binary files. We might have to provide a similar hexadecimal work-around as we use for .cis files.
3. Upon start-up, the plug-in would inspect the resource pack and check for mistakes (invalid zip, missing pack.mcmeta, missing custom items folder, json syntax errors...). If the resource pack seems ok, it will send the resource-pack and sha1-hash to our webserver. (The plug-in can just compute the hash.)
4. The webserver replies with the url (and will send the resourcepack to anyone who sends a GET request to that url).
5. The plug-in would then do one of the following (which option to choose has to be decided in the future):

• Edit the server.properties and insert the resource-pack and resource-pack-sha1. This will only work if the server would read the server.properties after loading the plug-in, but I'm not sure this really happens.
• Use the Bukkit API to send the resource pack url to the players.

6. The plug-in sends a ping message containing the url to the webserver every 10 minutes.
7. The webserver deletes any resourcepack that hasn't been pinged for 15 minutes. Thus, unused resourcepacks won't occupy disk space and the disk space usage won't keep piling up...

This idea has the following benefits:

• Little work to do for server admins: just install the plug-in and put the resource-pack on the server filesystem.
• No more sha1 or url issues ever.
• It can automatically check the resource pack for errors. (It has occurred multiple times that people fetched random resourcepacks from the internet rather than the one made by the Editor, people occasionally make syntax errors in custom models...)
• It can also be used for regular server resourcepacks.
• Unused resourcepacks will be cleaned up automatically.

Follow-up ideas: get rid of the .cis vs .cisb distinction: users only need .cisb files and put that in plugins/CustomItems. The custom items plug-in would extract the resourcepack from the .cisb file and communicate it with the resourcepack plug-in (which we could even bundle with the custom items plug-in). This would also ensure that it is no longer possible that the .cis file is not in sync with the resourcepack and would make the admins work even easier.