Reverse Engineering der NLT

[SiENcE]

@Shazu:

hi,
ich hab nach langer Zeit mal wieder in das Forum geschaut und deinen reverse eng. Dungeon Viewer gesehn. Ich hab auch ein bisschen Erfahrung mit dem rev. eng. von Spieler, aber mehr von nachprogrammieren von GameEngines als opensource.

http://www.iris2.de <- Iris2 ein 3D Ultima Online client (projekt von mir)
http://gemrb.sourceforge.net/ <- Biowares Infinity Engine nachprogrammiert (ich arbeite hier ein bissl mit)

Nun mal zu dem was ich sagen will. Wie wäre ein Projekt zur Dokumentation der Fileformate (so wie bei der infinity engine http://iesdp.gibberlings3.net/main.htm ) und danach dann das neucoden von DSA1. Informationen gibts ja über dsa1 genug.

Ich weiss wie aufwändig sowas ist, an Iris1 haben wir 4 Jahre gearbeitet und dann an Iris2 nur noch 6 monate. Ich hab Dsa irgendwann vor 10jahren oder so gespiel. Ich würds aber gern als Oss haben, da man so eigene Dinge um/einbauen könnte.

Es ist nur eine Idee. Was denkt Ihr darüber? Hat jemand Lust?

mfg

SiENcE

[Borbaradwurm]

Nun mal zu dem was ich sagen will. Wie wäre ein Projekt zur Dokumentation der Fileformate (so wie bei der infinity engine http://iesdp.gibberlings3.net/main.htm ) und danach dann das neucoden von DSA1. Informationen gibts ja über dsa1 genug.

Ich weiss wie aufwändig sowas ist, an Iris1 haben wir 4 Jahre gearbeitet und dann an Iris2 nur noch 6 monate. Ich hab Dsa irgendwann vor 10jahren oder so gespiel. Ich würds aber gern als Oss haben, da man so eigene Dinge um/einbauen könnte.

Es ist nur eine Idee. Was denkt Ihr darüber? Hat jemand Lust?

Ich habe schon mit der Dokumentation der Fileformate unter der GNU FDL begonnen. Leider ist die Webseite im Moment nicht mehr auf neustem Stand da mein Studium meine Freizeit gegen Null gehen lässt.

Status:
*mit Ausnahme des NLT1 Intros sind alle Archive der Nordlandtrilogie entpackbar
*NLT benützt bei einigen Dateien den Amiga PowerPacker
*viele Dateitypen sind Standart Dateiformate teilweise schon in OSS Software dokumentiert und implementiert
*Texte sind einfach auszulesen, Dialoge möglicherweise auch
*ein paar Bilddateien der Schicksalsklinge können gelesen werden

danach dann das neucoden

Ich besitze die Regelbücher der dritten DSA Edition.

[SiENcE]

Das hört sich ja schonmal gut an. Ich werd mal dsa vorkramen und die Filedocu lesen. Das komplexeste ist das Kampfsystem denk ich mal, das könnte schwierig werden.

Wenn das intro *.SMK (smaker) ist, dann sollte das auch kein problem sein.

[Shazu]

Sämtliche Videodaten sind afaik Smacker Videos in DSA1. Es sind eigentlich alle Daten in DSA1 sehr simpel aufgebaut und leicht zu lesen, das einzige was mir ein totales Rätsel ist sind die "Dialoge" in Dungeons (ich vermute ja immer noch, dass die hardcoded sind), Dialoge mit NPCs in Städten etc. sind auch ohne größere Probleme zu entziffern.

Bei den Bildern ist afaik nur die verwendete Palette ein Problem...

[Borbaradwurm]

Sämtliche Videodaten sind afaik Smacker Videos in DSA1.

falsch, Smacker wird erst in Schatten über Riva benutzt die Videos von Sternenschweif sind im Autodesk Animator Animation Format und das Intro von Die Schicksalsklinge ist ein eingens hierfür entwickeltes Programm.

Bei den Bildern ist afaik nur die verwendete Palette ein Problem...

Nein, z.B. im Format der Typus Bilder in der Generierung ist die verwendete Palette gespeichert.

[Shazu]

Sämtliche Videodaten sind afaik Smacker Videos in DSA1.

falsch, Smacker wird erst in Schatten über Riva benutzt die Videos von Sternenschweif sind im Autodesk Animator Animation Format und das Intro von Die Schicksalsklinge ist ein eingens hierfür entwickeltes Programm.

Stimmt, hab ich verwechselt. Schweif Videos lassen sich btw mit Quicktime Player abspielen und die von Riva (logischerweise) mit einem SMK Player.

Bei den Bildern ist afaik nur die verwendete Palette ein Problem...

Nein, z.B. im Format der Typus Bilder in der Generierung ist die verwendete Palette gespeichert.

Okay, die Daten des Generierungstools hab ich noch gar nicht angeschaut...aber bei den anderen Bildern ist - zumindest bei denen, die ich mir so angeschaut hab - keine Palette dabei.

[Borbaradwurm]

Stimmt, hab ich verwechselt. Schweif Videos lassen sich btw mit Quicktime Player abspielen und die von Riva (logischerweise) mit einem SMK Player.

Ich benutze für Sternenschweif und Schatten über Riva videos mit mplayer.

Okay, die Daten des Generierungstools hab ich noch gar nicht angeschaut...aber bei den anderen Bildern ist - zumindest bei denen, die ich mir so angeschaut hab - keine Palette dabei.

Welche Bilderdateien hast du dir denn angesehen?

[SiENcE]

Ok. Ich denke mal die Videos sind erstmal egal. Das wichtige sind alle Spielrelevanten Fileformate und spezielle Hardgecodete Dinge in der Exe.

Dann sollte man sich überlegen wie man es umsetzt. Da alles 2D grafik ist und nirgendwo Geschwindigkeitskritische Dinge geschehen, kann man sich überlegen eine nette 2D Engine mit scripting support zu nehmen. In c++ würde ich sowas nicht entwickeln. Lua würde sich meines erachtens gut eignen, die viele Spiele die Sprache verwenden, sie open source und schnell zu erlernen ist.

Nach der entscheidung über die Engines müsste man eine groben Plan machen und Infrastuktur Anforderungen klären. Also anmeldung bei Sourceforge (öffentliches svn), website. Kommunikation kann man ja in diesem Forum weitermachen. Eventuell ne kleine Website mit einem Wiki, zur Dokumentation der Entwicklung (ungefähr so http://iris2.de/index.php/Development ). Ein Developer Blog mit aktuellen Bildern hat sich bei uns super bewährt. Das lockt viele Leute an und jeder kann aktuell die Entwicklung mitverfolgen.

So nun meine Frage. Hat wer Lust das anzufangen.

Da ich ziemlich eingespannt bin mit Ogre3D maintaining, Iris2 und GemRB, würde ich zwar mitcoden und bei Fragen (SF, OSS, Lizenzen etc.) helfen aber das ganze organisatorische und Fileformatdocu mit DSA könnte ich nicht übernehmen.

[Borbaradwurm]

Ok. Ich denke mal die Videos sind erstmal egal. Das wichtige sind alle Spielrelevanten Fileformate und spezielle Hardgecodete Dinge in der Exe.
Dann sollte man sich überlegen wie man es umsetzt. Da alles 2D grafik ist und nirgendwo
Geschwindigkeitskritische Dinge geschehen, kann man sich überlegen eine nette 2D Engine mit scripting support zu nehmen.

Nur in Die Schicksalsklinge ist alles 2D Grafik.

In c++ würde ich sowas nicht entwickeln. Lua würde sich meines erachtens gut eignen, die viele Spiele die Sprache verwenden, sie open source und schnell zu erlernen ist.

Ich würde Aufgrund meiner persönichen Präferenzen C++ nehmen.

Nach der entscheidung über die Engines müsste man eine groben Plan machen und Infrastuktur Anforderungen klären. Also anmeldung bei Sourceforge (öffentliches svn), website. Kommunikation kann man ja in diesem Forum weitermachen. Eventuell ne kleine Website mit einem Wiki, zur Dokumentation der Entwicklung (ungefähr so http://iris2.de/index.php/Development ). Ein Developer Blog mit aktuellen Bildern hat sich bei uns super bewährt. Das lockt viele Leute an und jeder kann aktuell die Entwicklung mitverfolgen.

Ich würde mit der Entscheidung über den Engine erst abwarten wie die Texturen der pseudo-3d engine der Schicksalsklinge aussehen.

So nun meine Frage. Hat wer Lust das anzufangen.

Ich schon, leider fehlt mir im Moment die Zeit.

Aus dem Hexthread:

Schön dass noch jemand sich auf Byte-Ebene mit den Spieldaten der Nordlandtrilogie auseinandersetzt, einiges von dem was Shazu herausgefunden hat war mir neu anderes bereits bekannt. Ich habe im Moment leider keine Zeit mich selbst mit den Daten auseinander zu setzten aber ich möchte doch der interessierten Öffentlichkeit Zugang zu den Dateien innerhalb der Archive von allen Spielen der Nordlandtrilogie verschaffen. Die Programme die Die Schicksalsklinge betreffen wurden bereits an anderer Stelle in Crystals Forum besprochen/zugänglichgemacht dieser Post deckt nun alle drei Teile ab:

nlt2_schick_dat.zip/nlt1_schick_dat.exe
Enpacker/Packer für SCHICK.DAT wobei die Ziel bzw Ursprungs Verzeichnisoption (das Programm arbeitet/sucht immer im aktuellen Verzeichnis) funtkioneren nicht. SCHICK.DAT muss von der CD-Version 3.02 sein (da die Liste der Dateinamen aus SCHICKM.EXE stammt, BLADE.DAT von v3.09 sollte auch gehen, da mir gesagt wurde das die Liste der Dateinamen dieselbe ist)
Um es zu benutzen am besten ein neues Verzeichnis erstellen, SCHICK.DAT und nlt1_schick_dat.exe zusammen dorthin kopieren und dann dort "nlt1_schick_dat -x SCHICK.DAT" zu entpacken bzw "nlt1_schick_dat -c [DATEINAME]" zu packen ausführen, ich rate im Moment dazu SCHICK.DAT vor dem packen aus dem Verzeichnis zu löschen wenn wieder zu SCHICK.DAT gepackt wird

nlt1_dsagen_dat.zip/nlt1_dsagen_dat.exe
Enpacker für DSAGEN.DAT, wird mit "nlt1_dsagen_dat.exe [DATEINAME]" aufgerufen

nlt2_dat.zip/nlt2_dat.exe
Entpacker für die DAT Archive von Sternenschweif, wobei nur die Archive aus dem "DATA"-Verzeichnis auf den CDs funktionieren (das hat mit der min/norm/max Installationsgröße zu tun...), wird mit "nlt2_dat.exe [DATEINAME]" aufgerufen

nlt3_alf.zip/nlt3_alf.exe
Enpacker für ALF Archive von Schatten über Riva, wird mit "nlt3_alf.exe [DATEINAME]" aufgerufen

Warnung: die Programme enthalten keinerlei Fehlerbehandlung und arbeiten immer im aktuellen Verzeichnis...
http://mitglied.lycos.de/noctrun/dsa/files/

Die Programme sind, obwohl ich selbst unter Linux entwickle, für Windows, den entsprechenden Sourcecode (C++) gibt's auf Anfrage.

[Shazu]

Ok. Ich denke mal die Videos sind erstmal egal. Das wichtige sind alle Spielrelevanten Fileformate und spezielle Hardgecodete Dinge in der Exe.

Bei dem (vermutlich, bin mir immer noch nicht sicher) hardgecodedetem Zeug bin ich ja nicht weiter gekommen, die einzige Möglichkeit die ich da sehe ist meiner Meinung nach das alles einfach nachzuprogrammieren...

Dann sollte man sich überlegen wie man es umsetzt. Da alles 2D grafik ist und nirgendwo Geschwindigkeitskritische Dinge geschehen, kann man sich überlegen eine nette 2D Engine mit scripting support zu nehmen. In c++ würde ich sowas nicht entwickeln. Lua würde sich meines erachtens gut eignen, die viele Spiele die Sprache verwenden, sie open source und schnell zu erlernen ist.

Wenn es in Lua gemacht wird bin ich sofort dabei! Ich hab relativ viel Lua Erfahrung (ich hab im Moment ein WoW Mod, das von mir alleine entwickelt wird und > 50k Zeilen Code und >500k Benutzer hat...da hab ich so einiges über Lua gelernt)

Ich denke eine schöne kleine 2D Engine wäre natürlich perfekt, wobei ich einer 3d-Engine gegenüber auch nicht abgeneigt wäre, damit wären auch die kleinen Probleme der Schick-Engine wie "wieso sehe ich die Truhe rechts neben mir nicht?" und "ist das da neben mir ein Tempel oder ein normales Haus?" gelöst.

Nach der entscheidung über die Engines müsste man eine groben Plan machen und Infrastuktur Anforderungen klären. Also anmeldung bei Sourceforge (öffentliches svn), website. Kommunikation kann man ja in diesem Forum weitermachen. Eventuell ne kleine Website mit einem Wiki, zur Dokumentation der Entwicklung (ungefähr so http://iris2.de/index.php/Development ). Ein Developer Blog mit aktuellen Bildern hat sich bei uns super bewährt. Das lockt viele Leute an und jeder kann aktuell die Entwicklung mitverfolgen.

SVN braucht man immer und Wikis sind toll, das sollten wir auf jeden Fall so machen

So nun meine Frage. Hat wer Lust das anzufangen.

Da ich ziemlich eingespannt bin mit Ogre3D maintaining, Iris2 und GemRB, würde ich zwar mitcoden und bei Fragen (SF, OSS, Lizenzen etc.) helfen aber das ganze organisatorische und Fileformatdocu mit DSA könnte ich nicht übernehmen.

Ich wäre wohl ziemlich sicher dabei




Die Frage ist, ob man wirklich alle Dateifopmate so übernehmen will? Einige scheinen mir eher weniger gut zu sein...das Format für Dungeons gefällt mir z.B. überhaupt nicht und ist in Schick wohl nur mit ziemlich viel hardcoding so möglich.

Auch die beiden Textformate TLK und LTX würde ich so nicht übernehmen...zumindest LTX würde ich streichen und in TLK umwandeln oder gleich was anderes für beides nehmen.

TLK enthält Daten über den Verlauf eines Dialogs mit NPCs, LTX enthält nur Strings...auch von Dialogen wie "hier ist eine Falle, wollt ihr <sie versuchen zu entschärfen> <...>", wo da der Verlauf etc. gespeichert ist? K.a.

Das Savegame-Format ist teilweise auch seltsam, ich weiss nicht, ob ich das übernehmen würde....

Nur so als Beispiele

[SiENcE]

Ich bin erfreut über die Antworten.

C++ würde ich nicht nehmen, da gibts einfach zuviele Fallstricke. Um eine Core engine kommen wir eh nicht drumrum. Die muss dann eh in C++ programmiert werden. Jedenfalls ist mir keine Engine bekannt die komplett auf einen Luabinding setzt. Ich habe auch sehr viel Lua Erfahrung (Iris2) und würde dies auch bevorzugen. @Shazu: welches WoW addon hast du denn gecodet, wenn ich fragen darf :-) ?

Wenn wir die original Daten (grafiken, sound etc.) nehmen wollen, dann müssen wir auch loader für alles schreiben. Man darf nicht daten in andere Formate konvertieren und dann distributieren (das haben wir alles schon mit UO durch, da is auch vieles suboptimal (gelinde ausgedrückt)).

Natürlich sollten wir alles so abstrakt wie möglich halten, damit man später neue Dungeons dazubauen kann (die können wir ja dann als xml file oder so, abspeichern). Ich würde vorschlagen das wir so eine art wrapper für jedes dsa1 dateiformat schreiben. Die Datenstrukturen für das Dsa1 Remake sollten wir aber nach unseren Wünschen gestallten. Der wrapper läd dann die original Dateien und modelt sie in unsere Datenstrukturen rein.

Damit kann man dann auch einfach neue wrapper schreiben, zum Beispiel für neuere Dateiformate oder DateiformatVersioen von dsa2 und 3.

In Bezug auf die Engine müsste man sich mal umschauen. Eine reine 2D Engine limitiert die Möglichkeit, dass wir auch support für Dsa2 und 3 einbauen. Vielleicht findet man eine 2D/3D Engine, die komplett in Lua gescripted werden kann. Ich persönlich habe viel erfahrung mit Ogre3D, jedoch ist sie für 2D Projekte eigentlich nicht geeignet.

In Bezug auf die sourceforge projekt registrierung (http://sourceforge.net/register/index.php). Welche Namen nehmen wir?

opendsa
dsaclient
nlt
nltclient
...weitere Vorschläge?

[Shazu]

Jedenfalls ist mir keine Engine bekannt die komplett auf einen Luabinding setzt. Ich habe auch sehr viel Lua Erfahrung (Iris2) und würde dies auch bevorzugen.

Es gibt IrrLua (Irrlicht Lua bindings, aber afaik wird die seit ca. 1 Jahr nicht weiter entwickelt) und "Luxinia", das ist dann eine komplette 3d engine, die sich komplett mit Lua ansteuern lässt

@Shazu: welches WoW addon hast du denn gecodet, wenn ich fragen darf :-) ?

Deadly Boss Mods (www.deadlybossmods.com)
Falls du dir den Source jetzt durchliest, nicht wundern...das war mein erstes richtiges Programm, das ich in Lua geschrieben habe. Also da ist viel alter Code dabei, bei dem ich viele Tricks von Lua noch nicht kannte. Ich habe vor ca. 60% des Codes neu zu schreiben für eine der nächsten Versionen

Wenn wir die original Daten (grafiken, sound etc.) nehmen wollen, dann müssen wir auch loader für alles schreiben. Man darf nicht daten in andere Formate konvertieren und dann distributieren (das haben wir alles schon mit UO durch, da is auch vieles suboptimal (gelinde ausgedrückt)).

Stimmt, verdammt. :/

Natürlich sollten wir alles so abstrakt wie möglich halten, damit man später neue Dungeons dazubauen kann (die können wir ja dann als xml file oder so, abspeichern). Ich würde vorschlagen das wir so eine art wrapper für jedes dsa1 dateiformat schreiben. Die Datenstrukturen für das Dsa1 Remake sollten wir aber nach unseren Wünschen gestallten. Der wrapper läd dann die original Dateien und modelt sie in unsere Datenstrukturen rein.

Damit kann man dann auch einfach neue wrapper schreiben, zum Beispiel für neuere Dateiformate oder DateiformatVersioen von dsa2 und 3.

Das wäre sinnvoll, ansonsten würden wir sehr schnell an die Grenzen des DSA1 Formats stoßen
(z.B. Dungeons: max 16 Ebenen, mit je 16*16 Felder, die 16. Ebene wäre leicht in der Funktion eingeschränkt...oder evtl. Hinzufügen neuer Objekte/Haustypen in Städten wäre ein Problem, das ist auf 16 begrenzt im Dateiformat...die Anzahl der Gegner in Kämpfen auf 20 oder so)

Das größte Problem für den Wrapper wäre dann das hardgecodete, aber das wird schon irgendwie gehen

In Bezug auf die Engine müsste man sich mal umschauen. Eine reine 2D Engine limitiert die Möglichkeit, dass wir auch support für Dsa2 und 3 einbauen. Vielleicht findet man eine 2D/3D Engine, die komplett in Lua gescripted werden kann. Ich persönlich habe viel erfahrung mit Ogre3D, jedoch ist sie für 2D Projekte eigentlich nicht geeignet.

Siehe oben


Edit: opendsa oder opennlt wären schöne Namen

[SiENcE]

Luxinia ist eigentlich gut, aber leider nicht OSS und auch nur für Linux. Irrlicht würde ich pers. nie nehmen.

Dann schon lieber Ogre3D. Zumal wir da Lugre ( http://lugre.schattenkind.net/index.php/Main_Page ) programmiert haben (ein Ogre3D Lua binding mit erweiterten 2D funktionen und vielen anderen kleinen helferlein).

Man könnte auch LuaSDL: http://luaforge.net/projects/luasdl/. Für 3D könnte man dann ja eine 3D render engine nehmen. So richtig gefällt mir das alles nicht.

OpenDsa finde ich auch gut.

[Shazu]

Luxinia ist eigentlich gut, aber leider nicht OSS und auch nur für Linux.

Jo, leider nicht open source...aber sehr wohl auch unter Windows

IrrLua würde ich pers. nie nehmen. Dann schon lieber Ogre3D. Zumal wir da Lugre programmiert haben (ein Ogre3D Lua binding).

Hab ich mir gedacht
Lugre kannte ich bisher noch gar nicht, das sieht ja extrem gut und brauchbar aus!

Leider hat Ogre3D nur sehr rudimentäre 2D Funktionen.
Wie wäre es mit LuaSDL: http://luaforge.net/projects/luasdl/. Für 3D könnte man dann ja eine 3D render engine nehmen. So richtig gefällt mir das alles nicht. Ich hätte gern eine gekapselte 2D engine, mit OIS und OpenAL bzw. Fmodx. Aber SDL ist Plattformübergreifend und wir können auf noch andere SDL addins einbauen. Ich such aber noch weiter.

OpenDsa finde ich auch gut.

An SDL hatte ich auch gedacht, mir persönlich wäre es jedoch lieber gleich eine 3d Engine zu nehmen, auch DSA1 würde sich damit imho super darstellen lassen...je nachdem wie sich die Texturen Verwenden lassen, das müsste man sich noch anschauen.

[Fury]

Hilfe? Bahnhof?

[SiENcE]

@Fury: Wart solange bis ne website mit beschreibung da is...im moment is das hier ziemlich technisch :-).

Also dann kein SDL. Ich hab mal mit unserem Lugre Entwickler geredet und er meint wir sollten Ogre+Lugre nehmen (OIS für inputsystem und OpenAL oder FMod für Sound). Damit ließe sich alles umsetzen und er könnte für uns noch weitere Dinge in Lugre einbaun (falls nötig). Weiterhin nutzen bis jetzt 4 projekte Lugre und die Ogre3D community ist ja sowieso 1A hilfsbereit (bin übrigends maintainer bei ogre für den mingw sdk).

[Obi-Wahn]

Iris2 sieht ja schon mal sehr gut aus und wird wohl auch vollkommen reichen für ein "Remake" der NLT. Es ist im Gegenteil besser, wenn die Grafik nicht so gut ist. Wenn ihr im späteren Verlauf, also wo es nichts mehr mit Programmierung zu tun hat, mit Modells und Texturen anfangt, könnt ihr mich ja mal fragen, ob ich dann noch Lust habe mit zu machen. In solche Sachen würde ich mich wohl rein arbeiten.

[Asgrimm]

Klingt interessant, leider kann ich aber auch nicht mehr sagen als Fury (Hilfe? Bahnhof?)

Paranoia on
Das man durch so was keine Schwierigkeiten bekommen kann, hast du gecheckt?
Paranoia end

[Shazu]

Was ich mir im Prinzip eigentlich vorstelle ist so etwas ähnliches wie Schweif, das Feldersystem ist super um leicht und ohne große Vorkentnisse oder viel Aufwand Städte/Dungeons zu erstellen...das ganze lässt sich imho super mit Ogre/Lugre realisieren...die Karten könnte man irgendwie in XML speichern, mir schwebt da irgendsowas vor:

<Dungeon>
<Feld x="1" y="1">
<Typ Objekt="normalesHaus" Tür="S"/>
<OnEnter>
<![CDATA[
luacode()
]]>
</OnEnter>
</Feld>
</Dungeon>

Das geht zwar schon viel zu weit ins Detail, aber egal


Generell bin ich gegen "gute" Grafik, wie z.B. in Riva...der Aufwand um z.B. eine neue Stadt zu erstellen oder ein neues Dungeon wäre mir einfach viel viel zu hoch. Imho würden zu hohe Grafikstandards einfach irgendwie zu viel Arbeit auf sich ziehen, lieber was gescheites, großes anstelle von etwas kleinem mit super toller Grafik. Man muss ja nur mal z.B. die Anzahl der Städte von Schick bis Riva vergleichen
Oder die Arbeitszeit hinter dem Erstellen von einer Stadt wie z.B. Prem in Schick, Lowangen in Schweif und Riva in Riva vergleichen.


Ansonsten hätte ich nichts gegen Lugre/Ogre...Ogre-Grundkentnisse kann ich auch vorweisen, ich hab zumindest mal die meisten Tutorials im Wiki durchgearbeitet und besitze dieses Buch "Pro Ogre 3D programming"

[SiENcE]

Ja wie gesagt, bei der Grafik sollten wir erstmal das gegebene nehmen. Gibt es schon programme um die Grafiken in ein richtiges Bildformat zu konvertieren?
Später kann man die Texturen und Bilder ja austauschen gegen highres bilder.

IMHO sollte erstmal alles beim alten belassen werden und sich voll auf die prog. gestürzt werden. Ich glaube auch nicht, das wir schwierigkeiten bekommen. Ich sagte ja schonmal, dass man die original daten nicht verändern oder distributieren darf. Also jeder der freedsa (opendsa der name is schon weg bei sourceforge) benutzen will, benötigt erstmal auch Dsa (später wenn man genug eigene grafik erstellt hat wird das obsolete). Falls wir es schaffen die 3d Modelle der Städte von Schick zu decodieren, brauchen wir auch nix neues erstllen. Wir laden das einfach und stellen es dar. Wie gesagt wrapper.

@Shazu: den codetrigger zu lua sollte man nicht ins xml reincodieren. Das sollte man in der lua datei machen, da man so sogar mehrere trigger oder auch ausnahmen usw. darauf anwenden könnte ohne das man vorhersehen muss was der anwender eigentlich will (bissl lua muss er dann aber schon verstehen). Naja wie auch immer. Erstmal anfangen. Ich werd morgen mal den Namen "freedsa" bei SF registrieren (einwände oder vorschläge bis dahin noch an mich (eventl. einen namen ohne free oder open aber mit dsa) ;-).