[SERVER] Protection vs Griefer

[noliVe]

still, this doesnt help getting a problem fixed. of course i know about all the rules but this doesnt solve the problem.

discussion about having a protecion against griefing is untouchable ;D and i am sorry for saying this but please stop arguing about ... is it worth or whatever!
Please focus on making it possible. thank you. And i am not saying : "i dont like you" i only want to get further!

- i updated the first post with more ideas or what is needet .

In my opinion any "complex" system for auto-detection and/or action against griefer MUST
1- be an option.
2- build by and for, those who suffer from griefer.

1. true . i like beeing a griefer sometimes. just to keep my friends busy.
2. yes. and here i am . suffering a lot with you because you tell me my idea is crap .. still i like you *hehe*

again please share some thoughts and maybe we get some modders who understand the situation and can do something about it.

[noliVe]

and here it is this was my first post Idea.
Thanks devs! first stepp done

https://www.factorio.com/blog/post/fff-184

The input action permissions system (Rseding)

The improvements to how multiplayer works in 0.14 made having an open multiplayer game not out of the question. However this introduced a new problem, in that there is no way to protect yourself from people that just want to ruin the fun. To try to fix those problems I've added 3 new things for 0.15: white-list support, the ability to disable friendly fire, and an input action permissions system.

Factorio handles all player actions and interactions through our system of 'input actions'. The input actions tell the game what the player is trying to do, where and what keys/clicks he is making, and basically all game state interactions are done with input actions. This makes it relatively easy to filter what players can and can't do, by limiting what input actions they can perform, which can now be controlled through the permissions system:

The permissions system is completely optional, and it supports any number of permission groups, allowing server admins to define allowed/disallowed actions for everyone in that group. Before anybody asks: yes you can deny yourself the ability to edit permissions (after confirmation), if for some reason you wanted to do that.

The server console (and RCON) have unrestricted access to edit permissions. So, if you do lock yourself out (I don't recommend you do), you can always get back in through that. Additionally, permissions can be edited through the Lua API since the next logical step would be some automated system to slowly grant players permissions on a public server. The ability to edit permissions through the Lua API is checked so a player with console access can't just give themselves permissions if they don't have the required permissions.

[noliVe]

another great idea from
posting.php?mode=reply&f=53&t=29937

Banned: gapspring
Reason: Deconstruction of huge swaths of base.

Well, I have discovered something about deconstruct. The "built by" name of the object changes to the name of the player that ordered the deconstruct. so if you see anything with a red X on it, just check the "built by" name and you've got your griefer.


Was originally built by fleas, but mass-deconstructed by gapspring.

(Found this by loading previous autosaves, and checking the same object's owner before deconstruct.)

[darkfrei]

I have suggested idea about adding information who built and who is entity.last_user
Just wait for 0.15

[Rseding91]

another great idea from
posting.php?mode=reply&f=53&t=29937

That's the whole point of the "last user" property...

[darkfrei]

another great idea from
posting.php?mode=reply&f=53&t=29937

That's the whole point of the "last user" property...

Here must be first_user or creator, then it's possible to compare them by the script.

Another option - on_pre_marked_to_deconstruction, where is possible abort a lot of deconstruction if last_user was another person.

[noliVe]

what about "

USER - RIGHTS | GROUPS will be addet soon so i get more hope on this one
i hope these Groups can be configured individualy!?

maybe even set the color

[Impatient]

Hi all,

I have a new idea for an anti-griefer protection:

Admins have the ability to protect an area on the map. In these areas only players with the ability to protect (other admins) can construct, deconstruct or destroy. All non-protected areas are open for all players.

This way admins can protect vital parts of a base against griefers, without being alert all the time, or having to exclude random joining players from participating, which is possible via some server configuration, I noticed.

Examples:
When a powerplant is set up and finished, an admin can protect the area. This way a griefer can not cut the water or coal supply. Finished parts of the base can be protected against nade attacks from griefers, ... can be protected from subtle changes in the belt system, .. from subtle removings of crucial parts, etc etc.

Further ideas:
- A map overlay can show which areas are protected and by which protector. This way a non-authorized player can see it and ask to make changes or to unprotect the area.
- Protecting and unprotecting an area can be as simple as clicking a button and drawing a rectangle around the area.


What do you think? Should I write a separate feature request for this? After all, this thread is old, I don't know if this has something to do with the server and the start of the thread is about completely different ideas.


My motivation:
This week I played on 5 days on public servers and EVERY SINGLE time the base was sabotaged or destroyed by griefers. Some people even make youtube channels out of griefing .. I don't believe it!

https://www.youtube.com/watch?v=CNQu75YabPM
https://www.youtube.com/watch?v=M9J_viGYfgI

[Themme]

Hello Folks,

TL;DR

A system that prevents new joining players to grief in the first minutes of a game.

What ?

There could be 2 options to keep track of (potential) griefers,

Option 1. When a player joins a server for the first time, this server checks the use of the deconstruction tool, for example if this new player grabs a deconstruction tool within 5 minutes AND deconstructs more than 100 objects, the host of the server gets a pop-up asking, mark player xxxxx as griefer? Yes/No.
A log will be saved of this player and after an X amount of marks, the player will be marked as potential griefer.
When this player joins another server, he will have restrictions, he cannot grab a deconstruction tool for the first 5 minutes, and when he joins, the host gets warned that a potential griefer has joined the server.
This would require a database that keeps log of each player to check how many reports he recieved.

Option 2. This option will not require a database, and might be easier to implement.
When a player joins a server for the first time, and this person deconstructs more than 100 objects in the first 5 minutes, the host gets a message "New player xxxxx marked more than 100 objects for deconstruction, continue? Yes/Abort. It could be possible to have a second question pop up when Abort has been ticked asking to ban the player as well.
Of course, the deconstruction of the objects marked by that player will be cancelled.

Why ?

Because it is a pain in the ass when you forget to put up a password on a server and someone random joins and dismantles your entire factory.

Thanks, Themme

[Koub]

[Koub] Merged into older topic of requests about protecting servers vs griefers