Das war auch das tolle in ottd fand ich!
Ja, ne vernünftige Paketverwaltung wär superklasse!
> -- Tag-System
> Also: Es gibt Tags, und jedes Objektpack oder Objekt hat seinen eigenen Tag. Szenarien die diese Objekte benutzen haben diesen Tag automatisch. Auf diese Weise kann man z.B. sortieren: Eke Szenarien - das sind einfach alle Szenarien die dieses Objektpack benutzen.
Und es waere nicht schlecht, wenn andere Autoren auch Tags hinzufuegen koennten, um z.b. schnell eine Uebersicht ueber alle Szenarien fuer ein Turnier zu bekommen.
Nach sowas hab ich mich schon immer gesehnt, hatte oft das Problem dass ich spielen wollte, aber nicht mitspielen konnte weil ich das Paket nicht runterladen kann und manchmal nur die Nachricht kommt, dass meine Version abweicht. Das kann Spieler übrigens sehr gut abschrecken, mir verfliegt danach zumindest sofort die Lust zu spielen.
So funktioniert auch das neue Steam-Tagging. Jeder setzt für sich selbst Tags und die populärsten werden allgemein angezeigt.
Hm, könnte man seinen Eintrag nicht einfach mit einem anderen verlinken?
Beispielsweise haben wir das KDD-Magiepack (man kann verschiedene Versionen davon runterladen, die neusten steht immer ganz oben). Jetzt kann der Autor des Szenarios Blackfield bei seinem Eintrag angeben, man benötigt das KDD-Magiepack in Version 1.15 und unter dem Szenario wird es direkt verlinkt. Gleichzeitig kann der Autor des KDD-Magiepack jederzeit einsehen, welcher Eintrag auf welche Version seines Packs jemand verlinkt.
So hätte man jederzeit volle Information wer welches Pack in welcher Version verwendet/voraussetzt.
Ja, aber genau das bitte in Maschinen-lesbarer Form - lädst du nun im OC-Client Blackfield runter, schlägt er dir automatisch vor, auch das KdD-Pack zu laden (Linux-Paketverwaltung lässt grüßen 
)
> OC-Client
Hab wohl zulange kein OpenClonk mehr gespielt.
Wenn man nun schon soweit ist, sollte man OC gleich mit Lorry verbinden und anzeigen, welches Szenario was in welcher Version voraussetzt.
Jopp, genauso ists gedacht (In meinem Post waere die Verlinkung also gleich dem Tag - auf den man klickt, und dann fungiert er auch als Link).
Wobei die meisten Linux-Paketverwaltungen mit unterschiedliche Paketversionen auch große Schwierigkeiten haben und typischerweise darauf basieren, die Version irgendwie in den Namen aufzunehmen.
Wenn du beispielsweise ein Skript hast, das mit #!/usr/bin/env python anfängt, wird es mit Python 2 oder Python 3 ausgeführt?
Man könnte eine zwingende Versionierung einführen (zB [MAJOR].[MINOR]) und dann die Objektpakete in Unterordnern entsprechend der Version ablegen oder solche Spaesse. Man muss nur aufpassen, dass man die Versionsnummern NICHT in die Requirements der Szenarienordner selber aufnimmt (aka "Braucht CMC Version 1.2" ~ "Definition1=CMC-1.2.ocd").
1. Weil das nichts für Updates bringt. "1.2" heisst bei den Clonksachen normalerweise nicht "ab 1.2" sondern "irgendwie vielleicht so ab 1.2", weil Abwärtskompatibilität hier viel unwichter war und ist als bei Linuxlibraries.
2. Weil Autoren verschwinden und Szenarien vielleicht nie wieder geupdated werden. Da wäre es ziemlich bescheuert die Version da rein hartzucoden. Über irgendeine externe (Lorry) Paketverwaltung wär schon praktischer.
Hm, ich dachte eher daran, dass die Verlinkungen sauber untereinander angeordnet sind. Diese Tag-Geschichte ist ja immer extrem chaotisch.
Erst mal: vielen Dank für die ganze Mühe, das alles zusammenzutragen! Wirklich toll das alles so zu lesen und in einer übersichtlichen Form zusammengetragen zu haben.
Insgesamt ist das Konzept doch sehr nahe an dem, was ich als die optimale Lösung betrachten würde - mit viel Nutzen für die Spieler, die Autoren der Pakete, und Modder der Pakete.
–
Ganz allgemein zu dem Konzept: Die Tags an sich sind schon eine sehr gute Idee. Wie du bereits zusammengetragen hast sind sie vielseitig nutzbar und helfen nicht nur Spielern schnell nach ähnlichen Packs zu suchen, sondern eben auch bei Updates.
Viele der Ideen (gerade mit dem automatischen Updates und Mods) hatte ich in abgewandelter Form mal geplant, aber nicht ganz speziell als Tags - eher als Einträge auf der Downloadseite eines Addons. Wie Adler schon angemerkt habe finde ich, dass viele Tags schnell unübersichtlich werden, vor allem, wenn bei jedem Pack neben dem Namen gleich alle Tags angezeigt werden - das beste Beispiel für den Tagwahnsinn ist meiner Meinung nach das Clonk-Center. Ich glaube die Sammlung hat aber gut gezeigt wie brauchbar das System an sich ist.
Daher schlage ich vor: Anzeige von Szenarien/Packs in einer Gesamtliste mit nur wenigen wichtigen Tags, z.B.:
Codename: Modern Combat (Pack) (Clonk Rage) (Mehrspieler) (Melee) (Hazard)
Stippel Valley (Szenario) (Clonk Rage) (Kooperativ) (Adventure) (First Aid Pack)
oder gar
Codename: Modern Combat (Clonk Rage) (Melee)
Stippel Valley (Clonk Rage) (Adventure).
Die restlichen Tags würden dann nur auf der Addon-Seite selbst oder bei der Suche erscheinen.
Ich halte es auch für sinnvoll, automatisch generierte Tags von den benutzerdefinierten Tags abzugrenzen. Beispielweise soll das Spieletag immer eins aus (Clonk Rage)/(OpenClonk) und das Spielertag z.B. aus (Einzelspieler)/(Kooperativ)/(Mehrspieler) sein - dadurch hat man keine (Rage), (CR) oder (OC)-Tags, und garantiert dass die Tags in gewisser Weise sinnvoll zusammenhängen, vor allem dass keine Duplikate dabei sind.
–
Die Versions- und Abhängigkeitsverwaltung halte ich für einen integralen Bestandteil einer guten Plattform. Gerade wenn das System steht, und die Plattform mit ein paar Klicks anbietet, einen Mod hochzuladen bekommen wir mehr Aktivität auf der Plattform, interessierte Spieler können den Mod gut bewerten, dem Entwickler mehr Feedback und Motivation geben und dadurch auch neue Entwickler einladen, eine Runde weiterzumodden. Durch die Versionsbewertung (die ja auch so im Prinzip von iTunes und dem Google-Play-Store umgesetzt wird) können wir hoffentlich die Probleme von M&M und KDD vermeiden. Eine Win-Win-Situation für Spieler und Entwickler 
–
Die anderen Geschichten, speziell die Versionsverwaltung halte ich auch für so wichtig, dass sie für einen 1.0-Release von Lorry durchaus wichtig sind. Aber da sich das ganze ja um eine Webplattform handelt, können wir auch gut Stück für Stück vorranschreiten - ich setze erst das grundlegende Erstellen von Addons mit dem Hintergedanken auf verschiedene Versionen und Abhängigkeiten um, und erweitere das System dann stückchenweise, um mehr automatische Tags umzusetzen und dann auch die benutzerdefinierten Tags zu erlauben (das Steam-System, welches Luchs ja auch schon angesprochen hat, finde ich da auch eine besonders tolle Idee). Auch eine mögliche OpenClonk-Integration wäre richtig toll, und ich hatte ja bereits mal ein paar Worte mit Kanibal früher im Thread gewechselt - wenn das eigentliche System und die Tags mal stehen kann ich relativ einfach eine REST-API bauen - an die dann eigene Programme oder im Idealfall OpenClonk ingame heraus die Downloaddatenbank anzapfen kann.
Liga-Verlinkung wäre auch eine tolle Idee - vielleicht schaffen wir ja für die nächste Generation der Clonk-Liga nach dem Abschalten des offiziellen Servers eine Verlinkung mit dem dann größten Masterserver - ob das jetzt Clonkspot oder OpenClonk ist. Vom Bugtracker bin ich nicht ganz überzeugt, Projektverwaltung selbst überlasse ich da lieber Tyron und dem CCF - bzw. hoffentlich bald dem FTW :happy:. Ich finde auch, lieber haben wir mehrere Plattformen die ihre Aufgabe richtig gut tun, als eine große Plattform die alles kann, aber auch abschmieren oder aussterben kann.
–
Also nochmal - danke für dein Feedback! Je mehr Ideen wir zusammentragen, und darüber diskutieren, desto ausgereifter wird das Endprodukt - Lorry soll unbedingt ein Communityprojekt sein, nicht nur mein Code. Im besten Fall können wir dann Lorry vor Release mit ein paar Packs befüllen, auf den Foren die Werbetrommel rühren und dann eine gute Plattform für alte und vor allem auch neue Clonk-Spieler bieten.
Vielleicht wäre auch eine Art CI-Modus für OC praktisch, mit dem nur der Ladevorgang ohne Grafik usw. ausgeführt wird und der Log davon ausgegeben wird. Wenn ein Objektpaket aktualisiert wird, könnten damit dann alle Szenarien automatisch getestet werden: Falls irgendwelche Fehler auftreten, ist das Pack definitiv nicht kompatibel und Lorry könnte eine alte Version empfehlen, bis das Szenario aktualisiert wird.
>Da solltest du eigentlich einfach die URL posten - aber du hast Recht, das ist nicht selbstverständlich. Ich kann einbauen dass auch die Zahl selbst akzeptiert wird.
Ich hatte beides ausprobiert, die URL von hier: http://www.clonkforge.net/user.php?usr=388 - und nur die Zahl. War beides ungueltig.
Stimme dir da zu, Uebersicht ist wichtig. Eine Tag-Flut wirkt dieser aber wieder entgegen.
Die Trennung zwischen Objektpacks (etc.) und sonstigen Stichwoertern (Siedlung, Adventure) halte ich fuer sinnvoll. Am Ende braucht man wahrscheinlich garnicht soviele Tags der User.
Ich mein Melee und sowas ist ja schon definiert, was will man nun nun noch gross Taggen? Eventuell ob es ein Adventure ist - dass es ein Siedelszenario ist, ist irgendwo aber auch schon klar - anhand des Spielziels.
Ach, mit www. Okay, das wird jetzt etwas lockerer behandelt.
Dedizierter Server? hust
Die CC-Tags haben sich in der Tat nicht sonderlich gut bewährt
Für etwas inspiration:
Ich hab mir für FTW/CCF2.0 habe ich einen leicht bearbeitbaren globalen Ajax-Kategoriebaum gebaut, wo sich alle Unterseiten mittels codes (“tracker”, “project”, etc…) an definierten stellen einklinken. Dann wirds neben dem üblichen FTW Bugtracker auch noch einen “Categorytracker” geben wo Leute Verbesserungen am Kategoriebaum vorschlagen und voten können.
Wenn FTW jemals fertig wird, könnte ich eine Category-API bereitstellen zum auslesen des Kategoriebaums. Dann gäbs das Problem der Kategorisierung nur an einem zentralen Ort.
Das wichtige an der Stelle sind wahrscheinlich dann wirklich die custom Kategorien.
Wenn ich zum Beispiel alle <EKE> Szenarien, die <Stippeljagd> sind, suchen will. Fällt das bei dir unter die "Per Project Categories", die ich da sehe, oder so? 