cPlugin_NewLua: why is it Lua-exported?
#11
(06-14-2012, 01:26 AM)xoft Wrote: No, Taugeshtu, those are actually the new plugins already. The old plugins are ones that are set in the settings.ini by Plugin=<name>, rather than NewPlugin=<name>. They have a completely different architecture, from what I can gather. I don't even think all the new hooks work in them. I certainly didn't write any glue code for that.

Taugeshtu is right though Smile

The old plugins don't need any glue code, that's what the metatable crap was for. The old plugins use some hacky way of inheriting and instantiating a cPlugin class. ToLua++ creates all the glue needed for that in a class called Lua__cPlugin automagically.

I first thought I could have Lua files that would contain multiple plugins. But that idea is pretty useless I noticed back when I created the new Lua interface. It's much easier and cleaner to have a single cPlugin instance per Lua plugin and stop trying to force C++ idioms to Lua.
Reply
Thanks given by:
#12
Quote:The old plugins are ones that are set in the settings.ini by Plugin=<name>, rather than NewPlugin=<name>. They have a completely different architecture, from what I can gather.
O, RLY?)

Take a look at the Area plugin. It's an old-style plugin:
Code:
-- create new unique global
AreaPlugin = {}
AreaPlugin.__index = AreaPlugin

-- some configurations
AreaPlugin.PLUGIN_NAME = "Area Plugin"
AreaPlugin.PLUGIN_VERSION = 3
AreaPlugin.PLUGIN_MSG_PREFIX = cChatColor.LightBlue .. "* "

-- some plugin locals
AreaPlugin.Players = {}
AreaPlugin.PlayerIdx = 0
..... BLAH-BLAH-BLAH ....
Get rid of that part:
Code:
function AreaPlugin:new()
    local t = {}
    setmetatable(t, AreaPlugin)
    local w = Lua__cPlugin:new()
    tolua.setpeer(w, t)
    w:tolua__set_instance(w)
    return w
end
Fix prefixes:
Code:
function AreaPlugin:OnDisable()
  -- write back file
  AreaPlugin.IniFile:WriteFile()
  
  Log( self:GetName() .. " v." .. self:GetVersion() .. " is shutting down..." )
end
One should also replace "self" with custom table variable that has Plugin as it's value (look at Core, PLUGIN variable)
Code:
function OnDisable()
  -- write back file
  AreaPlugin.IniFile:WriteFile()
  
  Log( PLUGIN:GetName() .. " v." .. PLUGIN:GetVersion() .. " is shutting down..." )
end
Remove that part too, as it will be done automatically:
Code:
-- create new instance of plugin
cRoot:Get():GetPluginManager():AddPlugin( AreaPlugin:new() )
Change GetWorld() (if it has no parameters) to GetDefaultWorld() and...
TADA! Now you have new-styled Area plugin.

Quote:I don't even think all the new hooks work in them.
Fair point. But when old-style plugins were written those hooks didn't even exist.

Of course, if plugin is REALLY old and don't have command bindings (it parses chat messages manually) you might want to update it to use commands (so commands would be visible with /help core plugin command!). But that's not requied for plugin to work.
Reply
Thanks given by:
#13
Well, in the end I managed to pry a hole in the virtual method hooks lua file so now AllToLua generates compilable code again, even for my callback Smile
So we can keep the old plugins a bit longer.
and FakeTruth got the 600th commit right in front of meTongue
Reply
Thanks given by:
#14
xD he didn't post a revision for about a month and then he commes with the 600th xD
Reply
Thanks given by:
#15
Oh sweet!! I didn't even notice XD
Reply
Thanks given by:
#16
Since I'm already cleaning up the API, I thought I'd remove the old-style plugins API with all their virtual method cruft.
Pity that I cannot remove all the references (yet), I'd really love to see the cPlugin and cPlugin_NewLua all gone from the API.
Reply
Thanks given by:
#17
Why?
Reply
Thanks given by:
#18
Why should a plugin need to know about its own object? We could make the API so that all functions work without knowing a single instance of a cPlugin. That would make the API a bit easier to grasp.

Internally, we could do that by defining our own global variable in the Lua environment and the API functions would read that variable if they needed the plugin object.
Reply
Thanks given by:
#19
I think they need it to call functions on other plugins though
Reply
Thanks given by:
#20
Hmm, true. But it's the only reasonable usage.
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)