Black Knight's Small Cron System für AdminMod (plugin_bk_cron) |
|
|
INHALT
Einleitung: Was ist ein Cron System?Für das Linuxbetriebssystem gab es Bedarf an einem System, dass zu einem bestimmten Zeitpunkt einen Befehl ausführen konnte. Aus diesem Grunde wurde das Cron System entwickelt. Hauptziel war es, sich wiederholende Aufgaben zu bestimmten Zeiten auszuführen, ohne dass sich ein User am Rechner sitzt. Das Konzept, dass entwickelt wurde ist sehr flexibel und einfach. Man muss sich jedoch mit der Syntax auseinandersetzen und diese verstehen. Das mag im ersten Moment nicht einfach erscheinen, man kann aber mit wenigen Zeilen komplexe Abläufe und Aufgaben generieren. Jeder Scheduler muss sich mit diesem System messen lassen.Ein Cronsystem ist also in der Lage verschiedene vorprogrammierte Aufgaben zu unterschiedlichen Zeiten auszuführen. Aus diesem Grund liegt es nahe dieses System, wenngleich abgespeckt, auch auf AdminMod zu übertragen. Features: Was leistet das BK Cron System?
Einschränkungen: Was leistet das BK Cron System NICHT?
Verwendungszweck: Was kann ich damit anfangen?
Installation:
Konfiguration:Das Trennzeichen ist das Leerzeichen (doppelte Leerzeichen, Tabulatoren, etc. im Zeitbereich führen zu Fehlern, sind aber im Commandbereich zugelassen)Musterbeispiel: * * * * * 1 mp_timelimit 20 delete
Will man dies wieder löschen, so muss man in einem anderen Task den gleichen Befehl angeben und ein "delete" anfügen. Beispiel: 0 12 * * * 1 mp_timelimit 20 0 0 * * * 1 mp_timelimit 30 delete Im ersten Task wird jeden Tag (unabhängig von Monat und Wochentag) Punkt 12 Uhr das Timelimit auf 20 Minuten gesetzt. Dies bleibt über alle Mapchanges erhalten, egal was in der server.cfg steht. Der zweite Task löscht um 0 Uhr jeden Tages diesen Eintrag aus der tasks.cfg und setzt den Wert auf 30 Minuten. Dieser Wert gilt bis zum Mapchange, anschließend gilt hier der Wert aus der server.cfg, soweit definiert. Ein Task zu verschiedenen Zeitpunkten: Ich möchte den gleichen Task zu verschiedenen Zeitpunkten ausführen. Dafür stehen mir zwei Möglichkeiten offen: Beispiel, falls ein Task viertelstündlich ausgeführt werden soll: 0,15,30,45 * * * * 0 say Viertelstunde vorbei! oder 60/4 * * * * 0 say Viertelstunde vorbei! Beide Beispiele machen das gleiche. Allerdings fängt das zweite immer bei 0 an! Einen AdminMod-Befehl ausführen: Dies ist relativ einfach zu bewerkstelligen. Vor jeden AdminMod-Befehl gehört ein admin_command. Ein zum oben vergleichbares Beispiel: 0,15,30,45 * * * * 0 admin_command admin_say Viertelstunde vorbei! Viele Befehle gleichzeitig ausführen: Hierzu verwendet man den "exec"-Befehl. Die entsprechende Datei muss dann natürlich auf dem Server abgelegt werden. Außerdem hat man auch hier die Wahl, ob man das ganze in der tasks.cfg über den Mapchange hinaus speichern möchte oder nur einmalig bis zum Mapende. Wichtig, siehe Einschränkungen unten. Einschränkungen:
Befehle:Für die Befehle braucht Ihr das Recht 65536!admin_cron_add <command> Mit diesem Befehl kann man eine neue Aufgabe in eine freie Stelle in der schedule.ini schreiben. "Command" muss der Struktur des Musterbeispiels folgen. admin_cron_del <line> Mit admin_cron_del kann man einen Eintrag in der schedule.ini löschen. Dazu benötigt man zusätzlich die Nummer des Eintrages. Diese bekommt man über admin_cron_list heraus. admin_cron_edit <line> <command> Wenn man den Inhalt einer bestimmten Zeile in der schedule.ini verändern möchte, kommt dieser Befehl zum Zug. Auch hier wird die Zeilennummer benötigt. Der "Command" muss vollständig sein, da die komplette Zeile überschrieben wird. admin_cron_forcecheck Dieser Befehl übergeht den Timer und checkt sofort, ob etwas ausgeführt werden soll. Evtl. mal nützlich, kann aber in der Regel ignoriert werden. admin_cron_forceexe <line> Der Befehl admin_cron_forceexe führt einen Befehl unabhängig vom Zeitpunkt aus. Man benötigt lediglich die Zeilennummer aus der schedule.ini (s. admin_cron_list). Dieser Befehl ist nach einer längeren Auszeit des Servers evtl. wichtig. Man kann den Server dann schnell wieder auf den aktuellen Stand bringen. admin_cron_list <line> Mit diesem Befehl kann man sich den Inhalt der schedule.ini in 10er Schritten ansehen. Der nachstehende Parameter ist optional. Wird beispielsweise 11 angegeben, so zeigt der Befehl alle Zeilen von 11 bis 20 an. Außerdem kann man mit diesem Befehl die Zeilennummer ermitteln, die man für die anderen Befehle benötigt. admin_cron_refresh Dieser sollte ausgeführt werden, sobald die schedule.ini manuell bearbeitet wurde. Die schedule.ini wird dann neu eingelesen. Das gleiche kann man aber auch über einen Mapchange erreichen. admin_cron_timeleft <0/1> Der Befehl deaktiviert/aktiviert (0/1) das Setzen der mp_timeleft Variable. Bei Aktivierung wird das aktuelle Timeleft jede Minute in die Servervariable geschrieben und ist somit nach außen hin sichtbar. Beispiele:Sonntagsmapcycle:Mal angenommen man möchte jeden Sonntag einen Custommap-Tag machen. Das ganze soll natürlich automatisch ablaufen. Wenn Ihr ein mapcyclefile in der server.cfg angelegt habt, lauten die Tasks dafür: 0 0 * * 7 1 mapcyclefile sunmapcycle.txt 0 0 * * 1 1 mapcyclefile mapcycle.txt delete Im ersten Task wird jeden Sonntag (7) um 0:00 Uhr die Variable mapcyclefile auf sunmapcycle.txt gesetzt und in die tasks.cfg geschrieben. Dadurch wird der Wert auch über den Mapwechsel hinaus erhalten bleiben. Im zweiten Task wird jeden Montag (1) um 0:00 Uhr die Variable mapcyclefile auf mapcycle.txt gesetzt und aus der tasks.cfg gelöscht. Ab dem nächsten Mapwechsel gilt dann der Eintrag in der server.cfg (daher gibt man hier schon den Wert aus der server.cfg an). Ist kein mapcyclefile in der server.cfg angelegt so kann man das auch anders durchführen (Die erste Variante funktioniert hier aber auch.): 0 0 * * 7 0 mapcyclefile sunmapcycle.txt 0 0 * * 1 0 mapcyclefile mapcycle.txt Da kein Wert in der server.cfg steht, wird dieser beim Mapwechsel auch nicht überschrieben und gilt bis zum nächsten Umsetzen, Servercrash oder -restart. Sollte der Server während des Sonntages also abstürzen, so gilt wieder mapcycle.txt. Variante 1 ist also eher zu empfehlen. Täglicher Mapcycle: Es kann ja auch sein, dass man einen sich täglich ändernden Cycle machen möchte: 0 0 * * 1 1 mapcyclefile monmapcycle.txt 0 0 * * 2 1 mapcyclefile tuemapcycle.txt 0 0 * * 3 1 mapcyclefile wedmapcycle.txt 0 0 * * 4 1 mapcyclefile thumapcycle.txt 0 0 * * 5 1 mapcyclefile frimapcycle.txt 0 0 * * 6 1 mapcyclefile satmapcycle.txt 0 0 * * 7 1 mapcyclefile sunmapcycle.txt Auf das "delete" kann hier verzichtet werden, da nur ein mapcyclefile-Eintrag in der tasks.cfg existieren kann und dieser immer überschrieben wird. Mapcycle 2x im Monat wechseln: 0 0 1 * * 1 mapcyclefile mapcycle1.txt 0 0 15 * * 1 mapcyclefile mapcycle2.txt Am 1. und 15. jedes Monats wird hier der Mapcycle geändert. Clanwarankündigung: Auf einem Public Server möchte man ja nicht so gerne die Leute einfach kicken. Ein bisschen vorwarnen, dass gleich ein Clanwar losgeht wäre nett: 40,45,50,55 19 * * * 0 admin_command admin_csay Um 20 Uhr ist ClanWar! Dieser Task führt von 19:40 Uhr bis 19:55 alle 5 Minuten ein CSay durch. Statt der Sternchen kann man auch ein direktes Datum eingeben. Falls man dann vergessen hat den Eintrag zu löschen, wird er am nächsten Tag nicht ausgeführt: 40,45,50,55 19 4 1 * 0 admin_command admin_csay Um 20 Uhr ist ClanWar! Dieser Eintrag gilt nur für den 4.1. Clanwarstart: Natürlich kann man auch gleich die ClanWar-Konfiguration laden lassen: 0 20 * * * 1 exec cw.cfg 0 23 * * * 1 exec server.cfg delete Hier werden die CW-Einstellungen von 20-23 Uhr geladen. Leider weiß das Plugin nicht, wann der War zu Ende ist. Ich empfehle daher den CW Creator v3.0.1: 0 20 * * * 0 admin_command admin_war_set [WING] [-+MfG+-] Passwort de_dust de_dust2 esl.cfg Der War kann dann jederzeit mit admin_war_end beendet werden. Man muss anschließend nur noch diesen einen Eintrag wieder löschen. Ankündigung Freitag den 13.: OK, ist kein wirklich sinnvolles Beispiel, soll aber mal die Möglichkeiten darstellen: 0 0 13 * 5 0 admin_command admin_tsay Freitag der 13.^nViel Glueck! An jedem Freitag den 13. um 0 Uhr wird dieser Befehl ausgeführt. Bekannte Bugs:
FAQ:
Support:
ToDo:
Danke an:
Funktionsweise:Ich gebe hier nur einen kleinen Einblick, so dass man es auch als Laie einigermaßen verstehen kann.Mit dem Plugin wird ein Cronsystem simuliert. Beim Mapstart werden zunächst, auf Grund der ausgeführten tasks.cfg, alle mit bk_cron dauerhaften Variablen gesetzt. Evtl. vorhandene Einstellungen aus der server.cfg werden von denen in der tasks.cfg überschrieben (Daher soll der exec-Eintrag der letzte in der server.cfg sein). Beim Start des Plugins kurz danach werden die Daten aus der "schedule.ini", in der alle Aufgaben stehen, gelesen und in den Speicher des Plugins geschrieben (Dies ist wichtig, da viele Festplattenzugriffe zu Lag führen.). Anschließend ermittelt das Plugins die Anzahl der Sekunden bis zur nächsten vollen Sekunde und setzt einen Timer. So wird der Grundtimer, der jede Minute ausgeführt wird, sekundengenau gestartet. Jede Minute überprüft das Plugin nun, ob eine der Aufgaben im Speicher mit der aktuellen Zeit übereinstimmt. Ist dies der Fall, wird der entsprechende Befehl ausgeführt. Leider kann es auf Grund von Lag zu Abweichungen kommen, aber meist sind das bei einer Map nicht mehr als 2 Sekunden. Ich glaube, dass diese Abweichung zu verkraften ist. Interessant in diesem Zusammenhang dürfte es sein, was passiert, wenn ein Befehl zufällig während des Mapchanges ausgeführt werden sollte. Das Plugin kann daher einen bis zu fünf Minuten langen Mapwechsel überbrücken und führt die Befehle anschließend durch. Als kleines Extra habe ich dann noch das minütliche Setzen der Variable mp_timeleft eingebaut. Dadurch kann man von außen erkennen, wie lange es noch bis zum Mapwechsel dauert. Warum Counter-Strike das nicht selber macht, wird wohl immer das Geheimnis der Programmierer bleiben. Changelog
|