Beiträge von scumsaecke.de

    Moin, das schaut mir nach einer Vorbereitung für ein Rollout aus, was evtl mit den nächsten Patches kommt.?

    Zu den Händlern ein kleiner Tipp. Lösche in AppData die ecooverride und erstelle ein neues SinglePlayer Spiel. Dann wird eine neue eco generiert und du siehst die einträge.
    was du aber jetzt gerade suchst, scheint das hier zu sein: "Z_3_Hunter"



    Grüße
    phil

    Erster Test des RCON mit einer Bridge, damit alles verarbeitet wird wie bisher. Inkl. delay den ich mit als präfix oder suffix dazureichen kann.

    Wichtig: Fakename und Clearfakename Logik aus der normalen eingabe. der fakename wird von der bridge gemanaged

    Wer will kann einen schmalen multi-paket-faehigen Source-RCON-Client in Python bekommen.
    Oder wir können ihn gleich zum Paket dazu geben, so ist man nicht auf fremde codes (zb mcrcon) angewiesen.

    Grüße
    phil

    Starkes Projekt,

    mein Problem mit dem testen ist, dass ich dann Funktionen darauf aufbaue - und die bleiben dann auch.

    Ist dann nach einem Update seitens Gamepires etwas am Server geändert, kann es sein, es geht in Teilen nicht mehr oder der server crasht bei div Eingaben.
    Und hier liegt mein Problem - gern würde ich das einsetzen - aber ohne Code, den ich im Notfall Claude geben kann, der das fixt - müsste ich auf einen Fix der beteiligten Tools und Contribs warten.

    Contribs können Urlaub haben, krank sein oder einfach das Interesse verlieren. Dann basiert ein Teil meiner Infrastruktur auf Code den ich nicht ändern kann.

    Mir bleibt derzeit nur selbst bauen oder weiter meinen Game-Client nutzen.
    Closed Source Plugins, je nach dem wie weit sie integriert sind, können ganze Projekte einstampfen wenn sie nicht sofort nachgepflegt werden.
    Das habe ich schon zu oft gesehen und leider einmal selbst erlebt mit einem Conan Server.

    Sollte es irgendwann OpenSource gehen, nutze ich es sofort 8)
    Und der Code ist nicht um es zu veröffentlichen oder irgendwo einzubauen, sondern zur Sicherheit. Auch den Devcode der UE4SS habe ich mir beiseite gelegt, falls mal was sein sollte. :D
    Ich bin da quasi ein "gebranntes Kind"

    Trotzdem, starke Sache :*

    Wenn ich so darüber nachdenke ist mir schleierhaft, dass man sowas manuell proggen muss und es nicht einfach einstellen kann (Flagge pro Spieler). Der Server sitzt an der Datenquelle und kann instant nachsehen, ob eine weitere Flagge für den squad sein darf oder nicht.

    Gleiches bei Fahrzeugen - angesichts dessen, dass offiziell auch PvE Server betrieben werden ist mir rätselhaft, wie das da gelöst ist und die Spieler kein Hording betreiben. Warum kann ich nicht einstellen, dass ein Spieler nur 2 oder 3 Fahrzeuge abschließen darf? .... man stelle sich nur vor, das noch per Fahrzeugtyp. ^^

    Spieler will ein Schloss in ein FZ einsetzen? Kurzer blick für den Server in die Config und DB, gezählt, ja - nein. Done. :saint:

    Entweder das Schloss geht rein oder links steht da "Du hast die maximal eingestellte Anzahl Fahrzeuge erreicht!"

    Stell ich mir nicht wie ein Hexenwerk vor, ehrlich gesagt. Die Pipes sind bereits da, es fehlt nur eine kleine Funktion und der Eintrag in der Config. :sleeping:

    Phil

    Ok, kleiner Einblick :D Unser bot ruft nach jedem Login eine Flaggenliste und Squadliste ab und trägt sie in eine sqlite datenbank ein, der rest ist einfach nach Vorgaben vergleichen.

    Ob eine Flagge in einer von uns definierten Bauverbotszone ist, kann der Bot ebenfalls feststellen. Dazu hat er eine hoch auflösende Schwarz-Weiß Version unserer Baukarte und sieht in den Logs, wann wo eine Flagge gesetzt wurde. Die Koordinaten der Flagge werden in Pixeldaten umgerechnet und der bot "schaut" auf die karte ob der Spieler da bauen darf. Darf er das nicht, sendet er in einen DC-Channel für Mods/Admins eine Nachricht mit Flaggen-ID, Spieler-ID und fertigem Teleport-Befehl.

    Dann kann ein Mod da hin gehen und mit dem Spieler kommunizieren. Theoretisch könnte man die Flaggen auch automatisch weg machen lassen - aber das muss jeder selbst wissen.

    Grüße
    Phil

    Stimmt, wir konnten es mit genug Loginspam regelrecht triggern. Sobald sich 30-40 Leute gleichzeitig versucht haben einzuloggen, war es reines Glück. Meist kamen nur 1-2 Spieler pro Minute durch und ein Serverneustart hat eben mal einen 30 minütigen Login- Simulator getriggert, mit teilweise 700-800 Loginversuchen, bis alle wieder da waren.

    Wenn ich es richtig verstanden habe, gab es bei der Authentifizierung, bei zu vielen gleichzeitigen, einen Fehler in den IDs, darum kam dann immer "keine Berechtigung".

    Ein dev sagte mir, der Fehler war "nasty" zu finden.

    Aber sie haben ihn gefunden und wir können uns endlich wieder normal einloggen. 8) Top Sache

    phil

    ob du dich für offen oder geschlossen entscheidest, ein repo für den download wäre trotzdem nice. dass ich bei nexus einen acc machen muss, werbung zustimmen, adblock aus, usw, nervt tierisch.

    bei git könnte man es einfach herunterladen und eine doku mit den befehlen kann man sauber dort pflegen.

    Falls du Hilfe brauchst können wir easy einen Entwicklungs-Discord-Server erstellen. Da können wir uns austauschen, code teilen, usw.
    (das mache ich bei jeder entwicklung so)

    Grüße
    phil

    Es ist wirklich Zeit, dass wir was eigentständiges machen.
    Am besten richtig quelloffen mit git repo.

    Mein ziel ist es, dass es keinen unterschied gibt, ob per chat eingegeben oder per rcon.

    Wenn ihr igrndwo tatkräftige Unterstützung braucht, gebt gern bescheid - ich bin heiß auf den scheiß.

    Grüße
    phil

    genau daran hängt es , eine Funktion / Command wie #ExecAs fehlt noch in Herbie´s Rcon Schnittstelle , somit können keine Spawns umgesetzt werden.
    Ich möchte halt gern verhindern einen extra Account 24/7 online haben zu müssen ,der die Befehle übergibt.

    Auch hab ich leider noch keine Möglichkeit gefunden aus dem Rcon Client in den Chat (Global,Local,Team etc. ) zu senden .
    Aktuell funktioniert bei mir nur Announce , was ja nicht immer unbedingt von Vorteil ist ;)

       


    Ich habe ein wenig rumgesweept und backengineered. ein paar sachen habe ich gefunden. aber das problem, dass man einen user zum spawn braucht, ist auch hier nicht behoben.
    im gegenteil - selbst als elevated user kommt oft, dass man keine berechtigung hätte. Es muss noch eine Dev-Ebene geben - die habe ich aber noch nicht gefunden.

    Grüße
    phil

    da wir jahrelang alles per Client-Input realisiert haben, wäre es jetzt total praktisch, wenn man die gleichen befehle per rcon übertragen könnte. also wirklich 1:1
    und da wäre es sinnvoll für execas eine ID in einer config hinterlegen zu können und das tool übersetzt es sozusaqen :D

    ich versuche krampfhaft auf rcon zu gehen - aber durch die verschiedenen verarbeitungen bleibt mir wohl nur ein radikaler umbau unseres ganzen systems ;(

    Grüße
    phil

    Aber dein Text ist korrekt. Wie weiter oben geschrieben ist das hier nur ein Tool und der Umgang macht es. Das Tool ist umfangreich und sinnvoll., hier ging es eher um Whalley und globale Pranger, die Spielerdaten ausstellen und teilen.
    Das regelt weder jagex, noch eine EULA oder sonst etwas. das ist reines Datenschutzrecht - DSGVO.

    Auch ob SteamID ein relevantes Datum ist, ist nicht relevant. :D (cooles Wortspiel)
    Es werden die Logs an dritte gesendet und diese enthalten die IP Adresse (DSGVO relevantes Datum).
    Der Umgang zählt, nicht das tool. Darum nochmal:

    "Am Ende geht es also weniger um „das Tool ist böse“, sondern um Transparenz, Einwilligung und Kontrolle."

    Meine Kritik ging eher in Richtung der externen Dienste, die dann Banns offenlegen oder mit anderen Betreiben sharen - also die relevante Profilbildung

    Grüße
    Phil

    Da ich das Thema spannend finde, habe ich parallel ein Gespräch mit ChatGPT dazu geführt und teile das hier einfach mal:

    Das stimmt.
    Was allerdings eine ganz andere Dimension ist - wie du auch richtig sagst - sind Systeme wie z. B. WhalleyBot.

    Hier reden wir nicht mehr nur über lokale Serverlogs, sondern über eine zentrale Instanz, die serverübergreifend aktiv Daten sammelt und auswertet. Wenn ein Betreiber daran teilnimmt, werden Informationen nicht mehr nur lokal verwendet, sondern potenziell mit Hunderten anderen Servern geteilt bzw. korreliert.

    Und genau da stellen sich berechtigte Fragen:

    • Wer ist eigentlich verantwortlich für die Datenverarbeitung auf Seiten von Whalley?
    • Welche Daten werden konkret übertragen – nur Steam-ID oder auch IP, Verhalten, vollständige Logs?
      (Meiner Erfahrung nach: vollständige Logs mit allem, was das Spiel hergibt.)
    • Gibt es eine transparente Information für die Spieler?

    Sobald Daten an Dritte weitergegeben werden – insbesondere an eine einzelne Person und nicht an ein klar definiertes Unternehmen (idealerweise innerhalb der EU) - bewegt man sich zumindest im europäischen Raum (Stichwort DSGVO) in einem sehr sensiblen Bereich.

    Denn auch wenn eine Steam-ID für sich genommen oft nicht als direkt personenbezogen angesehen wird, kann sie durch die Kombination mit anderen Daten sehr wohl personenbeziehbar werden. Und genau das passiert bei zentralen Bannsystemen:
    Durch die Verknüpfung über viele Server hinweg entsteht faktisch ein Profil.

    Das eigentliche Risiko liegt also nicht beim einzelnen Server oder Admin, sondern in der Zentralisierung und Korrelation von Daten über viele Communities hinweg – vor allem dann, wenn Nutzer davon nichts wissen oder keine Möglichkeit haben, dem zu widersprechen.

    Am Ende geht es also weniger um „das Tool ist böse“, sondern um Transparenz, Einwilligung und Kontrolle.
    __________

    Wir für unseren Teil setzen deshalb seit 6 Jahren auf eine Inhouse-Lösung und verarbeiten Logs ausschließlich lokal. Es erfolgt keine Weitergabe an Dritte mit Korrelationsmöglichkeiten oder globalen Bannsystemen.
    Ich rate auch anderen Serverbetreibern davon ab, solche globalen Bannlisten zu nutzen oder Daten dorthin zu übertragen. Am Ende sind das nichts anderes als Pranger - oft sogar öffentlich einsehbar, inklusive Banngrund, Videos usw.

    Phil

    Ja, leider hat das jeder Admin und es ist schon genügend MIssbrauch damit getrieben worden. Es wurden schon genügend Spieler, unberechtigt oder aus fadenscheinigen Gründen, von einem fahrlässigen Serverbetreiber gebannt. Das hat leider Auswirkungen auf das joinen von anderen Servern.

    Gerade deshalb sollten die Werkzeuge die Serverbetreibern in die Hand gegeben werden, mit Bedacht ausgewählt werden.
    Bei der IP-Adresse muss ich Dir leider widersprechen. Er hat maximal die IP-Adresse meines Routers und die kann jeder sehr leicht ändern. Aber das ist techn. notwendig.

    Die Steam-ID wäre nicht notwendig. Aber genau da liegt der Hund begraben. 1x fälschlicherweise des Cheatens beschuldigt oder von einem Server gebannt, trägt man eine rote Flagge mit seiner Steam-ID herum. Und die wird man nicht mehr los. Nur durch ein neues Steam Konto.

    Du darfst dabei aber zwei Dinge nicht vermischen:
    die technischen Möglichkeiten eines Systems und den möglichen Missbrauch durch einzelne Betreiber.

    Missbrauch ist leider nie vollständig auszuschließen - egal ob mit oder ohne dieses Tool. Ein Serverbetreiber, der willkürlich bannt, braucht dafür weder zusätzliche Daten noch besondere Werkzeuge. Das liegt nicht an der Technik, sondern am Verhalten der Person, wann er bannt und warum.

    Was die „rote Flagge“ angeht:
    Diese entsteht nicht durch Serverlogs oder einzelne Community-Server, sondern ausschließlich durch offizielle Systeme wie z. B. Valve Anti-Cheat oder Maßnahmen direkt durch den jeweiligen Spieleentwickler.
    Ein privater Server kann keine globale Markierung auf einer Steam-ID hinterlassen.

    Ein Bann auf einem Server bleibt also genau dort – lokal.
    Andere Server sehen das nicht, es sei denn, sie betreiben bewusst eigene, separate Bannlisten (was dann aber wieder eine ganz andere, freiwillige Struktur ist).

    Und genau hier liegt der wichtige Punkt:
    Das Tool selbst verändert nichts an dieser Situation. Es macht keine neuen Daten sichtbar, sondern stellt lediglich bereits vorhandene Informationen übersichtlich dar.

    Wenn man also über Risiken sprechen möchte, dann sollte man eher über den Umgang mit Adminrechten sprechen. Warum ist in SCUM jeder "Admin" gleich Admin, mit vollen Rechten und vollen Informationen - HIER wäre ein Anfang zu machen, in feinkörniger Rechteverwaltung - nicht über ein Tool, das im Grunde nur Logs lesbarer macht. Aber das kann nur gamepires implementieren.

    Phil

    Dedicated Server... und die TPS gehen schon bei 20 Spielern runter - und damit geht das Spiel in den "predictive Mode". (was ischel beschreibt)
    Es rät also nur noch und fängt an, refreshes zu priorisieren. Mit dieser Flickschusterei MÜSSTE man das "PvP" eigentlich streichen.

    Irgendwie gerade wenig befriedigend.

    phil