It seems to me that all the effects of griefing could easily be managed if every player session was temporarily logged in the server(all the deletion and creation actions). When a player is banned/vote banned, all of their actions would be reversed using the log data. This would be much more effective than frequent backups, especially on servers with large numbers of users who would lose their hard work if a server admin needs to revert to and older backup due to grief.
Also, something like this would probably need to be able to be turned off or on from the server properties.
What would be kinda useful, would be a freeze admin command.
When used on griefers, they would be completely immobilized and unable to dig/build.
This way, an admin could freeze a griefer, or even all the players on a server, to kick several griefers before they got the time to do any more damage.
When oping, I have experienced that every second can cound because griefers can do tremendous amounts of damage with a flying/speedhack and autoclick on.
Impractical? each delete/create action would require only 5 - 8 bytes (depending on the level size), then every 200 or something actions, it would start a new file and gzip the previous file to save space. This could easily be done by saving serialized java data.
Save format:
[boolean create/destroy?][byte block type][byte or short x(depending on level size)][byte or short y(depending on level size)][byte or short z(depending on level size)]
Edit: An admin freeze command would be abused by admins just like spawn prisons are, they would freeze new players.
And you shouldn't need to stop a griefer in time before they do damage, with Degriefing they could destroy half the level and it would be fixed as soon as you ban them, easy peesy :tongue.gif:
Take my servers for example, they're online for >72 hours at a time. I have seen people join a server and play for a good 6 hours. Saving EVERY action for a single player over 6 hours, when they could potentially chang millions of blocks, would take up a huge amount of space. It's entirely impractical anyway. I could easily go into a server, play nice for an hour, then find some water and dam it up, play nice for another hour then grief EVERYTHING, some OP would undo my changes and they'd then find the entire map flooded because my dam was removed.
Hmm, it would not be difficult for the server to check if the block it is about to remove is holding back water. Simple check for a still water block on each of the 4 sides.
The file size dilemma is easily solved with gzip compression, i could make an example file of 1000+ edits into the format i suggested and post the file size after its broken up and compressed.
Edit: Ok, i will make a small program to generate the example logs using the statistics Zuriki mentioned, i will post the sample's filesize
Hmm, it would not be difficult for the server to check if the block it is about to remove is holding back water. Simple check for a still water block on each of the 4 sides.
The file size dilemma is easily solved with gzip compression, i could make an example file of 1000+ edits into the format i suggested and post the file size after its broken up and compressed.
Edit: Ok, i will make a small program to generate the example logs using the statistics Zuriki mentioned, i will post the sample's filesize
Okay, so what if I I use sand and a block, so when that block is removed the sand falls. Would the server also need to check that? You're assuming every server that runs minecraft has the power to handle all this. Furthermore, if we assume over 72 hours my server has 100 players and each plays for 2 hours that's a lot of file space and erroneous files to handle.
Well i made 32 user logs, each containing 600 block updates, the total size of everything comes toooo *drum roll*
90kb :tongue.gif: still smaller than a map lol
@citricsquid: good question, so as a rule the server would have to ignore blocks that held back water, and the blocks that supported them.
You guys probably aren't going to convince me that this isn't practical, server level generation consists of 100's to 1000's of block checks and manipulations, at it in preformed nearly instantly. These degriefing tasks would only be run several times per hour, and only access one file that is no where near the size of even the map file.
I don't really see where you guys are getting the idea that reading a 2-4kb file and interpreting it is a large task for a java server considering what it already does.
Well i made 32 user logs, each containing 600 block updates, the total size of everything comes toooo *drum roll*
90kb :tongue.gif: still smaller than a map lol
@citricsquid: good question, so as a rule the server would have to ignore blocks that held back water, and the blocks that supported them.
You guys probably aren't going to convince me that this isn't practical, server level generation consists of 100's to 1000's of block checks and manipulations, at it in preformed nearly instantly. These degriefing tasks would only be run several times per hour, and only access one file that is no where near the size of even the map file.
I don't really see where you guys are getting the idea that reading a 2-4kb file and interpreting it is a large task for a java server considering what it already does.
32 user logs with 600 block updates? have you SEEN some of these creations? I myself have created well over 100,000 block updates on the Eagle 3, a huge multi hour creation of Spadge and myself. And you can't say that I wasn't a greifer so it don't matter, becuase I still would be recorded like every player good and bad.
Rollback Post to RevisionRollBack
<TrueWolves> That's what I meant Iguana, I'm like an Extra+, to just fill in tiny cracks... right?
<Iguana> YUS. <Iguana> BUT WE NEED YOU
<Iguana> You are like...Billy Mays Mighty Putty. (trademarked)
IRC quote on the Minecraft Machinima
100,000... yes that is alot, wouldn't be so much if the server clears the logs every 20 minutes though, because you probably need some more ops if you can't catch a griefer until 20 minutes after.
p.s. i love you guys, its really easy to refine ideas with you guys bouncing all these problems at me :tongue.gif:
A way i see this could make a log its something like this.
Every player get a intern ID wen they acess the server, and ID's stay in a file. Ex:
Niffle = 1;
jack = 2;
etc...
Then, there was gonna be a single file with all the modifications. Having the coordinate of all blocks followed by every by the ID and block type, it could also read the file by line number, making the use of the coordinate of the blocks unnecessary. Ex:
This translate:
On the block of cordinate 0,0,0 it first had grass(code G) (Server ID 0) Then a user ID(1) deleted it and created a stone block (S) after that a user with the id of 3 came and and created a wood block(W), so if the op anted, he could undo all the work of user ID 1, making the file like that.
0,0,0 = 0G 3W;
0,0,1 = 0G 2SP;
And later undo the player with ID of 3, making the block going back to be a grass block.
Also with you be good some type of perimeter you could made to only undo some parts of the server.
Another way would be very similar to that, making all players have his own log.
In the same way there was gonna me a txt file with all the cordinates of the blocks. But only with two logs in every block.
0,0,0 = G W;
0,0,1 = G;
In 0,0,0 it means that the block was a grass block and he created a wood block instead, if he destroy the wood block and replace it with a glass one, the server would look at 0,0,0 and see if there is a wood block, if there is it gonna replace the W(wood) by GL(glass), if not it means that someone created something there while he was doing some other stuff, then instead of changing only the W, it would change also the G(grass) to anything that was put in there.
That way wen using th undo instead of comming back to a grass it would become something else.
I just don't have sure how you could log the "air blocks" with this second method.
@citricsquid: good question, so as a rule the server would have to ignore blocks that held back water, and the blocks that supported them.
You guys probably aren't going to convince me that this isn't practical, server level generation consists of 100's to 1000's of block checks and manipulations, at it in preformed nearly instantly. These degriefing tasks would only be run several times per hour, and only access one file that is no where near the size of even the map file.
This idea has been suggested many times before and you can search to find the oppositions. You don't seem to understand that it is not practical. My previous examples were only that; examples, there are many more scenarios where this can cause problems. Furthermore, let's say there's 10,000 blocks created by a user, each of these affects a sand block which in turn affects other sand blocks that block water. The amount of validation and checking that would need to be done is HUGE, add to that the possibility for multiple people to be banned at the same time, it would cripple a server.
Furthermore, let's say for example I join a server and there aren't any ops there, I go to lots of previously made buildings and replace all/half the blocks they've created with my own, the same type and everything. Now, I go around a map and do this for an hour, replacing thousands of blocks, then an OP comes online and and I start griefing to make a "scene" to attract his attention, now he probably won't consider my previous actions so he'll want to undo what he's seen me do, not realising that I've totally destroyed the map before he was there. So he does /ban citricsquid and suddenly every building on the map loses the blocks it had.
The OP would have done more "griefing" than me. Furthermore, what about the logs being stored between visits? If I disconnect and reconnect are my block changes removed to save space, or are the block changes for every user saved indefinitely? I've got 16 servers each running 24/hours a day, they've all been online for around a month, I'd guess that there's been well over 10,000 joins on my servers. How huge will the logs for that be? Massive.
If you don't keep logs permanently then I can just grief a few times, reconnect, grief again, reconnect etc etc.
This plan has so many holes when you actually consider it.
About the ingenious water traps:
Such a thing as this could be useful to, you know, maybe stop the lesser griefing aka people running rampant with autoclick delete.
Even though it could not stop such things as "water traps" the griefer could easily do so without making an intricate trap..
Just because it is not foolproof, and cannot save EVERY situtation does not mean it is not worthwhile. I can think of an enormous amount of situations where it would be useful.
However, if it is possible or not, I don't know.
None of the tools an op has at his disposal is the ultimate tool that will stop all griefers, but all of them help.
EDIT:
What about a tool that notifies ops if a player has deleted 80% blocks and built 20%, so an op could at least watch them.
Or maybe 40 blocks in less than a minute. or something in that direction, so we can know if a player is going berserk underground where we cannot see him. Sometimes it is hard to keep track as an op.
About the ingenious water traps:
Such a thing as this could be useful to, you know, maybe stop the lesser griefing aka people running rampant with autoclick delete.
Even though it could not stop such things as "water traps" the griefer could easily do so without making an intricate trap..
Just because it is not foolproof, and cannot save EVERY situtation does not mean it is not worthwhile. I can think of an enormous amount of situations where it would be useful.
However, if it is possible or not, I don't know.
I assume this tool is supposed to combat determined griefers, you don't need an undo for the average griefer who joins and then destroys a few blocks before getting kicked. A good griefer can destory an entire level without being caught.
Private servers with good moderation seems to be the only solution.
That, or frequent resets.
However, I once frequented a server with a very nice custom map which was fun building on.
The server was not dedicated, and the host was very unstable, so we were getting disconnects every so often.
In minecraft, this is not that much of a hassle, it does not take a very long time to rejoin, and if you had spent a good amount of time on something, you would rejoin.
Griefers, however, and trolls in general, had a tendency not to come back, because they were not "connected" to anything on the server.
What about a system that autokicked you after 15 minutes or so (not a ban) the first couple of times, and then, when you were "established" you could stay for as long as you wished?
Or just a script that restarts the server every half hour.
Because this bad connection on this particular server, was actually more favourable than it was bad. We almost didn't get griefed at all! :smile.gif:
Just throwing in ideas because I' myself find it hard to op and keep track sometimes.
Also, something like this would probably need to be able to be turned off or on from the server properties.
Your thoughts?
Dave
When used on griefers, they would be completely immobilized and unable to dig/build.
This way, an admin could freeze a griefer, or even all the players on a server, to kick several griefers before they got the time to do any more damage.
When oping, I have experienced that every second can cound because griefers can do tremendous amounts of damage with a flying/speedhack and autoclick on.
Save format:
[boolean create/destroy?][byte block type][byte or short x(depending on level size)][byte or short y(depending on level size)][byte or short z(depending on level size)]
Edit: An admin freeze command would be abused by admins just like spawn prisons are, they would freeze new players.
And you shouldn't need to stop a griefer in time before they do damage, with Degriefing they could destroy half the level and it would be fixed as soon as you ban them, easy peesy :tongue.gif:
300 blocks per player
8 bytes per block
32*2400=76800bytes
Also, I could create a flood trap that would activate on /undo ing my work.
The file size dilemma is easily solved with gzip compression, i could make an example file of 1000+ edits into the format i suggested and post the file size after its broken up and compressed.
Edit: Ok, i will make a small program to generate the example logs using the statistics Zuriki mentioned, i will post the sample's filesize
Okay, so what if I I use sand and a block, so when that block is removed the sand falls. Would the server also need to check that? You're assuming every server that runs minecraft has the power to handle all this. Furthermore, if we assume over 72 hours my server has 100 players and each plays for 2 hours that's a lot of file space and erroneous files to handle.
90kb :tongue.gif: still smaller than a map lol
@citricsquid: good question, so as a rule the server would have to ignore blocks that held back water, and the blocks that supported them.
You guys probably aren't going to convince me that this isn't practical, server level generation consists of 100's to 1000's of block checks and manipulations, at it in preformed nearly instantly. These degriefing tasks would only be run several times per hour, and only access one file that is no where near the size of even the map file.
I don't really see where you guys are getting the idea that reading a 2-4kb file and interpreting it is a large task for a java server considering what it already does.
32 user logs with 600 block updates? have you SEEN some of these creations? I myself have created well over 100,000 block updates on the Eagle 3, a huge multi hour creation of Spadge and myself. And you can't say that I wasn't a greifer so it don't matter, becuase I still would be recorded like every player good and bad.
<Iguana> YUS. <Iguana> BUT WE NEED YOU
<Iguana> You are like...Billy Mays Mighty Putty. (trademarked)
IRC quote on the Minecraft Machinima
p.s. i love you guys, its really easy to refine ideas with you guys bouncing all these problems at me :tongue.gif:
Every player get a intern ID wen they acess the server, and ID's stay in a file. Ex:
Niffle = 1;
jack = 2;
etc...
Then, there was gonna be a single file with all the modifications. Having the coordinate of all blocks followed by every by the ID and block type, it could also read the file by line number, making the use of the coordinate of the blocks unnecessary. Ex:
0,0,0 = 0G 1S 3W;
0,0,1 = 0G 2SP 1GL;
or simply
0G 1S 3W;
0G 2SP 1GL;
This translate:
On the block of cordinate 0,0,0 it first had grass(code G) (Server ID 0) Then a user ID(1) deleted it and created a stone block (S) after that a user with the id of 3 came and and created a wood block(W), so if the op anted, he could undo all the work of user ID 1, making the file like that.
0,0,0 = 0G 3W;
0,0,1 = 0G 2SP;
And later undo the player with ID of 3, making the block going back to be a grass block.
Also with you be good some type of perimeter you could made to only undo some parts of the server.
Another way would be very similar to that, making all players have his own log.
In the same way there was gonna me a txt file with all the cordinates of the blocks. But only with two logs in every block.
0,0,0 = G W;
0,0,1 = G;
In 0,0,0 it means that the block was a grass block and he created a wood block instead, if he destroy the wood block and replace it with a glass one, the server would look at 0,0,0 and see if there is a wood block, if there is it gonna replace the W(wood) by GL(glass), if not it means that someone created something there while he was doing some other stuff, then instead of changing only the W, it would change also the G(grass) to anything that was put in there.
That way wen using th undo instead of comming back to a grass it would become something else.
I just don't have sure how you could log the "air blocks" with this second method.
This idea has been suggested many times before and you can search to find the oppositions. You don't seem to understand that it is not practical. My previous examples were only that; examples, there are many more scenarios where this can cause problems. Furthermore, let's say there's 10,000 blocks created by a user, each of these affects a sand block which in turn affects other sand blocks that block water. The amount of validation and checking that would need to be done is HUGE, add to that the possibility for multiple people to be banned at the same time, it would cripple a server.
Furthermore, let's say for example I join a server and there aren't any ops there, I go to lots of previously made buildings and replace all/half the blocks they've created with my own, the same type and everything. Now, I go around a map and do this for an hour, replacing thousands of blocks, then an OP comes online and and I start griefing to make a "scene" to attract his attention, now he probably won't consider my previous actions so he'll want to undo what he's seen me do, not realising that I've totally destroyed the map before he was there. So he does /ban citricsquid and suddenly every building on the map loses the blocks it had.
The OP would have done more "griefing" than me. Furthermore, what about the logs being stored between visits? If I disconnect and reconnect are my block changes removed to save space, or are the block changes for every user saved indefinitely? I've got 16 servers each running 24/hours a day, they've all been online for around a month, I'd guess that there's been well over 10,000 joins on my servers. How huge will the logs for that be? Massive.
If you don't keep logs permanently then I can just grief a few times, reconnect, grief again, reconnect etc etc.
This plan has so many holes when you actually consider it.
Such a thing as this could be useful to, you know, maybe stop the lesser griefing aka people running rampant with autoclick delete.
Even though it could not stop such things as "water traps" the griefer could easily do so without making an intricate trap..
Just because it is not foolproof, and cannot save EVERY situtation does not mean it is not worthwhile. I can think of an enormous amount of situations where it would be useful.
However, if it is possible or not, I don't know.
None of the tools an op has at his disposal is the ultimate tool that will stop all griefers, but all of them help.
EDIT:
What about a tool that notifies ops if a player has deleted 80% blocks and built 20%, so an op could at least watch them.
Or maybe 40 blocks in less than a minute. or something in that direction, so we can know if a player is going berserk underground where we cannot see him. Sometimes it is hard to keep track as an op.
I assume this tool is supposed to combat determined griefers, you don't need an undo for the average griefer who joins and then destroys a few blocks before getting kicked. A good griefer can destory an entire level without being caught.
Private servers with good moderation seems to be the only solution.
That, or frequent resets.
However, I once frequented a server with a very nice custom map which was fun building on.
The server was not dedicated, and the host was very unstable, so we were getting disconnects every so often.
In minecraft, this is not that much of a hassle, it does not take a very long time to rejoin, and if you had spent a good amount of time on something, you would rejoin.
Griefers, however, and trolls in general, had a tendency not to come back, because they were not "connected" to anything on the server.
What about a system that autokicked you after 15 minutes or so (not a ban) the first couple of times, and then, when you were "established" you could stay for as long as you wished?
Or just a script that restarts the server every half hour.
Because this bad connection on this particular server, was actually more favourable than it was bad. We almost didn't get griefed at all! :smile.gif:
Just throwing in ideas because I' myself find it hard to op and keep track sometimes.