Information standard formatting

[hugeblank]

So, in aaa9c41f86263c536d24e8595ff14993fee9cfcf I updated the information standard format to be as follows: For a command with a usage of "!help [plugin id | command tag | page number] [page number]":

local helpInfo = {
  generic = "Demo help command",
  plugin = {
    optional = true,
    generic = "Plugin ID",
    page = {
      optional = true,
      generic = "Page number"
    }
  },
  command = {
    optional = true,
    generic = "Command tag, Ex: (!allium:help)",
    page = {
      optional = true,
      generic = "Page number"
    }
  },
  page = {
    optional = true,
    generic = "Page number"
  }
}

Where: generic is the information of the parameter optional is a parameter that is completely optional (An example of this is a page number, see above.) noclick is a parameter that is required, but not specifically the name of the parameter. (An example of this is when the parameter is a username. You can't just plonk a username in.)

By default parameters can be clicked on to automatically load them into the chat input, thus the need for the optional and noclick tags.

Here is a demo of the table in action:

There is a lot of repetition going on here, and I'm wondering if anyone could propose a better method to write this information, preferably one where a usage string could be derived.

(And yes I know the example could be simplified like this):

local page = {
  optional = true,
  generic = "Page number"
}
local helpInfo = {
  generic = "Demo help command",
  plugin = {
    optional = true,
    generic = "Plugin ID",
    page = page
  },
  command = {
    optional = true,
    generic = "Command tag, Ex: (!allium:help)",
    page = page
  },
  page = page
}

[hugeblank]

I've had a thunk or three about this and I came up with an improvement. generic is totally not necessary, it could just not have a key associated to it, and be seen as [1] within the table. This is the only tag that makes sense to remove, since it's used so often. Meta tags like optional and noclick will stick around. I think.

This is what the demonstrated table (uncondensed) would look like without the generic tag:

local helpInfo = {
  "Demo help command",
  plugin = {
    optional = true,
    "Plugin ID",
    page = {
      optional = true,
      "Page number"
    }
  },
  command = {
    optional = true,
    "Command tag, Ex: (!allium:help)",
    page = {
      optional = true,
      "Page number"
    }
  },
  page = {
    optional = true,
    "Page number"
  }
}

...you probably could have visualized that without this demo.

This revelation has been pushed to the unstable branch, however this RFC still stands. Better exists, I just have yet to come up with it.

[hugeblank]

After doing a bit more tweaking and work, I pushed 647c257affdb3fb79c2cf066e82d3727e09e342f a couple of days ago. This brings several changes which I cover in the Unstable documentation of the wiki. I will reiterate here:

• optional is for when you want the parameter to be identified as optional. Optional parameters have square brackets around them in the UI. For example, the 'page' parameter for Allium's help command is always optional no matter where.
• clickable is for when you want/don't want the parameter to be placed into the suggestion bar and run the next parameter query. The default value is true, it is not mandatory to add this unless you specifically don't want the parameter to be clickable. For example, if the 'page' parameter was clickable and the user clicked on it, the word 'page' would be appended. This is undesired, so we set clickable to false.
• infill is for when you want to present a preset variety of options that at the time of running the command you don't know. These could be anything from users to commands, to your own options. Infill takes a variety of inputs:
  • "username": Generates a UI listing all of the online users
  • "plugin": Generates a UI listing all of the plugins that got successfully loaded
  • "command": Generates a UI listing all of the commands with their plugin name prefix. This does not prepend an '!' to the command.
  • table: Takes a table of strings and converts it to a list of options for the user.
  • function: Runs a function provided to get a table of strings. Converts this table in the same manner that the table option above does Infills provide a dynamic capability to your command that is nigh on uncomparable to Minecraft's own vanilla functionality. An example of this can be found in Allium's help command 'plugin' and 'plugin:command' parameters. 'plugin' simply uses an infill to list the plugins loaded, and 'plugin:command' lists all commands.
• default is for when you don't necessarily want an infill for a parameter, but would like it to provide something

[hugeblank]

Going to close this now since I think the format is as good as it will get. If anymore revelations occur to me, depending on the severity of them, I'll be sure to either reopen this discussion or open a new one