1
Plugins / Re: The new Plugin API
« on: January 27, 2011, 12:38:05 pm »
It would be less work to simply port the plugins to c++
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
if (obj)
{
// insert many lines of code
if (foo)
{
// insert many lines of code
if (bar)
{
// insert many lines of code
}
}
}
return;
if (!obj) { return; }
if (!foo) { return; }
if (!bar) { return; }
Foo foo;
Bar bar;
foo->getName();
bar->getTitle();
setBlockCallback(BLOCK_OBSIDIAN, call);
<_Andrew> Apart from those things what do you think about how it's structured? Is it ok? I've made some pretty big changes to the codebase
<ReDucTor> some parts from that fast delgate c++ thing arent needed while be nice to cut it down
<_Andrew> I've tried to make it so that scripts can overwrite functions so when you add that it later it won't be difficult to do.
<ReDucTor> abstraction is good but always need to think out the overhead in worst case (heavy load) in base code
<_Andrew> definitely
<ReDucTor> we need to provide an interface to export (pass to plugins)
this should just be a struct with pointers to functions
using classes and functions inside a class is inconsistant
<_Andrew> Yeah, I didn't want to build the interface for plugins but since I needed something that was going to probably overwrite them I thought it best to go this way and then others can add the actual plugin stuff.
<ReDucTor> ya
i'dd suggest post proposed things on forum thread on minecraft forum thread we're using..a few plugin dev wanna be's ttthere
or here
<_Andrew> Can you fork a fork on github? Could use some help making the changes if you got time :D
<Fador> should be possible ;)
<ReDucTor> ya i can help tho i dont have enough time till a week latre
got holidays then
<Fador> =)
<ReDucTor> then productivity++
<Fador> Independence day at 6th day
<_Andrew> I hope I didn't step on anyones toes with the changes
<ReDucTor> na
dont ever feel that
<Fador> =)
<_Andrew> I'm more interested in abstracting the block related stuff out of packets.cpp rather then actually implementing the scripting stuff
<ReDucTor> any comments/suggestions i and anyone else (i hope) offer are suggestions in hopes to improve the project as a hole..
ya the whole blend between classes is a bit eww (no offence)
<_Andrew> You think it would be better just to group everything up into one class?
<Fador> non taken ;)
<ReDucTor> _Andrew, depends on whats in that class
<Fador> I know there's just too much stuff in for example block_placement function
<_Andrew> blend between classes as in the /blocks/* classes?
<ReDucTor> Someone shoudl do a UML of current then we can propose changes and create a UML and refactor for it
Doing plugin's per block, how likely is it that someone will want this? is it worth the overhead over someone just doing void onBlock(int blockid) { if(blockid != BLOCK_WHATEVER) return PLUGIN_UNHANDLED; ..... whatever.... return PLUGIN_HANDLED; }
most plugins which want block changes will be all / range of blocks
these checks could be performed faster by if statements in their code
one call, X conditions
compared to an entire loop checking what block has registered
<_Andrew> Well.. for example, what if you have a script that changes only the placement of wood objects
<ReDucTor> ffs notch's latest post no in english
<_Andrew> Say for example I want to make a quick script that allows me to place wood on the water but I still want the rest of block to have the same functionality.
<Fador> ReDucTor: he's saying something about hiring more people
<ReDucTor> Fador, already translated.
<Fador> ok ;)
* Fador was in swedish lessons just an hour ago
<ReDucTor> _Andrew, simply if(block != BLOCK_WOOD) return;
<_Andrew> Could you explain a little how you think it should be different because I'm having a hard time understanding. :)
<ReDucTor> I was thinking more call the onblock call backs, each has their own if(block != XXX) if they are specfic, and have a general / main one which has its own if(...) which the default method
<_Andrew> So for example.. onPlace (placing a block) it only checks if the placing block isn't for example wood then returns true or false?
<ReDucTor> you'd probably have a PLUGIN_HANDLED and PLUGIN_CONTINUE
PLUGIN_HANDLED would tell it to not continue processing PLUGIN_CONTINUE would move onto the next plugin
<_Andrew> What about when you have something that requires more then just true or false? For example say I want my wood block placed on the bottom of the ocean to float to the top?
<ReDucTor> return values could be customised to include PLUGIN_HANDLED + for specific callbacks which need a range of returns
<deoxxa> i'd think that something like that would return PLUGIN_HANDLED, then register itself to be run on the next plugin tick
<ReDucTor> however in your example i dont see where such a situatio would not need just PLUGIN_HANDLED and PLUGIN_CONTINUE
<deoxxa> and would continue to do so until it decided it was finished
<ReDucTor> PLUGIN_* would be in the call back functions
e.g. void onBlock(...) { return PLUGIN_HANDLED; }
then in mineserver code it would be void blockPacket(...) { if(plugins.onBlock(...) == PLUGN_HANDLED) return; .. do normal stuff here .. }
<Fador> should there also be somekind of a priority value for each plugin?
PLUGIN_HANDLEFIRST PLUGIN_HANDLELAST etc ?
otherwise they would just go on load order =b
<ReDucTor> Fador, that sorta thing should be done on loading
Fador, and prioritise there rather then in the function
<Fador> yeah..thats what I was thinking
<ReDucTor> we dont want sorting to occur per call
<_Andrew> So you're saying kind of the way I've structured it however the callbacks should return data to be processed rather then do the processing within them?
I don't really get the idea behind changing it to an on block process.. Do you mean in the function it would have something like if (status == startedDigging) { } else if (status == placeBlock) { } ?
Then you'd run through the whole thing on a per block callback rather then a per block + event callback
Is that what you mean?