Naja, wenn es nur um ein paar doppelte Tiles gehen würde hätte ich auch kein Problem damit. Allerdings bleibt das nur so wenn es wenige Maps nach Deinem Vorbild gibt, bei denen aufwendige Scripts die Karten passend setzen.

Dies klappt aber nicht mit Story- oder gescripteten Missionen. Derartige Scripte in einer Datei zu kombinieren wird sehr fehlerträchtig, d.h. solche Missionen werden immer einzelne Kartendateien zugeordnet bekommen.
Und bei 20 Story-Missionen hat man dann einen Faktor 20 bei einem häufig verwendeten Tile...

Das ist aber zugestandenerweise eine sekundäre Überlegung, denn Story-Missionen werden im Spielsatz integriert sein und der Kartenimport für die Spielsatzdatei kann die Karte dann auch auseinander nehmen und alle Tiles in einer internen Liste zusammenstellen.


Ich stimme Dir da im Prinzip zwar zu, aber jeder muss irgendwo üben und anfangen - und das ist dann das Hacking bestehender Karten. Wenn wir das von vornherein unmöglich machen, dann wird der Kreis der Kartenersteller sehr elitär (=klein) bleiben ;-)


Stimmt - aber nur solange die Datei passwortgeschützt ist und niemand außer dem Ersteller daran manipuliert. Damit sind wir wieder bei meinem Einwand oben...


Wenn Du ein Tileset wirklich modifizierst (d.h. alte Bilder austauschen statt nur neue Ergänzen), dann musst Du regelmäßig alte Karten nacharbeiten und zwingst alle Leute, die Kartenversionen ständig auf dem aktuellsten Stand zu halten.
Und genau aus diesen Schwierigkeiten hearus wurde die Löschfunktion für Tiles ja weggelassen, eben damit nicht alte Karten auf einmal mit fehlenden oder falschen Grafiken Probleme haben.
D.h. hier liegt das Problem eher bei den Tileseterstellern...


Womit wir wieder bei mehreren Tilesets sind ;-)




Es ist nicht kosmetisch, sobald andere Leute anfangen bestehende Tileset-Dateien zu ergänzen (!Dummy) oder ihre neuen Tilesets die gleichen Namen tragen.
Um das zu erreichen müsste man eine feste Namenskonvention durchsetzen und die Dateien mit Passwort versehen können, damit niemand anders daran herumwerkelt.

Es gibt eine Lösung wie man mit einigen Änderungen an der Art der Tilespeicherung alle diese Probleme beseitigen kann, aber ich weiß nicht ob man das in den bestehenden Programmen ändern kann - deshalb habe ich den entsprechenden Vorschlag erstmal nur per Mail an Jim gesendet und warte darauf, das er Zeit hat sich das durchzulesen.

Vielleicht sollten wir das Ganze auch mal von hinten aufzäumen. Wie genau sieht die Struktur im Moment aus, wie und welche Tiles werden wann (wann nicht) woher genommen, wenn man eine Karte erstellt?

Und? Ist doch niemand gezwungen, die neuere Version zu nutzen. Nur um das nochmal klarzustellen: Es werden wohl nur die wenigsten (wenn überhaupt) Fankarten + zugehörige Tilesets in den Standard an Zufallskarten aufgenommen. Und solange eine Karte + Tileset im Spielsatz gespeichert ist, gibt es doch keine Probleme.

PS: Und nochwas zu dem Speicherbedarf. Der Festplattenverbrauch ist nicht entscheidend. Vielmehr geht es um die Downloadgröße (denn das ist immernoch der Hauptvertriebsweg). Es gibt noch genügend Leute die mit ISDN oder Modem ins Internet gehen. Da ist es ein gewaltiger Unterschied, ob man 10 MB oder 100 MB runterladen muss.

Im Moment sieht es so aus:

Das sind die zwei sinnvollsten bisher genannten Loesungen:

Mein Vorschlag geht genau in die Richtung zu verhindern das jemand an Tilesets herumschraubt. Macht er sein eigenes dann gibt es kein ergänzen.


Namenskonventionen sind sicher eine gute Idee! Würde deinen Vorschlag gerne in der Online Doku sehen (der aus dem Forum). Dies sollte nämlich der zentrale Anlaufpunkt fuer solche Fragen sein.


Zugegeben ein Problem - vornehmlich aber doch wohl fuer den Standardsatz und der bleibt schlank. Wenn jemand mehr Karten will dann kann/muss er wohl mehr Downloadaufwand in auf nehmen - ist ja heute bei den Spielsätzen auch so.

Ich hab auch vor einiger Zeit mal mit Jim gemailt und vorgeschlagen zu ZIPen oder PNG/JPG zu nehmen. Damit sollte das Problem zumindstens reduziert werden.

Ich stimme Dir zu, dass das die diskutieren Lösungen sind. Danke fuer die grafische Darstellung -> erleichtert die Diskussion.

Die erste Variante hat einfach wenig Flexibilität. Die Kartenersteller und die Spielsatz ersteller muessen sich einigen und nimand kein unabhängige Karten erstellen.

Die zweite Variante entspricht meinen Vorstellungen besser. Solange man gewährleisten kann das die Karten/Tiles zusammenpassen und eine Einheit bilden ist alles ok. Das man mehrer Tilesets (die aber unter der Oberhoheit der Karte stehen und nirgends anders verwendet werden) ist aus meiner Sicht gut. Ich würde mir vielleicht ein Tool wünschen das die verteilten Sets nach der Entwicklung zusammenfasst und optimiert.

Und ja - ich bin mir bewusst das die Spielsatzdatei in Variante 2 ein multiple Karten - Tile Abhängigkeit vorsieht -> das ist aber keine externen Abhängigkeiten und muss vom Spielsatzersteller verwaltet werden.

Ja, und wozu brauche ich dann eine Namenskonvention oder komplizierte überlegungen zu Versionen? Bei den Spielsätzen kümmert sich doch auch keiner darum, ob es vielleicht in 2 verschiedenen Spielsätzen 2 gleichlautende Skripte geben könnte. Oder wollt ihr die Karten dann nachträglich in die Standardauswahl an Zufallskarten kopieren? Das wäre aber in meinen Augen auch schlecht, denn vom Kartendesign hängt schließlich auch die Schwierigkeit des Bodeneinsatzes ab. Wenn ein Spielsatzautor nicht weiß, welche Karten erscheinen, dann wird es nochmal deutlich schwerer einen Spielsatz auszubalancieren. Und für den Spieler ist es wohl auch nicht gerade erfreulich, wenn alle Karten anders sind (Kann ich die Wand jetzt sprengen, oder nicht?).

Bitte mal eure hitzige Diskussion unterbrechen, bis ich fertig bin ;) Ich glaube nämlich, hier sind alle zu versteift.

bitte meine Frage zu Variante 2 beantworten (unterstrichen)

Mal sehen, ob ich es richtig auf die Reihe kriege, Fehler bitte korrigieren bzw. erweitern:

Variante 1:

Ein Spielsatz enthält den Spielsatz-Inhalt sowie das Kartenmaterial mit den dazu gehörigen Tilesets.

Vorteil:
- Spielsatz enthält immer alle nötigen Dateien

Nachteil:
- ggf. extreme download-größe

Schlussfolgerung:
- Form für Standard-Spielsatz
- Form für extrem enge Spielsätz (z.B. Stargate-mod)


Variante 2:

Spielsatz enthält Spielsatz-Inhalt + im Verzeichnis befindliches Kartenmaterial. Das Kartenmaterial ist dabei so aufgebaut, dass eine Karte mehrere Tilesets enthält und diese von den Karten aus "gesucht" werden.
Dabei gibt der Spielsatz die Karten vor(?) <- ist das richtig oder wie?

Vorteile:

- geringere downloadgröße für zusätzliche Karten

Nachteile:

Schlussfolgerung:

Der Spielsatz KANN erzwingen [da gibts so nen Windows-Ankreuz-Haken in irgend nem Dialogfeld], dass nur Spielsatzinterne Karten angezeigt werden. OPTIONAL kann eingestellt werden, dass auch Karten verwendet werden duerfen, die auf dem Rechner gespeichert sind.

Eigentlich nicht. Kartendateien und Tilesetdateien werden Separat [aber dennoch im Spielsatz integriert] gespeichert. Der Spielsatz enthaelt also zum einen Tilesets, zum andern Karten, die auf die Tilesets zugreifen koennen und dann natuerlich noch den Rest, der eventuell die Karten steuern kann [Skripte, Spezielle Ausruestung in Karten deponieren etc...].

@Lennstar:
Es gibt noch keine Entscheidung über die Art, wie Karten und Tilesets in den Spielsatz eingefügt werden.
Fest steht nur das es auf jeden Fall Spielsatz-interne Karten geben muss (mindestens für Story-Missionen, die woanders keinen Sinn ergeben) und einen Standartsatz an Karten für allgemeine Situationen - wobei hier noch offen ist, ob die in einem Verzeichnis oder auch im Spielsatz liegen sollen.

In jedem Falle braucht der Spielsatz dabei irgendeine Form der Kontrolle darüber, welche Karte im Bodeneinsatz gewählt wird - andernfalls kommen die Story-Missionen durcheinander oder werden als Zufallskarten aufgerufen.


In der Kartendatei wird der Name des Tilesets sowie die Nummer des Tiles innerhalb dieses Sets gespeichert - deshalb gibt es ja das ganze Durcheinander:
Fehlt die entsprechende T3D-Datei oder ist sie umbenannt worden, kommt es zu den Fehlermeldungen.
Bearbeiten mehrere Leute dieselbe Tile-datei, dann haben unterschiedliche Bilder in unterschiedlichen Ergebnissdateien die gleiche Tile-Nummer und die Karten kommen durcheinander, je nachdem wessen Version der jeweiligen T3D-Datei bei welchem Spieler installiert ist.

Der Lösungsansatz den ich Jim geschickt habe beruht im Wesentlichen darauf, den Namen der Tiledatei bei jedem Tile mit abzuspeichern und sie so besser unterscheidbar zu machen - aber das ist keine so triviale Lösung wie es sich im ersten Moment anhört. Damit das vernünftig funktioniert müsste die Dateilogik in allen drei Programmen verändert werden - insgesamt habe ich 8 Änderungspunkte gefunden, bis das vernünftig inklusive Import etc. arbeiten würde...
Deshalb ging das nur an Jim um festzustellen ob diese Änderung überhaupt möglich ist...


Damit mehrere Kartenersteller ohne Spielsatz beliebig ihre Dateien tauschen und gegenseitig verwenden können, bevor irgendwann die Endergebnisse an einen Spielsatzersteller gegeben werden.
Für die Spielsätze etc. wird das dann natürlich nicht mehr benötigt - siehe auch weiter unten meine Überlegungen zu einer dritten Variante;-)


Du hast recht, damit hatte ich tatsächlich spekuliert. Allerdings sind Deine Gründe dagegen auch stichhaltig und von mir schlicht und einfach übersehen worden.

Deshalb wird es wohl irgendwie auf drei Gruppen von Karten hinauslaufen statt zwei:
1.) offizielle Zufallskarten, entsprechend bekannt und ausbalanziert
2.) Spielsatzinterne Karten, die der Spielsatzersteller festgelegt hat
3.) freie Zufalls- und Testkarten ohne Balance-Garantie

Und im Spielsatz würde jeweils festgelegt werden müssen, welche Karten erlaubt sind - wobei die dritte Gruppe in allen Spielsätzen standartmäßig gesperrt ist und nur gezielt in kleinen bzw. zu Testzwecken vorgesehenen Spielsätzen freigeschaltet wird. Denn wenn man jede unvollständige Kartendatei zum Beta-Test erst in einen Spielsatz importieren müsste, dann ist das unnötiger Aufwand...

OK, und dann kommen wir zu meiner Version 3 für die Kombination Tileset/Karte/Spielsatz ;-)

Sobald eine Karte im Spielsatz enthalten ist, wird sie sowieso nicht mehr bearbeitet - höchstens gelöscht und durch eine aktuellere Version ersetzt.
Deshalb würde ich die Importfunktion des Spielsatzes aufwendiger programmieren und sie beim Import die Tilesortierung erneuern lassen.

Als Ergebnis gibt es intern nur ein einziges Tileset, das allerdings mehr Informationen enthält als die bisherigen externen Tilesets.
Zu jedem Tile im Spielsatz wird die Information gespeichert, aus welchem externen Tileset es stammt, welche Nummer es dort hatte - und eine interne fortlaufende Tilenummer.
Die Karten werden dann umgespeichert auf die neue interne Tilenummer anstelle der alten ID.
Wird eine weitere Karte importiert, dann schaut die Funktion nach ob die Kennung der externen T3D-Datei schon intern vorhanden ist - wenn nein dann wird das entsprechende Tile am Ende der Liste importiert und danach kriegt die neue Karte die interne Indizierung verpasst.

Spart Speicherplatz weil es keine Doppelten mehr gibt und macht die Programmierung des Bodeneinsatzes und die späteren Aufrufe im Spiel auch einfacher, weil es nur noch eine große Tileliste gibt...
Allerdings klappt so eine Neusortierung nicht mit externen Dateien, da diese ja permanent weiterbearbeitet werden...

Warum müsst ihr dass immer so kompliziert machen?
Und vorallem so große Posts.
Es wäre doch am besten wenn es interne und externe Tilesets gäb. Der Spieler kann wählen welche er will, kann sie auch mischen lassen.

Ich hab nur das untere von deinem Roman gelesen.

Nochma: das ganze laeuft gar nich ueber IDs.
Die ganze Idee wirft wieder das Problem des ultra-umstaendlichen Handlings auf. Es ist viel einfacher, wenn man mehrere Tilesets hat, die mit den Karten einfach mitimportiert werden. Sollten die identisch sein, dann wird es schon ein einfaches aussortier-Skript geben.
Zum einen Richtig. Spart Speicherplatz, da nicht ganze Tilesets ueberprueft werden, ob sie identisch sind, sondern nur einzelne Tiles. Das wirft dann sicher mehr raus. Zum anderen: Es macht ide Programmierung des Bodeneinsatzes und die spaeteren Aufrufe im Spiel nicht wirklich einfacher, wenn es nur noch eine grosse Tileliste gibt. Vielmehr gibt es dann probleme bei der Tilesetverwaltung im Spielsatz, was wohl ein sehr grosser Mangel an der Idee ist. Ausserdem muss die Verknuepfung von Tileset und Karte dann sehr aufwaendig und fast voellig neu programmiert werden.

Externe Tilests soll es in der oberen Loesung 2 eh nicht mehr aktiv geben. Nur Kartenarchive, die eventuell vom Spielsatz aufgerufen werden und Spielsatzinterne Karten.

Das Problem bei Loesung 2 ist allerdings, dass einige doppelte Tiles nicht aussortiert werden. Grund:
Ein Tile ist in Tileset1 und Tileset2 vorhanden und identisch. Jetzt kann aber weder das erste noch das zweite geloescht werden, da es auf der Welt ja Kartendateien gibt, die eben auf das eine oder andere zwanghaft zugreifen muessen.

Es läuft über eine Nummerierung der Tiles pro Tiledatei. Ob Du das nun als Kennziffer oder ID bezeichnest ist egal, wobei es im Quellcode intern sogar auch als ID bezeichnet wird.
Das Problem ist nur das diese ID nicht Tileset-Übergreifend ist...

Falsch - absolut gar keine Neuprogrammierung notwendig.
Bisher wird ein Tile identifiziert über den Namen seines Tilesets plus seine Nummer in diesem Tileset.
Als Name wird nun einfach die Bezeichnung des internen Tilesets eingesetzt und als seine Nummer die Nummer, unter der das Tile im internen Tileset neu gespeichert wurde.

Ist im Gegenteil sogar weniger Aufwand als wenn es im Spielsatz mehrere Tilesets mit unterschiedlichen Namen geben würde, die dann untereinander unterschieden werden müssen.
Die Import-Funktion wird natürlich aufwendiger, weil sie bei der Neunummerierung der Karte aufpassen muss - aber das ist im Editor und hat keinerlei Auswirkungen auf das Spielprogramm...

Okay, besonders schlauer bin ich jetzt auch nicht, aber machen wir ruhig weiter mit dem von hinten aufrollen, teilweise habt ihr das ja schon getan. Es bringt nichts, über den Bilderrahmen zu reden, wenn man noch kein Bild hat *g*
Also erst mal davon ausgehen, was am Ende spielerisch raus kommen soll.




Fassen wir erst mal zusammen, was wir wollen:

1. Spielsätze mit darin festgelegten Karten, die zur Story passend sind, und "offiziell" vom Spielsatzersteller dazu auserkoren wurden.

2. Weitere Kartensets, (die dazu passen) und in sich geschlossen logisch sind. (z.B. Ein Arktisgebiet, ein Dschungel, eine Stadt) Diese stellen (wenn das implementiert ist)eine Sammlung Regionsspezifischer Einzelkarten dar, und das Kartenset ist damit exklusiv, d.h. andere Karten sind nicht nötig.

3.a) Einzelkarten - offiziell als geeignet gekennzeichnet (oder wie auch immer)
3.b) Einzelkarten - auf eigenes Risiko

Soweit einverstanden?

Daraus folgt:

Es muss Auswahlmöglichkeiten geben.
Die wären:
1. Spielsatzersteller: wählt Kartenmaterial aus. Diese sind im Spielsatz selbst enthalten mit allen nötigen Daten.

2. Spieler: Wählt Kartensets aus

3. Spieler: Wählt Einzelkarten aus

Was muss dazu beim Spieler vorhanden sein?

1. Auswahl bei der Spielsatzwahl: Mit Original-Karten spielen

2. Auswahl bei Spielsatzwahl: Mit anderem Kartenset spielen: Kartenset wählen

3. Auswahl bei Spielsatzwahl: Mit Zufall-Einzelkarten spielen: Verzeichnis wählen.

Diese Möglichkeiten sind kombinierbar, wobei beachtet werden muss, das Karten von 1. nicht herausgenommen werden können, wenn der Spielsatzersteller das sagt- z.B. weil Kartenmaterial in story-script-missionen verwendet wird.

Daraus folgt:
Es ist am besten, jeweils ein Verzeichnis für Kartensets und Einzelkarten zu haben, letzteres ggf. unterteilt in "offiziell" und "inoffiziell".

Frage: Müssen festgelegte Karten des Spielsatzes in diesem gespeichert werden, oder werden sie beim download (ggf. entpacken) automatisch in das Kartenset-Verzeichnis geschoben?
Ersteres ist einfacher, bläht aber den Spielsatz auf.

Das ist erst einmal, was am Ende herauskommen soll für den Spieler. Das solltet ihr immer im Kopf haben.

Was bedeutet das für die Struktur von Tileset-Karte-kartenset?

Die kleinste Einheit ist das Tileset. Aus einem oder mehreren baut sich die Karte auf. Wiederum mehrere Karten bilden ein Kartenset.

Die Nötig-Verknüpfung geht dabei von groß nach klein: Das Kartenset benötigt alle Einzelkarten, die wiederum alle ihre Tilesets benötigen.
Andererseits sollen tilesets in anderen Karten und Einzelkarten in anderen kartensets verwendbar sein.


Damit sind wir wieder an dem Punkt angekommen, den wir vorher hatten, nur mit dem Unterschied, dass wir jetzt besser wissen, was das Ziel ist!

Wenn ihr also dieser Gliederung im allgemeinen zustimmt, müsst ihr danach einen Weg finden, die Karten untereinander kompatibel zu machen.

Ja, sieht doch schon sehr gut aus.
Und wo ist nun noch dass Problem?
Könnt ihr euch nicht entscheiden wers erfunden hat?
Denn die Versionen die ich gelesen habe klingen für mich relativ gleich.

Sie unterscheiden sich hauptsächlich in der Effektivität der Speicherung (=weniger Dateidownloads) und dem Aufwand bei der Programmierung.

Was wir als Ziel wollen dürfte mittlerweile bei vielen identisch sein (zumindest so wie sich die Diskussion imho immer mehr den Details genähert hat), es geht jetzt nur noch darum welche Methode die beste Umsetzung und damit den geringsten Speicherbedarf bei wenig Aufwand bietet...

@Unrealer: Ich war noch nicht fertig ;)
Da siehst du nämlich das Problem. Im Grunde geht es darum beide Vorschläge zu verbinden, aber ohne die Nachteile des anderen.

Denn: Während es bei einer Einzelkarte noch gehen mag, überflüssige Tiles drin zu haben, ist das bei kompletten kartensets einfacc zu groß, und wenn dann noch ein Spielsatz dazu kommt...
Außerdem muss man, wenn man einen Boden-typ haben möchte, nicht die Tiles für eine ganze Karte importieren.

Ganz wichtig aus dieser ganzen Diskussion finde ich erst einmal folgenden Punkt:
Es muss eine Möglichkeit geben, einzelne Tiles einfachst einzufügen oder zu löschen.

Wie sieht das im Moment aus, wie arbeitet der Karteneditor? Speichert der die Tiles in der Karten-Datei oder funktioniert nichts mehr, wenn ich die die tilesets lösche?

Wenn ich das richtig sehe, speichert die Karte die benötigten tiles nicht ab, sondern nur die Position des tilests, wo die zu finden sind, oder?

Dann bräcuhte man eigentlich "nur" eine Exportoption im Karteneditor, der die Karten-datei und die Tilest-Datei auf welche Art auch immer zusammen packt, so dass sie "versandfertig" ist.
Heruntergeladen wird die dann automatisch entpackt und die Karte in das Karten-Verzeichnis, die tilesets in den tileset-ordner platziert. Dabei sind Karte und tileset schreibgeschützt.
Das ist der "Spielerzustand" für die Verwendung.

Jemand, der eine neue Karte aus alten tilesets erstellen möchte, kann eine erstellen ohne das tileset zu ändern und braucht nicht mal das schreibgeschützt zu entfernen. In diesem Fall reicht es sogar aus, nur die Karte zu verschicken, wenn klar ist, dass der andere die tilesets hat, ansonsten wird wieder alles verschickt.

Wer die vorhandene Karte ändern will oder die tilesets, nimmt den Schreibschutz raus, ändert und "packt" es anschließend wieder in Transportform, wenn er sie anderen zur Verfügung stellen möchte.


Folge: Mit ein paar guten "offiziellen" Tilesets im Downloadpacket des Spieles kann man viele verschiedene Karten bauen ohne noch tilesets extra laden zu müssen, und diese Karten kann jeder ohne Problem verwenden, da ja keine Änderungen in den tilesets vorgenommen wurden.


Man hätte folgende Klassen von Karten:

1. Lieferzustand des Spieles
2. Karten, die die tilesets des Lieferzustandes verwenden, und deshalb keinen tileset-download brauchen
3. Karten, die auf eigenen/fremdem tilesets basieren, aber diese nicht verändern und somit auch ohne tileset-downlaod auskommen. (falls diese vorhanden sind, betrifft z.B. Dinge wie einen Stargate-Mod, bei dem aus den Tiles des Torraumes im Stargate-Center die Alpha-Basis zusammen gebaut wird)
4. Karten mit eigenem tileset, die mit diesem geladen werden müssen (siehe Export)

Somit kann jeder entscheiden, wie er downloaden will, und falls man tilesets doch benötigt, wird die "Versandversion" entpackt und alles ist da.

Zusammen mit der Kartenauswahl beim Spielstart und der Kennung der Karten/Tilesets z.B. mit dem eigenen Kürzel und einer Beschreibung (und wenns nur K1TS2b für Karte 1 Tileset 2 Ausführung b) dürfte es keine Probleme mehr geben :D

Wenn jetzt jemand Karten hat, die für seinen Spielsatz nötig sind und extra erstellt sind, kann er die hinzufügen. Das funktioniert auch wie der Karten-Export: Der SPielsatz wird in einer Versandversion gespeichert, in der auch die Karten mit den benötigten Tilesets drin sind.
Alternativ, wenn davon auszugehen ist, dass die Karten schon vorhanden sind, wird nur der Spielsatz verschickt, die Karten können ja für den Fall des Falles getrennt angeboten werden.

Man darf ja auch nicht vergessen, dass alles in einen Spielsatz zu packen am Ende bestimmt zu einer Größe führt, die der Normaluser mit seinen freenet, web.de etc. Adressen gar nicht versenden kann!
Also Spielsatz und Karten getrennt an Jim schicken, der es dann zum download anbietet in der Form:
(Spielsatz komplett)
Spielsatz
- Karten zum Spielsatz (Exportform mit tilesets)

Wem das jetzt zu viel ist (oder eine Zusammenfassung haben will): Mein post sagt aus, wir brauchen eine automatische Exportoption, die tilesets in Karten und Karten mit tilesets in einen Spielsatz integriert und nach dem download wieder aufsplittet.
Je nach Ebene der Exportversion (Karte/Kartenset/Spielsatz) wird die Datei größer, aber es können auch die einzelnen Teile heruntergeladen werden, falls der Rest schon vorhanden ist.
Dazu noch ein einfaches hinzufügen/löschen von einzelnen Tiles und wir haben kleine Teile für die Bastler und ein großes für den Spieler, der es nur noch entpacken muss (bzw. die config, die das automatisch macht)

Tiles zu addieren ist schon jetzt sehr einfach möglich, hat aber bei Verwendung unterschiedlicher Programmversionen sowie bei gemischter Bearbeitung einer Tileset-Datei durch mehrere Leute Probleme - deshalb möchte Jim ja das alle Tilesetersteller erst einmal ihre eigenen Tilesets erstellen und nicht in den Tilesets von anderen arbeiten.

Das Löschen von Tiles ist dagegen nicht so trivial. Die Löschfunktion ist mit voller Absicht weggelassen worden, da es mit der aktuellen Datenstruktur der T3D-Dateien schlichtweg eine Katastrophe wäre - das Löschen eines Tiles aus einem Set könnte die ganze Kartengraphik durcheinander bringen.

Deshalb kommen ja die ganzen aufwendigen Diskussionen um die Sortierung und Umstellungen der Kartendaten zum Import in den Spielsatz - nur bei diesem Import kann man Tiles weglassen, und das auch nur weil die Karten im Spielsatz nicht mehr weiter bearbeitet werden.

Also könnte man bei dem, was ich Exportform genannt habe dieses weglassen einbauen, die Daten wären bereinigt und wunderbar.
Wie gesagt, wir hätten so die Komplettdaten (Exportversion) und die einzelnen Teile (nach dem entpacken), und Probleme mit verschiedenen tilesets lassen sich einfach bereinigen, indem man sich die Exportversion besorgt, die tilesets und die eigenen nimmt, wieder exportiert, und dann müsste ja (siehe oben) alles doppelte gelöscht werden. (Schlag mich, wenns proggi-mäßig nicht zu machen ist, keine Ahnung.)

Wenn also Leute Karten erstellen, nehmen sie alte tilesets, fügen ggf. Dinge ein, und das wird dann unter anderem Namen gespeichert.
Wäre ganz einfach zu realisieren, indem Standardmäßig jeder editor beim ersten Start die Eingabe eines Kürzels verlangt, das dann vor alle veränderten tilesets/karten kommt. So hätte man bei mir eine LS-dummy. Und die wird dann exportiert.
Umbennen oder was auch immer, kann man immer noch auf eigene Gefahr, aber Inkompatibilität (außer vielleicht bei gleichen Kürzeln) sollte damit erledigt sein.

Ich fang jetz auch an laengere Posts zu schreiben.

Das ist mit der DirkF Methode gar nicht so einfach. Und noch was: Eine Direkt-Bearbeitung-Option taete gut. Tile einfach mit Standard-Bildbearbeitungsprogramm von Windows oeffnen und gut.

Hier mal wieder eine Grafik von mir. Veranschaulichung der aktuellen DirkF Methode [zumindest so, wie ich das verstehe]
BTW: 'DirkF-Methode' soll nicht beleidigend klingen.



Christian hat mal in nem andern Thread geschrieben, dass es nicht ueber IDs laeuft und deshalbt einige Dinge so problematisch sind, wie sie atm eben sind.

Das is auch noch ne gute Idee. Im Spielsatz-Editor zwar festlegen, dass Standardmaessig nur interne Karten verwendet werden, aber doch dem Spieler eine gewisse Eigenmacht ueber die Karten geben.

Ist in gewisser weise identisch mit 1.

Mitten im Spiel oder vor dem Spielstart festlegen?

Ja, das waere einfacher. Blaeht den Spielsatz auch auf. Aber auf der anderen Seite hast du dann keine anderen notwendigen Dateien einzeln herumflattern, und das ist ein Bestandteil dessen, was wir alle wollen. So wenig einzelne Dateien wie moeglich um so viele Fehler in der Dateiverwaltung zu vermeiden.

Die kleinste Einheit ist eher das Tile. Es wird wichtig, dass das Tile die kleinste Einheit ist, wenn man sich das Bild in diesem Post anschaut.
Genau das ist eines der groesseren Probleme im Moment. Das Tile ist nicht die Kleinste Komponente in der ganzen Struktur.

Mit der neuen DirkF-Loesung Benoetigt das Kartenset [nenn ich immer Kartenarchiv] alle Einzelkarten [nenn ich immer Karten-Dateien], sowie auch alle Tiles, und auch nicht Tilesets, sondern wirklich Tiles.


EDIT:
@LennStar:
Mach doch auch Grafiken. Das lockert auf, macht alles leichter verstaendlich und man findet Probleme einfacher. Gerade bei Zusammenfassungen gut.