buildlog/revert (was Non-gameplay Updates 12/08/2010)

[Superpie]

would still be nice to have revert fixed so that you don't have to individually fix everything a basenade destroyed
for example

Code: [Select]

!revert 8
!revert 7
!revert 6 is much slower than

Code: [Select]

!revert [#] [amount] or just

Code: [Select]

!revert [team] [amount] like it used to be

[Rezyn]

you can revert multiple things, just use the oldest id# that you want to rewind

Code: [Select]

/revert 6
done.

[Superpie]

Ah, I see now. Perhaps it could be better specified in the /adminhelp. Still, there is no specification of which team to revert for.

[SlackerLinux]

Ah, I see now. Perhaps it could be better specified in the /adminhelp. Still, there is no specification of which team to revert for.

thats because its made to go back to the buildable id that you specify everything gets reverted up to that id they did this so it isnt abused easy

[UniqPhoeniX]

Ah, I see now. Perhaps it could be better specified in the /adminhelp. Still, there is no specification of which team to revert for.

thats because its made to go back to the buildable id that you specify everything gets reverted up to that id they did this so it isnt abused easy

So because it was *possible* to abuse it, the devs had to castrate the admin commands (without making them not abusable... cmon which cmd can't be abused?). Really smart. Totally.

[F50]

So because it was *possible* to abuse it, the devs had to castrate the admin commands (without making them not abusable... cmon which cmd can't be abused?). Really smart. Totally.

Castrated? Hardly. Show me a case where you'd really want to revert a single team's buildables. Admittedly there are some uses where it would be nice to revert a single build item (glitch-building, for instance), but is there really a case where you'd do a revert after enough time that you'd care about some of the other team's buildables being reverted? Only one buildable that gets built by each granger, and any buildables that the humans destroy in that amount of time would matter, but at the same time your reverting buildables that the aliens destroyed, so would it really make sense to revert one teams buildables and not the other?

[Lakitu7]

That decision was also influenced by the fact that the code is ridiculously more simple this way, in addition to the concerns about abuse / the other functionality just not really being that useful most of the time.

[Kiwi]

That decision was also influenced by the fact that the code is ridiculously more simple this way, in addition to the concerns about abuse / the other functionality just not really being that useful most of the time.

Abuse shouldn't be a reason to reduce the helpfulness of a command.  Maybe we should make /mute or /kick just call a vote, I think that would help cut down on abuse too. (sorry for the snide remark, but I just don't think abuse is a valid reason at all for reducing the power of an admin command.  The people who have access to that command should just be changed).  If porting/redesigning /revert to 1.2 caused lots of problems, then I suppose leaving the way it is is fine for now, but the old system of revert should be implemented before 1.2 is released.  The old system provided much more control and helped you revert bugbuids without reverting half of your teams rush that was just about to win you the game.  Sure bugbuilding doesn't happen *that* often, but when it does wouldn't it be nice to have a way to fix it without completely changing the game (and succeeding in helping bugbuilders reach their goal).  I often stay alive for quite some time, and during that time before I spawn out of a bugbuilt egg, assuming no one else complains about it, a lot could happen.

[A Spork]

I just don't think abuse is a valid reason at all for reducing the power of an admin command.  The people who have access to that command should just be changed

THIS!
seriously, the devs seem to think people abusing a command is a good reason to change or remove it, when it should just be the people abusiv it should loose admin.
Same applies to setlevel IMHO.

[Lakitu7]

It's lovely to focus on one facet of the reasons but you're forgetting the parts where
* Nobody used those features. I literally never saw anyone use them except for me, while reading people bitch about how the command too complicated all the time
* The code was complex as hell and was also simplified by this choice

Nobody neutered it for abuse-potential on its own. It's also that it just wasn't that useful.

[Undeference]

revert was very complex. Its full range of functionality was difficult to use for non-gurus and only its most basic functionality was used most of the time. Partially because of its more advanced, largely unused functionality—and largely because of how it was updated over time—the code was overly complex and would have been unpleasant for anyone other than the original authors to maintain. That last issue is the primary reason revert was rewritten.

The fact of the matter is that in most cases, only the most recent changes are particularly interesting from an administrative perspective. Consider the common case:
A Griefer connected
A Griefer entered the game
A Griefer join the Humans
UnnamedAlien was machinegunned by A Griefer
UnnamedAlien tried to invade A Griefer's space
Reactor DESTROYED by teammate A Griefer
UnnamedHuman couldn't escape teammate A Griefer's grenade
Telenode DESTROYED by teammate A Griefer
Armoury DESTROYED by teammate A Griefer
UnnamedHuman: admin deconner ban ban ban
UnnamedHuman was molested by UnnamedAlien's granger

Only a small part of the human base was destroyed by A Griefer's grenade; the large part was destroyed by the aliens who thought they caught the humans moving or just didn't care that the humans were deconned and wanted to improve their stats a bit.
As I understand it, if only human building is reverted, the majority of the human base is still gone. And the aliens got extra time to play with their base.

What happens to the acid tubes UnnamedAlien built where the reactor was? Does the reactor not come back or do they get destroyed (and is that revertable)? Or should those acid tubes be reverted too?
If everything is reverted to its position before A Griefer's grenade, there are no particularly difficult questions to answer, since the answer is: there were no problems before so there should be no problems now (except players might be in the way, but that's handled specially).

[Lakitu7]

By-team was by the team identity of the buildings, not the actions. In your example, it would have been put back.

If there was an acid tube in the way, it'd say something like "OVERLAPS WITH ANOTHER BUILDABLE. REPEAT WITH ! IF YOU ARE SURE" and then you'd repeat the command with ! at the end and it'd just replace the acid tube with the reactor.

I basically agree with your post but you're wrong about a couple things that make your examples bad.

[UniqPhoeniX]

Decons can still be dealt with if you always manage to pause instantly as it happens, but stopping the whole game because someone deconned a non-critical structure is not a good idea. What if the aliens are on the run & eggspamming, and someone decons the RC? Aliens may lose an egg/OM which can easily end the game at that state. Also consider that OM needs whole 30sec to grow, reverting an OM move without need is not acceptable. Needs per team revert.

However on larger maps you may not notice some grief building for several minutes, and during that time the other team could move their whole base. Needs per player revert (including players no longer in the game).

Being able to revert a single event can also be helpful.
*Significantly* (I'd say at least 5gu) overlapping buildables could be removed and the bps returned, or at least guarantee that there won't be any errors where buildings very close to the 1 reverted will be removed. If you don't add the features, someone will anyway, and if it becomes widely adopted the code will end up being messy again. Also with these features the amount of buildables to revert makes more sense then ID.

[DraZiLoX]

I didn't read any of these, and it might has been noticed. If you kill buildable, and build another buildable in place where the another buildable was bild, and then kill it, and then revert the buildable you killed first, and ta-da you have doubleturret/reactor.

eDIT: http://dtrem.com/files/bugrevert.dm_70

[Dracone]

Yeah, that one's been known since basically the week revert came around. People have used it to make weird layouts and shit like that, since you can make as many reactors and overminds as you want.

[KillerWhale]

One example of a situation that calls for by-team revert is this:

Human commando pulls out a painsaw and goes after the overmind.
Human commando has a lucky moment where there are no aliens in base and takes down the OM.
Human griefer basenades at the same time as the lucky commando is killing the alien base.
Admin has to revert the alien base at the same time, even though it was rightfully destroyed and likely cannot be killed again in that manner.

[Undeference]

Also consider that OM needs whole 30sec to grow, reverting an OM move without need is not acceptable. Needs per team revert.

So it is unacceptable to you that a decon does not result in one team almost always being unnecessarily penalized?

However on larger maps you may not notice some grief building for several minutes, and during that time the other team could move their whole base. Needs per player revert (including players no longer in the game).

(2010-12-05 18:16:35) Undeference: basically, revert is a heavy handed solution, so it's usually best to avoid it if possible (e.g., if one player is occasionally destroying things, they can probably be replaced quickly enough, and just ban them instead of reverting)
(2010-12-05 18:18:46) Norfenstein: and you're right, in the situations I'm thinking of the game can usually recover without intervention

revert is not needed for grief building, nor was it intended to solve that. The solution is less broken maps and a few bug fixes, and responsible players in the meantime (and denybuild).

Being able to revert a single event can also be helpful.

So can blowing up a door that is in your way. But you could just open it instead and your results—while certainly less satisfying—might be better.
As was previously explained, "one event" could very well be many, which raises a number of questions without any easy answers that are acceptable to you.

If you don't add the features, someone will anyway, and if it becomes widely adopted the code will end up being messy again.

This can be interpreted as either "do things the way I want them" or "what you do is completely irrelevant", neither of which is particularly likely to get someone to do what you want. So my response is that if you want it changed, change it yourself. And if it's not too terribly messy, your code might even be committed.

[UniqPhoeniX]

Also consider that OM needs whole 30sec to grow, reverting an OM move without need is not acceptable. Needs per team revert.

So it is unacceptable to you that a decon does not result in one team almost always being unnecessarily penalized?

I OBVIOUSLY meant that if humans get deconned and you can't revert it without also reverting an OM move, then that is unacceptable.

However on larger maps you may not notice some grief building for several minutes, and during that time the other team could move their whole base. Needs per player revert (including players no longer in the game).

(2010-12-05 18:16:35) Undeference: basically, revert is a heavy handed solution, so it's usually best to avoid it if possible (e.g., if one player is occasionally destroying things, they can probably be replaced quickly enough, and just ban them instead of reverting)
(2010-12-05 18:18:46) Norfenstein: and you're right, in the situations I'm thinking of the game can usually recover without intervention

revert is not needed for grief building, nor was it intended to solve that. The solution is less broken maps and a few bug fixes, and responsible players in the meantime (and denybuild).

Another sign that the devs don't know much about the game they create. Simple grief building includes eggs above lava etc, and if there are 3+ you will be stuck spawning from those until som1 else comes and helps you (that is only if there are any other eggs left, which an experienced troll/griefer will remove after creating those above lava, and it's then when you first find out about those. Even if there are other eggs left, taking the best player of a team out of the game for even 30sec can sometimes end the game).
You seem to have never encountered any ACTUAL intentional griefing, just some bad building and noobs bleeding base. There are many much worse things that can be done, but I don't want to give any ideas. Revert IS needed for grief building, and it's irrelevant what YOU intend it to be used for. 1.1 revert was excellent in solving many problems, whether you intended it or not.

If the solution was less broken maps, why haven't all the default maps been fixed? Do you really think you can make all mappers fix every bug someone finds in a map they created 6+ months ago? Or are we to just not play any slightly broken maps because you didn't like the 1.1 revert? People will want a more capable revert, and porting the 1.1 code will probably be done.
On public servers you can't guarantee having ONLY responsible players, nor can you denybuild griefers before you know they are griefers.

Being able to revert a single event can also be helpful.

So can blowing up a door that is in your way. But you could just open it instead and your results—while certainly less satisfying—might be better.

What?

As was previously explained, "one event" could very well be many, which raises a number of questions without any easy answers that are acceptable to you.

1.1 revert worked fine in that aspect.

If you don't add the features, someone will anyway, and if it becomes widely adopted the code will end up being messy again.

This can be interpreted as either "do things the way I want them" or "what you do is completely irrelevant", neither of which is particularly likely to get someone to do what you want. So my response is that if you want it changed, change it yourself. And if it's not too terribly messy, your code might even be committed.

You can interpret it however the hell you want, I just stated what I think is likely to happen. (insert regular response to the dev's usual DIY response) I think you should care about giving admins the ability to effectively moderate servers. If you don't care about it, I obviously can't force you.

[Undeference]

Simple grief building includes…

Simple and impossible to mitigate for utterly incompetent admins.

Revert IS needed for grief building, and it's irrelevant what YOU intend it to be used for.

The evidence to support your first assertion is very weak and your second assertion is contradicted by your post.

1.1 revert was excellent in solving many problems… People will want a more capable revert, and porting the 1.1 code will probably be done.

You seem to care a lot for someone so sure what we do is irrelevant.

On public servers you can't guarantee having ONLY responsible players, nor can you denybuild griefers before you know they are griefers.

Responsible admins have to be first and foremost responsible players. Lacking that, your server has more serious problems than revert.

If the solution was less broken maps, why haven't all the default maps been fixed?

That is tangential to the discussion.

[UniqPhoeniX]

You are being an idiot. I have nothing more to say to you.

[A Spork]

I agree with Whales and Uniq.
1.1 revert was far better.
Just because you've never needed to use it more precisely, doesn't mean it never needs to be used more precisely.
1.1 revert=a scalpel, 1.2 revert=a chainsaw.
Both can remove cancer, but the chances are very high that the chainsaw will remove more than needed, and likely cause far more harm than needed, or acceptable.

[Celestial_Rage]

Seeing how buggy 1.1 revert was, comparing it to a scalpel is hardly accurate. It was mentioned before, you often end up reverting structures or structures go missing that you do not intend to (especially when when you get that conflicting structure error). I feel the developers' decision to include a less buggy version of revert was right. The important thing is to get 1.2 out, we can worry about low probability griefer situations situations in the future where the features of revert can be expanded upon.

[A Spork]

Well, I meant the way 1.1 revert was supposed to work, not the fact that it was buggy.

[F50]

Well, I meant the way 1.1 revert was supposed to work, not the fact that it was buggy.

That's dangerously close to rose-colored glasses is it not? Revert never quite worked that way? The fact that the code was buggy was directly related to the features it was supposed to have. Hence a rewrite.

Honestly for 90+% of the cases I find the 1.2 rewrite to be very good, primarily because it is fast, and it is the speed of the revert command that allows it to be precise. The alien buildings (that IMO should be removed to be fair) are a relatively little amount of fallout compared to the delay that I encountered with the 1.1 revert. IMO, I think people notice the effect of deconners less because of this.

Unfortunately, having used the 1.1 revert back when I played 1.1, and not having figured out exactly what it can do that the 1.2 revert cannot except revert per team (which again is not very useful IMO), what is the use of the 1.1 revert again? What made a buggy piece of technology like a scalpel?

Did the ability to revert a single buildable actually work in 1.1? I tried to find out if it possible to get it to work, and failed. Even so, could you reliably find out which buildable it was from buildlog? In many cases it would be easier to tk the egg and /denybuild or perhaps kick or ban depending on how bad it is.

KillerWhale brings up a decent point, but that happens very, very rarely, and it is even more rare when that actually makes a difference as to the result of the match.

[UniqPhoeniX]

IIRC 1.1 revert worked perfectly except when it recreates a buildable that has some other buildable VERY close to it, in which case that some other buildable would be removed as if it was overlapping (needed ! at end of cmd), when in fact it was not. That on its own should be relatively easy to fix, tho a rewrite would be best if the code really is that messy, as long as it doesn't take away most of its features.
It had per team revert, per player, and per ID, while 1.2 revert only allows you to revert everything back to a certain point.

[Celestial_Rage]

The 1.1 revert could also be used to get multiple OMs/RCs, specifically because of the ability to revert individual events anywhere in the buildlog.

[Kiwi]

Ok, many of you guys are saying that the 1.2 revert is worse than the 1.1 revert, because the 1.1 revert was buggy.  This might be true, but that doesn't matter.  What does matter and what should happen is that the revert code should be rewritten (like it has been done), and it should include the features that the 1.1 revert provided.  The time that it takes to use a command should really not matter.  It takes the same amount of game time to type "/pause" then "/revert 8" and "/pause", "/buildlog", "/revert #34", "/revert #35" and "/revert #42".  Those extra 5 seconds to type building log and add a couple numbers is defiantly worth the precision that you get out of the revert.  And yes, precision matters a great deal.  Oh and lets not forget that 1.1 revert CAN revert a set number of builds back.  In 1.1: "!revert x5" In 1.2 "/revert 5".  Damn, that "x" takes so long to time, looks like we should remove all the helpful commands that 1.1 revert provided.  Remember: reverting specific numbers as stated in buildlog, reverting a set number back from a specific team, allowing you to revert a set number of builds back from a set number, reverting only a certain players builds, ect..  All that great stuff was amazingly helpful, and we removed it at the cost of adding? nothing?  The code might look a little cleaner, but what's clean code without it being useful.

1.2 should not be rushed.  Many community members have waited 3+ years for 1.2, and delaying the release another month or two is defiantly worth getting all these small wrinkles fixed.

[UniqPhoeniX]

In 1.1: "!revert x5" In 1.2 "/revert 5".

In 1.2 you need to enter the ID of the event to which you want to revert back to, not the amount of events. Which also means you always need to use /buildlog.

[Kiwi]

In 1.2 you need to enter the ID of the event to which you want to revert back to, not the amount of events. Which also means you always need to use /buildlog.

O yeah, and you do have to use /buildlog every time.