@ 1,2,3 (Kartenauswahl): Ich habs ja extra detailliert geschrieben. (Außerdem teilweise überholt, wenn man meine Export-Funktion nutzt)
Es geht darum dass der Spieler auswählen kann, auf welchen Karten er spielt. Beim Spielstart. Zwischendrin halt ich nicht für sehr gut, außerdem dürfte das Verwaltungsprobleme bringen.
Der Spieler wählt im Grunde aus: Mit von Spielsatzersteller vorgegebenen Karten spielen, oder womit?
Das Womit ist der Übersichtlichkeit unterteilt in vollständige Kartensets (man muss also bloß eins auswählen, und diese können ev. automatisch erkannt werden) und Einzelkarten, die man dann entweder per Verzeichniswahl oder einzeln auswählen kann.
Wenn der Spielsatzersteller keine eigenen Karten vorgegeben/vorgeschalgen hat, werden automatisch die Standardkarten genommen, also die, die beim Spiel installieren mitkommen.

@Tiles/Tilesets: Eigentlich meinte ich auch einzelne tiles, aber ich weiß nicht, wie das gespeichert und verarbeitet wird, darum hab ichs bei tileset gelassen. Ein tile ist auch ein tileset ;)
Ich habe das auch deswegen gemacht, da ich im Hinterkopf hatte, dass ein tileset ja auch die Wände, Türen, Fenster eines Hauses sein kann, aber keine Bodenplatten, und somit mehrere nötig sind für eine Karte. Das gibt aber wiederum kleine tilsets, die einzeln verschickt werden können. So kann ein Grafiker UFO-Innenteile machen, der nächste ne Kirche etc. und dann kann jeder da draus ne Karte bauen wie er will. (und mit der Exportoption automatisch zusammenfassen)


Wie ich schon mal erwähnt habe, ich kenne mich mit den editoren nicht aus, aber in Logik und Strukturen bin ich gut ^^ Nur mit fehlenden Daten nützt natürlich auch die beste Logik nichts. (Wieso denke ich jetzt an Mr. Spocks Verwirrung bei der Frage: Wie fühlen sie sich? *g*)

@nightelf: Wenn du mir noch sagst, wie ich die Grafiken machen soll? ;) Ich weiß nicht, ob ich das überhaupt in paint hinkriege, gescheige woanders (wo auch immer). Außerdem seit ihr so schnell, da schaffe ich es ja nicht mal zu schreiben, bis ihr schon wieder postet, und dann auch noch ne Grafik machen O.o

Eben nicht so ohne weiteres. Das klappt bei dem Import in den Spielsatz nur, weil die Dateien im Spielsatz nicht mehr weiter bearbeitet werden können.
Sobald Du aber eine "exportierte" Karte wieder bearbeitest, können identische Tiles mit unterschiedlichen Kennungen entstehen. Das passiert schon automatisch indem Du dasselbe Tile aus einem externen Tileset nimmst, was Du in der früheren Bearbeitung schon einmal benutzt hast. Es ist sofort zweimal im Kartensatz, weil es mit den bestehenden Dateiformaten keine Möglichkeit gibt diese Tiles als identisch zu erkennen.
Und es ist extrem schwer die Disziplin zu waren, immer erst in der zugeordneten unsortierten Kartentiledatei mit allen bereits verwendeten Tiles nach einem bestimmten Bild zu suchen, wenn man weiß wo es in den geordneten externen Dateien liegt...

Theoretisch könnte man zwar eine aufwendige Vergleichsroutine schreiben, aber die würde auch andere Probleme haben - das ist weiter oben unter "interne Speicherung der Tiles in der Map" diskutiert worden.

Kannst du das mal genauer sagen?

Wie wird bei einer Karte was gespeichert? Und was passiert, wenn ich ein gleiches Tileset zusammenschiebe?

Problem: Einzelkarten, oder wie ich sie bezeichne 'Karten-Dateien' sind Bestandteil eines Karten-Archives, oder wie du es nennst 'Kartenset'. Einzelkarten wieder zum Spielen zu verwenden wirft wieder die Einzeldate-Verwaltungsprobleme auf, die ja anfangs Hauptziel dieser Diskussion waren.
Wenn man wieder Einzelkarten im Spiel selbst benutzt kann man das 'Kartenarchiv' wieder ganz weglassen und alles einzeln abspeichern, und die Diskussion ist zumindest ein Drittel umsonst.

Hehe, gute Ueberlegung, ist aber nicht so ganz so. Einzelne Tiles und Tilesets mit nur einem Tile drinnen haben Unterschiede. Lauter Tilesets mit nur einem Tile drin sind einfach umstaendlich und kompliziert. Einzelne Tiles sind im Moment noch gar nichts, und das ist eines der Probleme, fuer das eine Loesung gefunden werden muss. Es muss eine verbesserte Verwaltungsmoeglichkeit fuer einzelne Tiles gefunden werden. Eine moeglichkeit ist, in saemltichen Kartenarchiven anstatt mehrere Tilesets nur lauter Tiles zu verwenden. Tilesets in Form von richtigen Tilesets sind dann nur noch fuer Grafiker zum Transport wichtig. Fuer diese Loesung muesste man halt genausestens ueber die aktuelle und ueber jegliche moegliche Verwaltungsmoeglichkeiten bescheid wissen.

Jein ;-)

Es wird unmöglich sein, Tiles im Spielsatz zu löschen (genau wie es aktuell absolut unmöglich ist Tiles in Tilesets zu löschen).
Das ist allerdings unabhängig von den Möglichkeiten, Tiles und Tilesets vorher zu bearbeiten und zu löschen.
Nach meiner Version sollte der Spielsatzersteller die Karten fertigstellen, bevor er sie in den Spielsatz integriert. Dieser Import würde dann das Durcheinander mit den jetzt bestehenden Formaten beseitigen, allerdings um den Preis das anschließend im Spielsatz nur noch Karten gelöscht und ersetzt werden können, aber weder Karten bearbeitet noch Tiles gelöscht werden.


OK, mal genauer beschreiben - dann wird auch klar weshalb die Tiles momentan nicht gelöscht werden können.
Einiges vom folgenden habe ich übrigens nicht im Quellcode gefunden, sondern nur aus Querverweisen und Jim's Hinweisen geschlossen.

Innerhalb der T3D-Datei liegen die Tiles ohne irgendwelche Verwaltung hintereinander.
Die Map-Datei muss aber sehr wohl diese Tiles identifizieren können, sonst würde ja alles durcheinander gewürfelt sein. Dies geschieht dadurch, das die M3D-Datei jeweils den Namen der T3D-Datei zusammen mit der Nummer des Tiles innerhalb der T3D-Datei speichert.
Dementsprechend braucht jede Map-Datei alle namentlich gelisteten Tiledateien in genau der Form wie sie bei dem Kartenersteller vorlagen.

Gegeben sei jetzt eine Karte M und eine Tiledatei X mit drei Tiles, im folgenden 1, 2, 3 genannt.
Der Kartenersteller benutzt diese drei Tiles, die dann in der M3D-Datei auch mit Kennung X1, X2, X3 gespeichert werden.
Wenn jetzt Tilesetersteller 1 hingeht und ein Tile 4 einfügt, dann wird dies mit Tilekennung X4 in den Kartendateien M gespeichert. Der Tileersteller hat also eine Variante der Tiledatei X erzeugt, die ich als Xa bezeichne obwohl sie immer noch den Namen X trägt.
Tilesetersteller 2 hat jetzt ein Bild 5, speichert dies aber in der Originaldatei - womit dieses fünfte Bild in einer Variante Xb ebenfalls als Tile mit der Position X4 gespeichert wird.

Wenn jetzt eine Karte mit der Verwendung des vierten Tiles erstellt wird, dann wird sie bei verschiedenen Spielern mit unterschiedlichen Versionen der T3D-Datei X (denn die Ersteller haben natürlich nicht in Xa und Xb umbenannt, sondern den Namen X behalten) mal das eine und mal das andere Bild benutzen - die Kartendatei M speichert ja nur den Code X4, ohne eine graphische Unterscheidung vorzunehmen.

Sollte dagegen jemand hingehen und ein Tile (z.B. 1) aus der Datei entfernen, dann rutschen alle Tiles in ihrer Nummerierung nach vorne - d.h. das ehemalige Tile mit dem Code X2 hört jetzt auf den Zugriffscode X1 usw. Wenn dann eine Karte mit dem durch die Löschung verschobenen Tileset X aufgerufen wird, dann wird sich jede einzelne Tilegrafik verändert haben.

Und aus diesem Verhalten resultiert halt auch, das jede Tilesortierung wie ich sie beschrieben habe nur möglich ist wenn die entstehenden Karten und das Gesamttileset danach nie wieder bearbeitet werden.
Durch die Einführung des zusätzlichen Index in Form der ehemaligen Tilekennung der externen Dateien für die internen Tilespeicherungen ist es aber möglich, bei beliebigen Kartenaktualisierungen trotzdem konsistent zu bleiben und keine doppelten Speicherungen zu produzieren.

Und an der ganzen Misere wird sich nichts ändern, solange die T3D-Dateien keine dateiübergreifende Tile-Identifizierung erhalten. Eine derartige Umprogrammierung ist aber auch nicht trivial, wie ich oben schon postete...


EDIT: Bezeichnungen und Formulierungen im Beispiel X besser formuliert...

Jein - die Einzelkarten sind ja aus meiner Idee zur dritten Gruppe von Karten entstanden, den ersten Probekarten von Leuten die noch nicht fit genug sind um komplette Kartensets zu erstellen. Diese Einzelkarten müssen nach wie vor testbar bleiben - und wenn nur dafür damit ein Spielsatzersteller sie anschauen kann, bevor er sie in seinen Spielsatz übernimmt.

Allerdings war von mir nie vorgesehen (wie von LennStar teilweise unglücklich formuliert) das der Spieler diese Karten einem Spielsatz aufzwingen kann.
Wenn der Spielsatzersteller die Option freigibt beliebige Karten zu benutzen, dann kann sich der Spieler entscheiden derartige Karten hinzuzufügen und zu testen.
Ich gehe aber davon aus, dass die meisten Story-Spielsätze dies blockieren werden um die Spielbalance nicht zu stören und das nur dafür gedachte einfache Spielsätze diese Option für Abwechslung nutzen werden.

Und natürlich diejenigen speziellen Spielsätze, die von den Spielsatzerstellern für den Betatest unvollständiger Kartendateien geschrieben wurden, denn ich für meinen Teil möchte nicht ständig ein unvollständiges Kartenset in meinen Spielsatz importieren und wieder löschen - und mit dem Test zu warten bis ein größeres Kartenset vollständig ist hat wieder andere Probleme...

Okay, Definitionen sind gefragt:

Tile: ein X-mal-X großes Bild
(Einzel)Karte: X-mal-X (16x16?) große Fläche aus einzelnen tiles
Kartenarchiv: X Einzelkarten, die eine spielbare Bodeneinsatz-Karte ergeben.
Kartenset: Eine Zusammenstellung von Kartenarchiven, die mit script oder anderen Variablen gezielt aufgerufen werden können- Eisfeld, Wüste, Stadt, UFO etc. (bzw. lediglich die lose Ansammlung von Kartenarchiven wie im Moment noch.)

Spielsatzinhalt: Was mit dem Spielsatzeditor erstellt wird- Waffen, Aliens etc.
Spielsatz: Spielsatzinhalt+ ausgewähltes Kartenset (egal ob eine oder mehrere Kartenarchive)


In Ordnung so? Berichtigungen, Ergänzungen?
Wenn wir uns nicht einigen, redet der eine nur am andern vorbei ;)

Ich würd mich ja gerne noch an der Diskusion beteiligen aber hier wird so viel geschrieben das ich mit dem Lesen nicht mehr nachkomme. Darum nur was zum letztem Post.


Ich glaub auch.
Beziehen die sich nun auf jetzt oder sind das Vorschläge wie etwas in Zukunft definit werden soll?


Für mich ist das ein Raum.

X Räume + ein Script das diese zu verschiedenen Bodeneinsatz-Karten zusammen setzt ist ist für mich ein Kartenset und wird in einer .m3d Datei gespeichert.

Fuer mich ist das auch ein Raum.
Eine Einzelkarte ist eine .m3d Datei. Darin sind auch Skripte enthalten. Sie sollen nach gefundener Loesung nicht mehr vorkommen.
Ein Kartenarchiv sind x .m3d Dateien und y .t3d Dateien. Evtl xt: xma [x-force map archive]
Kartenset = Kartenarchiv.
Spielsatz = Spielsatzinhalt + Integrierte Karten. Nicht ausgewaehte, eventuell externe.

@Lennstar:
Die Räume haben 15x15 Tiles und sie sind hier nie diskutiert worden, da sie Teil einer Einzelkarte sind - und zwar ein Teil den man nie Kartenübergreifend verbreiten wird, da eine Karte auch ein passendes Script zur Raumverteilung braucht.


Du wirst immer auf Einzelkarten zugreifen müssen - gerade Spezialmissionen lassen sich nicht anders als mit Einzelkarten reallisieren.

Der Vorteil eines Kartenarchivs mit mehreren Karten gegenüber mehreren Einzelkarten liegt hauptsächlich in der Reduzierung des Speicherbedarfs und der Dateiverbreitung, aber im Spiel selber werden nach wie vor die Einzelkarten für den Bodeneinsatz aufgerufen - unabhängig ob sie nun Teil einer Gruppe von Karten in einem Archiv oder für spezielle Zwecke geschaffene Einzelkarten sind.

Ich hab absichtlich ein wenig "daneben" formuliert (provoziert), denn besser als schwammige Defs sind welche, die auf Widersprüche stoßen und so besser werden. Also so:

Definitionen:

Tile: ein X-mal-X großes Bild
Raum: X-mal-X (15x15) große Fläche aus einzelnen tiles
Einzelkarte: X Räume, die eine spielbare Bodeneinsatz-Karte ergeben (Räume angeordnet durch scripte). Gespeichert als .m3d
Kartenarchiv (Kartenset): Eine Zusammenstellung von Einzelkarten, [die mit script oder anderen Variablen gezielt aufgerufen werden können- Eisfeld, Wüste, Stadt, UFO etc. (bzw. lediglich die lose Ansammlung von Kartenarchiven wie im Moment noch.)]

Spielsatzinhalt: Was mit dem Spielsatzeditor erstellt wird- Waffen, Aliens etc.
Spielsatz: Spielsatzinhalt+ vom Spielsatzersteller ausgewähltes und integriertes Kartenset

In Ordnung so? Berichtigungen, Ergänzungen?
Wenn wir uns nicht einigen, redet der eine nur am andern vorbei ;)

Was soll nicht mehr vorkommen? .m3d? Scripte? Einzelkarten?

Das ist schon klar. Das spiel wird alle in einem Kartenarchiv gespeicherten Karten und auch Tilesets [evtl statt tilesets nur tiles] entpacken muessen.
In beispielsweise 'finde das UFO Wrack und saeubere es' kann man eine .m3d Datei so Alaska-Maessig machen, wo dann halt noch ein UFO auf ein paar Raeumen ist.

1. Doppelpost 2. .m3d dateien. Sie sollen halt bestandteil des ultra-vorteilhaften Kartenarchivs werden.

Ein Kartenarchiv hat nur dann Vorteile, wenn es mehrere ähnliche Karten enthält. Das klappt aber nicht automatisch - z.B. wird das UFO-Wrack nicht unbedingt für jede beliebige Landschaft existieren.
Außerdem setzt Du damit vorraus, das ein Spielsatzersteller überhaupt eine Klimazonenabhängige Kartensortierung verwenden will - das muss nicht der Fall sein.
Ich möchte das eher universell halten - siehe 1223. Und ein Kartenarchiv mit nur einer Karte ist auch eine Platzverschwendung - da kann man besser Einzelkarten als Option offen lassen.

Das is ja logisch.

Tu ich nicht. Der Einsatz soll vorgegeben in Alaska generiert werden. Is mir halt grad so eingefallen.

=> Wieder problem mit Tilesets => Ganze Diskussion umsonst.

Wieso sollte es da ein besonderes Problem geben?
Das aktuelle Problem der fehlenden Tile-ID mit ihren Folgen wirst Du auch in den Kartenarchiven nicht los (wenigstens so lange nicht wie Du nicht sagst das Kartenarchive nie mehr bearbeitet werden dürfen), und andere Probleme sehe ich nicht...

Vielleicht solltest Du mal sagen was für Dich in einem Kartenarchiv drin ist und wie es aus einzelnen Karten und einzelnen Tilesets zusammengestellt wird und wo es dann eingesetzt werden soll...

Richtig


Die Dateiverwaltung!! Deswegen hat diese Diskussion [oder dieser Thread] angefangen! Keine einzelnen .m3d und .t3d Dateien mehr.

Wenn es keine IDs gibt, warum wird dann bei Bedarf nicht eine eingebaut?

Aber mit einzelnen Dateien ist es doch meiner Meinung nach einfacher dass alleszu handhaben.
Also eine Für die Pole, eine für Europa, eine Für Asien...

Der Globus ist in Gebiete unterteilt. Der PC schaut, ahha Gebiet Nr.3 allso kann er sich zwischen allen Tilesets mit der ID 3XXX eins aussuchen und die Karte somit aufbauen.
Der Tileset Autor muss nur beim bauen beachten welche Zone dies ist damit er es auch dann auswählen kann.

Nicht ganz korrekt.

Für den Spielsatzersteller und für den Spieler darf es keine einzelnen M3D und T3D-Dateien mehr geben.

Der Kartenersteller ist aber zwangsweise auf diese einzelnen Dateien angewiesen - zum einen gibt es keine ID mit der man die T3D-Dateien auseinanderreißen kann und zum anderen müssen die Tiles für die Kartenersteller ja nach wie vor tauschbar bleiben - sonst könnte jeder in seinen Karten nur noch eigene Tiles anwenden, und ein Tausch der Tiles per Pseudo-Archiven (Archiv mit leerer Karte) ist auch nur umständlich.

Korrektur: Keine publiken einzelnen .m3d unt .t3d Dateien mehr. Grafiker brauchen T3D Dateien und Mapper M3D Dateien.
nochn prob: wenn die mapper jetz ihre map fertig ham, muesstens gleich en kartenarchiv erstellen, da sonst evtl wieder fehler und probleme und so auftreten. des archiv muss aber flexibel sein sodass auch karten und tilesets noch bearbeitet werden koennen.