Featurewünsche für LegacyClonk

Mir würde noch einfallen dass man Savegames die kaputt sind automatisch fixen lassen könnte. Der Frame muss ja immer ein Vielfaches des Ticks sein. das könnte die Engine doch eigentlich selbst bearbeiten, oder?

Nebenbei wäre noch nett wenn man die KI Funktionen der Clonks überladen könnte, bzw. mit Callbacks unterbinden. Mich nervt es dass bei aktivierter Energieregel immer versucht wird einen Leitungsbausatz an die Werkstatt anzuschließen.
Bei einem Energiesender braucht man keine Leitungen.

1 „Gefällt mir“

Gute Idee. Noch besser wäre es natürlich, den Bug zu fixen, aber auf jeden Fall sollten Savegames ohne manuelles Bearbeiten spielbar sein.

Da bin ich mir nicht sicher, ob man das nicht bereits über die richtigen Überladungen im Script lösen kann.
Auf die Schnelle fällt mir ein, dass man eventuell was mit ControlCommandAcquire, oder vielleicht mit Initialize im entsprechenden Gebäude machen könnte.

Erstmal Hut ab! Nach all der Zeit freut es mich, dass die Entwicklung von Clonk immer noch voranschreitet, und was für tolle Features schon hinzugefügt wurden.

Ich weiß nicht, ob es in Zeiten moderner Hardware noch ins Gewicht fällt, aber die Gemeinschaftskonto-Regel hat mehr Frames gekostet als die meisten anderen Objekte im Originalpack.

Das ständige Beobachten, Synchronisieren und Überschreiben der Kontostände ist ziemlich hackig. Wenn die Engine selbst Gemeinschaftskonten unterstützen würde, würde einiges an Rechenaufwand und Bugrisiken wegfallen.

Außerdem hatte ich mal das Brennstoffsystem (Hochofen und Kraftwerk) erweitert.

  • Somit können neue Objekte mit einer einfachen Callback-Funktion als Brennstoff definiert werden;
  • der Brennstoff-Sammel-Befehl vom Clonk ist entsprechend verallgemeinert;
  • Restenergie geht nicht verloren (wenn z. B. ein ganzes Fass Öl für ein Stück Erz verbrannt wird);
  • die clunker-effizientesten Brennstoffe werden zuerst verbraucht;
  • und neue Gebäude können mit einer Include-Bibliothek Brennstoff benutzen (+ Kraftwerk und Hochofen haben weniger doppelten Code).

In einigen edge cases trat noch komisches Verhalten auf, aber bei Interesse möchte ich diese Bibliothek gerne beitragen.

Performance-Probleme sind mir zwar mit der Gemeinschaftskonto-Regel noch nicht aufgefallen, ein Bug allerdings schon.
Werden wir eventuell für ein späteres Update in Betracht ziehen.

Das Brennstoffsystem klingt sehr interessant und könnte in einem späteren Update bei einer Erweiterung von Objects.c4d (diese Erweiterung müssten aber Szenarien ebenfalls explizit aktivieren) inkludiert werden.

Ist, wie Der Tod bereits geschrieben hat, mit ControlCommandAcquire möglich (und mMn auch die sauberste Lösung) - mit ControlCommand* lässt sich die Engine-KI bereits ziemlich stark an die eigenen Wünsche anpassen.

Danke für die Hinweise :+1:

:heavy_check_mark: Featurewunsch von Funni #1:
Ich will meine Ladestatusanzeige zurück. Ich will wissen, wann ich bedenkenlos starten kann, wenn ich noobs oder fremdsprachige Nutzer in der Lobby habe

1 „Gefällt mir“

Featurewunsch von Funni #2: Abfrage “Paket speichern”
Nutzer sollen bei Paketen z.B. > 20 MB beim Eintreten in die Lobby gefragt werden, ob sie das Paket dauerhaft speichern möchten.

Featurewunsch von Funni #3: Text im Chat kopieren
Text sollte zumindest in der Lobby aus dem Chatfenster kopiert werden können

1 „Gefällt mir“

Featurewunsch von Funni #4: Wichtig!!! URLs öffnen
URLs sollten per Mausklick geöffnet (An den Browser übergeben) werden können, um Neulingen schnell und unkompliziert Hilfestellungen geben zu können. Gerne mit Linkwarnung.

1 „Gefällt mir“

Featurewunsch von Funni #5:
/alert mit sound (und Spambegrenzung), damit man auch was mitbekommt, wenn man gerade Youtube Vollbild schaut

So das war’s glaub ich erstmal :slight_smile:

Featurewunsch von Funni #6:
IPv6 Support (Backporting von Openclonk)

Da Luchs den Spamfilter so streng eingestellt hat ^^

Featurewunsch von Funni #7: Portcheck z.B. durch Masterserver
Realisiert so, dass bei der Anmeldung am Masterserver dieser die Ports des anmeldenden Hosts kurz testet und einen entsprechenden Report für den Client bereitstellt.
Konkret entweder:

  • HTTP Anfrage -> Rückgabewert ist eine URL mit einem randomteil, Masterserver checkt und stellt den Report z.B. im JSON-Format bereit -> Client ruft den Report nach einem festgelegten Timeout ab -> Report wird beim Masterserver nach X Sekunden gelöscht
  • PHP-Script läuft so lange, bis der Check durch ist (ergo HTTP-Request dauert an) und gibt die Daten dann im Abschluss z.B. im JSON-Format an den Client aus

Als Option wäre eine Opt-Out Lösung nicht schlecht

2 „Gefällt mir“

Da Luchs den Spamfilter so streng eingestellt hat ^^

kA wie das funktioniert, das sind die Standardeinstellungen.

Featurewunsch von Funni #7: Portcheck z.B. durch Masterserver

Mit UDP hole punching ist das halt nur mäßig nützlich. Ports öffnen ist damit meistens unnötig, sodass eine einfache Überprüfung wie du sie vorschlägst meistens fehlschlagen wird. Der Erfolg des hole punchings hängt aber von Firewall und NAT auf beiden Seiten ab. Es ist also im Allgemeinen nicht möglich, eine gute Vorhersage zu geben, ob die Verbindung klappen würde.

Zugegebenermaßen könnte zumindest erkannt werden, wenn eine Verbindung auf gar keinen Fall möglich ist. Ich gehe aber davon aus, dass das zumindest in Heimnetzwerken eher selten der Fall ist. Für andere eingeschränkte Netzwerke (Hotspots oder bei der Arbeit) würde wohl auch schon eine Warnung ausreichen, wenn keine Verbindung zum netpuncher möglich ist, weil diese Netzwerke oft auch ausgehende Verbindungen filtern.

Als ich den OC-Netpuncher gebaut habe, hatte mich vor allen Dingen abgehalten, etwas derartiges hinzuzufügen, dass der Server dann eine zweite IPv4-Adresse brauchen würde. Die sind relativ teuer für den geringen Nutzen hier.

Hole punching ist schon implementiert?
Ich schlug ja keine NAT-Traversal Implementation vor, sondern “nur” eine Überprüfung, ob der vom anmeldenden Host angegebene Port (TCP und UDP) von außen erreichbar ist. Ob der Masterserver also tatsächlich mit einem Clonk-Client spricht (oder meinentwegen reicht notfalls auch bei TCP zu prüfen, ob es ein SYN-ACK gab). Wenn der Test fehlschlägt, kann man das ja entsprechend an den Client (der die Verbindung parallel ja auf DPort 443 aufgebaut hat zurückgeben)

Ich mein, ich sehe doch die ganzen 2er-Spiele, die wahrscheinlich noch Hamatchi o.ä. nutzen, bei denen man partout nicht joinen kann.

Hole Punching ist in OC schon implementiert und dürfte einfach zu portieren sein. Was du vorschlägst, ist in jedem Fall eine Neuentwicklung.

Benötigt aber nur eine IPv4 :stuck_out_tongue_winking_eye: und sollte in allen Fällen ein korrektes Ergebnis zurückgeben. Ist halt weniger unter “NAT-Durchdringung” sondern eher unter “Analyse” einzuordnen

Es gibt bereits CREMA, das kann immerhin den TCP-Part überprüfen.

1 „Gefällt mir“

sollte in allen Fällen ein korrektes Ergebnis zurückgeben

Nein, eben nicht. Wenn jemand keine Port-Weiterleitung eingerichtet hat, NAT/Firewall aber Hole Punching zulassen, ist das Ergebnis deines Vorschlags nicht korrekt. (Übrigens auch schon mit dem netpuncher, den CR so wie es ist unterstützt.)

Du findest meinen Vorschlag (Benutzern, die ihre Firewall(s) nicht richtig konfiguriert haben eine Meldung anzuzeigen) also nicht gut, weil die Erkennungstechnik (Portcheck) mit einer noch nicht implementierten Technik (Hole Punching), welche das Verbinden zum Host in nicht allen Fällen und nur über UDP ermöglicht nicht gut, weil diese Erkennungstechnik nicht mit Hole Punching kompartibel wäre und es zu fehlerhaften Meldungen kommen könnte?
Verstehe mich nicht falsch, ich habe nichts gegen Hole Punching es ist für mich aber keine optimale Lösung:

  • Ich schließe keine Kombination der Techniken aus, wo eine UDP-Verbindung auch durch den Hole Puncher getestet wird.
  • Wir haben bereits CREMA (Danke @Kanibal, davon wusste ich nichts), welches „nur“ eingebunden werden müsste (ich sag das so leicht ich weiß…)
  • Nehmen wir an, dass Hole Punching funktioniert, ändert das nichts an der Tatsache, dass der Host seine Firewall nicht ordnungsgemäß konfiguriert hat. Die Verbindung muss nicht zwingend klappen.

Eine Meldung mit fehlgeschlagenem Hole Punching und geschlossenen Ports könnte dann so lauten:

Der Masterserver [oder „Wir haben“] hat festgestellt, dass deine Firewall nicht richtig konfiguriert ist. Die von deinem Client an dem Masterserver gemeldeten Ports

  • TCP 11112
  • UDP 11113
    [wieder einrücken] sind von außen nicht erreichbar. Das Umgehen der Firewall mittels Hole Punching schlug ebenfalls fehl. Dies bedeutet, dass sich deinem Spiel aus dem Internet kein Spieler anschließen kann, da du von außen nicht erreichbar bist. Lokale Mitspieler in deinem Netzwerk sind davon nicht betroffen [hier z.B. Fußnote mit Mousehover „Gilt nur, sofern deine PC-Firewall die Verbindungen zulässt.“]

Die entsprechende Meldung mit erfolgreichem Hole Punching und geschlossenen Ports:

Der Masterserver [oder „Wir haben“] hat festgestellt, dass deine Firewall nicht richtig konfiguriert ist. Die von deinem Client an dem Masterserver gemeldeten Ports

  • TCP 11112
  • UDP 11113
    [wieder einrücken] sind von außen nicht erreichbar. Das Umgehen der Firewall mittels Hole Punching war allerdings erfolgreich. Da du unter bestimmten Umständen für Spieler aus dem Internet erreichbar bist, können sich deinem Spiel manche Spieler möglicherweise anschließen. Lokale Mitspieler in deinem Netzwerk sind von dem Problem nicht betroffen [hier z.B. Fußnote mit Mousehover „Gilt nur, sofern deine PC-Firewall die Verbindungen zulässt.“].

Die Überprüfung darf gerne in den Einstellungen dauerhaft deaktivierbar sein, die Meldung darf gerne „für dieses Netzwerk“ (erkennbar an ARP-Table → MAC des Gateways) deaktiviert werden können.

Hole Punching sollte eine Notlösung für unseren Spieler X sein, der sein Routerpasswort vergessen hat und Firewalleinstellungen mangels technischem KnowHow sowieso nicht hinbekommt.

Edit: habe nochmal gesucht und es doch gefunden:

By default, Clonk uses port 11112 TCP and port 11113 UDP for game connections. For best speed it is recommended to forward both of these ports through your router or firewall.

https://wiki.openclonk.org/w/FAQ

An der Stelle sind wir wohl geteilter Meinung. Idealerweise sollte meiner Ansicht nach alles einfach so funktionieren, ohne dass der Spieler irgendwelche Konfiguration verändern muss. Manuelle Konfiguration sollte die Notlösung sein. Heimanschlüsse, wo man am Router sinnvoll etwas konfigurieren kann sind dank DS-Lite und anderen CGNAT-Verfahren sowieso am aussterben. Deshalb denke ich auch, dass Entwicklungszeit besser bei der Verbesserung der Hole Punching-Verfahren aufgehoben ist.

Die entsprechende Info aus der OpenClonk-Wiki ist nicht falsch - die Ports entsprechend freizuschalten kann durchaus sinnvoll sein, ist aber auch nicht unbedingt notwendig.

Aber wir sind hier sowieso eigentlich bei LegacyClonk, wofür du nicht mich überzeugen musst. Vielleicht baut’s ja jemand dafür.