For$
<!-- begin site header -->
<div id=

Author Topic: Discussion and comments on the callback system i've been working on  (Read 6982 times)

Andrew

  • Developer
  • Newbie
  • ****
  • Posts: 9
    • View Profile
I've currently been restructuring the code so that the block functionality is abstracted and can be overwritten.
https://github.com/andrewfenn/mineserver

I already started the discussion in IRC but I want to continue talking about it in the forums so I have posted the relevant parts below.

Code: [Select]
<_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?

So where I am right now is wondering if what I talked about on IRC is an accurate description of how you envisioned it?  ;D