Prüfungen
Prüfungen sind die Auffälligkeiten, die dzbot gefunden hat und die ein Mensch beurteilen muss. Das System kann dir sagen, dass sich zwei Konten einen Browser teilen oder dass jemand ein erst letzte Woche erstelltes Discord-Konto verknüpft hat — ob das ein Betrugsversuch, ein Haushalt oder Zufall ist, kann es nicht sagen. Diese Entscheidung liegt bei dir, und diese Seite hält sie fest.
Navigationspfad:
Server-Admin→Prüfungen
Zugriffsrechte
| Recht | Was es freischaltet |
|---|---|
admin.reviews.view | Die Prüfungen sehen, die diesen Server betreffen |
admin.reviews.decide | Die Warteschlange bearbeiten: übernehmen, Notiz schreiben, Tickets verknüpfen, erledigen |
Eine Prüfung gehört zur Organisation, nicht zu einem Server: es geht um Menschen, und zwei Server dürfen über dieselben Menschen nie zu zwei verschiedenen Urteilen kommen. Du siehst die Prüfungen, bei denen mindestens eines der Konten auf deinem Server spielt — und deine Entscheidung gilt überall.
Was eine Prüfung auslöst
Prüfungen entstehen, solange die Organisation mindestens einen Server hat, der bezahlt ist oder in der Testphase läuft. Ohne einen solchen werden die Server-Logs weiter importiert — es geht nichts verloren —, aber es öffnet sich keine Prüfung.
Mehrfachkonto
Zwei oder mehr Konten teilen sich ein Browser-Profil oder eine Adresse — so, wie die Web-App es beim Anmelden gesehen hat.
Spielgeräte lösen keine Mehrfachkonto-Prüfung aus. Ein Teil der Geräte-Verknüpfungen wurde von einem Moderator eingetragen, der bereits wusste, dass die Konten zusammengehören — eine Prüfung gäbe ihm nur seine eigene Schlussfolgerung zurück. Der Rest stammt aus den Server-Logs älterer DayZ-Versionen; eine Geräte-Kennung liefert DayZ inzwischen gar nicht mehr. In beiden Fällen werden sie auf der Seite des jeweiligen Spielers behandelt und nicht hier. Für die nächste Prüfungsart sind sie dagegen genau der Beleg — die stellt die umgekehrte Frage.
Frisches Konto
Jemand hat ein Discord-Konto verknüpft, das erst kurz vorher erstellt wurde. Das ist die Prüfung, die viele Teams von Hand gegen Bann-Umgehung fahren: ein gebannter Spieler kommt mit einem neuen Discord-Konto zurück, verknüpft es und macht weiter. Das Alter steckt in der Discord-ID selbst, ist also exakt und braucht keine Abfrage.
Konto-Mitnutzung
Zwei Konten, die dasselbe Spielgerät benutzt haben, waren gleichzeitig online.
Wo die Mehrfachkonto-Prüfung fragt ist das dieselbe Person, fängt diese bei der Antwort an: zwei Konten auf einem Gerät sind normalerweise ein Spieler, und ein Spieler kann nicht an zwei Orten sein. Sind beide gleichzeitig im Spiel, sitzt jemand anderes am zweiten Konto — verliehen, verkauft oder einem Freund gegeben, um einen Bann auszusitzen.
Verknüpft wird ausschließlich über Geräte. Browser und Adresse bleiben bewusst draußen: einen Anschluss teilt sich ein Haushalt, und ein Haushalt spielt den ganzen Abend zusammen — das gäbe hier nichts als Rauschen. Die Verknüpfung wirkt außerdem über Ecken: haben A und B ein Gerät geteilt und B und C ein anderes, gelten alle drei als eine Person.
Der Beleg ist nicht „die Sitzungen haben sich überschnitten". Dein Spielserver schreibt alle paar Minuten auf, wer gerade verbunden ist, und die Prüfung zählt, wie oft beide Konten in derselben Liste standen. Zwei Konten in einer Liste waren in derselben Sekunde online; da gibt es keinen Kulanzzeitraum zu diskutieren, und man kann es einem Spieler in einem Satz erklären. Eine abgestürzte Sitzung, die noch eine Viertelstunde online aussieht — der übliche Weg, wie solche Prüfungen falsch liegen —, kommt an die Schwelle gar nicht heran.
Der Fall zeigt jedes Zusammentreffen mit Uhrzeit, bewiesener Dauer und der Zahl der Listen, auf denen sie beruht. Die Dauer ist eine Untergrenze, nicht die Länge des Zusammenspiels: sie reicht von der ersten gemeinsamen Liste bis zur letzten, und beide waren davor und danach online.
Waren die beiden Konten nie auf demselben Gerät, hängen also über ein drittes Konto zusammen, sagt der Fall das ausdrücklich. Schau vor einer Sanktion nach, über wen.
Die Prüfung fängt an dem Tag an, an dem sie eingeschaltet wird, und schaut nur wenige Tage zurück — ein Server, der schon Monate läuft, startet also mit einer leeren Warteschlange. Wenn du die Fälle willst, die vorher passiert sind, sag uns Bescheid: der Nachlauf reicht so weit zurück, wie die Logs vorhanden sind, und macht sie auf einmal auf. Diese Fälle werden ohne Aktionen geöffnet — ein Zusammentreffen aus dem März darf heute keinen Auto-Bann auslösen — sie warten also einfach in der Warteschlange.
Gerätewechsel
Am selben Gerät wurde von einem Konto auf ein anderes gewechselt — ein zweites Konto an derselben Konsole, oft eines, das niemand registriert hat. Das ist eine eigene Prüfungsart, getrennt vom Mehrfachkonto: Ein Browser oder eine Adresse, die sich zwei registrierte Konten teilen, ist ein anderer Befund als ein Zweitkonto im Spiel, und Teams verfolgen und bestrafen beides unterschiedlich.
Auf PlayStation und Xbox lässt DayZ das nächste Konto an einem Gerät warten, bevor es spielen kann, wenn gerade ein anderes Konto von diesem Gerät auf demselben Server war: 5 Minuten nach dem ersten Wechsel seit dem letzten Server-Neustart, 15 nach dem zweiten, ab dem dritten 30. Die Wartezeit endet sekundengenau eine Stufe, nachdem das vorherige Konto gegangen ist. dzbot liest das aus dem Server-Log und ermittelt, welches Konto vorher gespielt wurde.
- Passt genau ein Konto, ist das ein starkes Indiz und erzeugt standardmäßig eine Prüfung.
- Sind in dem Moment mehrere Konten gegangen, ist jedes ein schwaches Indiz — Freunde, die gemeinsam ausloggen, passen genauso — und erzeugt nur eine Prüfung, wenn mehrdeutige Gerätewechsel eingeschaltet sind (siehe Einstellungen).
- Konten, die in der Geräte-Verwaltung schon mit demselben Gerät verknüpft sind, bleiben außen vor: Die Prüfung soll die finden, die niemand registriert hat.
- Kommt ein Konto nach dem eigenen Logout zurück, ist das kein Wechsel und zählt nie.
- Das Spiel macht das nur auf Servern, auf denen der Mehrfachkonto-Schutz an ist (Standard im Nitrado-Panel), und nur innerhalb eines Servers: Wer auf einen anderen Server wechselt, wartet nicht.
Der Fall listet jeden Wechsel: wer nach wem kam, wann, wie lange gewartet wurde, die Sperrstufe und den Server. Ein neuer Wechsel öffnet einen erledigten Fall wieder. Dieselben Verbindungen stehen auch auf der Seite jedes Spielers unter Mögliche Zweitkonten, als Verbindung Gerät.
Die Warteschlange abarbeiten
Die Liste ist eine Warteschlange: eine Zeile pro Fall, mit Typ, Bearbeiter und Alter. Wer einen öffnet, bekommt den ganzen Vorgang in einem Panel — und eine eigene Adresse, sodass sich eine Prüfung aus einem Ticket, aus Discord oder von einem Kollegen heraus verlinken lässt.
Eine Zeile in der Warteschlange nennt die beteiligten Kanäle — Browser, IP — und sonst nichts. Welches Konto an welchem Beleg hängt, ist eine Frage für den Fall, nicht für eine Zeile, an der du vorbeiscrollst.
Wer einen öffnet, sieht ihn gezeichnet. Die Konten sind Kacheln, und dazwischen liegt eine beschriftete Verbindung pro Kanal: sie teilen ein Browser-Profil, eine Adresse, oder beides. Mehrere geteilte Adressen zwischen denselben Konten sind eine Verbindung und nicht fünf Linien — die einzelnen Adressen stehen in ihrem Detail. Hängen mehr als zwei Konten am selben Wert, laufen die Linien in einem kleinen Knoten zusammen, an dem das Label sitzt: ein von vier Konten geteiltes Cookie ist damit eine Aussage und nicht sechs Linien. Farbe und Strichart sagen, welcher Kanal es ist; die Legende unter der Zeichnung sagt, was er wert ist.
Wer auf eine Kachel oder eine Verbindung zeigt, schiebt den Rest des Falls in den Hintergrund: bei einem Konto bleiben seine eigenen Verbindungen und die Konten am anderen Ende stehen, bei einer Verbindung die Konten, die diesen Wert teilen. Bei einem Fall mit einem Dutzend Konten ist das der Unterschied zwischen Knäuel und Antwort. Der Tastatur-Fokus macht dasselbe wie der Zeiger.
Ein Klick auf das Label einer Verbindung zeigt, was über sie bekannt ist: für wie viele Werte sie steht, den Zeitraum jedes einzelnen — und bei einer Adresse den Internet-Provider und das Land. Die Adresse selbst bekommst du nie zu sehen, und nie einen Ort genauer als das Land. Der Provider ist der nützliche Teil: zwei Konten bei Deutsche Telekom AG sind ein Haushalt, zwei an einem kommerziellen VPN-Ausgang sind zwei Fremde, die denselben VPN benutzen.
Ein Klick auf eine Konto-Kachel zeigt deren Discord-Identität und öffnet die Seite auf diesem Server — mit Spielzeit, Bans, Notizen und Kontostand. Ein Konto, das zur Prüfung gehört, aber hier nicht spielt, führt stattdessen auf seine Organisations-Seite.
Prüfungen, die vor dieser Darstellung entstanden sind, behalten ihre alten Beleg-Pillen. Ihr Datensatz wird nur neu geschrieben, wenn der Fall erneut gemeldet wird — bei manchen passiert das nie.
Einen Fall übernehmen
An dieser Warteschlange arbeiten mehrere Leute, deshalb lässt sich ein Fall übernehmen. Damit steht er auf „in Klärung" unter deinem Namen, und alle anderen sehen auf einen Blick, dass sich jemand kümmert. Gibst du ihn ab, geht er zurück in die Warteschlange; zieht ihn jemand an sich, steht auch das im Verlauf. „In Klärung" und „offen" lassen sich zusätzlich von Hand setzen — für einen Fall, der auf eine Antwort wartet und nicht auf dich.
Die Warteschlange zeigt offene und in Klärung befindliche Fälle zusammen: einen Vorgang zu übernehmen darf ihn nicht aus der Liste werfen, in der du ihn übernommen hast. Unbearbeitetes steht oben, darunter das Älteste zuerst.
Über der Liste findet die Suche einen Fall über seine Nummer oder den Namen, unter dem ein Beteiligter auf diesem Server spielt. Die Filter grenzen auf deine eigenen Fälle, eine Fallart, die Fälle eines Spielers oder einen Eröffnungszeitraum ein; der Sortier-Chip stellt auf „neueste zuerst“ um.
Wird eine entschiedene Prüfung wieder geöffnet, verliert sie ihren Bearbeiter. Wer sie entschieden hat, hat einen kleineren Fall beurteilt als den, der jetzt vorliegt — und ein wiedereröffneter Fall mit einem Namen daneben sieht aus, als kümmere sich jemand.
Tickets
Aus einer Prüfung können Tickets entstehen, und die Verknüpfung hält in beide Richtungen: die Prüfung listet sie, und jedes Ticket nennt den Vorgang, aus dem es kam. Erstellen lässt sich eins direkt aus der Prüfung — ohne Spieler bleibt es intern, was eine Zweitkonto-Prüfung normalerweise sein sollte. Bestehende Tickets werden von der Ticket-Seite aus zugeordnet.
Ein Ticket auf einem anderen Server deiner Organisation bleibt sichtbar, ist von hier aus aber nicht anklickbar; ein Ticket in einem Support-Level, das du nicht sehen darfst, behält seine Nummer und verschweigt den Rest.
Erledigen
Eine Prüfung wird mit einer Notiz geschlossen, und die Notiz ist Pflicht — sie ist die vollständige Aufzeichnung des Ergebnisses. Schreib hin, was du geprüft hast und was passiert ist: „Brüder, gleiche Wohnung, geduldet", „gebannt, hat sich nicht gemeldet", „über Ticket #7KQM geklärt, nichts dran".
Es gibt bewusst keine Liste von Urteilen zum Anklicken. Eine frühere Fassung bot pro Typ drei an — das unterstellt, dass der Prüfer die Antwort im Moment des Hinschauens schon kennt. In der Praxis macht er ein Ticket auf oder bannt vorsorglich und erfährt sie erst später. Dazu kommt: je mehr Prüfungsarten es gibt, desto mehr eigene Vokabulare bräuchte man, und „bestätigt / nicht bestätigt" passt auf die wenigsten davon.
Alles, was mit einer Prüfung passiert — geöffnet, übernommen, Ticket verknüpft, erledigt, wieder geöffnet — bleibt in ihrer Historie, auch später überholte Ergebnisse. Eine bereits erledigte Prüfung erneut zu erledigen ist erlaubt und hängt einen neuen Eintrag an, statt den alten zu überschreiben.
Wann eine Prüfung zurückkommt
Eine entschiedene Prüfung geht nur dann wieder auf, wenn ein Konto dazukommt, das du bei deiner Entscheidung noch nicht gesehen hattest. Derselbe Beleg, der erneut auftaucht, öffnet nichts — und auch mehr Belege über dieselben Leute nicht. Die hattest du ja schon vor dir.
Wenn sie wieder aufgeht, ist das neue Konto markiert: du siehst, was sich geändert hat, statt den ganzen Fall erneut lesen zu müssen.
Die Konto-Mitnutzung ist die Ausnahme, weil ihr Beleg von anderer Art ist. Ein geteilter Browser ist ein Dauerzustand — ihn morgen wieder zu sehen ist derselbe Umstand, nicht ein zweiter. Zwei Konten gleichzeitig online ist ein Vorfall, und ein zweiter nach deiner Entscheidung ist jemand, der wieder tut, was du für beendet hieltest. Jedes Zusammentreffen nach deiner Entscheidung macht den Fall also wieder auf.
Eine Kombination freigeben
Bei Geschwistern ist genau das falsch. Beim Erledigen kannst du deshalb „diese Kombination nicht mehr melden" ankreuzen — dann erzeugen diese Konten dauerhaft keine Mitnutzungs-Prüfung mehr.
Die Freigabe gilt für genau die Konten, die in diesem Moment am Fall hängen. Taucht später ein drittes Konto im selben Netz auf, hat das noch niemand beurteilt, und der Fall geht wieder auf — ein freigegebener Haushalt darf kein Versteck werden.
Freigegebene Kombinationen stehen unten in der Warteschlange, mit Grund und Urheber, und lassen sich dort zurücknehmen. Das Zurücknehmen öffnet den alten Fall nicht wieder; es sorgt nur dafür, dass das nächste Zusammentreffen wieder gemeldet wird.
Automatisierung rund um Prüfungen
Fertige Actions
Im Marketplace gibt es für jede Prüfungsart eine Action: Multi-Account Review Automation, Fresh
Account Review Automation, Account Sharing Review Automation und Device Switch Review Automation. Installiere die gewünschten über den
Tab Marketplace unter Admin → Actions.
Jede besteht aus unabhängigen Bausteinen. Jeder hat seinen eigenen Schalter und seine eigenen Einstellungen, und keiner ändert, was ein anderer tut; die Einstellungen eines Bausteins erscheinen erst, wenn er eingeschaltet ist:
- Bannen der betroffenen Spieler — Grund, Dauer und organisationsweiter Bann sind einstellbar.
- DM an die betroffenen Spieler auf Discord.
- Ticket — eins pro Spieler mit dem Spieler darin, oder ein einziges internes.
- Prüfung schließen, mit einer Notiz, was die Action getan hat, damit in der Warteschlange nur liegt, was noch ein Mensch entscheiden muss.
- In einen Discord-Kanal posten — jeden Fall, mit dem, was die Action getan hat.
Um die Fälle erst eine Weile zu beobachten, bevor die Action handelt, schalte Bann, DM, Ticket und Schließen ab und setze nur den Kanal.
Wer als betroffen gilt, hängt von der Art ab. Bei Mehrfachkonten wählst du zwischen allen Konten (Standard) und allen außer dem ältesten: Das älteste Discord-Konto, meist das Hauptkonto, bleibt verschont, auch wenn es auf einem anderen Server spielt. Standardmäßig löst nur ein geteilter Browser aus, eine geteilte Adresse allein nicht. Auf Gerätewechsel reagiert sie nie — die sind eine eigene Prüfungsart. Bei Konto-Mitnutzung ist es der registrierte Besitzer. Gerätewechsel bieten dieselbe Wahl wie Mehrfachkonten und handeln standardmäßig nur bei starken Treffern, bei denen genau ein Konto passt; ein schwacher Treffer, bei dem mehrere Konten die vorherigen gewesen sein können, braucht einen eigenen Schalter. Bei einer Wiedereröffnung ist nur das neu hinzugekommene Konto betroffen.
Eigene Actions schreiben
Beim Öffnen und Wiedereröffnen schreibt eine Prüfung ein review_opened-Log-Event — damit können
Actions darauf reagieren: automatisch bannen bei starkem Match, in einen
Discord-Kanal schreiben, was auch immer dein Team braucht. Ein Event deckt beide Fälle ab
(reason ist created oder reopened), sodass eine einzige Action für „hier muss jemand
draufschauen" genügt.
Jedes Konto im Event trägt is_new — eine Action kann also gezielt nur das Konto behandeln, das die
Wiedereröffnung ausgelöst hat, statt der ganzen Gruppe, die letzte Woche freigegeben wurde. Dazu
kommt is_oldest, das das älteste Discord-Konto der gesamten Prüfung markiert.
Was in details steht, hängt von review_type ab:
multi_account:tier(z. B.browser_new),evidence,linksfresh_account:accountCreatedAt,accountAgeDays,maxAgeDaysaccount_sharing:observations,provenMinutes,incidentCount,lastIncidentAt,incidents,sharedDevicesdevice_switch:strength(strong, wenn nur ein Konto passt,weak, wenn mehrere passten),switchCount,lastSwitchAt,switches,links
Eine Action kann auch ein Ticket öffnen und es an die auslösende Prüfung hängen, damit automatische Arbeit dort landet, wo auch die manuelle liegt:
server.create_ticket(
"Zweitkonto prüfen: " .. data.accounts[1].username,
"Vorgang " .. data.review_id .. " geöffnet (" .. data.reason .. "). " .. data.url,
nil,
data.review_id
);
Ist die Prüfung inzwischen mit einer anderen verschmolzen und ihre Nummer existiert nicht mehr, wird das Ticket trotzdem erstellt und die Action läuft weiter — nur die Verknüpfung entfällt, mit einem Hinweis im Action-Log.
Hat die Action den Fall erledigt, schließt server.close_review(data.review_id, notiz) ihn mit der
Notiz als Ergebnis, angezeigt als erledigt von System. Das Event erreicht jeden Server, auf dem die
Konten spielen, deshalb darf der Aufruf mehrfach kommen: Nur der erste schließt die Prüfung.
Einstellungen
Unter Organisation → Allgemein lässt sich einstellen, welche Treffer eine Prüfung erzeugen, wie jung
ein Discord-Konto sein muss, damit die Neukonto-Prüfung greift (Standard: 90 Tage; 0 schaltet sie ab),
und in wie vielen gemeinsamen Online-Listen zwei Konten stehen müssen, bevor eine Mitnutzung gemeldet
wird (Standard: 3, also grob eine Viertelstunde; 0 schaltet sie ab).
Browser-Treffer erzeugen standardmäßig eine Prüfung; IP-Treffer sind aus: etwa die Hälfte aller Treffer und fast nie ein Fund, weil WGs, Familien, Mobilfunknetze und VPNs sich alle Adressen teilen. Sind beide aus, gibt es keine Mehrfachkonto-Prüfungen.
Gerätewechsel erzeugen standardmäßig eine Prüfung, wenn genau ein Konto passt; mehrdeutige Gerätewechsel — in dem Moment sind mehrere Konten gegangen — sind aus. Jede Prüfungsart lässt sich abschalten.
Wo Prüfungen sonst auftauchen
Die Seite eines Spielers zeigt die Prüfungen, an denen er beteiligt ist, in der Moderations-Historie neben Notizen und Einschränkungen. Dort begegnet man ihnen meistens: während man ohnehin etwas anderes über diesen Spieler entscheidet.
Die organisationsweite Übersicht
Organisation → Multi-Account-Erkennung zeigt alle Fälle der Organisation auf einmal, egal ob
daraus eine Prüfung geworden ist. Sie existiert, weil eine Prüfung nur für die Stufen aufgeht, die
ihr eingestellt habt; der Rest steht hier — und hier arbeitet man ihn in einem Durchgang ab. Nötig
ist org.linked_accounts.view.
Die Fälle sind genauso gezeichnet wie in einer Prüfung, gruppiert danach, was der Beleg wert ist: gleicher Browser oben, nur gleiche Adresse darunter. Spielgeräte kommen in diesem Bild gar nicht vor — sie werden auf der Seite des jeweiligen Spielers behandelt, wo die Geräteliste sie und alle nennt, die sonst darauf gesehen wurden. Drei Dinge helfen beim Lesen einer solchen Karte:
- Das Label hängt an der Verbindung und sagt, welcher Kanal sie erzeugt hat: Browser oder Adresse. Das ist die wichtigste Angabe auf der Karte, denn die zwei sind sehr unterschiedlich viel wert.
- Ein Knoten heißt ein Wert, nicht mehrere. Linien, die sich in einem kleinen Punkt treffen, hängen alle am selben Browser-Profil oder derselben Adresse.
- Ein hervorgehobenes Konto hält die Karte zusammen. Nimmt man es weg, fällt sie in einzelne Teile — und genau dann sind zwei Konten gar nicht miteinander verbunden, sondern nur mit einem gemeinsamen Dritten.
Ein Fall mit mehr als zehn Konten wird als Liste dargestellt statt gezeichnet. In dieser Größe bleibt keine Anordnung lesbar, und dieselben Angaben sind pro Zeile einen Klick entfernt.