Ein Benutzer, der den Sticky-Status von einem Administator erhält, wird automatisch in einen definierten Kanal verschoben und kann diesen nicht mehr verlassen, auch dann, wenn er selbst Admin ist.

Dieses Script ist ein Port nach MuMo von https://github.com/Natenom/murmur-sticky.

Das Script und die .ini-Datei gibt es bei Github: https://github.com/Natenom/mumblemoderator-module-collection-legacy/tree/master/sticky.

Siehe hier: Installation neuer Module für MuMo.

Wie man an die Kanal-ID herankommt, steht unter KanalID / ChannelID / channel_id.

• Zuerst erstellt man einen Kanal
• Dann erstellt man eine Gruppe „stickyusers“ und fügt ACL-Einträge zum Server hinzu, die Benutzern dieser Gruppe alles verbieten außer das Sprechen und Betreten des Sticky-Kanals und „Durchqueren“ für alle übergeordneten Kanäle
• In der .ini-Datei ändert man folgende Einstellungen:
  • sticky_channel: Die ID des Kanals eintragen, in die der Benutzer hineingeschoben wird (wie man an die ID eines Kanals kommt, steht hier)
  • sticky_group: Den Namen der Gruppe eintragen, die man erstellt hat

• Zuerst lässt man sich die Liste der aktuell online befindlichen Benutzer anzeigen:

  !sticklist

• Nun setzt man den Status für den Benutzer:

  !stick SessionID

Hat der Benutzer seine Zeit „abgesessen“, muss man sich erneut mit !sticklist die Liste anzeigen lassen, da die SessionID sich bei einem Reconnect ändert und gibt dann ein:

!unstick SessionID

• Während jemand „Sticky“ ist, kann derjenige sich nur im definierten Kanal befinden
• Der Benutzer kann selbst als Admin nicht den Sticky-Status entfernen
• Der Benutzer kann währenddessen keinen anderen Benutzer in den Sticky-Status versetzen
• Der Status wird – bei registrierten Benutzern – selbst über einen Reconnect hinaus gespeichert
• Man kann sich nicht selbst in den Status versetzen
• Nach dem Entfernen des Sticky-Status wird man wieder in den vorherigen Kanal zurück geschoben
• Findet der Benutzer trotzdem einen Kanal, den er betreten kann, wird er sofort wieder zurück geschoben

Es waere sehr gefaehrlich bei einem Fehler, saemtliche ACL und Gruppen im Rootkanal neu zu schreiben - was man nach meinem Verstaendnis mittels getACL und setACL tun wuerde. Wenns schief laeuft, ist alles weg … Deshalb arbeitet das Script mit temporaeren Zugehoerigkeiten zu einer Gruppe. Wir muessen uns zwar bei dieser Art selbst darum kuemmern, dass bei einem Reconnect der Benutzer wieder in der stillen Treppe landet, aber das ist mir lieber als zu riskieren, bei einem Fehler alle Einstellungen im Root-Kanal zu verlieren :P

• Die Implementierung ist löchrig, da ein Admin z. B. immer noch Kicken kann usw. jedoch „bestraft“ man normalerweise keinen Admin :P