Messages

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

2

Development / Re: Coding Style

« on: December 07, 2010, 08:19:39 am »

I personally don't see the point behind using outdated hungarian notation by putting m on all the member variables.

Both Microsoft and Bjarme Stroustup recommend against it and that's enough for me. We're not coding in C and need to keep check of if our variables are "members" of our "class"

this->m_foo.. you already know it's a member of the object you're calling.

I also suggest putting brackets on all if statements as it's very easy to create a bug by proxy of someone else editing your code. The only reason no one really does is simply laziness (myself included).

I think the most important thing however is the way people write code and the names they use for methods. I think it's more important then general syntax and how many spaces an indent is.

A bad example with difficult to read code..

Code: [Select]

if (obj)
{
  // insert many lines of code
  if (foo)
  {
     // insert many lines of code
     if (bar)
     {
       // insert many lines of code
     }
  }
}
return;
A better way of doing the same thing

Code: [Select]

if (!obj) { return; }
if (!foo) { return; }
if (!bar) { return; }
A bad example with method naming simply because everyone uses a different name for getting similar data across classes.

Code: [Select]

Foo foo;
Bar bar;
foo->getName();
bar->getTitle();
My personal experience is that when working in teams the previous two examples are much more important then making sure everyone's syntax is similar.

3

Development / Re: Potential OpenMP support?

« on: December 07, 2010, 07:37:56 am »

You could easily make all the callbacks multithreaded as long as functions to Map were thread safe. I believe it would involve making sure you're not trying to read and write to the same block at the same time.

4

Development / Re: Some more admin functions

« on: December 03, 2010, 12:36:15 pm »

If you can build the code then you can remove the following line from plugins.cpp

Code: [Select]

setBlockCallback(BLOCK_OBSIDIAN, call);

5

Development / Re: Version in Config.

« on: December 03, 2010, 10:40:23 am »

Ah, I misunderstood you. I thought you meant having the ability to change the version number in the config file.

6

Development / Re: Glass disappearing

« on: December 03, 2010, 10:39:02 am »

Both problems are now fixed in my branch. They should be pulled into Fadors branch later on today. 

7

Development / Re: Version in Config.

« on: November 29, 2010, 06:34:05 am »

You mean announcing the server version number in chat when someone joins? Right now the server version number is already placed in the code. When running the server it will tell you which version you are using.

I don't think putting it in the config file is such a good idea because people might upgrade their server without upgrading their config file but perhaps announcing it in chat when a player joins is a good idea.

8

Development / Re: A Proper Statistics / Detailed SQL Log System.

« on: November 29, 2010, 06:21:22 am »

I think this is a very good idea for a plugin but I wouldn't really like it put it in vanilla personally as it complicates testing / fixing the base server. Good news is that I wouldn't be hard to write as a plugin.

9

Development / Discussion and comments on the callback system i've been working on

« on: November 26, 2010, 02:17:35 pm »

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?