Wie auf unserer [Projektseite auf dem CCF](http://www.clonkforge.net/pr.php?pr=1538) schon zu sehen ist, wollen wir auch einen weiteren Schritt in Richtung OpenClonk wagen und die Aktivität stärken. Windmill soll in erster Linie ein Client werden, der Schwierigkeiten bei der Content-Entwicklung mit OpenClonk ausmerzen soll und eine Anregung zur Erstellung neuer Projekte in OpenClonk sein soll.
Zuerst möchte ich jedoch noch ansprechen, warum wir neben dem Clonkforge auch die Miniblogsektion von Clonkspot benutzen. Und zwar wollen wir hier etwas weiter ins Detail gehen, alles genauer erläutern und auch zukünftige Pläne und Hoffnungen erwähnen, die eventuell auch verworfen werden. Dieser Thread kann auch nützlich für Meinungsumfragen und allgemeiner Meinungsäußerung sein, besonders dank der Baumstruktur. Das wars hierzu, weiter zum eigentlichen Thema.
Windmill ist ein auf [XUL](http://de.wikipedia.org/wiki/XML_User_Interface_Language) basierter Client der über Mozillas Gecko Engine läuft. Die Technik mag bei Weitem nicht mehr die modernste zu sein und ist mit Sicherheit allgemein nicht die beste Wahl um ein solches Programm zu schreiben, aber da unsere Kenntnisse sich hauptsächlich auf Sprachen zur Webentwicklung beschränken (HTML, Javascript, …) war es die einzig gute Möglichkeit, die uns bekannt war. (Wir hatten vorher schon mit Adobe AIR rumprobiert, wo wir jedoch sehr schnell an Grenzen gestoßen sind. Zudem gab es massive Performanceprobleme) Obwohl der Client auf XUL basiert, besteht der Client zu einem großen Teil auch aus HTML5-Frames.
Die Idee hinter Windmill war es, eine Entwicklungsumgebung auf die Beine zu stellen, die sich tatsächlich an die Entwicklung mit OpenClonk orientiert, da diesem einfache Möglichkeiten des alten Clonk Editors fehlen. Hierzu sind schon allerlei Ideen aufgekommen, die jedoch zum großen Teil nur Gedankenspielereien sind. Die Verwirklichung dieser ist nicht garantiert. Neben dem schon vorhandenen Scripteditor, wollen wir – nach Möglichkeit – die folgenden Features einbauen:
* Bilder bemessen. Dieses Tool soll die Arbeit mit Sprites deutlich vereinfachen. Es können Raster schnell eingeteilt werden, die direkt in die jeweils passende Information umgearbeitet werden können, um ActMaps, Partikel und vergleichbares einfacher aufstellen zu können. Außerdem können Rechteck-Informationen und weiteres direkt Abgegriffen werden. Für weitere Bildbearbeitung können die Bilder mit nur einem weiteren Klick oder per Shortcut direkt im gewohnten Bildbearbeitungsprogramm geöffnet werden.
* Zusätzlich zum Bilder bemessen, wird ein allgemeines Tool für Grafikabhängige Objekt-Properties gestellt. Nach dem Setzen des Offsets auf die Objektgrafik, können so bspw. Vertices direkt auf der Objektgrafik bestimmt werden, was einem viele Rechnereien erspart.
* Ein FolderMap-Ersteller.
* Ein integrierter Meshviewer
* Ein Bearbeitungsprogramm für BMP-Dateien um Landschaften nachbearbeiten zu können, ohne dass die Materialien am Ende falsch sind.
* Ein RTF-Editor, um nicht unbedingt jedes Mal ein externes Programm zur Bearbeitung zu öffnen. Dieser brauch nicht besonders viele Funktionen besitzen, da diese sowieso kaum benutzt werden.
Für den Spielmodus sind neben der Spieleübersicht und dem Hosten von Spielen auch weitere Ideen geplant:
* Ein Benachrichtigungssystem, dass nach eingestellten Mustern sucht und den Benutzer über geöffnete Spiele informiert und eine Quick-Join-Funktion zur Verfügung stellt. Hierbei soll es möglich sein, Windmill auch in einen Performanceschonenden Zustand zu fahren, um Ressourcensparend den Masterserver zu durchforsten.
* Ein direkt vorhandener Downloadclient, mit dem es möglich sein soll, Clonkinhalte direkt herunterzuladen. Eine Kooperation mit B_E’s Lorry wäre von unserer Seite aus natürlich gerne gesehen. Da Windmill bereits auf XUL/HTML basiert, und somit über eine Web-/Downloadschnittstelle verfügt, bestehen scheinbar kaum wirkliche Probleme bei einer Umsetzung.
* Sollte Windmill soweit sein, dass es auch von Clonk-Neulingen benutzt wird, wäre auch eine direkte Umsetzung eines IRC-Clients denkbar und sicher auch nicht falsch. Ansonsten wäre das vermutlich eher nutzlos.
* Anzeigen von FolderMaps für das HostGame-Modul, da diese ein nettes Feature sind und gerne auch in Windmill weiterhin vorhanden sein sollen. Im ersten Release wird dies wahrscheinlich nicht vorhanden sein.
Windmill soll zudem, wenn alles wie geplant verläuft, auch für Linux verfügbar sein.
Leider wird Windmill auch ein paar Nachteile haben, wie beispielsweise dass gepackte Verzeichnisse nicht eingelesen werden können. Die Umsetzung erwies sich mit den gegebenen Mitteln einerseits als schwierig, andererseits als durchaus Ressourcenaufwendig. Daher haben wir uns dafür entschieden, dass das Clonkverzeichnis zur Bearbeitung durchgehend komplett entpackt sein muss, was – wenn nicht anders eingestellt – bei Start des Programms automatisch geschieht.
Wir sind natürlich gerne für Fragen, Kritik, Meinungen, Anregungen und Diskussionen offen und versuchen darauf so gut wie es möglich ist einzugehen.
Wie sieht es mit einem Syntax-Check für die Scripts aus? Diese Funktion finde ich beim Eclipse-Plugin nämlich sehr sehr nützlich!
Ist mitunter auch geplant. Der Ace-Editor verfügt wohl über so eine Funktion, da müssten wir uns nur entsprechend weiter reinarbeiten.
Hört sich interessant an und die Screenshots sehen schonmal gut aus.
>Leider wird Windmill auch ein paar Nachteile haben, wie beispielsweise dass gepackte Verzeichnisse nicht eingelesen werden können. Die Umsetzung erwies sich mit den gegebenen Mitteln einerseits als schwierig, andererseits als durchaus Ressourcenaufwendig. Daher haben wir uns dafür entschieden, dass das Clonkverzeichnis zur Bearbeitung durchgehend komplett entpackt sein muss, was – wenn nicht anders eingestellt – bei Start des Programms automatisch geschieht.
Wo ist denn das Problem? Zumindest das Lesen sollte doch relativ schnell gehen?
Hängt insbesondere mit den Begrenzungen zusammen, die XPCOM mit sich bringt: Wir können nicht c4group -v benutzen, da die Ausgabe nicht erfasst wird, weshalb wir entweder was eigenes zum Auslesen der Groupdateien brauchen oder wir müssten den Inhalt temporär entpacken, was wahrscheinlich sowieso passieren müsste um eine Preview anzeigen zu können. (Beispielsweise zum Hosten der Spiele) Ersteres lässt sich leider nur schwer umsetzen, zumindest hat von uns sich keiner damit auseinandergesetzt, wie die Groupdateien aufgebaut sind. Ob wir die Zeit und Lust dazu finden werden, zweifle ich auch an. Und dann wäre noch die Performancefrage da, da das Verarbeiten der Informationen über einer Javascript-Engine laufen würde.
Solange sich dafür keine Lösung findet, werden wir vermutlich bei der Alternativlösung bleiben.
C4Group-Dateien lassen sich eigentlich ganz einfach selbst entpacken. Hab mich vor einer Weile mal damit beschäftigt und die Dateistruktur ins Wiki eingetragen: http://wiki.nosebud.de/wiki/C4Group. Das größte Problem beim Lesen dürften die veränderten Magic Bytes sein (C4Group-Dateien sind eigentlich Gzip-Archive). In C# z. B. habe ich dazu einen GZipStream benutzt, der als Eingabestream einen Stream bekommt, der die Magic Bytes des tatsächlichen Eingabestreams ersetzt. Der Rest sollte dann eigentlich kein Problem mehr sein.
Klingt gut, macht mal!
github link plz? 
Hey, coole Sache. Über die Lorry-API gibt es bald ein paar Infos, aber im Prinzip könnt ihr damit alle Daten von Erweiterungen und Releases auslesen, die es auch auf der Seite gibt und die Downloadlinks abfragen. Der Download wird auch standardisiert, damit man immer entweder direkt eine c4*/oc*, oder eine Zip mit vorgegebener Struktur, damit ihr das programmatisch entpacken könnt, und eventuell generiert Lorry später auch c4u/ocus. Ich freue mich aber vor allem auf ein neues Spielerfrontend.
Außerdem sehr cooler Name 
Eine Sache die mir im Eclipse immer fehlt ist das auswählen der Spieler vor dem Start der Editor-Mode. Wäre schön wenn sowas endlich mal gebaut wird. Was ich aber bei Eclipse wieder sehr nett finde ist das ich jetzt zwei Script Editors neben einander aufmachen kann. Dieses Projekt sieht aber vielversprechend aus!
Ich habe mich bisher nicht großartig damit befasst, ich kanns mir ja nochmal genauer anschauen - allerdings bin ich mir auch nicht ganz sicher, ob das alles so gut oder einfach funktionieren würde.
Du hast gemeint dass es nur einfach wäre, Dateien zu lesen? Wie soll das dann mit der Speicherung funktionieren, wäre das sehr viel aufwändiger? Ohne Schreiben macht das ja glaub ich nicht viel Sinn für einen Editor.
Die Spielerauswahl ist aktuell in Arbeit und schon weitgehend fertig. (fehlt nur Design und die Möglichkeit Spieler zu ändern/erstellen) Sieht man zum Beispiel in den Screenshots oben rechts.
Zu der Sache mit den Scripteditors nebeneinander: Wie meinst du das denn genau? Ich denke, da lässt sich sicherlich was vergleichbares einbauen.
>Zu der Sache mit den Scripteditors nebeneinander: Wie meinst du das denn genau? Ich denke, da lässt sich sicherlich was vergleichbares einbauen.
So in etwa? Oder eben vertikal gesplittet. Zur Inspiration, wie das mit Tabs funktionieren kann, vielleicht mal Notepad++ oder Sublime Text angucken.
>Wie soll das dann mit der Speicherung funktionieren, wäre das sehr viel aufwändiger?
Das Problem beim Speichern ist, dass man zuerst die komplette Datei entpackt haben muss, um sie mit den Änderungen wieder neu zu packen. Das bedeutet, dass man entweder die Datei jedes mal beim Speichern komplett neu einlesen muss, oder sie die ganze Zeit im Speicher behält. Beide Optionen skalieren nicht besonders gut mit der Dateigröße.
>Ohne Schreiben macht das ja glaub ich nicht viel Sinn für einen Editor.
Doch, ich fände reinen Lesezugriff schon sehr hilfreich. Das Arbeiten auf gepackten Dateien funktioniert ja auch schon im Editor mehr schlecht als recht. Ich verwende den im Allgemeinen nur, um mal schnell Objektscripts oder DefCore-Einträge in fremden Objektpaketen nachzugucken.
Ja genau so, für mich dann vertikal gesplittet weil ich auf 3440x1440 arbeite.
Auf einem riesigen Display oder mit besonders hoher Pixeldichte?
Okay, Wow.
Ich hab seit Jahren mit zwei kleinen (19" und 17") 5:4/4:3-Monitoren jetzt seit Weihnachten ein 24"-Display, und das ist mir schon fast unangenehm groß. Ich ertappe mich immer wieder dabei, wie ich das 19"-Display weiterhin als primären Monitor zum Surfen usw. verwende 
War auch mein "Weihnachtsgeschenk", es ist etwas groß aber ich benutze es auch zum Filme schauen und da lohnt es sich schon. Aber Browser sind meistens zu 75% weiß 