Arena-Forum

Hallo zusammen,

ich sitze gerade während meiner Klausuren-Pause an dem (hoffentlich) bis auf weiteres letztem Stück Software, das das AddOn für die nächste Stufe (Renaissance) vorbereiten und mir helfen soll, die Alpha etwas besser zu entbuggen als es bisher der Fall war.

Dazu ist allerdings eine folgenschwere Entscheidung zu treffen: Wie ist mit der Kompatibilität von TC-/AddOn-Maps umzugehen?

Vorweg: Wie vermutlich bekannt ist, hat jede Einheit und jede Technologie im Spiel eine bestimmte, feste ID. Solange die gleich bleiben, funktionieren Maps auch in gemoddeten Spielversionen. Wenn einige dieser IDs aber verschoben oder überschrieben werden, ist es meist auch mit der Kompatibilität von Maps dahin.

Warum betrifft das das AddOn? Nun, es wird eine große Menge von Objekten im Spiel geändert, um das neue Zeitalter und die neuen Einheiten zu realisieren. Der Technologiebaum wird weitgehend umgestaltet. Bisher wurde darauf geachtet, dass ältere Maps immer noch mit dem AddOn funktionieren; nachdem ich nun aber bei den Programmierarbeiten auf die Hürde gestoßen bin, dass sich das effiziente und fehlerfreie Hinzufügen und Einbetten neuer Einheiten als schwierig erweist, da die DAT-Datei so arg verworren ist, möchte ich eine Diskussion über die weitere Handhabung dieses Themas einleiten.

Es geht um folgende Idee: Mein Programm ändert nicht wie ursprünglich geplant nur bestimmte Orte in der DAT und lässt alles weitestgehend so, wie es seit ES-Zeiten war, sondern sortiert sämtliche Einheiten, Gebäude und Technologien so um, dass der Programmieraufwand und damit auch die Buganfälligkeit minimal werden. Das würde aber offenbar automatisch die Kompatibilität zu mit früheren Versionen erstellten Szenarien killen, heißt: Eine TC-Map läuft nicht auf der Beta, und eine Beta-Map läuft nicht auf der Gamma. Wir machen uns darüber Gedanken, da hoffentlich so manch einer mit dem Beta-Release die neuen Einheiten und Eye-Candys wird ausprobieren wollen , und es schade wäre, wenn dann niemand mit der Final-Version (Gamma) diese Maps wird spielen können. Ich überlegte auch schon bereits, das Beta-Zwischenrelease zu überspringen und direkt die Gamma fertigzubauen, aber das wird vermutlich an mangelnder Zeit seitens Barbarossa und mir sowie noch nicht hinreichend fertiggestellter Gamma-Grafiken scheitern.

Nun also die beiden Möglichkeiten, die wir haben:

1. Abwärtskompatibel: TC-Maps sollen in allen AddOn-Stufen funktionieren; Beta-Maps (Renaissance) sollen in der Gamma Version (finales Release, Renaissance+Schiffsänderungen) funktionieren
2. Release-konsistent reicht: Solange etwaige spätere Bugfix-Patches die Kompatibilität von Maps nicht stören, ist alles okay

Argumente für Möglichkeit 1:

• In einer AddOn-Version läuft alles.
• Ältere TC-Maps können direkt im AddOn geöffnet und überarbeitet werden - also ein guter Ansatz für Remakes.
• Einige im Spiel hardgecodete (= fest in die EXE einprogrammierte) IDs könnten nicht mehr richtig funktionieren (abschwächbar: Die hardgecodeten IDs halten sich in Grenzen, die meisten sind längst bekannt; die schwer verschiebbaren könnte man notfalls auch beibehalten).

Argumente für Möglichkeit 2:

• Es lässt sich mit vorhandenen Bibliotheken gern ein kleines Konvertierungsprogramm nachreichen, das alte Maps automatisch auf das neue AddOn upgradet.
• Ob die Beta-Änderungen (und aufwärts) mit älteren Maps überhaupt kompatibel sein können, ist noch nicht sicher; es werden viele Standard-Dinge geändert (allein schon die Civ-Boni...), sodass trotz weitgehender ID-Gleichheit keine sichere Funktionalität garantiert werden kann.
• Die neuen Einheiten können bei Möglichkeit 1 von keiner KI entwickelt werden (abschwächbar: Das Verschieben/Löschen einiger sowieso nie verwendeten Nonsens-Einheiten könnte genug Platz schaffen).
• Es gibt ohnehin für jede AddOn-Stufe einen eigenen Scenario-Ordner, sodass die Stufen unabhängig voneinander gespielt werden können.
• Hoher Programmieraufwand bei Möglichkeit 1.
• Geringer Programmieraufwand, da einfache und effiziente Algorithmen eingesetzt werden können, sobald die große Datenmenge einmal konvertiert ist.
• Struktur-bedingte Bugs können nahezu ausgeschlossen werden (Sachen wie "Kloster entwickelt auf einmal Milizsoldaten" oder ähnliches )

Ich persönlich sehe die Vorteile klar bei Möglichkeit 2, aber da wir ein Community-AddOn erstellen, möchten wir vorher gern eure Meinung dazu hören

Je nachdem, welche Variante die meiste Zustimmung findet (besonders unter den alteingesessenen Mappern hier ), werde ich diese umsetzen oder nicht. Was den höheren Aufwand betrifft, da macht euch keine großen Sorgen - wenns dem allgemeinen Wunsch entsprecht, ist das für mich kein Problem.

Wenns Fragen gibt oder euch noch Argumente einfallen, oder ihr nur eure Meinung sagen wollt - ich freue mich über jeden Post!

Ich halte die Abwärtskompatibilität nicht für so wichtig.
Das wäre eigentlich nur ein Stückchen Komfort, auf das ich verzichten kann.
Solange man TC/Addon ja auch getrennt voneinander spielen kann seh ich da keine tieferen Probleme.

Und wenn man durch gute Sortierung Ordnung in die Ganze Sache bringt, ist das doch auch eine Investition in die Zukunft, oder nicht?
Das dürfte spätere Arbeiten damit doch erleichtern bzw. beschleunigen.

Ich sehe das genau so. War schon das gleiche bei TC zu AOK oder FE zu TC. Wenn man die ursprüngliche Karte "original" spielen wollte dann starte man einfach das alte Spiel.

Wenn man die ursprüngliche Karte "original" spielen wollte dann starte man einfach das alte Spiel.

Eben. Ist im Prinzip ja nur ne Frage, welches Start-Icon man drückt.
Das, worum es ja im Grunde nur geht, ist der einzige Wehrmutstropfen bei Lösung 2:
dass gegebenenfalls schon mit der Beta gemappte AddOn-Maps nicht mit der finalen Gamma-Version kompatibel sein werden. Allerdings ist das dann auch nicht umständlicher, als wenn man eben heutzutage noch ne Age of Kings-Map spielen will.

Davon abgesehen, ist #2 wegen der technischen Vorteile, die Jan genannt hat, einfach die vorteilhaftere Variante.
Insbesondere angesichts des geringeren Programmieraufwandes für Jan und des minimierten Bug-Potenzials.

Janworks hat geschrieben:Das Verschieben/Löschen einiger sowieso nie verwendeten Nonsens-Einheiten könnte genug Platz schaffen

Janworks hat geschrieben:Ob die Beta-Änderungen (und aufwärts) mit älteren Maps überhaupt kompatibel sein können, ist noch nicht sicher;

Seitdem Parallel-Installationen ja problemlos möglich sind (vor FE und Userpatch ja noch ein Heiß' Eisen...), ist diese einschränkende alte Prämisse ("nur additive Änderungen zu AoC!") zum Glück eh bedeutungslos geworden.

Kompabilität wäre ein n2h, aber bei dem ausstehenden Mehraufwand, so wie er beschrieben wurde, definitiv nicht wert.

Der Unterschied von AoK -> TC oder TC -> FE verglichen mit diesem Mod ist allerdings auch, dass das Gameplay gleich geblieben ist, wenn es auch minimale Balance-Änderungen gab. Szenarien konnten also größtenteils gleich gespielt werden, nur dass es z.B. beim Spielen in TC Petarden gab. Wenn ich mir dagegen die stark spieländernden Veränderungen, eine gesamte neue Zeit und komplett umgebauten Wasserkampf, angucke, dann hat das doch erheblich weniger vom Originalgameplay. Daher müssten wohl entweder Szenarien eh umgebaut werden, oder entsprechend auf manche Änderungen (die jetzt nicht AddOn- sondern Conversion-Charakter haben) verzichtet werden. Beides scheint aber nicht das Ziel zu sein, deshalb ist das durchaus eine schwierige Frage.

John hat geschrieben: dass das Gameplay gleich geblieben ist

Das spielt ja aber für die derzeitige Fragestellung wie gesagt überhaupt keine Rolle, da dank der Parallelinstallationen niemand mehr einen nachvollziehbaren Grund hat, zB ein Spielversion X-Szenario unbedingt mit Spielversion Y spielen, erstellen oder umbauen zu müssen.
Userpatch und FE waren da ja durch die neue Dateiendung nun weit subversiver. Und auch bei AoK und TC gabs durchaus mehr Kompatibilitäts-Querelen zu bedenken als die Petarden - erinnere mich zB an eine sonst funktionierende AoK-Map, die sich unter AoC durch den Ersatz des Harald Haardrade-Helden erst zu Ende als ungewinnbar offenbarte.

Hier gehts letztlich ja nur um die Diskussion über den Bedarf einer Kompatibilität von AddOn-Szenarien innerhalb der einzelnen drei AddOn-Releasestufen. Und das eigentlich nur für den hypothetischen Fall, dass jemand bereits vor Gamma-Release schon eine Map auf Basis von Beta erstellen will.
Das wäre auch schon der einzige (wie Timinator so schön formuliert hat) "Nice to have"-Vorteil von #1.

Ohhh ich hab mich dann wohl verlesen, sorry. Dachte es geht um TC -> AddOn.

Ja sowas wie den Harald da hatte ich bei den Schiffen gemeint.

Aber wenn es nur um Versionen innerhalb des Mods geht, dann ignoriert meinen Post.

Ich sehe, aMa hat das sogar in die News gepackt...
Umso besser

Da haben sich ja schon einige Posts angesammelt. Top!
Freut mich, dass Variante 2 bisher deutlich bevorzugt wird.

@John:

Ohhh ich hab mich dann wohl verlesen, sorry. Dachte es geht um TC -> AddOn.

Nein, hast du nicht. Es ging technisch gesehen um beides - sowohl TC -> AddOn als auch AddOn -> AddOn
Die Beta würde gegenüber TC vermutlich relativ kompatibel bleiben, sofern man halt alle neuen Einheiten und Technologien auf neue IDs legt und die alten nur bedingt anfasst.

Sehe ich sonst auch so wie du: Die neuen Schiffslinien werden vermutlich so schon kein Haar mehr am Originalsystem lassen, da gibts bei Map-Ports vermutlich grundsätzlichere Probleme als geänderte IDs...

@Aws:

Und wenn man durch gute Sortierung Ordnung in die Ganze Sache bringt, ist das doch auch eine Investition in die Zukunft, oder nicht?
Das dürfte spätere Arbeiten damit doch erleichtern bzw. beschleunigen.

Ja, definitiv. Von der viel geringeren Buganfälligkeit ganz zu schweigen.

@Barbarossa:

Wenn das machbar ist, auf jeden Fall. Denn eine Menge der slps sind mit hoher Wahrscheinlichkeit bloß Datenmüll...
Rein visuell im MPS oder vergleichbaren Tools kann man das natürlich gerade bei den nur fragmentarisch erkennbaren slps oft nur vermuten. Aber das kannst über die .dat ja denke sicher ermitteln, ob die wirklich nirgendwo verwendet werden?

Naja, die SLPs würde ich erstmal so lassen, wie sie sind...da könnte man gewiss auch mal drüber nachdenken, aber bis auf weiteres ist es doch einfacher, die bei den bekannten IDs zu behalten. Der Aufwand ist da ja noch überschaubar, und freie IDs gibts da ja zuhauf

Vielleicht mag noch jemand etwas schreiben, der für Variante 1 gestimmt hat?

Janworks hat geschrieben:Ich sehe, aMa hat das sogar in die News gepackt...

Die neuen Schiffslinien werden vermutlich so schon kein Haar mehr am Originalsystem lassen

Die Beta würde gegenüber TC vermutlich relativ kompatibel bleiben, sofern man halt alle neuen Einheiten und Technologien auf neue IDs legt

Auch dann blieben aber glaube immer noch paar Einzelfälle, wo sich Einheitenstats und -optiken ändern und sich ggf. in einer Map hinderlich oder auswirken könnten.
Das verhielte sich, so ad hoc eingeschätzt, derzeit ähnlich zwittrig wie bei AoK-Maps unter AoC: technisch an sich vllt. kompatibel, aber optisch und funktional (durch Änderungen von vereinzelten Grafiken, Techs und Einheitenwerten) im Einzelfall misslich.

Aber insgesamt ja eben zu Gunsten der Innovationen kein Thema (mehr), eine 100%ige sichere Kompatibilität von AoC-Maps zu AddOn zwingend zu wahren.
Die Abstimmung ist da nun eh recht eindeutig - und sollte tatsächlich jemand ankündigen, zwischen Beta und Gamma schon was mappen zu wollen, ließe sich auch (mit etwas Vorwarnzeit) vllt. eine Lösung finden.

Naja, die SLPs würde ich erstmal so lassen, wie sie sind...

Bin ich jetzt auch nur mal drauf eingegangen, weil du es selbst als Bedarfsoption angeschnitten hast.
Einfacher wäre es natürlich, wir kämen ohne aus. Evtl. reicht es ja, alle AddOn-Objekte, die nicht KI-relevant sind, bei der Nummerierung nach hinten zu schieben (?)

Die KI braucht IDs von 0 - 899, um eine Einheit "sehen" zu können. Also um sie zu zählen oder speziell auszuwählen. Bauen kann sie sogar auch so, auch wenn das ohne die restlichen Funktion schonmal sehr... spaßig werden kann. (Hatte mal ne Einheit mit höherer ID baubar und die KI sollte davon max. 5 ausbilden aber da sie nicht zählbar war, hat die KI nicht damit aufgehört diese Einheit zu bauen und konnte daher nichts anderes in diesem Gebäude mehr machen.)

Gibt aber reichlich ungenutzte IDs in dem Bereich, und da ich glaube dass die meisten Einheiten und Gebäude ja eher für den Editor gedacht sind solltet ihr sogar gänzlich ohne ID-verschieben auskommen.

Aaah, danke für die genaue Information! Hatte schon danach gesucht, aber keine weiteren Angaben darüber gefunden. Scheint als wär der Forenbeitrag dazu hier wieder irgendeinem Bug zum Opfer gefallen...
Wo wurde diese Beschränkung überhaupt eingeführt? Erst im UserPatch oder schon in TC?
Eben, es ist eher sinnfrei, wenn die KI die Einheiten zwar bauen, aber nicht zählen kann

Hmm, die ID-Verschiebung liegt auch eher weniger am mangelnden Platz, sondern wie gesagt an der Methode, mit der ich meine Änderungen in die DAT schreibe. Eine Umsortierung ohne Rücksicht auf Verluste ist algorithmisch einfach viel schneller umzusetzen und spart obendrein benannte Buganfälligkeiten.

Die KI benutzt die IDs im 900er Bereich für Klassen. 936 ist zum Beispiel die Klasse der berittenen Bogenschützen. Ohne Userpatch können 900+ Einheiten die KI verbuggen und das Spiel in Kombination mit dieser instabil machen, soweit ich weiß. Mit Userpatch sind sie schlichtweg nicht wahrnehmbar aber machen auch keine anderen Probleme.

Warum Einheiten im 1000+ Bereich auch nicht nutzbar sind, kann ich nicht sagen, ich weiß nur dass es so ist.


Ach ja, Einheiten mit 900+ IDs werden in der militärischen Minimap-Ansicht ebenfalls nicht mitgezählt.

Sorry für meine späte Rückmeldung, die letzte Woche war bei mir etwas "verklausurt"

Soo, danke für die zahlreichen Antworten! Das ist ja ein klares Ergebnis für Variante 2, die ich dann jetzt auch implementieren würde.

@John: Aah, okay, danke für die Erklärung. Dann sorg ich dafür, dass die Standard-Einheiten entsprechend bevorzugt werden.

Haha, kein Problem. Hatte zuletzt selbst 3 Klausuren und schreibe auch noch 2, also genau das gleiche hier.

Ich hasse Finanzbuchführung und Marketing.