• 0

    posted a message on OpenCraft Alpha 0.1 Release
    Hey guys!

    After installing sun-java6-jdk and sun-java6-jre and running ant, this will launch the server:

    run.sh:
    #!/bin/sh
    java -Xms512m -Xmx1024m -cp bin:lib/mina-core.jar:lib/slf4j-api.jar:lib/slf4j-jdk.jar:lib/xstream-core.jar org.opencraft.server.Server
    Posted in: Mods Discussion
  • 0

    posted a message on On Griefers - The Player's Predicament
    Oh, Notch doesn't want us to? I guess I won't do this then out of respect for him, but it's kinda sad to see the maker of the game refusing to let us help him make it better.

    Still, of course he has the right to do that. This isn't exactly an open source game after all.
    Posted in: Server Support and Administration
  • 0

    posted a message on On Griefers - The Player's Predicament
    Hmm. Seems like the current solutions are either "this would be too slow so I'm not going to even try" or "this doesn't exist yet but really should."

    I don't think it would take very much ram, would it? How big are the levels? 1024×1024? The blocks are one byte which means that's 1MB to store one revision of the level. Storing everything as history attached to the player (where every change is one byte for the block plus two bytes for the player ID, I don't know if java is this efficient) means that even if they change every single block in the level 10 times, that would be about 30MB.

    Firefox right now is hogging up 530MB and pidgin is taking 150MB.

    As for speed? I don't think appending something to a list for each chunk update takes all that much effort. Then again, I don't really know how much bandwidth reverting a large change would take...

    The server doesn't look too complicated. Thanks for the link, erronjason. I'll look into this when I have some free time.
    Posted in: Server Support and Administration
  • 0

    posted a message on On Griefers - The Player's Predicament
    Hello, everyone. I'm gcr. Feel free to mercilessly make fun of me; I'm just a n00b, but perhaps it is this unfamiliarity that affords me to see things from a different perspective.

    I see a problem with this game, particularly in the multiplayer part. Perhaps you know what I'm talking about. Griefers. They mess stuff up, flood caverns, construct rude shapes. I just visited a server where someone used automated tools to turn every 5th block into a sponge. Once that happens, there's nothing players can do but manually go and fix everything by hand.

    What are our current tools for dealing with griefers? Currently, we exclude people. We build spawn jails to confine them to certain parts of the map. We kick them after they do their dirty work. We constantly police the server, so much that admins are so busy keeping people in line that they can't have fun building things themselves. In fact, we've put so much effort into tuning these weapons of administration that there are custom servers floating around that automate these precise things to a frightening degree. It's all I can do to build enough trust to even be let out of the jail cell, let alone get kicked right when I join a server. As a new player, knowing I'm not wanted is excruciatingly annoying.

    I think we're attacking this the wrong way. Griefers aren't the real problem: they're just a symptom. The real problem is that the map is immutable, and once a change happens, there is no undo. Should we compensate for this by kicking people out and letting no one in? Or should we build an undo button?

    Here's what I'm proposing: Let's take a cue from revision control systems like SVN and git. Let's build a server that keeps track of everyone who touched a block. Every time I destroy a block, that empty space will have my name on it. Every time I construct a building, every piece of that structure will have my signature in its history.

    Why would this be useful? In more ways than one: Perhaps the admin decides he doesn't like what I've done. In a normal server, he would kick me out and try to rebuild what I've broken. However, if our server tracked history, the admin could simply type /revert 5min gcr to undo everything I've done in the past five minutes. All my damage will disappear along with the rude shapes I've made. There would also be benefits for the player. What if I spend all my time making a wonderful skyscraper, the likes of which have never been seen? Obviously, I wouldn't want anyone to mess it up. In our hypothetical server, I would type /lock 2hr. All of the blocks I've made in the past two hours would now be locked, and griefers wouldn't be able to touch them. The Admin could still destroy them of course, but at least my work would be safe from everyone else.

    Of course, there are other ways of solving this problem. Why not give new players their own little "plot" of land that they can freely build on and destroy, or allow builders to secure a certain section of the map? This would allow new players to have fun without messing anyone else's work, and it would allow veterans to show off without worrying about vandalism.

    You all spend so much time creating these wonderful works of art. Why do you hide them away so that only your trusted circle of friends can even enter the map? Why not show them to the world by building tools that allow you to do so safely and in a controlled manner that lets everyone have fun?

    Being a n00b, I don't know how the network protocol works. I don't know how the server keeps track of things, or how much memory would be used. I don't even know if you guys like the idea. But I'd love to try and see what we could do to fix this.

    If we can build the tools to mitigate and control damage, we wouldn't have to kick griefers out of the game because when they see that even their best most destructive efforts take only a few keystrokes to fix, there would be no fun left in griefing. Their actions would then be an annoyance, not terrorism.

    Are there any open source servers I could hack on? If so, is this even a good idea? What other ideas do you all have?
    Posted in: Server Support and Administration
  • To post a comment, please .