Dear Hawknet community,

Yesterday Belgeran demoted me from Architect to Designer and reduced my blocks modified from 300k to 50k.

He found out reading the logs that I was spamming /undo and /redo commands, so without any further communication towards me, he decided to demote me and he greatly reduced my amount of blocks modified.

I think he gave me 2 reasons:

1. spamming /undo and /redo would increase my amount of blocks modified.

2. spamming /undo and /redo would harm the server.

While I developed great respect for the staff I think this is a very basic and rude action towards someone of architect rank. To be honest I thought he is a great guy and I really did expect that he would ask around first in a situation like this.

Allright, time for me to explain what happened.

I'm really really really really really active lately, got my architect rank in a few days (yay). While I LOVE building alot, I do get bored after some time. That's when I start to fool around.
For example:
How much fun is it, to have a clueless guest see a tree appear, disappear and reappear in front of him?

That's where my command spamming came from, about 25 blocks being generated and removed.

First of all, my command spamming did not increase my amount of blocks modified, it simply doesn't happen using /undo and /redo.

Second of all, making about 25 blocks appear and disappear does not harm ones server, that just doesn't fit in with the blocklimits we got and well.. if it does you shouldn't be hosting anyway.

In my opinion I did nothing wrong, I actually never ment to do harm to anyone. I hope Belgeran's decision is not final.

Thanks for your time,

Spiritas

Well, as the owner and developer of the server that you play on, I can garuntee you several things.

Firstly, performing the /undo and /redo commands modifies the block buffer of the player executing the command, this is how is it written in code. When you create or destroy blocks (even by using commands), several properties of the map are stored in what we call an "undo" file ([playername].undo). This file currently contains 300,000 blocks worth of data that the person last performed. Hence how it can be known to increase ones modified block count.

Secondly, when the /undo command is executed, here's what happens:
The process is reversed (more or less) for the /redo command, however the /redo buffer is completely different (which uses more memory), and is very very volatile. Since you say you were doing this multiple times in rapid succession, it can cause stress to the server and its resources.

Incase you're wondering, we are more than capable of running several servers side by side on our machine. We are running on an Intel Core i7 980, with 16GB of DDR3 1600Mhz RAM, a nice 500GB hard drive (which is only around 100GB full, due to running other servers and software), and it's connected to a 100Mbps/10Mbps FTTC internet line. We have been running this server for well over a year and a half, and our team is more than capable of managing the software and community.

I am fully supportive of Belgerans decision for the demotion, and since you have broken several of our Terms and Conditions (which are legally binding by the way), you should consider yourself lucky you only got a demotion. Technically what you explained you were doing could be borderline on harassment too, which is also a breach of the Terms.

You can always re-earn your rank, and due to it all being based on your block count, you just have to build again. It is far better than what one of our Agents got after we found out he used the same command 226 times in 13 minutes...

If you ever find yourself bored on Classic, learning new commands, or helping guests with their builds is always a good way to boost community morale, and it will also get you on good terms with us, which gives you a higher chance of promotion from the Architect rank. HawkServ offers a lot of commands to make your builds one step better, like Doors, oDoors, and tDoors, which add functionality. If you catch me online, ask me to show you my map for a few of the projects and builds (using the functions explained) that I done when I was a low rank.

In conclusion, you demotion will remain until it has been re-earned. I hope you understand how repeating actions can cause stress to the server and its job, and I hope you learn that there are better ways to spend bored moments on the server.

Mainly what you're saying is, that the undo and redo commands refresh the complete history file of that player? Updating the lvl happens with every action right.

Allright, I can understand that it may cause stress on the server then. I won't make this mistake again.

But then again, what filesizes are we talking about?

And wouldn't it be better to let the server create multiple .undo files based on sessions? or a certain limit of data in each file?

I mean, rarely people want to undo anything out of their current or maybe last session and griefers mostly only run one session.

I appreciate you took the time to write that all down btw

The information stored in the undo files for each player is:


Since the information is stored under the players name, its quick and easy to access (search for a file with the players name, if it exists, conitnue, if not, make one). Having multiple files per player will add to the file space used, will increase read and write times to the drive (and ultimately lower the drives' lifespan) and it could take even longer if the program has to run through several files to find the one it wants.

Typical file size of undo files range from 0k (a few bytes), to 11Mb+. We're currently storing 461 undo files for our players, with 7 of those files being over 1Mb. The entire undo selection is over 50Mb in size.

In terms of undoing per session, the current undo system (record the time the block was placed. When /undo is called with a time parameter, check the difference between the stored time to the current time and if it's within range, undo the block action) works quite well. The source needs optimising to make good use of resources and threading, but ultimately, it's a good system that works well.

Due to HawkServ being a fork of MCLawl, and when I got a hold of MCLawl's source, it was in pretty bad shape. HawkServ has a lot of features and optimises since then (we started on v62.0.0.0, we're now on v67.6.0.1), and have made the program a lot more stable, running for days instead of hours, or even minutes.

I actually got curious and asked around a bit about the .undo file storage. Both Mcstorm and Mcforge developers agreed that working with multiple .undo files greatly reduces the ram usage on the server. In general cpu and HDD power is saved because mostly only the latest .undo file needs to be loaded (by the player itself).
As I already suggested, griefers mostly run 1, maybe 2 sessions.
The only situation more server strain would occur, is when a dedicated player, suddenly decides to go rampage gets banned and undone.

The search problem, I'm not sure how the files are sorted, I think by point in time. The only thing you need to find out is in which file the undo reaches it's last data, the rest of the files can be completely reverted.

Allright this is my last contribution to this, I don't want to force you to edit anything. I just felt like offering some kind of help after the mistake I made.

Well, as stated above, the undo system in HawkServ will be getting updated when I get around to getting it working again. MCStorm and MCForge (both forks of MCLawl, which is what HawkServ is based on) have likely already updated their system due to having large development teams, whereas HawkServ is just being developed by me, and it will take a little longer, but I beleive the end product will be far better.