even assuming certain restrictions on development (!), a proper defence against malice would be to have the server populated, at all times, by individuals who r statistically disciplined, willing and capable, and r authorized, with trust, to manipulate the game in case of immediate needs (these individuals r the „admins”), and to provide proper administrative tools. this is to achieve the following ideology (here „players” refers to guests in particular):
1. players should always enjoy an uninterrupted game, even with griefers in play:
the game should not be disruptible. but if this can’t be mathematically achieved, then at least:
players on the server should not feel significant quirks: the effects of malice should be reversed locally (eg., in-game remuneration (and perhaps loadout and position resetting) after being maliciously teamkilled or being deprived of a medistation by a malicious decon), if detected early. but if not, then at least:
the quirks should be limited to full game pauses and full game state reversions. but if not, then at least:
the game should never be practically unsalvagable following strategically important malice (typically deconning of the main support buildable).
2. the protocol for dealing with griefers should not place a burden on players:
players shouldn’t have to do anything about bringing justice upon griefers. but if not, then at least:
players shouldn’t have to invest significant time/effort into reporting cases:
players should only have to navigate some trivial user interface, to mark a suspicious individual, and perhaps to choose a violated point in the set of rules. but if not, if the players have to put the game away to visit a website, then at least:
players shouldn’t have to register, solve captchas or anything like that. but if not, then at least:
players shouldn’t have to read yet another page on „How to Report Abuse”. but if not, then at least:
players should only have to invest significant time/effort into in reporting for their first time:
players shouldn’t have to provide evidence (which should be available in the server logs anyway) for or write a detailed description of each abuse. but if not, then at least:
players shouldn’t have to be (and learn to be) proactive (eg., to record all games) to be ready to provide evidence.
3. the admins should also be able to enjoy the game:
admins should have powerful, fool-proof and easy-to-understand-and-use tools to manipulate the game and manage access to the server. but if not, then at least:
admins shouldn’t have to dedicate effort to monitoring for abuse.
(the plan to implement the most ideal workings on all 3 counts is not described.)
This is physically impossible, as actions which are not always disruptive can be disruptive given the right circumstances. For example, shooting a luci at an alien can be good if it kills them, but if the alien dodges and the luci hits a friendly buildable, that’s disruptive.
It is nearly impossible to have a system automatically detect whether a teamkill is “malicious” or not, and if there was such an automated system, you could abuse it by maliciously killing weak teammates who are about to die to get them all their credits back. Alternatively, being able to reset a malicious medistation decon (for example) would mean you could decon a 10% health Reactor, claim it was malicious, and then get a full health Reactor immediately. Obviously admins aren’t stupid enough to fall for that, but I’ve seen people revert “accidental” decons before, so it is always a possibility.
One problem here is that the revert system is buggy for “overlapping” buildables (even if they were just really close to each other initially) for reverting deconned buildables. Additionally, with base nades, you can’t revert partially damaged buildables, so if the RC ends up with 10% hp after the pause is over, a goon can pounce in and finish it off and end the game.
However, the biggest problem is incompetency among the administration team. Many admins have no fucking clue how to use !buildlog and !revert to selectively revert the correct things, and so they just do !revert x5 and revert 4 unrelated things just to revive the OM. No player should become an administrator without showing proper knowledge of how to use the commands they are about to receive, but I could name at least a handful of people I know have fucked up reverting buildables off the top of my head. Another problem is that a lot of the people who would be competent admins do not care enough or are not given admin in the first place. It doesn’t help that a large portion of the old AA admin squad has since stopped playing Tremulous.
I think it’s worth noting that, if Sparky or any other head admin of GHub had taken my advice 6 months ago (a full half year ago), we could have had TremStats with fully public game action logs a long time ago, just like the official GPP servers (and other servers) did. You just go to the TremStats site, click on the game that just happened, and you’ll have every kill, decon, build, and chat message (besides PMs) that happened during that game available to scour through. This would provide irrefutable evidence that certain things happened (primarily base nades and decons), even if it doesn’t provide the context and visual data.
Personally, as a Tremulous player with over 4 years of administrator experience on various servers on both 1.1 and GPP, I think these tools are already extremely easy to use and are more than powerful enough for any possible problem that could pop up. Did one team get deconned while the other team was building? It’s easy to pick out the right things to revert with !buildlog to get the buildlog numbers and !revert #30 (for example) to revert specific buildlog numbers. Alternatively, if you just need to revert the last 3 human decons, just use !revert x3 h and be done with it. For quick responses, it’s incredibly easy for admins to have a !pause bind that they won’t press accidentally but that can be activated quickly (such as, for me, pressing “i” then “3”, since I use vstr binds to set up menus). The only things admins can’t do, as I said, are heal buildables which were damaged (e.g. by a base nade), and give credits or evos to players who were maliciously teamkilled (or /callvote spec’d, etc., although those should be cancelled in the first place). I don’t think much fault lies on the GHub developers when it comes to the administration team being an utter mess at the current time. It’s all down to the head administrators failing to educate their new admins and selecting admins with little or no experience over those who actually know the ropes.
All-in-all, I largely agree with you. The GHub administration team is full of incompetent admins who have no clue how to use the power they are given, and they aren’t even given the power they need in some cases to properly manage problems. This isn’t some problem that can be excused with a, “Oh, in the Swirl Game Mode, we’ll have this BRAND NEW FEATURE which will make administration EASY! There will never be griefing again!”, because it’s a problem NOW, on the server people actually play on. I’d say on the average day at least 20-30 invalid votes pass which harm the gameplay experience for one or more players, and griefing happens more frequently than most people think, especially since nobody has put any work into finding a way to prevent Desala from ruining games and evading every ban put on him. The only thing I disagree with you about (I think) is that admins do not have the tools necessary to prevent the majority of problems, because if I was an admin like I was on AA, I could solve almost any problem in under 20 seconds.
automated detection does not imply automated reaction. automated detection can be beneficial if applied in combination with a human confirmation system: if the system detects that there is eg. ≥75% chance that a teamkill was not accidental, or if the target complains, then an admin could quickly review the case and confirm the system’s suspicion. if there is no admin, or all admins r idling or too busy playing on the other team, then there could be a teamvoting-calling system in place, or there could be automated action when the chance is eg. ≥95%, or the system would be disabled. btw, teamkills by more trusted players r to be rated more accidental.
pertaining this, another examplary thing to consider is, putting the question of malice aside, that a high-impact human base nading is almost always not interesting for either team, because the game ends basically by random circumstance, so it is better to require an admin to approve additional damage beyond a threshold, and since accidental human base nadings happen relatively rarely, perhaps the offender could be kicked or spectatized for 2 minutes. again, protected players r to be immune from such kicking/spectatization.
PS: Amsterdam Unlimited had an Auto™Kick(R) bot(C) that punished level-0 players for excessive teambleeding/teamdamaging; it worked relatively well.
which is exactly why noone proposes that reversions somehow regenerate full hit points, and alike.
obviously, if a reactor with 10% HP was deconned, then to revert that action, a reactor with 10% HP should be created at the original position (and any other reactor should vanish). this isn’t perfect, because the reactor could have been repaired to eg. 40% HP by the time the revert kicks in, or the reactor could have been destroyed. perhaps the full game should just be slightly reversed instead. with these, in case of a malicious decon, and arguably also in case of an accidental decon (see the paragraph before the one mentioning the Auto™Kick(R) bot(C)), a remedy is significantly better than no remedy.
obviously, if someone had 10% HP before being attacked and killed by a teammate, then to revert that action, the target should be repositioned to where he/it was before the teamattack begun, with 10% HP and the original class/inventory (and funds); details omitted. this isn’t perfect; details omitted.
this could be made much better with a proper user interface, where an admin could see the list of buildable-related actions coupled with „revert” buttons. also, what happens if, after the decon, but before „x3” some human builds another buildable ? i’m guessing that „x4” (or „x3” followed by „x1”) would have to be used, but in any case, the builder’s build delay timer is not immediately reset.
regarding all other parts of ur post that i didn’t directly quote here (they don’t even reply to what they pose as quotes !): yes, u have just expounded on what i meant under „lack of administrative tools”, „lack of training” and „non-enforcement” in the disruption log thread. consider moving these paragraphs there, and also the one below too. btw, the overlapping issue has already been fixed in the latest version of Tremulous, but GrangerPub is primarily based on old code. btw, i’m also in the „not give admin” category, because @cron is a NIGGER.
In my opinion, the real problem is that GrangerHub admins are way too permissive. Most griefing (especially invalid votes) is done by regular players because there are almost no consequences for bad behavior. Kick votes last two minutes, deconners usually get banned for an hour and so on.
Desala is an excellent example - dozens (or more?) decons and still not banned. I’ve heard that Desala “cannot be banned” for some reason, but that only further proves that the admins are incompetent and/or don’t want him banned.
Well constantly having to ban desala is sort of pointless since he just keeps coming back and yes we know we can permanently ban him but he can get on a new client or something.
He does, ‘anonymously’ but he’s easy to rat out because he likes to cause his own problems, verbally abusing people and harssassing them. Just being the general troll. I suppose this is his next step
We have a pretty good idea for the reason, it is due to some technical limitations of the current admin system. With these limitations, if we were to take measures to to ensure Desala remains banned for an extended period time, a very large chunk of Eastern Europe would also be permanently banned. GPP’s admin system would not have handled this particular issue any better either. However, we are working on technical solutions for the new admin system in 1.3 (including a karma system) that should more than adequately address the problems of evasion.
Are you really going to let Desala decon for all eternity? Because that’s how much time will probably pass till the 1.3 release, judging from how GrangerHub’s been doing so far.
Impatient much? We have only been working on 1.3 for about a year, and many many many successful projects have taken a lot longer before release (I’m talking about projects in general, not just Tremulous related). Even Tremulous 1.1 was released about 5 years after it started as a mod on quake 3, and gpp took 3 years after that. Quake 3 took about 4 years or so. Still 1.3 won’t take as long to release as those projects.
Anyways, the problem with the issue of some evaders is technical, the problem isn’t due to unwillingness to address the issue nor due to incompetence. We can and do take action that addresses the problem for the short term, but the long term solution requires new systems/features/enhancements . It would take a lot longer to attempt to implement these improvements on the old CODEZ™ of slacker’s qvm. The new admin system/features/enhancements are one of the top priority items for 1.3, and will definitely be included for the initial release, as the problems that they address need to be solved.
I started getting impatient around November last year, about three months after you said you would release 1.3 “in the very near future”. Right now I’m not even waiting for it anymore. Tremulous’s player base has shrunk by at least 60% in the last year, so there’s little hope for a revival of the game at this point.
The development of Tremulous 1.3 yes will take many many years (Just like the development of my dads game.) Not only that but the fact that 1.3 doesn’t have 15+ (I think) devs working on 1.3 it should be taking a long time.
Tremulous 1.3 is released as a alpha or just ([color=lime]T[/color][color=cyan]est[/color]) server for players to play on and test while it is still out 1.3 is being worked on an adding new things hence Dev Games/Test Games. In my opinion this is my theory about the (if) released of Grangers Tremulous 1.3
Tremulous 1.3 has not been released yet (with the exception of the development cgame/ui qvms and the current assets), as the client nor server binaries nor code have been released yet. But we hold public tests on test7341.
This is still in the very near future.
With that said lets get back on topic. I think the overall model proposed in the original post on this topic is something that should be approached by the design of the new admin system/features/enhancements.