Sammelpatch für die NLT

[tommy]

Mir kommt gerade ne ganz toll idee, wo ihr hier so viele individuelle Sachen macht. Ich habe daran gedacht, das man einen Patch machen könnte um ganz leicht Änderungen einzufügen und wieder rückgängig zu machen. Da hätt ich irgendwie richtig bock drauf und wenn ihr mir helft geht das auch ruck zuck (also je nachdem wie ich Zeit habe, vielleicht ne Woche oder so).

Mir schwebt da was Plugin basiertes oder gescriptetes vor, so das ihr zur not auch noch ohne mich patches ergänzen könntet.

Bitte bezieht ich immer auf die aktuellste Version des Spiel, dass erleichtert es für uns alle.
Bitte schreibt immer rüber was ihr geändert habt und trennt das immer schön, so dass nur das an Änderungen zusammensteht was auch zusammengehört.
Bitte auch gerne Patches die Fehler beheben...z.B. wie ich gerade gelesen habe, taucht in Schick die Textbox nicht auf, dass das Totenschiff untergeht.

So zum Layout. Bitte kurz schreiben was geändert wurde und dann nach Möglichkeit untereinander (erleichtert mir einiges, ist aber auch kein muss) die jeweiligen Adressen und der neue Wert.

z.B.
Ich bin ein Text, der sagt was geändert wurde
0xAF00 = 0x26
0xAF01 = 0x30
0xAF02 = 0x01

So dann werdet mal kreativ, ich bin gespannt was ihr da so zaubert^^

[Lippens die Ente]

wen meinst du da konkret, tommy? mich auch? ich ändere nur per Hexeditor, sobald ich weiß, wo was steht.

[guitarjohnny]

also ich habe ja grade für meinen nlt durchlauf mir eigene klassen überlegt und dafür waffen blacklists und magische waffen angepasst.

was man vermutlich einfach umsetzen könnte und auch toolgestützt schön darstellen könnte, wäre ein update der waffenblacklists auf sinnvolle werte (zwerge = schwere armbrust, thorwaler = streitaxt etc.). hierbei würde ich nichts zusätzlich einschränken, sondern nur freischalten, damit für niemanden gewohnheiten eingeschränkt werden (ich bin sicher es gibt einige powerelfen mit magischem kettenhemd da draußen ).

mittelmäßiger aufwand wäre ein rebalancing der magischen waffen, bei dem ein bisschen darauf geachtet wird, dass möglichst jede klasse eine sinnvolle magische waffe finden kann. dabei würde ich einerseits waffendaten anpassen - ich habe z.b. das bastardschwert stärker gemacht.
weiterhin könnte man auf dem weg ein paar völlig neue waffen kreieren, allerdings immer auf kosten einer bereits bestehenden besonderen waffe. da es aber einige meines erachtens nach recht nutzlose besondere waffen gibt, sollte das kein problem sein (z.b. die unspektakulären asthenilteile).

starter ideen:
- ich habe schonmal versucht, die für druiden nutzlose magische sichel in einen unzerbrechlichen vulkanglasdolch mit pflanzenkunde bonus zu verwandeln, scheitere aber noch an der bildreferenzierung und der zuweisung der korrekten waffengattung. wenn das vollbracht wäre, kann man die blacklist an der stelle anpassen und der druide hat eine richtig nette klassenwaffe.
- einen der zahlreichen besonderen zweihänder im spiel (z.b. orkhöhlenzweihänder) könnte man in ein deutlich besseren degen verwandeln.
- langdolche gibt es bislang in der nlt gar nicht. asthenildolch wird zu magischem langdolch (1w+3, at +1, unzerbrechlich).

ich könnte mich in mittlerer zukunft mal an die blacklists setzen, komme aber erst in ein paar wochen dazu.

[tommy]

@Lippens die Ente
ja dich auch, das was guitarjohnny geschrieben hat geht schon in die richtige Richtigung. Im Grunde meine ich alles von Bugfixes, über verbesserungen im Spiel oder sogar das erschaffen von neuen Herausforderungen.

Also im Grunde will ich das war ihr aktuell für euch mit einem Hexeditor ersetzt mithilfe von simplen sripten und einem selbstgeschriebenen Installer für alle zugänglich zu machen. Eurer creativität sind hierbei keine Grenzen gesetzt.

Theoretisch lässt sich sowohl die .exe als auch die .dat modifieren. Das Umsetzen für die .exe sollte sehr schnell gehen, das geht einfach über über die Adresse. Die Dat dauert da schon etwas länger, weil ich vorher entpacken und hinterher wieder verpacken muss, aber da kann ich auch viel code aus meinem "DSA viewer" wiederverwenden...nur von Riva hab ich noch nicht alzuviel ahnung.

Aber überlegt euch einfach ein paar Settings, die ihr gerne umsetzen würdet und sagt mir was ihr konkret geändert habt. Für den Angfang reichen mir so 1-2 Settings die mir einen gewissen Überblick über die nötigen baustellen geben. Aus diesen Grundgedanken werde ich dann ein Installer und ein Scriptkonzept (höchstwahrscheinlich xml) entwerfen. Und wenn das ganze dann steht, kann jeder neue Settings/bugfixes/verbesserungen entwerfen und diese hier im Forum teilen.

Also werdet einfach ml kreativ, ich bin gespannt^^

[Hendrik]

Tommy, so ein Tool haben wir schon. Das "cracker.exe" genannte Tool verwendet ein ähnliches Format und wurde von mir für den MR-Patch von Schicksalsklinge verwendet:

Ein Beispiel:

Code:

00397801: FF 11 # 12 (Pirat)

ersetzt an Position 0x00397801 das Byte 0xFF durch 0x11; der Rest der Zeile ist Kommentar.
Man kann in eine .crk-Datei beliebig viele Patches aufnehmen; die Angabe von altem+neuem Byte dient nicht nur der Sicherheit (Prüfung, ob die richtige Version gepatcht wird); sie ermöglicht es auch, den Patch rückgängig zu machen.

Einziges Manko: Man kann keine Daten einfügen / löschen. Das ist aber bei Binärformaten ohnehin nicht ganz einfach. Ein für diese Zwecke geeignetes Tool wäre übrigens "gsar": (binary) Global Search And Replace, das verwende ich derzeit, um Kunars Schreibfehler-Liste für Schick in einen Patch umzuwandeln.

EDIT: Ebenso täte es das von NRS verwendete "replace.com", zusammen mit einer passenden .BAT-Datei. Nachteil gegenüber "cracker.exe" ist, dass die Originaldaten fehlen, damit gibt es weder Sanity-Check noch Undo-Funktionalität.

[guitarjohnny]

mir ist noch eine idee eingefallen, um die sich lippens mit seiner truhenhexerei-knowledge beschäftigen könnte.

wir haben doch den magischen säbel aus dsa1 im spielrepository. der ist übrigens auch noch in schweif vorhanden wenn man ihn im inventar hat. wenn du weisst, wo und wie es geht, wäre es klasse, wenn wir den in eine truhe hexen könnten. dafür würde sich meiner meinung nach eine truhe in der zwingfeste anbieten, die ja insgesamt noch relativ lootarm ist im vergleich zu den andern dungeons. als erste magische waffe die auch gegen untote besonders wirkt, hätte der säbel direkt gegen den heshtot auch eine funktion und später auch bei herberge & co. gute verwendung.

ich würde die stelle rausfinden, an der wir die waffe dann noch etwas verbessern und unzerbrechlich machen können, dann hätten die hiebwaffenkämper ein nettes gimmick.

[Lippens die Ente]

Jetzt, da ich weiß, wo die Truheninhalte (hier zählen auch die Leichen und Regale dazu) sich in etwa befinden (auch die Inhalte der Daspota-Häuser sind hier zu finden), kann ich das sehr leicht tun. Dieser Säbel soll ja nirgends zu finden sein. Er hat den Hexcode
AC (nur das erste Byte ist hier wichtig). Hier muss man allerdings die Schickm.exe verhexen, und zwar etwa bei 0x1Bxxx , da beginnen die Truhen- Kisten- und Leicheninhalte in den Dungeons. Es gibt allerdings zwei Arten von Behältern, wobei jedes Dungeon nur eine von beiden Arten unterstützt. Die Zwingfeste zum Beispiel enthält gestapelte Gegenstände, die Spinnenhöhle Einzelgegenstände. Will man in einen Behälter der Zwingfeste also den Säbel hineinlegen, sucht man eine Truhe aus und ändert einen der vorhandenen Gegenstände in AC um, dahinter käme dann die Anzahl dieses Gegenstandes, zum Beispiel 2 davon wäre AC 02. in der Spinnenhöhle gibt es nur Einzelgegenstände, da müsste man dann AC AC eingeben, um zwei magische Speere in die Truhe zu legen.

Aber Vorsicht: du darfst keine bytes löschen oder einfügen, sondern nur vorhandene Gegenstände umändern. Wir die Anzahl der gesamt Bytes gestört, startet das Spiel nicht mehr. Das gilt aber nur für die schickm.exe, die entpackten Dateien der Schick.dat kannst du erweitern und kürzen, ohne dass gleich das Spiel kaputt ist.

[tommy]

Tommy, so ein Tool haben wir schon. Das "cracker.exe" genannte Tool verwendet ein ähnliches Format und wurde von mir für den MR-Patch von Schicksalsklinge verwendet:

Ein Beispiel:

Code:

00397801: FF 11 # 12 (Pirat)

ersetzt an Position 0x00397801 das Byte 0xFF durch 0x11; der Rest der Zeile ist Kommentar.
Man kann in eine .crk-Datei beliebig viele Patches aufnehmen; die Angabe von altem+neuem Byte dient nicht nur der Sicherheit (Prüfung, ob die richtige Version gepatcht wird); sie ermöglicht es auch, den Patch rückgängig zu machen.

Einziges Manko: Man kann keine Daten einfügen / löschen. Das ist aber bei Binärformaten ohnehin nicht ganz einfach. Ein für diese Zwecke geeignetes Tool wäre übrigens "gsar": (binary) Global Search And Replace, das verwende ich derzeit, um Kunars Schreibfehler-Liste für Schick in einen Patch umzuwandeln.

EDIT: Ebenso täte es das von NRS verwendete "replace.com", zusammen mit einer passenden .BAT-Datei. Nachteil gegenüber "cracker.exe" ist, dass die Originaldaten fehlen, damit gibt es weder Sanity-Check noch Undo-Funktionalität.

Interessant, wusste ich so noch garnicht. Aber ich muss sagen wirklich befriedeigen tut mich das nicht...

Ein einfaches ersetzen würde sowieso nur bei der .exe funktionieren und damit wären die Änderungen nur auf Bugfixes beschränkt....abgesehen davon ist die cracker.exe ne 16Bit anwendung und funktioniert nur über DosBox...kann man zwar machen, aber naja...und ich finde es auch nicht unbedingt optimal jedes mal eine neue .crk Datei erzeugen zu müssen...

Mich wundert nur gerade wie funktioniert das mit dem "gsar" Ding? Die Texte sind doch verpackt, die dürftest du doch eigentlich garnicht direkt ändern können oder?

Also bisher bleib ich auf den Stand, dass ein neues Tool sehr nützlich wäre...gerade wenn neue Patches als xml Dateien nachgeladen werden könnten...


@Lippens & Jonny
Ihr macht das super, genau sowas wollte ich sehen^^ So verleihen wir den Spielen einen ganz neuen Charm

Mal schauen, wenn ich es schaffe, plane ich heute Abend mal das Tool auf dem Papier

[Hendrik]

Tommy, so ein Tool haben wir schon. Das "cracker.exe" genannte Tool verwendet ein ähnliches Format und wurde von mir für den MR-Patch von Schicksalsklinge verwendet:
[...]
EDIT: Ebenso täte es das von NRS verwendete "replace.com", zusammen mit einer passenden .BAT-Datei. Nachteil gegenüber "cracker.exe" ist, dass die Originaldaten fehlen, damit gibt es weder Sanity-Check noch Undo-Funktionalität.

Interessant, wusste ich so noch garnicht. Aber ich muss sagen wirklich befriedeigen tut mich das nicht...

Ein einfaches ersetzen würde sowieso nur bei der .exe funktionieren und damit wären die Änderungen nur auf Bugfixes beschränkt....abgesehen davon ist die cracker.exe ne 16Bit anwendung und funktioniert nur über DosBox...kann man zwar machen, aber naja...und ich finde es auch nicht unbedingt optimal jedes mal eine neue .crk Datei erzeugen zu müssen...

Mich wundert nur gerade wie funktioniert das mit dem "gsar" Ding? Die Texte sind doch verpackt, die dürftest du doch eigentlich garnicht direkt ändern können oder?

Also bisher bleib ich auf den Stand, dass ein neues Tool sehr nützlich wäre...gerade wenn neue Patches als xml Dateien nachgeladen werden könnten...


@Lippens & Jonny
Ihr macht das super, genau sowas wollte ich sehen^^ So verleihen wir den Spielen einen ganz neuen Charm

Mal schauen, wenn ich es schaffe, plane ich heute Abend mal das Tool auf dem Papier

Das Hinzufügen von Daten ist ohnehin nicht so ganz ohne. Einfachste Lösung dafür ist: Archiv enpacken, Datei ändern, Archiv einpacken - so wie Lippens es auch bereits tut.
Das "gsar" funktioniert nur dann wenn man (a) nicht-komprimierte Archive oder Einzeldateien patcht und (b) in Archiven nicht die Dateigröße ändert. Die Archivformate der NLT haben allesamt keine eigene Kompression, das macht das Lesen von Dateien recht einfach und schnell (war ja damals wichtiger war als ein wenig Speicherplatz sparen). Für das Ändern von Texten ist das in der Tat nicht befriedigend, da müsste man zwischendurch das Archiv entpacken, die einzelnen Dateien verändern und das Archiv wieder einpacken.

Es gibt übrigens auch noch Binpatch, das etwas moderner und flexibler ist als die cracker.exe. Inkrementelle Patches (das ist es doch, was du möchtest, oder?) leistet das aber auch nicht ohne Weiteres.
Gerade habe ich noch das hier gefunden: Multipatch. Das sollte dem, was du suchst, schon recht nahe kommen. Leider Mac-spezifisch, da müsste man einen plattformunabhängigen Fork machen.

[tommy]

Das Hinzufügen von Daten ist ohnehin nicht so ganz ohne. Einfachste Lösung dafür ist: Archiv enpacken, Datei ändern, Archiv einpacken - so wie Lippens es auch bereits tut.

genau das war auch mein Gedanke und da ich vieles davon bereits in meinem DSA Viewer genutzt habe, sollte sich ein Tool welches den Vorgang automatisiert auch recht schnell umgesetzen lassen.

Mein Gedanke war halt, das ich ein tool stelle, welches eine Reihe von Patches(xml Dateien) einliest und dann einen Auswahldialog für die Installation anbietet. Die .exe und .dat würde ich vorher sichern, sodass änderungen jederzeit wieder rückgängig gemacht werden können.

Mein Gedanke ist halt, so eine xml Datei kann jeder schnell umsetzen und wenn das Tool da ist kann das auch jeder ohne große Schwierigkeiten umsetzen. Die anderen Tools finde ich halt etwas ungeeignet, da sich damit die .Dat nicht so ohne weiteres manipulieren lässt.

[Hendrik]

Das Hinzufügen von Daten ist ohnehin nicht so ganz ohne. Einfachste Lösung dafür ist: Archiv enpacken, Datei ändern, Archiv einpacken - so wie Lippens es auch bereits tut.

genau das war auch mein Gedanke und da ich vieles davon bereits in meinem DSA Viewer genutzt habe, sollte sich ein Tool welches den Vorgang automatisiert auch recht schnell umgesetzen lassen.

Mein Gedanke war halt, das ich ein tool stelle, welches eine Reihe von Patches(xml Dateien) einliest und dann einen Auswahldialog für die Installation anbietet. Die .exe und .dat würde ich vorher sichern, sodass änderungen jederzeit wieder rückgängig gemacht werden können.

Mein Gedanke ist halt, so eine xml Datei kann jeder schnell umsetzen und wenn das Tool da ist kann das auch jeder ohne große Schwierigkeiten umsetzen. Die anderen Tools finde ich halt etwas ungeeignet, da sich damit die .Dat nicht so ohne weiteres manipulieren lässt.

Wenn du Hilfe mit den Archiven brauchst, sag einfach Bescheid, ich habe mich damit ja recht intensiv auseinandergesetzt. Es gibt da tatsächlich ein paar Fallen, in die man laufen kann. Ich kann dich bei diesem Teil auch gerne mit Code unterstützen.
Warum möchtest du eigentlich XML als Format? Ist das nicht etwas unhandlich (im Sinne von "mit Spatzen auf Kanonen schießen") für diese Aufgabe? Ich würde ein einfacheres Format empfehlen, z.B. eines der Binary-Patch-Formate (IPS, UPS, PPF, XDelta, BSDiff, BPS), ggf. mit einem kleinen Header davor.
Unabhängig davon kannst du statt XML auch JSON verwenden, das ist etwas handlicher (beim Schreiben/Lesen von größeren XML-Dateien werden die ganzen Tags schnell zur Spaßbremse).

[tommy]

Danke für das Angebot, wenn ich auf Probleme stoße komme ich gerne drauf zurück...aber zumindest das entpacken hab ich ja schonmal umgesetzt gehabt, dass packen kann da ja auch nicht so viel schwerer sein...

Ich fand xml halt immer recht übersichtlich (wenn man es richtig aufbaut...) und das lässt sich halt auch recht schnell mit einem texteditor erstellen und ansehen ist auch ganz einfach. Aber ehrlich gesagt kenn ich die anderen Formate garnicht, aber ich kann sie mir ja mal anschauen^^
Achja und wegen mit "Kanonen auf Spatzen schießen" (haha ich seh gerade du hast die redwendung falschrum geschrieben, wie geil xD) Ja stimmt es ist etwas overpowered, aber ehrlich gesagt die änderungen werden wohl nie sooooo riesig sein und selbst wenn der PC mal ne Sekunde braucht um das abzuarbeiten merkt das eh keiner...und wie gesagt ich finde xml halt sehr übersichtlich und leicht zu erstellen....aber ich schau mir auch gerne nochmal die alternativen an^^

[Hendrik]

Mit Spatzen auf Kanonen schießen ... muss ich mir merken.
Also, die Formate, die ich da aufgelistet habe, sind einfach nur die Formate, die Multipatch unterstützt. Die meisten davon kannte ich vorher auch nicht, und außerdem sind es größtenteils Binärformate. Wir sollten dennoch darüber nachdenken, ein existierendes Format zu benutzen (oder zumindest zu unterstützen), weil man dann mehr Toolunterstützung hat, z.B. ein Binary-Diff-Tool zum automatischen Erstellen von Patches.
Es spricht m.E. auch nichts dagegen, eines dieser Formate in eine XML- oder JSON-Datei einzubetten, z.B.

Code:

"name" : "Schick: MR-Patch (Hendrik, deutsche Version)"
"author" : "Hendrik"
"patchdata-format" : "cracker"
"patchdata" : {
  00397801: FF 11 # 12 (Pirat)
  00397961: FF 11 # 20 (Thorwaler)
  ...
}

[tommy]

Hmm du bringst mich da auf eine gute Idee, es spricht eigentlich überhaupt nichts dagegen mehrere Formate zu verwenden. Ich würde wahrscheinlich (wenn ich ne gute Bibiothek für c# finde) das JSON Format benutzen, dass sieht sehr vielversprechend aus und dadrin könnte man ja auch verschiedene Formate Kapseln. Aber anfangen würde ich wohl mit einem eigenen Format, gerade im Textänderungen möglich zu machen, das wird ja bei den binär Formaten etwas schwierig...

So ich hab mal nen paar Minuten, sollte zumindest schonmal für die GUI und die ersten feinheiten reichen^^

[tommy]

So ich hab mal ein probedesign erstellt

   

So zu erklärung, ich stelle mir vor, dass jeder Patch einen eigenen Pfad für die Darstellung in der Hierarchie hat. Z.b. "Bugfixes\Gegner MR fixes\".
Das ermöglicht es mir eine übersichtliche hierarchische Darstellung zu verwenden...dadurch bleibt der Pfad allerdings in den händen der Patch entwickler...aber ich denke da die Menge übschaubar bleibt sollte es hier zu keinen großen Problemen kommen...

Ansonsten würde ich automatisch nur die patches für das ausgewählte Spiel anzeigen (Schick, Schweif, Riva). Falls die Versionsnummer des Spiels falsch ist, würde ich Patches einfach ausgrauen. Auch würde ich bereits installierte Patches markieren...wahrscheinlich farblich hervorheben oder so...

hmm ansonsten ja das icon für die Einstellungen muss ich noch ändern, dass sieht doof aus

...sonst noch irgendwelche ideen und anmerkungen???

[guitarjohnny]

das sieht sehr gut aus tommy, super!
was vielleicht noch interessant wäre, ist eine information seitens des programms, in welchen dateien die änderung erfolgt und was der jeweils originale wert ist.

[thEClaw]

Das sieht gut aus. Zwei Kleinigkeiten würde ich persönlich anders gestalten - vielleicht findest du etwas davon ja interessant.

Ich würde die Buttons unten links (Patches entfernen/installieren) zu einem einzigen zusammenfassen ("übernehmen") - vorausgesetzt, da spricht technisch nichts dagegen. Checkbox-Elemente, die vom Nutzer geändert wurden, könnten ihren Haken in einer anderen Farbe darstellen oder so (vielleicht besser die Schriftfarbe des Textes, damit die Änderung auch bei entferntem Haken sichtbar ist).

Außerdem könnte die Patch-Information rechts noch etwas "untergeordneter" dargestellt sein. Heißt, dass dem Bild zwar logisch zu entnehmen ist, dass sich der Inhalt des rechten Bereiches je nach angewähltem Patch ändern müsste, aber mit z.B. einer Überschrift ("Ausgewählter Patch") o.ä. könnte dieser logische Zusammenhang durchaus noch ein wenig betont werden.


Und nun noch eine Frage: Könnte man eigentlich einen Patch erstellen, der das Spiel anstelle mit der "Schick.dat" (ich hoffe, ich erinnere mich richtig^^) einfach mit den entpackten Daten arbeiten lässt? Sofern die Daten im Arbeitsspeicher nicht auch gepackt waren, sollte das doch keinen Unterschied machen - könnte aber eventuell das (De-)Installieren von Mods vereinfachen.

[HenneNWH]

Ein Patch wird das sicher nicht können, aber ich könnte soetwas mit wenig Aufwand in Bright-Eyes einbauen.

Interesse?

[tommy]

Ich würde die Buttons unten links (Patches entfernen/installieren) zu einem einzigen zusammenfassen ("übernehmen") - vorausgesetzt, da spricht technisch nichts dagegen. Checkbox-Elemente, die vom Nutzer geändert wurden, könnten ihren Haken in einer anderen Farbe darstellen oder so (vielleicht besser die Schriftfarbe des Textes, damit die Änderung auch bei entferntem Haken sichtbar ist).

interessanter Gedanke, gefällt mir

Außerdem könnte die Patch-Information rechts noch etwas "untergeordneter" dargestellt sein. Heißt, dass dem Bild zwar logisch zu entnehmen ist, dass sich der Inhalt des rechten Bereiches je nach angewähltem Patch ändern müsste, aber mit z.B. einer Überschrift ("Ausgewählter Patch") o.ä. könnte dieser logische Zusammenhang durchaus noch ein wenig betont werden.

ok auch das ist nachvollziehbar und leicht umzusetzen

Und nun noch eine Frage: Könnte man eigentlich einen Patch erstellen, der das Spiel anstelle mit der "Schick.dat" (ich hoffe, ich erinnere mich richtig^^) einfach mit den entpackten Daten arbeiten lässt? Sofern die Daten im Arbeitsspeicher nicht auch gepackt waren, sollte das doch keinen Unterschied machen - könnte aber eventuell das (De-)Installieren von Mods vereinfachen.

boah das wär aber ein ordentlicher Patch^^ Aber da Henne wohl recht, in BrightEyes wäre das deutlich leichter umzusetzen
Und für mich ist es eigentlich egal, ums entpacken kommt man so oder so nicht drum herum und das neu verpacken ist dann auch nicht mehr das Problem...Und in sachen Geschwindigkeit sollte das auch kein Problem werden, da ich die Dateien ja garnicht echt entpacke sondern nur die .DAT in den Arbeitsspeicher lade.

Aber freut mich, dass es euch so schonmal gefällt...jetzt muss ich nur mal schaue wann ich nächste Woche mal zeit dafür finde^^

[thEClaw]

Ein Patch wird das sicher nicht können, aber ich könnte soetwas mit wenig Aufwand in Bright-Eyes einbauen.

Ist das so tief vergraben? Hätte ja sein können, dass man einfach einen Programmteil aushebeln kann. Letzten Endes (Priorität -1000 ^^) wäre es vielleicht nicht schlecht, wenn Bright-Eyes mit unkomprimierten Daten arbeiten könnte - allerdings optional, damit der Ottonormalverbraucher nicht die Daten entpacken muss.