Change penalty

[S-S-X]

• First, remove that 20 second cap.
• Make penalty increase more aggressive if circuit time usage is significantly higher than normal simple circuits. Possibly also less aggressive for mapblocks using less cpu time.
• Add publicly usable chat command (not restricted with privileges) to clear penalty with per player command execution cooldown, dynamic cooldown would be very simple to implement and can completely prevent command abuse. Some admin priv could be added to skip cooldown if needed.

[FeXoR-o-Illuria]

Penalty could also just drop faster when block has less than say 5% usage so command would be less needed. Exponential increase/decrease may work for high usage/penalty values.

[BuckarooBanzay]

First, remove that 20 second cap.

You want a stricter environment, do i get that right? What would be a better upper limit for that?

Make penalty increase more aggressive if circuit time usage is significantly higher than normal simple circuits.

(i originally wanted to draw some pretty response-diagrams for usage/penalty but i'm rusty with gnuplot) This is the current calculation: https://github.com/minetest-monitoring/mesecons_debug/blob/40ecd2db7223d178de6d21807499ff17ad3cf2ce/context.lua#L57-L66

I think we could start with putting some of those constants into runtime-configurable settings and then tune it ingame, maybe even with some command-block/button magic :rainbow:

Add publicly usable chat command (not restricted with privileges) to clear penalty with per player command execution cooldown, dynamic cooldown would be very simple to implement and can completely prevent command abuse.

How would you want to let players clear the penalty and also prevent abuse? :thinking:

[S-S-X]

You want a stricter environment, do i get that right?

Stricter yes but just for circuits that actually gets very close to penalty limiter. There's now been example circuits that do hit limiter and after hitting limits actually start gaining more CPU time for mapblock because limits do not really matter anymore.

What would be a better upper limit for that?

∞, yes I do think that best upper limit is to not have upper limit. or better disable mapblock permanently until player resets it with penalty cleanup command.

How would you want to let players clear the penalty and also prevent abuse?

publicly usable chat command (not restricted with privileges) to clear penalty with dynamic cooldown (globally per player, not per mapblock) would be very simple to implement and can completely prevent command abuse.

That means if player uses command often it will be locked longer but would still be useful to correct mistakes and test again without moving to next "clean" mapblock.

[BuckarooBanzay]

The latest commit introduces the following:

• Chatcommand: /mesecons_clear_penalty with 120 seconds cooldown that resets the current mapblocks penalty
• Faster penalty rise, slower penalty reduction
• Upper limit of 300 seconds for the max penalty (not infinite right now)
• :warning: Every mapblock with a penalty over 60 seconds (penalty_mapblock_disabled) won't execute any mesecons stuff anymore

[S-S-X]

Penalty can still be ignored completely and mapblocks with 60 seconds penalty can still execute just like any other mapblock (tested at about 5 events / second with about 60 second penalty) after you fill queue.

[BuckarooBanzay]

Penalty can still be ignored completely and mapblocks with 60 seconds penalty can still execute just like any other mapblock (tested at about 5 events / second with about 60 second penalty) after you fill queue.

Do you have an example circuit? Which event is it exactly, did i miss some? :confused:

[S-S-X]

Penalty can still be ignored completely and mapblocks with 60 seconds penalty can still execute just like any other mapblock (tested at about 5 events / second with about 60 second penalty) after you fill queue.

Do you have an example circuit? Which event is it exactly, did i miss some? 😕

Simplest is to feed messages to penalized mapblock using some component to feed trigger messages and does not generate penalty (rtc, nic, timers, lua controller, lua tube) and forward those to area with penalty but only to feed queue (to keep queue feeder without penalty). Not so simple method is by duplicating messages so that you emit 1 message and get 2 into queue growing queue larger and having enough penalized events in queue, those will be delayed 60 seconds execution happens in order so end result is simply everything shifted 60 seconds to future but without any real penalty. Message duplication is more complicated because you need additional guards to not burn lua controllers in loop (digiline limiter can be used to drop messages after you reached desired queue size to skip penalty).