
Der Editor sollte sich ähnlich verhalten, wie der alte Editor von CR. Bearbeitet die Datei je nach Laune. In den Optionen lassen sich Editoren für einzelne Dateitypen einstellen, wenn nicht das Windows-Standardverhalten gewünscht ist. Neben dem Startknopf sieht man das ausgewählte Szenario und ein Feld, um Startparameter festzulegen.
Derzeitige Version: 0.6 Beta - Hier klicken!

Ab jetzt Beta. Man kann anfangen, jetzt damit richtig zu arbeiten. Trotzdem empfehle ich dringend, Backups anzulegen! Ich habe kein Feedback über Bugs bekommen, daher nehme ich an, dass der Editor noch recht ungetestet ist.
Der Editor kann mit einer normalen OpenClonk Installation betrieben werden, solange Schreibrechte im OpenClonk Verzeichnis vorhanden sind.
Installation:
Dateien irgendwohin entpacken, wo es passt. Der Editor braucht Schreibrechte in diesem Ordner. Beim ersten Start müssen das OpenClonk Verzeichnis und OC .exe ausgewählt werden.
Änderungen in 0.6
- Dateioperationen auf der obersten Ebene sind nun möglich.
- Neusortierung nach einer Operation, die die Ordnerstruktur ändert (Umbenennen, Verschieben).
- Bug gefixt, dass Löschen von nicht-leeren Ordner nicht möglich war.
- Kopieren gefixt (es wurde stattdessen Ausschneiden ausgeführt).
- Buttonbereich neu geordnet, kleinere Buttons.
- %AppData%\OpenClonk\ wird im ersten Dateibaumeintrag angezeigt. Dateioperationen sind problemlos möglich.
- Quick Edit für Textdateien.
- Szenarieneditor.
Der Dateibaum sollte jetzt voll einsatzbereit sein. Die zwei neuen großen Features wären: Quick Edit und Szenarieneditor.
Quick Edit dient dazu, Textdateien direkt im Editor zu bearbeiten, ohne ein weiteres Programm öffnen zu müssen. Quick Edit ist sehr simpel, also keine besonderen Features wie Syntax Highlight o.ä.
Der Szenarieneditor ist ein simples Interface, um grundlegende Einstellungen zusammenzuklicken. Er wird überarbeitet, sobald die hier besprochenen Änderungen umgesetzt werden. Ich würde nicht empfehlen, bereits bestehende Szenarien ohne weiteres im Szenarieneditor zu ändern, da dieser Einträge (im Scenario.txt), die er nicht kennt, überschreibt.
Hotkeys:
CTRL+N - Neue Datei
CTRL+X - Ausschneiden
CTRL+C - Kopieren
CTRL+V - Einfügen
Delete - Datei löschen
F2 - Umbenennen
F5 - Dateibaum neu laden
CTRL+Space - Engine starten
CTRL+Z - Quick Edit zurück
CTRL+Y - Quick Edit vor
CTRL+S - Quick Edit speichern
Bekannte Fehler:
- Objects.ocd ist nicht geschützt! Wenn es geändert wird, kann man nicht mehr in Netzwerkspiele beitreten! Also aufgepasst.
- Man kann keine Objekte ins Sichtfenster ziehen in OC Version 2.2.0. Dies ist erst ab eb568b1771ac möglich, also mit dem letzten Dev Snapshot.
- Der Quick Edit Button zeigt noch kein Icon und ist deshalb schwierig zu sehen. Er ist hier:

Einschränkungen gegenüber dem Editor aus CR:
- Extern geänderte Dateien werden erst neu im Vorschaufenster geladen, wenn diese neu ausgewählt sind. Es ist nicht geplant, dies zu ändern, da ich den Kosten-/Nutzenfaktor für schlecht halte.
- Man kann nicht beliebige Objektpakete aktivieren und in der Engine laden. Der Editor kann dies, aber es ist deaktiviert, da die OC-Engine dies nicht mehr unterstützt. Es ist nicht geplant, dieses Feature zu reaktivieren, aus mangelndem Engine-Support.
- Der Editor kann gepackte Verzeichnisse nicht einsehen. Alles muss entpackt werden. Es ist nicht geplant, dies zu ändern.
TODO:
- Originaldateien schützen (Objects.ocd, ...)
- Wenn das OC Verzeichnis schreibgeschützt ist, sollte in %AppData% gearbeitet werden.
- Andere Editoren möglich (Landschaft, Material)
- Mesh Viewer einbauen, je nachdem, was damit machbar ist.

Mach bitte weiter

> AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys).
Das klingt nicht, als könnten wir in Sachen IDE-Entwicklung mit Unterstützung rechnen, um es vorsichtig auszudrücken.
Nichts gegen das Projekt (definitiv Respekt!) aber wenn mir hier etwas nicht wirklich einleuchtet, dann die Richtung. Wohin genau geht die Reise? Und wollen wir da wirklich hin? :/

Ich habe selbst lange auch nur auf Explorerbasis gearbeitet, misse dort aber spezielle für Clonk ausgelegte Funktionen. Deshalb:
> Nochmal den Windows-Explorer zu reimplementieren?
Eher ein Explorer, der speziell auf Clonk ausgelegt ist. D.h. ich habe schnellen Zugriff auf C4Group packen/entpacken (das hab ich mir im Windows Explorer zwar auch eingerichtet, aber das ist sicherlich keine Option für alle) und ich wähle ein Objekt nur im Fileexplorer an, um Grafik und Beschreibung sehen zu können. Ich kann mir eigene Editoren einstellen für alle Dateitypen, die in Clonk relevant sind. So kann ich z.B. Sounds/Musik mit Audacity öffnen, was ich im normalen Windowsbetrieb keineswegs als Standard einrichten will.
Ich kann auch kurz in Dateien reinschauen, weil mir deren Inhalt angezeigt wird, ohne dass ich ein Drittprogramm starten muss.
Zuletzt wähle ich mir einfach ein Szenario aus und starte die Engine. Ich muss mir kein .bat Script bauen und auch nicht wieder im Kontextmenü des Windowsexplorer rumhacken.
Das sind Funktionen, die mir den Einstieg erleichtern. Jedem, der intensiver scripten möchte o.ä., dem empfehle ich dann irgendwann Eclipse mal zu testen.
> Nochmal bizarrere technische Grundlagen zu verwenden?
Ich gebe zu, AutoIt ist nur meine erste Wahl, weil ich damit vertraut bin. Es hat eine einfache und gut zugängliche Implementation der WinAPI, was mir das GUI-Scripting möglich macht.
> Das klingt nicht, als könnten wir in Sachen IDE-Entwicklung mit Unterstützung rechnen, um es vorsichtig auszudrücken.
IDE ist definitiv zu hoch gegriffen für dieses Projekt. Verbesserter Explorer passt da schon eher. Welche Art von Unterstützung würdest du denn von AutoIt erwarten?
> Wohin genau geht die Reise?
Etwas einsteigerfreundliches soll her. Zugänglicher als Eclipse. Ich habe mit der Implementation der Irrlichtengine bisher nur rudimentär herumgespielt. Aber wenn es dann möglich sein sollte, Meshes darin anzusehen, hat der Editor einen großen Vorteil gewonnen. Weitere Idee von mir ist ein Landschafteditor ähnlich Mape.
Und Gruppen packen/entpacken sollte man ja nicht wirklich oft tun - entsprechend muss auch es auch nicht unbedingt super-komfortabel sein. Wenn man nicht am Explorer rumbasteln will, kann man dafür auch ein separates Tool verwenden.
> IDE ist definitiv zu hoch gegriffen für dieses Projekt
Für mein Verständnis ist das genau was du baust: Eine integrierte Entwicklungsumgebung. Die Idee ist ja schon, das Herzstück der Entwicklung zu werden. Du gibst vor, wie Dateien strukturiert sind und wie genau "Packen" und "Entpacken" funktioniert. Es ist in der Arbeitsweise auf jeden Fall schon mal inkompatibel mit Eclipse, wenn ich das richtig sehe... :)
> Welche Art von Unterstützung würdest du denn von AutoIt erwarten?
Nun, was auch immer sie in Zukunft mit ihrem Tool anstellen werden - dass dein Programm weiter funktioniert ist wahrscheinlich nicht ihre Priorität. Und wir werfen hier natürlich Portabilität gleich als erstes aus dem Fenster.
> Zugänglicher als Eclipse.
Eclipse ist nicht automatisch unzugänglich. Eventuell macht das Clonk-Plugin es komplizierter als es sein muss - ich verstehe beispielsweise nicht, warum man den Clonk-Pfad konfigurieren muss, wenn man dazu auch einfach nach den Clonk-Einstellungen suchen könnte.
> hat der Editor einen großen Vorteil gewonnen
Und wir alle das Problem gewonnen, dass wir den Code portieren müssen. Eclipse-Plugins haben wenigstens den Vorteil, dass sie relativ eigenständig gebaut werden können. AutoIt-Features sind auf lange Sicht gesehen toter Code. Wie gesagt, deinen Enthusiasmus in Ehren, aber mir behagt nicht, wohin das alles führt :/

> Es ist in der Arbeitsweise auf jeden Fall schon mal inkompatibel mit Eclipse
Ja, durchaus. Das sehe ich aber nicht als schlimm an. Müssen zwingend alle IDEs (wollen wir das mal so nennen) kompatibel sein? Alternativen bieten jedem genau das, was gewünscht ist, wenn eine Lösung nicht passt.
> Nun, was auch immer sie in Zukunft mit ihrem Tool anstellen werden
Mein Programm verwendet zunächst einmal kaum bis keine ausgefalleneren Techniken. Ich habe mit AutoIt schon vor 5 Jahren gearbeitet und Scripte von damals sind immer noch kompatibel. Auch wenn die Sprache vielleicht unbekannter ist, so haben die doch eine feste Community und bis jetzt Beständigkeit, so dass ich nicht erwarte, dass mein Code morgen inkompatibel wird. Wenn dies in 3 Jahren o.ä. geschieht, was solls, dann muss was anderes her.
> Und wir werfen hier natürlich Portabilität gleich als erstes aus dem Fenster.
Ja. Portabilität kann ich nicht bieten, weil ich im Prinzip keine Sprache kann, die portabel ist. Dafür muss Eclipse eben herhalten und da wir ein solches Tool haben, sehe ich noch nicht das Problem, dass meines nur unter Windows läuft. Mit dem Editor will ich gewiss keinen Standard festlegen, sondern nur "ein Programm von vielen" bereitstellen.
> Eclipse ist nicht automatisch unzugänglich.
Das kommt immer auf die Person drauf an. Die Idee für den Editor habe ich nicht völlig aus der Luft gegriffen. Viel mehr habe ich mit mehreren Leuten in #openclonk gesprochen, die hereinkamen und fragten, wie denn nun Entwicklung in OC überhaupt geht. Dann habe ich hübsch erklärt, dass es dafür Eclipse gibt und etwas in der Richtung "ja, das habe ich gelesen, aber ich habe keine Lust Eclipse zu installieren / das ist zu kompliziert / ich will doch nur in die Dateien schauen können, gibt es denn nicht sowas wie den alten Editor?" zurück bekommen.
Irgendwann habe ich mir dann gesagt, gut, jetzt machst du sowas eben. Nach Guenthers Direktive "wer's macht, bestimmt" habe ich dann nun mal aus genannten AutoIt dafür gewählt. Weil es sonst keine Lobby für den Editor gibt, bleibt mir nichts anderes.
> AutoIt-Features sind auf lange Sicht gesehen toter Code.
Ja, das stimmt durchaus. Aber für den Moment funktioniert es. Wie gesagt, wenn das irgendwann untergeht, dann wird das so sein und ich trauere dem nicht hinterher.
> Müssen zwingend alle IDEs (wollen wir das mal so nennen) kompatibel sein?
Nein - aber wenn sie es nicht sind, gilt "mehr Tools sind besser" nicht mehr. Meine persönliche Idealvorstellung wäre eine IDE, die ermöglicht, all die unterschiedlichen Tools (Mape & co, Wizards, die Clonk-Engine selbst...) unter einem Dach zu vereinen.
Eclipse wäre so eine Plattform. Praktisch alles besteht aus Plug-Ins, man könnte eine Menge nachrüsten. Zumindest auf dem Papier ermöglichen wir jedem, seinen eigenen Objekt-Wizard oder Vorschau-Code zu schreiben und unabhängig zu pflegen.
Naja. IDEs neigen wohl einfach sehr dazu, sich zu zersplittern - ich wüsste keine Sprache, bei der sich in irgendeiner Form eine "offizielle" IDE heraus entwickelt hätte.

Das würde sich auch durch weitere Plugins nicht lösen lassen ;)
> gilt "mehr Tools sind besser" nicht mehr
Solange die Endergebnisse kompatibel bleiben - wo ist der potentielle Schaden?

Hatte da den Plan das ganze Type Inference Gedöns beim Skriptparsen optional machen. Die meiste Zeit über kann man auf so großartige Schlussfolgerungen wie das in einem ElevatorCase eine nicht existente LoseCombination-Methode aufgerufen wird verzichten, zumal das die Clean-'Build' Performance am meisten runterzieht.


Man mag mir Faulheit unterstellen, aber ich finde ein kleines simples Programm besser als Eclipse mit irgendwelchen Plugins (Ich will hier natürlich nichts schlecht reden - das Plugin war ne super Arbeit und wird ja auch entsprechend genutzt ;)).

Ansonsten stimme ich Dir zu@AutoIt; Respekt


> recht schnell(?)
Ja, doch. Lass es mal bisher 20-30 Stunden gewesen sein. Wesentlich weniger, als wenn ich jetzt z.B. noch GTK lernen müsste ;)

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill