[Suggestion] Detection of abusers and SS Goals.

[Alliguierg]

Hello. I would like to suggest some functionality to make life easier for admins.

1 - Detection of abuse: The server monitors players that are consuming most of the SS during the time they are online. Warning them and by executing the kick if the player does not solve its abuse. This function would also have an educational purpose.

2 - SS Goals: The adm defines a minimum SS average. When it is in this minimum state the server should not allow more connections. This allows the possibility of leaving the limit of players free and determined by the processing capacity of the server.

[Jimmacle]

The problem with this is that players themselves don't have a large effect on sim speed, it's what they build that eventually causes performance issues. One could link performance issues to players through block ownership but it's not 100% accurate so it's trickier to solve than it appears.

[XeroCreator]

You can have up to around ~60 people alone on a server with star system setup. adding one grid with full survival use, gives you about a .80-.90 sim speed almost instantly.

During a test on a very powerful server and during Xocliw's stream we had around 32+ people in what was called the 'clangthedral' and we were able to maintain 1.0 sim through this process... until someone turned off the thrusters and attempted to crash us in creative.

During this, the game felt fine, but when testing with i believe it was 20+ people and only 20 of the same grids (my ship called artorius) completely vanilla, it's fine, but with induction of mods as well, this makes it even harder to detect if a player is doing something crazy.

To add to this request though, maybe a detector type system to check programming blocks running on server? some of the scripts get crazy even if they are 'simple'.

edit: somehow hit comment too quick.

[Equinox-]

I'm going to implement a PB resource sharing system soon :tm: Basically you can tell it "I want PBs taking up to 5ms each tick" and that 5ms will be split among all players fairly.

Example: Server admin configures maximum PB time to 5ms. Player A has 4 instances of TIM running every tick on 4 huge grids. Average runtime is 3ms/each. Player B has MART running every tick. Average runtime is 1ms. Player C has Automatic LCDs running every tick. Average runtime is 2ms.

On a typical setup there would be 15 ms/tick of PB action, which would leave your server very sad. With the PB resource sharing system this would happen:

• Tick 1
  • The timer triggering Player A, TIM 1 runs. Player time {A: 3ms, B: 0ms, C: 0ms}, Tick time: 3ms
  • The timer triggering Player B, MART runs. Player time {A: 3ms, B: 1ms, C:0ms}, Tick time: 4ms
  • The timer triggering Player C, Auto LCDs runs. Player time {A: 3ms, B: 1ms, C: 2ms}, Tick time: 6ms
  • The total processing time has exceeded the max PB time of 5ms, so Player A, TIMs 2-4 timer blocks never trigger and are instead scheduled for the next tick.
• Tick 2
  • Player B has the lowest usage, so they get to run MART again. Player time {A: 3ms, B: 2ms, C: 2ms}, Tick: 1ms
  • Player C has the next lowest usage, so they get to run Auto LCDs again. Player time {A: 3ms, B: 2ms, C: 4ms}, Tick: 3ms.
  • Player A now gets to run TIM 2. Players: {A: 6ms, B: 2ms, C: 4ms}, Tick: 6ms
  • Total processing time has exceeded the max PB time so Player A, TIMs 1,3,4 don't trigger and are scheduled for the next tick.