“Lass mal Clonk neu machen! 
” - alle.
Nun bin ich also auch auf den Revolutions-Zug aufgesprungen und was wäre eine Revolution schon, wenn man nicht jedem, der nichts davon hören will, die Bude damit einrennen würde.
Mein Masterplan:
- Einen Fork von Clonk Rage ins Leben rufen! <- done
- Rage Sourcecode wieder kompilierbar machen <- done.
- Abwärtskompatibilität schrittweise abschaffen (d.h. alte Clonk Planet-Scripts ohne #strict würden demnächst rausfliegen)
- Andere Entwickler motivieren, mitzumachen
- Einen Entwicklungszyklus wie damals zu NET2 einführen
Folglich habe ich mir vorgestern mal den Clonk Rage Sourcecode geschnappt und ein wenig umstrukturiert.
Was bisher erledigt wurde:
- Neue Projekt-Files für Visual Studio 2013 erzeugt (cmake wäre eventuell besser, da gefallen mir jedoch die erzeugten VC++ Projektfiles, mit denen ich hauptsächlich arbeiten werde, nicht)
- Patch von DirectX 8 (das hat nun wirklich niemand mehr) auf DirectX 9
- aufgeräumt! Geflogen sind: komplette Registrierungsfunktionalität, OpenSSL, alte C-Datentypen (BOOL vs bool)
- ein bis zwei Platform-Funktionen umgeschrieben/korrigiert: static bool IsWindowsVista() lieferte nur dann true, wenn es wirklich Vista war, für Windows 7 aber beispielsweise bereits wieder falsch; diese Funktion bewirkt, dass beispielsweise die Update-Packages mit Admin-Rechten abgewandt wurden); ersetzt durch <VersionHelpers.h> aus dem Windows-SDK
- neue Versionsnummer erfund^W angepasst (4.10.0.1 [001]) <- ganz wichtig!
- Diesen Blog-Post schreiben <- done!
Was noch zu tun ist:
- Ein öffentliches Repository dafür erstellen. Ob git oder svn ist mir persönlich egal, svn erschien mir anfängerfreundlicher, git ist natürlich mächtiger. Kann aber erst erledigt werden, wenn matthes den Sourcecode neu lizenziert, bisher verstoße ich durch den Ausbau der Shareware-Funktion (aus einem Freeware-Produkt :whatever:) gegen die Software-Lizenz.
- Einschätzen, wie viele Features man von OC backporten kann (Zappers Partikel oder so?)
- Eine Liste mit potentiell coolen Engine-Funktionen zusammenschreiben (lassen!). Gemeint ist hier nun vorerst mal nicht sowas wie “Mach mal Laag weg!!”, sondern eher konkretes wie “Mach mal C4Network2HTTPClient TLS-fähig”.
- ???
- Profit!
Bilder hänge ich natürlich an! 
Daily WTF #001
Da wollte ich vorhin die verwendete zlib-Library(das ist die Bibliothek, die sich um’s Packen und Entpacken von Archiven kümmert) updaten (bei freetype2 habe ich das schon dringend erledigt, war auch dringend notwendig, bedenkt man, dass es bekannte Code-Execution Exploits gegen die vom offiziellen Build verwendete Version gibt), musste ich feststellen, dass danach nix mehr ging - keine einzige C4Group-Datei konnte mehr durch die Engine geöffnet werden, es wurde eine assertion in der C-Runtime ausgelöst, die daraus hinwies, dass die Datei schon geschlossen wurde (Beim Öffnen? wat.). OK, Debugger verwenden und mal bissl stöbern, woran es liegen konnte. Der Grund war anscheinend, dass Clonk sich auf die Aussage von der zlib-Library verlässt, ob eine Gruppe ein gzip-File ist oder nicht.
Hier muss ich kurz ausholen: gzip ist ein sehr verbreitetes Kompressionsverfahren für Byte-Ströme und wird in (leicht modifizierter Variante) auch für die Clonk Gruppen eingesetzt. In dessen Standard ist spezifiziert, dass eine gzip-Datei mit den 2 sogenannten Magic Bytes 0x1f und 0x8b beginnen muss. Daran kann man gzip-komprimierte Dateien erkennen.
Clonk verwendet, damit nicht jeder die Gruppenfiles mit einem beliebigen Entpack-Programm zerlegt, geänderte Magic Bytes: 0x1e und 0x8c. Und genau hier liegt der Knackpunkt: die neue Version der zlib konnte nicht mehr erkennen, dass es sich um gzip-Files handelt und hat das Öffnen dieser schlicht abgelehnt, und die Engine hat genau falsch reagiert, indem es versuchte, die schon durch die zlib geschlossene Datei gleich nochmal zu schließen. Dadurch kam es zu der assertion und zum Absturz der Engine direkt beim Laden.
Bei der alten zlib passiert genau dies alles nicht; ich durfte dann nach ordentlich Debugger-Arbeit feststellen, dass man da schlichtweg in der zlib einfach die Magic-Bytes geändert hat (was äußert unschön ist.), um dieses Problem zu umgehen. Dies reicht mir für einen “WTF des Tages” 
Um mal eine ungefähre Größenordnung zu geben: das alles hat mich ungefähr 2h gekostet 
Schoen dass sich jemand engineseitig mit dem alten CR-code beschaeftigt.
Schliesst du dich auch mit Sven und Tyron kurz? Bringt ja nichts wenn jeder sein eigenes Sueppchen kocht.
Sven2 hatte zuletzt viele Fixes aus dem OpenClonk Repository nach CR importiert und meinte neulich dass er ja nochmal ein Update fuer Clonk Rage pushen wuerde sobald die Liga auf clonkspot umzieht. Und sich mit Tyron zusammenzutun wuerde ja wegen seinem GoldenZapEdition Projekt Sinn machen. Werkelt er nicht auch am Source Code?
Ich bin ein grosser Fan von "dont repeat yourself" und eine Arbeit doppelt zu machen, ist umso schlimmer (und einfach auch Zeitverschwendung). Daher moechte ich dich darauf hinweisen, dass in den vergangenen 5 Jahren schon viel am Clonk Rage code getan wurde, naemlich im OpenClonk repository. Wir haben schliesslich auch mit dem Code angefangen den du jetzt vor dir hast. Code-Aufraeumarbeiten waren auch sehr viele dabei. Da alle Entwickler unter den Bedingungen der ISC-Lizenz am Code gearbeitet haben ist es auch lizenzmaessig kein Problem die commits zu uebernehmen, du musst uns nichtmal fragen.
>- aufgeräumt! Geflogen sind: komplette Registrierungsfunktionalität […], alte C-Datentypen (BOOL vs bool)
Das haettest du dir z.B. sparen koennen, diese Arbeit wurde schon vor Jahren im OC-code erledigt.
> [geflogen sind] OpenSSL
Ob das nicht demnaechst wieder reinkommt? Kommentar von Luchs, der gerade mit Sven (und mir) an der Ligaintegration arbeitet.
> - ein bis zwei Platform-Funktionen umgeschrieben/korrigiert: static bool IsWindowsVista() lieferte nur dann true, wenn es wirklich Vista war, für Windows 7 aber beispielsweise bereits wieder falsch; diese Funktion bewirkt, dass beispielsweise die Update-Packages mit Admin-Rechten abgewandt wurden); ersetzt durch <VersionHelpers.h> aus dem Windows-SDK
Ja, doch wofuer wird diese Versionsnummer benoetigt? Fuer einen Hack dass die Updates auch mit Windows Vista funktionieren. Der Hack funktioniert nur nicht mehr mit Windows 7. Siehe Bugtracker Eintrag. Einen richtigen Fix dafuer gibts im OpenClonk Repository: Commit des Fixes
Das ist alles voll gut und ehrenvoll und so.
Aber wie Newton gesagt hat: All die Arbeit, die du da gemacht hast wurde bereits gemacht.
Und die vielen, vielen Stunden Aufräumarbeit, die noch kommen werden, hat auch schon jemand über die letzten 5 Jahre für dich gemacht.
Wäre es nicht sinnvoll sich mit Marky, der CR nach OC portet, zusammenzutun? Ich bin mir sicher, er könnte noch einen tüchtigen Enginecoder gebrauchen, der ihm dabei hilft.
Und für dich springt dabei auch was raus: Du musst nicht mehr hauptsächlich total nervige Aufräumarbeiten machen. In der Zeit, in der du die Aufräumarbeiten machen würdest, die in OC schon drin sind, hättest du wahrscheinlich auch schon fast gesamt CR nach OC rübergeportet
PS:
>- Einschätzen, wie viele Features man von OC backporten kann (Zappers Partikel oder so?)
Die sind nicht für DX gebaut. Wenn du die porten willst, müsstest du DX Support einstellen (so wie wir das für OC gemacht haben)
PPS: Außerdem brauchen die zumindestens Günthers Proplists fürs Scriptinterface
PPPS:
>- Eine Liste mit potentiell coolen Engine-Funktionen zusammenschreiben (lassen!).
http://forum.openclonk.org/topic_show.pl?tid=2649 !
Ich bin überwältigt, was in letzter Zeit alles passiert. Großartig!
Technisch kann ich leider nicht viel dazu sagen, außer das Newtons Zeug sinnvoll klingt . Und Git wäre wohl auch sinnvoller. Ich könnte auch ein privates Repos auf Github zur Verfügung stellen.
Coole Engine-Funktionen:
• Endlich mal alle Einstellungen auch Ingame vornehmen, in einem modernerem Menü (inklusive Laden und Speichern)!
• Mach mal Laag weg!!
Viva la Revolution!
Ich fühle mich zwar auch zu doof, um hier etwas schreiben zu können. Aber vielleicht bring dir mehr Feedback ja Motivation. Also Go Kanibal! \o/
Coole Enginefunktionen:
- Mach mal Laag weg!! (Asynchronous Transfer Mode der funktioniert und nicht abstürzt?)
Juhuu \o/
Newtons vorschlag, einzelne commit zu backporten klingt cool, wo anwendbar und sinnvoll.
Ich könnte evtl. ein git repository auf meinen Server bereitstellen, wenn sich niemand anderer freiwilling meldet.
Hier sind ein paar Sachen dir mir beim GZE basteln aufgefallen sind:
Bugfixes
- Editor.exe: Scenario properties error on Landscape.txt + Custom Materials
- Network game: maxfileload size much higher and show appropriate error if too low
- Load Script files inside System.c4g/Subfolder - would be extremly useful to help organise code (e.g. one file for each function)
- => System.c4g cleanup - organize script code by category (like in the documentation)
- Why only .wav for Sound()?
- More appropriate Splash sound for lava pls (when objects fall in lava) :-)
- How about not using index 0 as materialindex? It makes many things way more complicated (0 should be "any" material in function parameters)
Features
- Ways to hook into various engine created content (e.g. Scenario Disasters Section, Vegetation placement, etc.)
- Clonk endeveaour like frontend (player mode / developer mode) with lobby and stuff. (I hate the CR Ingame thingy :<)
- pObj->localvariable = 123;
- void datatype for declaring no return values for funcs
- animated liquids plz! (example: animation abilities in minecraft resources packs)
- http sockets plz! :D
- We got SetSkyAdjust() and SetMatAdjust() but no SetObjAdjust() :(
To document
- Scenario.txt Min,Max,Random Values (e.g. landscape width)
- C4Id()
- datentyp "any" (e.g. InArray(any elem, array myArray))
>- Abwärtskompatibilität schrittweise abschaffen (d.h. alte Clonk Planet-Scripts ohne #strict würden demnächst rausfliegen)
Wiewas?
> - void datatype for declaring no return values for funcs
Wie meinen? Funktionen in Clonk haben doch gar keine Typisierung? :o
> - http sockets plz! :D
Intern für c4script? uh?
>>- Abwärtskompatibilität schrittweise abschaffen (d.h. alte Clonk Planet-Scripts ohne #strict würden demnächst rausfliegen)
>Wiewas?
Gemeint ist, so uralt legacy Sachen rauszuwerfen, die Neuerungen behindern. Sowas wie Bitmap-Grafiken für Objekte beispielsweise, das lässt sich ja sehr einfach auf png konvertieren und braucht nurnoch halb so viel Speicher.
>- Eine Liste mit potentiell coolen Engine-Funktionen zusammenschreiben (lassen!)
Es sind btw ein paar Scriptfunktionen in der Engine eingebaut, die man nicht per C4Script aufrufen kann, aber trotzdem nützlich sein könnten.
Z.B.
AreaSolidCount() oder MassMover.Create(tx,ty)
>Editor.exe:
Da fällt mir dazu noch die falsche darstellung der Clonk-Ränge seit [328] oder so ein! D:
Muss an den neuen Icons liegen.
Hört sich nach einem tollen Projekt an. Ich hab CR schon immer viel mehr gemocht als OC. Weiter so, ich bin gespannt, wo das hinführt. 
> - void datatype for declaring no return values for funcs
>Wie meinen? Funktionen in Clonk haben doch gar keine Typisierung? :o
Gute Frage, weiss nicht mehr was ich da meinte :<
> - http sockets plz! :D
> Intern für c4script? uh?
Jap! Wobei das sicher sync-probleme verursacht, hm.
Ich halte es nicht fuer eine gute Idee CR nach OC zu porten.
Vielleicht, dass nichts zurück zu geben nicht als 0 zählt?
> Clonk verwendet (...) geänderte Magic Bytes
Die "Verschlüsselung" des Headers kommt auch noch hinzu, weshalb man ohne weiteres keine Standardprogramme, -Libraries oder -Klassen (wie die praktischen Streamklassen in Java) benutzen kann.
Die Idee, statt C4Group ein Standard-Archivformat zu benutzen ist ja nicht neu. Wie viel Arbeit wäre das denn tatsächlich?
Interessant. Was spricht dagegen?
Ich finde einen CR zu OC Port inzwischen auch interessanter als weiteres Updaten von CR. Speziell, da ich mit dem Erstellen von S2Classics gesehen habe, dass die Engine gar nicht so sehr inkompatibel ist. Und weil OC eben die Entwickler und die Infrastruktur hat, um auch immer alles auf den neuesten Stand zu halten.
Auf weitere CR-Fixes habe ich persoenlich keine Lust. Man steigt dann immer wieder in die alte Codebasis ein und arbeitet um all die Unschoenheiten herum, die eigentlich schon seit langer Zeit verbessert sind.
Abwaertskompatibilitaet. Der grosse Pluspunkt an Clonk Rage ist dass es 10 Jahre+ Content hat. Baut man ein Clonk Rage auf der OC Engine auf, dann wirft man das ueber Bord. Und was hat man dadurch gewonnen? Fuer OC hatten wir das ueber Bord geworfen, damit wir tiefgreifende Verbesserungen am Spielprinzip machen koennen. Ein auf der OC Engine basierender Clonk Rage Clone haette nichtmal das.
Naja. So wie ich das sehe geht es den wir-wollen-CR-besser-machen-sager mittlerweile garnicht mehr so sehr darum, die Abwaertskompatibilität zu halten. Denen geht es eher um das alte Spielprinzip.
CR selbst verschwindet ja nicht ploetzlich - wer das alte InExantros spielen will, wird das auf der CR Engine immer können.
Ich sehe onehin nicht viel Änderungspotential an der CR Engine, das nicht nur Abwaertskompatibilität hält, sondern die alten Dinge noch verbessert. Neue tolle Scriptfunktionen? Neue Partikel? Das bringt den alten Sachen auch nichts!
Und bevor man sich jetzt entscheidet super viel Energie in Änderungen an der CR Engine zu machen (die sogar bereits gemacht worden sind…), sollte man sich zumindestens gut überlegen, was man sich davon erhofft. Abhalten werde ich persoenlich natuerlich niemanden.