header YouTube
Clonk Livestream auf Twitch.tv!

Clonkspot

Featurewünsche für LegacyClonk

#21

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.

0 Likes

#22

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.

0 Likes

#23

Danke für die Hinweise :+1:

0 Likes

#24

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 Like

#25

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.

0 Likes

#26

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

0 Likes

#28

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.

0 Likes

#29

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:

0 Likes

#30

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

0 Likes

#31

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.

0 Likes

#32

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.

0 Likes

#33

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

0 Likes

#34

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

0 Likes

#35

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

1 Like

#36

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.)

0 Likes

#37

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

0 Likes

#38

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.

0 Likes

#39

Das sollte auf alle Fälle immer das höchstpriorisierte Ziel sein, sofern es irgendwie möglich ist.

Abgesehen davon hat es sich als unglaublich schwer herausgestellt, einem relativ ahnungslosen Clonk-Neuling zu erklären wie man Ports weiterleitet, damit er mit seinen Freunden zusammenspielen kann.
Dabei bekommen wir da wohl auch nur den Teil mit, der es in den IRC schafft.

Das einzige was mir an der “Hole-Punching wirds schon richten”-Einstellung nicht gefällt ist, dass es meines Wissens nach als unmöglich angesehen wird, zwischen zwei symmetrischen (hoffentlich habe ich den richtigen Begriff in Erinnerung) NATs zu punchen und generell ein symmetrisches NAT auf Host-Seite alles ziemlich verkompliziert.

Ich weiß zwar nicht wie das im Allgemeinen aussieht, aber angenommen ich hab meine manuellen Experimente sinnvoll durchgeführt und richtig interpretiert, sind sowohl das NAT das der Router vom A1-Festnetzanschluss zuhause macht (Port-Forwarding geht aber), sowie das NAT, über das mein mobiles Internet läuft symmetrische NATs.

Allerdings hab ich noch nicht probiert ob OCs-Hole-Punching bei diesen NATs funktioniert.
Das werde ich eventuell irgendwann noch nachholen.

0 Likes

#40

Hmm da habt ihr auch wieder recht.

Gehe ich richtig in der Annahme, dass mit IPv6 Unterstützung das NATten wegfiele und somit in einem SoHo-Netzwerk die einzige Hürde die lokale Firewall wäre? Ich hab halt etwas Bauchschmerzen eine Verbindungstechnik zu nutzen, die bei manchen funktioniert und bei manchen nicht.

0 Likes

#41

Ja, genau. Kein NAT mehr, es muss nur noch die Firewall überwunden werden, was aber zumindest für UDP exakt genauso funktioniert wie die NAT-Durchquerung. TCP dürfte mit IPv6 sogar auch machbar sein, das habe ich aber noch nicht implementiert. (Mit IPv4 braucht man da Heuristiken zur Portvorhersage.)

Du hast aber recht, dass es kein Wunderheilmittel ist. Ich würde es eher als eine Ergänzung sehen, die es zusätzlichen Spielern ermöglicht, online zu spielen (eben die Spieler, bei denen die NAT-Durchquerung nicht klappt, aber die einen IPv6-Anschluss haben). Diese Gruppe ist zugegeben aktuell nicht groß, das wird sich aber mit der Zeit bestimmt ändern (IPv6-Verwendung steigt, während die IPv4-Adressen knapper werden).

0 Likes