Gibt es, einen Monat nach dem letzten großen Statusupdate 
- kommendes Wochenende!
Spoiler: Es gibt viele Screenshots /o/.
>Es gibt viele Screenshots /o/.
Pics or it didnt happen .
\o/
Du hast noch rund eine Stunde .
Yay, der dritte Monat von Lorry ist so halb durch! Was hat sich getan?
Github! Nachdem ich das bereits letzten Monat erwähnt habe, geschieht die Entwicklung seit ungefähr einer Woche nun vollständig auf Github. Jeder der Lust hat kann sich über den Code hermachen, mit mir in Verbindung setzen oder in den Issues schauen, woran ich gerade so arbeite. Oder sich beschweren, wenn der letzte Commit mehr als 24h zurück liegt 
.
Konzepte! Ich habe die meisten Workflows, gerade was Addon-Release betrifft so ziemlich fertig entworfen. Kurz beschrieben: Ein Entwickler erstellt ein Pack, und zu diesem Pack zugehörige Releases. Jeder Release hat eine Versionsnummer, kann über ein entsprechendes Changelog verfügen, kann eigene Screenshots und Beschreibungen anzeigen, und seperat veröffentlicht werden. Man kann sich das wie ein CCAN auf Release-Basis (und nicht auf Addon-Basis) vorstellen. Das immer wiederholte neu-editieren wie auf dem CCAN entfällt, ein neuer Release nutzt ansonsten einfach die Beschreibung des vorherigen Releases unverändert weiter (kann aber separat verändert werden). Das sollte für große Packs wie auch kleine Szenarien flexibel genug sein.
Neu organisierte Codebasis! Wie hoffentlich jeder andere Entwickler auch lerne ich selbst mit jeder Zeile Code etwas dazu. Ich war selbst noch nicht ganz zufrieden mit der Richtung, in der sich Codebasis entwickelt hat, viele unnötig übergebene Referenz und ein paar seltsame Konventionen waren die Folge. Nachdem ich noch etwas weiter recherchiert habe, wie das heutzutage am effizientesten gelöst wird bin ich nun mit der neuen Struktur richtig zufrieden. Das hat auch so ziemlich die Kernzeit der Entwicklung genutzt, sollte aber die weitere Entwicklung beschleunigen.
Screenshots! Ich weiß doch, das ist der Grund warum ihr das hier überhaupt lest:
Registrierung/Login - Startseite auf Mobilgerät (mit ausgeklappter Navigation) - Releasebuttons - Einstellungen (ein gutes Stück gewachsen) - “Willkommen bei Clonk!” - “Über das Projekt”.
Downloadseite gibt es auch schon, aber die ist momentan kaputt. Wer im Repos gräbt, kann sie sich anschauen, ansonsten beim nächstem Update :-).
…und ich hätte auch fast ein festes Releasedatum gegeben - aber ich weiß wie das immer endet 
.
Nett! Die letzten zwei Links sind aber noch localhost.
Wupps! Bei mir gehen die .
Wo ist der "Donate"-Button ?
Wo ist der Like-Button?
Ich weiß nicht, wie ernst das gemeint ist, falls da ein paar dabei sind könnte ich die Serverkosten ähnlich wie das OpenClonk-Projekt unter Interessierten verteilen, aber anfangs decke ich das erstmal selbst ;-).
(Falls ich plötzlich ein paar hunderttausend Downloads von einer neuen Fanbasis haben sollte melde ich mich, bevor ich die Seite zumachen muss . )
Jo, sieht cool aus - aber die wichtigste Seite fehlt natuerlich noch :)
Generell, ist es natuerlich noch etwas zu sehr Textlastig. Das find ich persoenlich zwar sehr angenehm (endlich mal Ruhe vor der Bilderflut), aber die Masse wird wohl eher nicht so viel lesen und mehr klicken wollen.
> Konzept
> Jeder Release hat eine Versionsnummer, kann über ein entsprechendes Changelog verfügen, kann eigene Screenshots und Beschreibungen anzeigen, und seperat veröffentlicht werden.
Uebersicht ist alles :). Ich fass nochmal zusammen, was ich irgendwann mal konzipiert hatte (OC Forum?):
Ich hoffe mal es geht dann in die Richtung des Tag-Systems, dass benoetigte Objekte direkt verlinkt werden koennen. Und man bei den Objektpacks im Gegenzug sofort passende Szenarien findet.
Ich faend es auch schick wenn man Mods gleich an Szenarien hinzufuegen kann. Und ihnen somit endlich eine legale Berechtigung gibt. Mods auf dem CCAN waren ja etwas verpoent.
Dann ist es wichtig, dass es zwar klar ist - dass bestimmte Szenarien fuer eine alte Version gebaut wurden, aber dass man beim suchen nach dem Eke-Pack z.B. auch das neuste findet und sich nicht durchwuehlen muss. Hier faend ich es schoen, wenn im Eke Pack selbst die alte Versionen zu finden sind.
Moment: Eben mal malen… so in etwa:
(Eke Nu, soll das aktuelle Eke sein, sorry kurz niederlaendisch gedacht)
Was dann noch angedacht war, war die Szenarien mit veraltetem Pack automatisch zu markieren mit einem Icon. Im Sinne von: Funktionsfaehigkeit nicht gewaehrleistet.
Nutzer koennen dann im Szenario voten, ob es noch (einwandfrei) funktioniert, eingeschraenkt, oder garnicht mehr funktioniert. Nach einer bestimmten Anzahl votes bekommt das Szenario dann diesen Status, bis zum naechsten Update.
---------
Hinzufuegen von Mods:
Mods werden ebenfalls direkt im Eintrag gelistet.
Ein alter Eintrag kann dann z.B. das haben:
Funktioniert nicht oder nur mit Eke Pack so und so, aber ein [ala mod.] ist gruen markiert und anklickbar, und suggeriert, dass dieser Mod funktioniert. Das orginal bleibt erhalten.
Die gruene markierung erreicht der Mod durch Voting.
Sieht ja alles ganz hübsch aus
>Release-Basis
Wie genau war das gedacht? :)
Wenn ich ein Release hochgeladen hab, dann bleibt das auf jeden Fall für immer da? Ich kann die Beschreibung nicht nachträglich ändern? Was sind die Vorteile davon?
>Wenn ich ein Release hochgeladen hab, dann bleibt das auf jeden Fall für immer da? Ich kann die Beschreibung nicht nachträglich ändern? Was sind die Vorteile davon?
Wahrscheinlich eher pro File
>Wie genau war das gedacht? :)
Du lädst Releases, die zu einer Erweiterung gehören, hoch - du kannst sie noch bearbeiten, aber die Datei bleibt final. Der Text im entsprechenden Screenshot ist da noch nicht korrekt formuliert. Der Sinn der Sache ist, dass eine "CMC.c4d" v1.5 immer ein CMC.c4d v1.5 bleiben wird, du releast den 1.5-Teil daran (der dann immer 1.5 bleiben wird). Falls du Änderungen hast muss das dann ein 1.5.1 werden. [Edit: Dateinamen korrigiert]
Alle Releases werden dann im Beispiel unter der Erweiterung CMC zusammengefasst, die dich im Normalfall auf den neuesten Teil weiterleitet.
Mh, was ist die Idee dahinter?
Ich kann mir zumindestens folgendes Problem vorstellen:
M&M Team läd M&M-1.0.c4d hoch. Viele Szenarien, die M&M benutzen, werden gebaut. Irgendwann (aus Faulheit zwei Jahre später) will das M&M Team ein Bugfixrelease hochladen. Ein reines Bugfixrelease! Die Kompatibilität bleibt erhalten und es kommt vielleicht noch ein neuer Zauber dazu und ein altes Szenario kommt raus.
Jetzt kann das M&M Team das nicht einfach als M&M-1.0.c4d hochladen (was natuerlich das beste wäre), sondern muss es M&M-1.1.c4d nennen. Natuerlich updaten die meisten der alten Autoren von den beliebten M&M Szenarien ihr Szenario nicht nur um die Versionsnummer der Vorgaben hochzudrehen.
Folgesituation: In #clonken spielen die meisten Leute mit einer veralteten M&M Version, weil ihre Lieblingsszenarien nunmal diese Version brauchen.
Die Dateibenennung sollte man mMn dem Autor ueberlassen. Bei Objektpaketen sowieso, weil sie unter dem exakten Namen in der Scenario.txt referenziert werden (siehe Zapper). Aber auch bei Szenarien ist es Mist, wenn man in der Auswahl dreimal das gleiche Szenario sieht und gar nicht weiss welche der Versionen nun die aktuellste ist. Nicht alle Autoren schreiben die Versionsnummer auch in den Titel oder die Beschreibung.
>Die Dateibenennung sollte man mMn dem Autor ueberlassen.
Okay, mein Beispiel war schlecht. Die eigentliche Benennung der Datei unterliegt (wie sonst auch) immer noch dem Autor, ich meinte eher die Datei als "CMC.c4d in Version 1.5" sollte getrennt verfügbar sein von einer "CMC.c4d in Version 1.3".
Ich meinte mit dem 1.5 nicht wirklich, dass das auch im Dateinamen erforderlich ist. Mir geht es um die Integrität nach dem Release - alle CMCs die ich irgendwann einmal als CMC.c4d v1.5 herunterlade, sind immer mit allen CMCs 1.5 kompatibel, egal wann sie heruntergeladen werden.
Da die Dateinamen durchaus gleich bleiben können, kann das immer noch eine M&M.c4d bleiben - es wird eben ein 1.1-Release angelegt, der die M&M.c4d zum Download anbietet.
Ich habe auch gar nicht vor, ein festes Dependency-System innerhalb von .c4ds oder mithilfe von neuen Namen festzulegen, das sollte dann wenn überhaupt durch einen getrennten Desktop-Client organisiert werden, der intern die Abhängigkeiten auflöst und speichert, welche Version installiert wurde (und damit auch weiß, wann Updates verfügbar sind).