Fork me on GitHub
  February 19, 2018, 09:47:44 pm
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  Home Help Search Login Register  
  Show Posts
Pages: [1]
1  Mineserver / Development / Re: A Proper Statistics / Detailed SQL Log System. on: December 14, 2010, 04:22:51 pm
pretty cool. will try it out some time later =)
2  Mineserver / Discussion / Re: Setting up admins on: December 08, 2010, 01:58:13 pm
Yeah currently any nickname (per line) followed by a # admins comment is registered as an admin, any nickname followed by "# ops" becomes an op and the same for members.
I know this is kinda suboptimal - we just discussed the config file format today on irc and it probably will change soon to be more flexible etc.
3  Mineserver / Development / Re: Coding Style on: December 07, 2010, 11:39:35 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'd prefer no prefixes as well, makes it harder to read imho. But I'm fine with using them if the majority demands it Cheesy

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..
if (obj)
  // insert many lines of code
  if (foo)
     // insert many lines of code
     if (bar)
       // insert many lines of code

A better way of doing the same thing
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.
Foo foo;
Bar bar;

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.
4  Mineserver / Development / Coding Style on: December 07, 2010, 01:12:26 am
Talked to Psoden today in irc and agreed that we need a coding style, immediately Smiley

Here's a proposal:
Comments welcome.
5  Mineserver / Development / Re: User permissions/groups on: December 06, 2010, 06:18:36 am
I talked to reductor about this. Mostly for performance reasons, you'll want to have the checks for the most common used permission levels be as fast as possible, since they might be checked upon touching every block.
I'll work on an easy way to extend it with custom permissions. For the most widely used permissions we have up to 32 bits (that just boils down to working with bitmasks and is quite fast), of which one is used for a "custom" bit, which indicates it's a custom permission (e.g. from a plugin or whatever) and so it will have to take a "slow path" for dealing with those (but more flexible of course).

Right now each available command can be assigned to a minimum level. I also thought about allowing custom groups etc. but that should be discussed as well I think. It could also be done via a plugin. Don't know if this is wanted in the core server.
6  Mineserver / Discussion / Re: Where to post bugs? on: December 05, 2010, 02:43:11 pm
I suppose it makes sense to keep the bugtracker centralized. Since you're using Github for your repository & forking action I suggest going with that?
Or what are the advantages of using redmine over Github issues? Most people looking at the code & contributing are probably looking at the Github issues list as well.
I know GH issues is pretty simple, but it works well for the common cases imho.
At least if you want to stick with redmine, we should somehow make sure people don't post issues in 2 places. Make a notice or something on Github (or disable it if that's possible).
7  Mineserver / Development / User permissions/groups on: December 05, 2010, 02:30:20 pm
I want to work on a permission system. Talked to ReDucTor about it on irc.
The idea was to have a certain amount of permissions/groups built-in with the option to allow custom permissions. The reason for the built-in permissions is speed, since we can use a simple bitmask for it and have a special bit be set for any custom permissions, which will then take a slow path for acessing/checking those. The reason is that permissions will most likely be checked on blocks being placed/destroyed etc. so having good performance there is essential for the common cases.

My question now is: Which permissions/groups should be provide built-in to the server?

Some suggestions: Guest (can't build/destroy things, just walk around and chat), Member (can build & destroy, chat), Operator (can teleport self & others, chat, give items, change user permissions up to Operator, kick, ban etc.), Admin (same as Operator as well as stop, start & reload server, change user permissions up to Admin, motd, etc.)
8  General / Off Topic / Re: Introduction, who are you? on: December 03, 2010, 03:40:09 pm
Hi, I found out about this a few days ago and gave it a try. Seems to have lots of potential =)

About me:

My name is Christopher Bertels.

- Location:
Osnabrück, Germany. Studying Computer Science & Philosophy.

- Server management experience
I've been running a server for me and 3 other guys for a couple of years.. Mostly web related stuff (php, mysql databases, ruby on rails sites etc) but also other stuff (teamspeak, minecraft etc)

- Programming experience
Got experience in: Ruby (very good), C++ (good enough I guess), C (same), Common Lisp (medium), php (little), C# (good), Java (medium) and some other languages

- Age (if you dare)
23 =)

- Possibly other hobbies
Mostly working on Fancy, a little dynamic programming language (running on the Rubinius Ruby VM) I created the beginning of this year.

Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!