Description
Minecraft supports sending resource packs to the client on join, allowing servers to get clients to load a resource pack for their custom content. This issue was going to be a long and lengthy dissecting of the problem of NeoForge collecting, merging and hosting server side resource packs, however after some code analysis and wiki reading most of this isn't required (multiple packs can be sent, and merging can be handled by the client provided mods aren't dumb).
What is still required is the hosting of packs. The packs are sent to the client in the form of URLs to download the pack from, and the client checks if the URL protocoi is http or https (so no base64 encoded packs sent through data://, sorry).
It would be great if NeoForge could provide an API to allow these packs to point back at the server who sent them, and the server provide the packs directly. This is going to be increasingly useful as vanilla moves to data-driven resources that need both a client and server component.
This would require a few things:
- A minimal system to reply to http packets requesting a resource pack. This could be a tiny web server (ie latvian-dev/tiny-java-server), or just a minimal custom setup using the built in java api to only respond to this one type of packet. Java also has one built in: https://docs.oracle.com/en/java/javase/17/docs/api/jdk.httpserver/module-summary.html
- Server hosts to open another port for these packets to go through. This is the only thing Neo cannot control, and unfortunately removes a bit of the 'it just works' magic.
- A system to allow server owners to host the packs themselves, in case they want to reduce bandwith to the main server. This requires being able to export the packs and swap the URL Neo sends for each pack.
- A system for mods to register packs (extension to AddPackFindersEvent?) to be hosted and sent to client.
- Sending a URL for the server requires the server knowing it's own IP address so it can direct clients back to itself. This requires some external service to tell the server it's public IP address, such as https://www.ipify.org/. A sneaky catch here is also that the server can have up to 6 ip address depending on the client connecting (one for ipv4 and ipv6 for each of localhost, local network and public), however this is easily solved by having the respond in kind to the client's IP (ipv6 public ip —> iv6 public ip, ipv4 private use ip —> ipv4 private use ip).