Vor kurzem wurde die erste LC-Version releast.
Falls ihr Featurewünsche habt, die die im Release-Post beschriebenen Bedingungen erfüllen, könnt ihr sie hier vorschlagen und wir werden sie vielleicht in zukünftigen Updates einbauen.
Bedenkt aber bitte, dass wir kleinere Features höchstwahrscheinlich viel eher implementieren werden, als solche die einen riesigen Aufwand mit sich bringen.
Um bereits gestellte Feature-Wünsche anderer Leute zu unterstützen, gebt ihnen am besten einfach einen Like.
Ich beginne gleich mal mit ein paar Features, die ich schon für meine eigene Engine, allerdings zwingend und nicht optional eingebaut habe, um festzustellen, wie wichtig diese für euch wären.
Als erstes gibts ein verkleinertes UpperBoard. Ursprünglich stammt die Idee von @Jan.
Ich habe diese Modifizierung in einem seiner Screenshots gesehen und irgendwann nachgebaut.
Für LC wäre dies eine Option mit der jeder nach seinen Vorlieben zwischen “normal” und “klein” wechseln kann.
Als nächstes kommen Timestamps für Chat-Nachrichten.
Natürlich ebenfalls optional.
Ein Bild sagt bekanntlich mehr als tausend Worte:
Oder auch zwei:
Das hab ich zwar noch nicht implementiert, aber eventuell wäre es sinnvoll, dass man erst “Bereit” anhaken kann, nachdem alles fertig geladen wurde. Dieser Ansatz kommt wird in [332] enthalten sein.
Vermutlich wäre es aber besser, stattdessen noch ein anderes Icon anzuzeigen, solange der Client lädt und ihn trotzdem Bereit anhaken zu lassen, es allerdings erst anzuzeigen wenn er fertig geladen hat.
Kennt ihr das, dass man um zwei Clonks weiter zu wechseln drei mal die Taste drücken muss?
Und für jeden weiteren zusätzliche zwei mal?
In der Engine gibt es, wie für alle anderen Tasten auch, aus welchem Grund auch immer, eine Extra-Behandlung für das Doppeldrücken dieser Tasten. Allerdings macht das doppelte Drücken einfach nichts.
Das habe ich bis jetzt so “behoben” dass meine Engine beim Drücken einer der zwei Clonk-Wechsel-Tasten (nicht die Mehrfachauswahl, da gibts ja was eigenes für doppelt) immer 2 Tastendrücke sendet, damit es mit CR kompatibel ist.
In LC wäre dies natürlich einfacher zu lösen indem die Behandlung des doppelten Drückens entfernt wird, oder einfach bei doppeltem Drücken die Aktion für einfaches Drücken ausgeführt wird.
Letzteres ist die Lösung, die in EkeReloaded unter anderem für den Inventarwechsel verwendet wird.
Leute, die schonmal bei mir gejoint sind kennen es vielleicht:
Meine Engine fügt, wenn ich Host bin, bei jedem Szenario “ObjectsAppend.c4d” zu den Definitionen hinzu, um diverse Funktionalitäten hinzuzufügen, vorausgesetzt es wird ohne Liga gespielt.
Eins der wichtigsten Features daraus sind für mich diverse Kontextmenü-Einträge wie Betreten und Anfassen sowie Erweiterungen der Kontextmenü-Einträge Baustelle, Fällen und Leitung trennen und ebenfalls eine Erweiterung der Leitung-anschließen-Aktion.
Die Erweiterung besteht darin, dass für den Fall, dass mehrere Objekte in Clonknähe in Frage kämen, ein Auswahlmenü erscheint, in dem man wählen kann welches man meint.
Hinter anderen Gebäuden “verlorene” Dinge sind so kein Problem mehr. (Das Katapult ist nur da, damit das Menü aufgeht, da sonst bei nur einem Kandidaten direkt angefasst wird.)
Diese Erweiterungen sind allerdings sicher ein kontroverses Thema, da sie gewissermaßen eine Form von Cheating ermöglichen. Ich finde sie allerdings für entspanntes Siedeln oft sehr hilfreich.
Deshalb könnte sowas natürlich nicht standardmäßig für alle Szenarien aktiviert sein, da es gewisse Mechaniken zerstören kann.
Mein Vorschlag wäre, dass es als Standard-“Pack” verteilt wird, und vom Szenario explizit aktiviert werden muss. Entweder durch Eintragen als Definition oder einen neuen Wert in Scenario.txt oder ähnlichem.
Mit einer ähnlichen Technik wäre es denkbar, auch andere prinzipiell Kompatibilitätsbrechende Objektpaket-Erweiterungen zu machen.
Ebenfalls in ObjectsAppend habe ich eine Regel namens “Crewauswahl”, die ein Menü erstellt, mit dem man einzelne oder mehrere Clonks auswählen kann.
Sie bietet eine intuitivere Alternative zur “Mehrfachauswahl”-Taste und zum Auswählen mehrerer Clonks mit der Maus durch ein Auswahlrechteck.
Diese Funktionalität dürfte sogar ohne Kompatibilitätsprobleme direkt in der Engine implementiert werden können.
Da hochauflösende Bildschirme immer relevanter werden, wie wäre es mit Clonk in “High-DPI”?
Toll ist, dass gewisse Grafiken in Clonk tatsächlich in vergleichsweise hoher Auflösung vorhanden sind, wie zum Beispiel das Clonkporträt links oben, oder die meisten Pictures von Objekten für Nachrichten (wie der Wipf hier).
Text lässt sich natürlich auch sehr schön skalieren, und Partikel kommen schön rüber.
Insgesamt muss man aber wohl mit deutlicher Pixeligkeit leben.
Ich hoffe allerdings, dass dies auf echten High-DPI-Bildschirmen nicht so schlimm auffällt.
Ich habe leider keinen mit dem ich das Beurteilen könnte.
Interessanterweise hat GentleClonker (und auch manch andere Packs) erstaunlich hoch aufgelöste Pictures. GentleClonker wird auch erst richtig gut spielbar, immerhin soll man das mit einer Auflösung von 400x300 spielen):
Das ist eher ein Feature was viel Aufwand mit sich bringt.
Außerdem ist meine Implementierung leider nicht perfekt.
Bei nichtganzzahligen Skalierungsfaktoren entstehen manchmal 1 pixel breite (Bildschirmpixel) Lücken und bei manchen Objekten schaut am Rand der Grafik ein Teil der SolidMask oder von einem anderen Animationsframe heraus (ähnlich wie wenn man etwas mit SetCon() sehr groß macht).
Wenn man mit der Maus spielt, und eine sehr große Anzahl an Objekten auswählen will, um sie zum Beispiel in ein Gebäude tragen zu lassen stößt man relativ schnell an ein Limit, nachdem man nicht mehr mehr Objekte auswählen kann (wenn ich mich recht erinnere liegt das Limit bei 25, oder zumindest in dieser Größenordnung). Das ist ebenfalls eine Beobachtung die ursprünglich @Jan gemacht hat.
Es kann auch passieren, dass man an die Begrenzung der Befehlswarteschlangenlänge des Clonks stößt und der Clonk nur noch regungslos stehen bleibt.
Mein Vorschlag wäre, beide Limits großzügig zu erhöhen, da spätestens durch das Zulassen des Auswählens von sehr vielen Objekten sehr schnell auch die Befehlswarteschlangenlänge das Limit erreicht, da jedes ausgewählte Objekt schon einen Platz in der Warteschlange belegt.
Das Erhöhen des Auswahllimits haben wir bereits getestet.
Die Warteschlangenlänge konnten wir allerdings noch nicht erhöhen, da es sonst zu Desyncs gegenüber unmodifizierten Engines kommen würde.
Erstmal großes Lob, so ein Projekt hätte ich mir zu den Hochzeiten von Clonk Rage erhofft, eine schrittweise Weiterentwicklung statt einen harten Schnitt zu etwas völlig anderem hätte die Community von damals sicher mit Freude angenommen.
Mein Featurewunsch: Eine Form von Community-Präsenz innerhalb der Engine.
Muss nichts großes sein, Beispiele wären
Der Zweck des Ganzen ist einfach die Community, Spieler und Entwickler, Aktivität deutlicher anzuzeigen bzw. Entwicklern eine Fläche zur Anzeige ihrer Projekte, Szenarien und Objekte zu geben.
Die Hoffnung dahinter ist, die Schockstarre in der Community etwas zu lockern sowie neuen Spielern, denen “CCAN”, der Unterschied zwischen Open Clonk und Clonk Rage und andere Dinge mal absolut garnichts sagt, so auch eine erste Anlaufstelle zu geben.
Die Idee klingt prinzipiell gut, alles zusammen bringt aber wohl doch ein bisschen mehr Aufwand als ich mir fürs erste gewünscht hätte.
Weil das relativ viele Interaktionen mit anderen Servern beinhaltet, wäre es aber auf jeden Fall besser, davor noch eine gute HTTP(S)-Library anstatt des HTTP 1.0-Selbstbaus einzubauen, was sowieso generell schon halb eingeplant ist.
Gerade für CCAN und Clonkspot wärs natürlich gut wenn die jeweiligen Betreiber da etwas bereitstellen könnten, wobei ich mir da hauptsächlich bei CCAN sorgen mache.
Könntest du eventuell noch skizzieren, wie du dir das Layout-mäßig vorstellst?
Aber bitte behalte im Hinterkopf, dass Layouting in der Engine eher mühsam ist (man muss die ganze Aufteilung quasi selber ausrechnen), also dass es eher simpler gehalten werden wird.
Danke dafür. Ich hätte es mir auch früher gewünscht, allerdings sind dafür zumindest Fulgen und ich einfach zu spät auf die Welt gekommen. 
Abgesehen davon ist es sowieso “erst” vor wenigen Jahre überhaupt möglich geworden, als matthes uns beim letzten Update mehr Freiheiten gegeben hat.
Ganz abgesehen davon habe ich fast meine komplette Freizeit der letzten 5-6 (Osterferien-)Tage in die “letzten 20%” des Updates gesteckt und auch Fulgen war fleißig (Osterferien sei Dank). So viel Zeit aufzuwenden ist im normalen Alltag eher ziemlich schwierig. Nur damit klar wird, warum wir trotzdem noch so lange dafür gebraucht haben.
Was vielleicht die Entwicklung erleichtern würde wäre das Verwenden vorhandener grafischer Assets und Menüs, hier beispielsweise die Nutzung des Optonsmenü-Layouts um eine kleine Nachrichtenübersicht anzuzeigen.
Draufklicken öffnet die entsprechende Webseite im Standardbrowser - vielleicht kann man hier soweit gehen und den Textinhalt direkt in der Engine anzeigen, oder das direkte Herunterladen von CCAN-Inhalten anbieten, ähnlich dem Laden von Szenarien und Objekten von hostenden Spielern.
Auf jeden Fall würden wir auf bestehende GUI-Elemente setzen.
Das sieht soweit recht machbar aus, aber zumindest ich selber will mich vorerst auf andere Dinge konzentrieren.
Es hängt also vorerst von den anderen Entwicklern ab, ob und wie schnell sowas implementiert wird.
Könntest du eventuell diesen Post mit dem anderen zusammenfügen, und evtl. wichtige Ausschnitte unserer Unterhaltung einbetten?
Dann könnten wir unsere getrennten Posts hier löschen damit es übersichtlich bleibt (weil es ja leider keine Baumstruktur hier gibt ).
Auch ein Lob von mir.
Ich hab mir noch ein paar Gedanken über Chat-Featurewünsche gemacht (ich mag den weißen Chat und die Timestamps)
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:
Da Like-Abstimmung bei mehr als einem Feature pro Post nicht funktioniert (Wer nichts davon will: nicht abstimmen):
0 Teilnehmer
Ich bin dafür, es standardmäßig zu aktivieren.
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.
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.
