Ich hab mir noch ein paar Gedanken über Chat-Featurewünsche gemacht (ich mag den weißen Chat und die Timestamps)
Weißer Chat für Lobby
Scrollen in Lobby mit Bild-Hoch / -runter Taste (vielleicht mit ein paar Zeilen Kontext)
Eigentlich kann man aber auch starten ohne dass alle fertig geladen haben, es lädt dann ja nach.
Ein wichtiger Unterschied dabei ist aber, dass man nicht auf das Speichern-Symbol klicken kann und das Szenario so nicht dauerhaft gespeichert wird.
Deswegen, noch ein Featurewunsch:
Noch nicht vorhandene Szenarien und Objektpakete werden automatisch gespeichert, wenn schon vorhanden bekommt man die Überschreiben-Anfrage automatisch
Da Like-Abstimmung bei mehr als einem Feature pro Post nicht funktioniert (Wer nichts davon will: nicht abstimmen):
Weißer Chat in Lobby
Scrollen mit Bild - Tasten
Automatisches Speichern von Szenarien und Objekten
Ich vermute, dass es mehr Szenarien gibt, in denen man das brauchen kann (z.B. alle Siedelszenarien), als es Szenarien gibt, in denen es die Spielmechanik kaputtmacht (da fällt mir gerade nur Turm der Verzweiflung ein). Also muss man weniger Szenarien ändern.
Ich denke nicht, dass es Cheating ist, wenn meine Clonks endlich mal das tun, was ich ihnen schon die ganze Zeit sagen will
Das stimmt, aber es ist doof dass die Clients nicht wissen was los ist und man keinen Chat hat.
Natürlich könnte man diese Nachteile auch beheben versuchen, aber vorerst so ein Icon zu haben wäre aufwandsmäßig viel attraktiver.
Ja, deshalb ist es bei meiner eigenen Engine auch immer aktiv, aber es widerspricht halt dem Ziel 100% dasselbe Spielerlebnis zu bieten und würde auch Vorteile in der Siedelliga bringen.
Da fände ich es besser, wenn man als Host irgendwie die Möglichkeit hat die Erweiterung einfach trotzdem zu aktivieren (zum Beispiel ein Button bei der Szenarioauswahl), solange es ohne Liga ist.
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.
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.
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
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 #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.
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
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.
Benötigt aber nur eine IPv4 und sollte in allen Fällen ein korrektes Ergebnis zurückgeben. Ist halt weniger unter “NAT-Durchdringung” sondern eher unter “Analyse” einzuordnen
Featurewunsch von Funni 
und sollte in allen Fällen ein korrektes Ergebnis zurückgeben. Ist halt weniger unter “NAT-Durchdringung” sondern eher unter “Analyse” einzuordnen