Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent player do decon for N time after having played in opponent team for M time #1054

Closed
illwieckz opened this issue Nov 19, 2017 · 4 comments

Comments

@illwieckz
Copy link
Member

illwieckz commented Nov 19, 2017

On a recent gameplay while playing on CTCS (UTCS remix by Matth) the human team was losing and someone from the human team switched team and started to decon the alien base. The deconner was banned and some previous build history was restored, but it's better if we can prevent that (it would also prevent us to ban people).

The idea is to forbid player to deconstruct things for 10 minute if he switched team after having spent at least 10 minute in the original team.

It means people can switch team while the game start (sometime people chose the wrong team then switch) and have full building right so they can deconstruct building to build a better base. But if someone played at least 10 minutes in a team, he can't switch to opponent team and start deconstructing things before player at least 10 minutes in the opponent team.

We can also imagine a mechanism that automatically switch the player to spectator team if the player reaches a certain level of friendly fire right in less than 5 minute after having switched team.

The idea of these two measures is to educate people with bad idea to discover the idea they have are bad ones so they can return themselves to play a normal game or ragequit by themselves but without needing us to ban people (which must always be the very last resort, we are here to build a player base).

The 10 minute/5 minute are just suggestions, perhaps we will need other values…

Edit: I'm not saying people must wait the exact same amount of time they spent on the opponent team to be able to deconstruct things, they are meant to be fixed value and they can differ: we can say for example deconstructing is forbidden for 10 minutes if player has played at least 5 minutes in the opponent team or the opposite…

@illwieckz illwieckz changed the title Prevents deconner Prevent player do decon for N time after having played in opponent team for M time Nov 19, 2017
@Viech
Copy link
Member

Viech commented Nov 27, 2017

This issue describes a very specific case of a problem, griefing, that is generally not solvable through unobserved gamelogic, without a human server admin watching the scene.

In particular, I don't think the proposed change is impactful. First, the player in question and their team did not gain anything. We are not awarding lifetime statistics, match making rating, a digital currency, item drops, or any other incentive to win a match apart from feeling good about winning a match. The griefer could have deconstructed their own base with the very same effect – spoiling the game for everyone else if there was no admin to prevent or revert it. Whose base gets deconstructed simply makes no significant difference. Second, even if the griefer's goal is to explicitly make the enemy team lose, there would still be plenty of ways to do so without further restrictions such as preventing friendly fire or preventing team switches, both of which we probably don't want to do. And even if we did, people will always find ways to ruin each others match if they insist on it. They are just so many ways to do so, including attaining a new identity, feeding the enemy, bodyblocking, blocking a spawn or the medistation, giving the enemy information. If we start adjusting the gamelogic to detect all that we are making the game inaccessible while spending a lot of resources in doing so.

@illwieckz
Copy link
Member Author

The griefer could have deconstructed their own base with the very same effect – spoiling the game for everyone else if there was no admin to prevent or revert it.

I think that we may implement a way to forbid a convicted people to build.

Those ideas are there to offer nasty people the opportunity of a redemption before a ban.

I'm the kind of people who believe on education.

On the other hand, if someone starts team killing or feeding in a way to ruin the team, we can't do anything than ban, we can't forbid someone to fire or die while keeping him in game.

I think about staggered penalization before ban because:

  1. I believe in the educational power of a warning that has effects,
  2. There can case where the admin does not understand what is happening.

Last month, I joined my server, and I've seen someone teamkilling buildables with his rifle in a row.
After some talks, I've discovered he was attempting to recover the build points this way, to move the base. He was learning the game and was not aware that any lost build point is lost forever, and had trouble to find the debuild keys shortcuts (see #544).

A way to forbid building would prevent a newbie to get banned by an admin having misjudged what happened, and would help admin to stop the unintentional sabotage while talking with the newbie.

@Gireen
Copy link
Member

Gireen commented Feb 3, 2020

As mentioned this problem is best solved by server admins or other players.

There are already ways to deal with this, like the denybuild command which removes building rights for a player and is also available as vote option.
Possible ways to handle griefers are:
warn->denybuild->speclock->mute->ban

The problem in your example could also be a result of #1155

@illwieckz
Copy link
Member Author

OK, would be cool to have a GUI for those admin options, I'm myself a bit (euphemism) lost.

I'm still thinking that a temporary auto denybuild on team switch would be a good feature to have, but that's something we would be able to reconsider when we would have thousands of players 😏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants