Uploaded image for project: 'Minecraft API'
  1. Minecraft API
  2. MCAPI-140

Client-side Modding Language (UI assets)



    • Type: New Feature
    • Status: Open
    • Priority: Normal
    • Resolution: Unresolved
    • Labels:


      I understand that it's barely API-related but hope it could be useful anyway. It's only general description, any additional information can and will be provided by request.

      Proposed Addition:
      Client-side modding by using custom, interpretable and fully sandboxed language. While it is most suitable for UI features, other usages are permitted.

      Specific Features:

      • Server says it's word about how client UI should look but then it may be changed locally to suite players preferences.
      • Various visual effects may be added locally.
      • UI assets will be composed from two parts: any markup like XML and small custom scripts to drive everything live.
      • Per server configuration to enable or disable some features.

      Justification and Use Case:
      Something like Lua could be used or even own language developed. World of Warcraft interface addons could be used as good example.

      It's possible to think about it as "UI assets" - some data that will be used by client to display something locally.

      • "Hello,World" examle:
        • Goal: display greeting message to every joined player.
        • Solution: plugin with simple UI asset.
        • UI asset: two files, first defines window for message itself and second makes this window functional.
          <window name="greetingWND">
            <label name="textLBL"></label>
            <button name="okBTN"></button>
          Hello.xxx (it's not lua)
          //registers event listener that will be called when player joins server
            UI.greetingWND.textLBL = "Hello, "+Player.name+"!";
          //another event listener
          //alternative form for UI event listener
          //more complicated event listener definition
            var oldListener = Player.onJoin;
            Player.onJoin = (){
              UI.greetingWND.textLBL = "Hello, "+Player.name+"!";
            Player.onJoin = (){
              UI.greetingWND.textLBL = "Hello, "+Player.name+"!";
      • Mod Examples:
        • Distance measurer. Additional UI window with text field and two buttons. First button sets starting position and second displays distance between player and remembered position. Access to player coordinates could be disabled by server.
        • Map and minimap, built from nearby blocks and saved in local storage or cache. Access to local storage and to blocks could be disabled by server.
        • Health bars for other players and names for mobs display. Access to entity properties could be disabled by server.
        • NBT-based entity display modification: textures and models for mobs, clan tags for players an so on. Access to NBT could be disabled by server.
        • (crazy idea inspired by comments) Ingame instruments for UI assets development, including text editors, preview and visual editors.
        • GUI for plugins like WorldEdit and WorldGuard. Using drawing engine and receiving custom messages from plugins could be disabled by server. (sorry I forget to put this link here MCAPI-216)
          WEGUI.xxx (it's not lua)
          onWorldEditEvent(Event e){
            etype = e.getField("type")
            if(etype = "addEffect"){
              model = e.getField("model")
              x,y,z = e.getFields("x","y","z")  // Multiple return, thing that I really like in Lua
              xs,ys,zs  = e.getFields("xs","ys","zs") //scale per axis for model
              affects.add( addEffect(model,x,y,z,xs,ys,zs) ) // adding model as visual effect and saving effect instance
            }else if (etype = "clearEffects"){
          //That's it - actual drawing will be performed by drawing engine, models will be downloaded as assets and server will instruct us what actual elements to draw. It's a bit simplified to save space.
      • Pros:
        • Additional flexibility to UI customization by plugins.
        • Additional way to safely customize client.
        • Custom complex controls are possible without any additional packet sent to the server in process as everything is done locally and only valuable result is sent.
        • Fully sandboxed from OS and partially sandboxed from game with additional possibility for server to disable access to some vital features.
      • Cons:
        • Hard to implement.
        • Another language to learn for mod developers.

      Challenges Faced:

      • It's not trivial to implement in general.
      • Various security vs usability cave-ins.

      P.S. all code samples are here only to demonstrate the idea, not to be a part of API proposal.


          Issue Links



              • Assignee:
                progfz23 Anton Sidorenko
              • Votes:
                5 Vote for this issue
                1 Start watching this issue


                • Created:

                  Potential Duplicates