Cuberite Forum
Plugin Description - Printable Version

+- 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)

Pages: 1 2 3 4 5

RE: Plugin Description - NiLSPACE - 12-29-2013

But there are commands that use two "/" like //set BlockType.
I was thinking. I could also set all the commands in categories in the file itself. Like: 
Navigation =
{
   Descend = {
      Command = "/descend;/desc"
      etc...
   },
   etc...
}

Region = 
{
etc...
Maybe we also need a plugin that generates a html page from these tables.
Oh wait.. the call function doesn't parse tables ;(
Wait! Maybe we can use the loadstring function for that.

RE: Plugin Description - xoft - 12-29-2013

We don't need a separate plugin for that, we can make a source file that will expect this table to be called g_PluginInfo and will export them. Easy.
As for the doubleslash commands, even that is possible, although it looks a bit worse:
Commands =
{
  ["/set"] = { ... }
}

I think the categories should be a "member variable" for each command; this way a command doesn't need to be in a category, or could be in multiple categories at once; the exporting code would take care of that. And the categories could get a separate description, too:
g_PluginInfo =
{
  ...
  Commands =
  {
    descend =
    {
      Category = "Navigation";
      Permission = "..."; ...
    },
    ...
  },
  CommandCategories =
  {
    Navigation =
    {
      Desc = "Commands in this category will teleport a player to various important places";
    },
    ...
  },
};


RE: Plugin Description - NiLSPACE - 12-29-2013

xoft Wrote:although it looks a bit worse:

Yea that doesn't look pretty Wink

xoft Wrote:I think the categories should be a "member variable" for each command; this way a command doesn't need to be in a category, or could be in multiple categories at once; the exporting code would take care of that. And the categories could get a separate description, too:
That's a good idea Smile
I created a branch where I'm now working on the new way of binding commands. Gonna work on the categories but I'l have some coffee first Smile https://github.com/STRWarrior/WorldEdit/tree/Better_Description

RE: Plugin Description - NiLSPACE - 12-30-2013

Ok Categories implented. Smile

RE: Plugin Description - xoft - 12-30-2013

Very well, I'll write the same thing for Gallery and then write a processor that will use such a table to produce the documentation.
You are still using the explicit commands, is that really necessary?
Hmm, we have a problem. Gallery allows the server admin to select their own command prefix, so the command names are not exactly known.

RE: Plugin Description - NiLSPACE - 12-30-2013

How were you planning on doing the processor. I started on it, but then we had dinner. Maybe you had a different approach in mind:
m_PluginManager = nil
m_Plugin = nil
m_ShouldReload = false

function Initialize(Plugin)
	m_Plugin = Plugin
	Plugin:SetName("DocumentPlugin")
	Plugin:SetVersion(1)
	
	m_PluginManager = cRoot:Get():GetPluginManager()
	cPluginManager.AddHook(cPluginManager.HOOK_TICK, OnTick)
	
	return true
end

function OnTick()
	if m_ShouldReload then
		m_PluginManager:DisablePlugin(m_Plugin:GetName())
		m_PluginManager:LoadPlugin(m_Plugin:GetDirectory())
	end
end

function DocumentPlugin(Plugin, FileName)
	local Folder = Plugin:GetLocalFolder()
	dofile(Folder .. "/" .. FileName)
	
	-- Process the g_PluginInfo table

	m_ShouldReload = true
	return true
end
I'm still using the explicit commands because I can now easily create aliases. Or should I do it like 
["/ascend"] = 
{
   Alias = "/asc",
   -- etc
},
instead of
Ascend =
{
   Command = "/ascend;/asc",
   -- etc
},


RE: Plugin Description - xoft - 12-30-2013

I'm writing the processor not as a separate plugin, but rather as a set of files that can be copied into any plugin and that will document that plugin.
I've started with the generic command registrator that will register all commands and subcommands based on the info in g_PluginInfo.Commands. I think it's getting close to being usable, so I'll commit it very soon to the Gallery plugin, if the net connection permits - I'm on a train back home.
I was planning on making a special variable available in each command, called Alias, which could be either a single string (for a single alias), or an array table of string for multiple aliases:
Commands =
{
  ascend =
  {
    Alias = { "asc", "a", },
  }
} ;
It fits better into the scheme of subcommands ("/gal info" etc.)

RE: Plugin Description - NiLSPACE - 12-30-2013

(12-30-2013, 04:33 AM)xoft Wrote: I was planning on making a special variable available in each command, called Alias, which could be either a single string (for a single alias), or an array table of string for multiple aliases:
Commands =
{
  ascend =
  {
    Alias = { "asc", "a", },
  }
} ;
It fits better into the scheme of subcommands ("/gal info" etc.)

Oh then I'l edit my table.
I implented it. Smile

RE: Plugin Description - xoft - 12-30-2013

With all those superfluous slashes in the commands, I decided that the full command name will be the key to the info table. I've already changed WE's info table, I'm now working on the dumper.
I decided to flatten WE's folder hierarchy to simplify loading the plugin. You won't be pleased with how much I've moved stuff aroundTongue

RE: Plugin Description - NiLSPACE - 12-30-2013

I guess all I can do is waitTongue