You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is somewhat okay that putkick, like pushmode, check channel membership before executing their action. They are documented as such.
The optimize-kicks setting promises to group kicks together (max-kicks) but I would expect it only to be optimized with putkick, like pushmode.
However, eggdrop is far more invasive with kicks. It actively goes through queued messages (putserv/putquick/puthelp), parses those, finds the ones that KICK someone and applies logic to that, for example purge_kicks().
IMHO Eggdrop should not parse and mess with putserv messages at all, kick optimization should be restricted to putkick (like pushmode).
Alternatively, optimize-kicks 0 should at least turn this invasive operation off.
Background is that networks with hidden users (ircu +D delayed join) want to execute that kick if scripts take care of tracking users themselves.
Found by: Empus
The text was updated successfully, but these errors were encountered:
It is somewhat okay that putkick, like pushmode, check channel membership before executing their action. They are documented as such.
The optimize-kicks setting promises to group kicks together (max-kicks) but I would expect it only to be optimized with putkick, like pushmode.
However, eggdrop is far more invasive with kicks. It actively goes through queued messages (putserv/putquick/puthelp), parses those, finds the ones that KICK someone and applies logic to that, for example purge_kicks().
IMHO Eggdrop should not parse and mess with putserv messages at all, kick optimization should be restricted to putkick (like pushmode).
Alternatively, optimize-kicks 0 should at least turn this invasive operation off.
Background is that networks with hidden users (ircu +D delayed join) want to execute that kick if scripts take care of tracking users themselves.
Found by: Empus
The text was updated successfully, but these errors were encountered: