[Feature Request] Proxy Support

[yusshu]

Add support for Velocity and maybe Waterfall

Help is needed!
How should proxies be handled? The resource-pack is always generated in the backend servers, there may be backend servers that do not have resource-packs, servers that have the same resource-pack, and servers that have different resource-packs.

Something like BungeePackLayer is enough?

[yusshu]

Solution Proposal: Centralize Resource-Pack Generation

The Problem

In a network, we may want to, either:

1. Use a single resource-pack for the entire network.
2. Use a base resource-pack for the network but having some aggregates for specific backend servers.
3. Not using a resource-pack for the entire network, just for some specific backend servers.
4. Using a different resource-pack for every backend server.
   And currently, this is not something easy (or even possible) to do with creative-central.

The solution

Internally, we want to avoid doing the same process twice, so:

• If the resource-pack is the same for the entire network, we want to generate it only once and send it to players only once when they join the network.
• If there are backend servers with specific resource-packs, we want to generate them only once per backend-server (or per server group) and send it to players only when they join the specific backend server (or group), and clearing them when they leave it.
• If there is no resource-pack, do nothing.

Part of the idea is: backend-server-specific resource-packs will have the ability to have a "parent" resource-pack

To do this, we could move the resource-pack generation responsibility to a separate, stand-alone application or the proxy (letting the server administrator decide), called the orchestrator.

The orchestrator will have to:

• Know how to generate every resource-pack variant: This would require developers to make plugins that support our stand-alone application or the proxy platform, and the orchestrator API.
• Communicate with the backend servers: The configuration for the plugins and servers would be present only in the orchestrator application and not on every backend server. The orchestrator would have to send plugin and server data to specific backend servers.

For example, creative-glyphs is a plugin that adds custom glyphs and emojis for Minecraft servers. Adding support for proxies would require it to:

• Make an orchestrator plugin that would load the glyphs and emojis.
• Make a serializable class to represent the configuration that needs to be sent to the backend servers. (synchronization)

For example:

class Glyph {
    String name;
    byte[] texture; // <-- Here! Note that resource-pack-only information should not be sent
    String character;
}

class CreativeGlyphsSyncData implements SyncData {
    Collection<Glyph> glyphs;
}

class CreativeGlyphsOrchestratorPlugin implements OrchestratorPlugin {
    @Override
    void sync(File configFolder, ResourcePack resourcePack, ServerSync sync) {
        var glyphs = YamlGlyphLoader.loadAll(new File(configFolder, "glyphs.yml"));

        // write glyphs to the resource-pack when requested
        someMethodToWriteGlyphsToTheResourcePack(glyphs, resourcePack);
        
        // remove 'texture' data from glyphs
       removeTextureData(glyphs);

        // send the glyphs to the backend-servers
       sync.send(serializeGlyphsToByteArray(glyphs));
    }
}

It would be also necessary to configure the orchestrator to know which orchestrator plugins every backend-server needs, we can specify this via an orchestrator config file, for example:

# the plugins that apply for all backend servers
# (may be empty)
global:
  - creative-glyphs
  
servers:
    queue:
#      parent: none
      parts:
          - !creative-glyphs # exclude creative-glyphs
    lobby:
#       parent: none
#       parts: []
    tnt-games-lobby:
#      parent: none
        parts:
            - ultratntgamesplugin
    tnt-games-game-*:
        parent: tnt-games-lobby
#      parts: []

The orchestrator would generate the following resource-packs and would use them in groups, as it is easy to know what resource-pack variants to generate:

Server	Resource Pack Variant	Resource Pack ID
queue	<no resource-pack>	-
lobby	creative-glyphs	1
tnt-games-lobby	creative-glyphs + ultratntgamesplugin	2
tnt-games-game-*	creative-glyphs + ultratntgamesplugin	2

Note that tnt-games-lobby and any server starting with tnt-games-game- would have the same resource-pack and switching
between those servers wouldn't require a resource-pack refresh.

Advantages

• No duplicated processes, only the necessary resource-packs are generated
• Easy for server administrators

Disadvantages

• Plugins would have to be multi-platform (supporting the Minecraft server platform and the orchestrator platform) and be present in both backend-servers and orchestrator server.
• Time-consuming

[Yazerrr]

Overall, I'm very excited about the proposed solution for centralizing resource-pack generation! Combining all server resource packs into one makes perfect sense from an efficiency and player experience standpoint. Additionally, the idea of built-in resource pack validation is fantastic, catching potential conflicts before they cause issues.

Specifically, I'd love to see support for the following:

• Velocity Integration: Since that's what we use, seamless integration with Velocity would be ideal. Understanding how this would work with back-end servers and existing plugins like ModelEngine4, Oraxen, and Creative Glyphs would be helpful.
• ModelEngine3 Compatibility: Supporting both ModelEngine4 and ModelEngine3 would cater to a broader user base, as many still rely on the older version.
• One-Pack Convenience: Merging all server resource packs into one would dramatically reduce administration time compared to handling them individually.

While the multi-platform plugin requirement for plugins might be a hurdle, I think exploring alternative approaches to minimize development overhead would be beneficial. Perhaps providing clear APIs and documentation for orchestrator plugins could be a starting point.

I'm very eager to see this solution come to fruition and would be happy to provide further feedback on future iterations or even participate in testing if possible. Collaborating to refine this and make it accessible to both administrators and developers could be incredibly valuable for the Minecraft server community.

By addressing these points and focusing on user-friendliness and flexibility, I believe this proposal has the potential to revolutionize resource-pack management for server networks.

I hope this helps!