+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Plugins (https://forum.cuberite.org/forum-1.html)
+--- Forum: Plugin Discussion (https://forum.cuberite.org/forum-8.html)
+--- Thread: Plugin Description (/thread-1291.html)
Plugin Description - ThuGie - 12-29-2013
Hey Guys,
I downloaded the hungry game package,
Just to see how it works,
But i noticed, its hard to figure out what each plugin exactly does,
Without reading the forum, and i should even hope the plugin is on the forum.
Would it be possible to get a info file in place ?
Like info.json where you can set name,description,version,author,website
It should not be forced cause of backwards compatibility.
If i download a plugin i can just read the info.json.
The plugin itself should also get access to the information.
To be able to print the name . version in console etc.
For version just string btw, so people can apply b/beta a/alpha etc.
Hope its possible.
RE: Plugin Description - xoft - 12-29-2013
I've long been trying to coax plugin writers to include a more detailed description for each plugin - not only a list of commands with brief (read: "cryptic") descriptions.
I like the idea of having a description file, but personally would prefer a Lua format - we write plugins in Lua, so why not put the description to Lua, too, so that it can be somehow processed by the plugin itself. For example if the description contained detailed descriptions of the implemented commands, the plugin could then generate its own info page (just like STR's WorldEdit does using an external script)
RE: Plugin Description - ThuGie - 12-29-2013
Hey,
Even if its in lua i think that's just fine, see no problem with it.
And yeah even the commands do need a proper information.
But if we could have a lua file that contains or a file that gets generated, that contains a proper description of the plugin in general, not just the commands that would be awesome.
RE: Plugin Description - NiLSPACE - 12-29-2013
The plugin I use for WorldEdit generates both the Github README.md and the forum main post. I did upload the plugin if others want to see how I did it. http://puu.sh/60Dbg.zip
RE: Plugin Description - xoft - 12-29-2013
STR, you could actually make it a part of WE, why not? Let it document itself; then you could include the detailed command descriptions or even as an in-game help for those commands (See how my Gallery plugin does just that for its subcommands: https://github.com/madmaxoft/Gallery/blob/master/CmdHandlers.lua#L593 )
I was pondering about having a repository for plugins - a web page that would store plugins with their descriptions, perhaps even comments from the users, and possibly even its own plugin that would allow MCS to check that webpage for updates. Somewhat like an "app store" for MCS plugins. But I'm no web developer, so it's out of my reach to make such a web; I could provide the hosting for the service, just like the windows nightbuilds.
RE: Plugin Description - SamJBarney - 12-29-2013
Well, after the Component rewrite is complete, I'll be able to work on that website like you asked, Xoft, and we could just make that a part of it.
RE: Plugin Description - NiLSPACE - 12-29-2013
(12-29-2013, 07:53 AM)xoft Wrote: STR, you could actually make it a part of WE, why not? Let it document itself; then you could include the detailed command descriptions or even as an in-game help for those commands (See how my Gallery plugin does just that for its subcommands: https://github.com/madmaxoft/Gallery/blob/master/CmdHandlers.lua#L593 )Intigrating into WE should be pretty easy.
About the command descriptions. Hmmm, I don't know.. My plugin works completely different then yours (or the APIDump). I use the cPluginManager::ForEachCommand function to document all the commands, and a table with some special cases (like commands without a permission string) that the plugin should edit. And I don't want to edit the command descriptions because I want to try to keep everything the same as the bukkit version.
As I asked here Could you make a list of commands where you think they need a better description? I could put them in the SpecialCases table. All the commands in there will override the default HelpString, Category, Permission.
RE: Plugin Description - xoft - 12-29-2013
I think it's easier to actually do things like I do - put all the commands in a table, with their handlers, permissions, help and anything else needed, and then use a simple for-loop to register the commands, another for-loop for printing the detailed help... Add another table around it, wrapping this into its Commands member, and adding a PluginDescription member, PluginName and PluginVersion, and you have exactly the info file that ThuGie wants:
g_PluginInfo =
{
Name = "MySuperPlugin",
Version = "0.1a",
Date = "2013_12_29",
Description = [[
This plugin is super, because it has a proper info file and everything!
]]
Commands =
{
Command1 = { ... },
Command2 = { ... },
},
}
RE: Plugin Description - NiLSPACE - 12-29-2013
So something like this?
g_PluginInfo =
{
Name = "WorldEdit",
Version = "0.1",
Date = "29-12-2013",
Description = [[]],
Commands =
{
Descend = {Command = "/descend", Permission = "worldedit.navigation.descend", Handler = HandleDescendCommand, HelpString = " go down a floor", Alias = "/desc" },
Ascend = {Command = "/ascend", Permission = "worldedit.navigation.ascend", Handler = HandleAscendCommand, HelpString = " go down a floor", Alias = "/asc"}
},
}
RE: Plugin Description - xoft - 12-29-2013
Yes. However, I think we should use the YYYY_MM_DD format for date so that it sorts naturally as a string. Also the command definitions are quite long, they should be split onto separate lines, and a detailed help for each command should be provided. On the other hand, you don't need the "Command = "/descend" part, because that is already contained in the dictionary key ("descend =")