unnamed / creative-central

The resource-pack unifier for Minecraft: Java Edition
https://unnamed.team/docs/creative-central
MIT License
18 stars 6 forks source link

[Feature Request] Proxy Support #3

Open yusshu opened 11 months ago

yusshu commented 11 months ago

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 commented 11 months ago

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:

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:

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

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 \ -
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

Disadvantages

Yazerrr commented 9 months ago

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:

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!