OI und ROO...

[Satsuma]

Hi,
hab gerade die gigantische Readme von OI 1.4 durchgelesen, und dabei eine saceh festgestellt: OI muss am ende geladen werden, gut jetzt steht aber in der Readme von ROO das OI als 3es geladen werden muss. Das hat mich jetzt erstmal richig verwirt, also wo muss das ding jetzt hin?

[Schlachtvieh]

Ich geb mal weiter an die PI-Abteilung. Da kann man dir sicher besser helfen

<--schieb

[RaimundP]

Das Ding muss weit an den Anfang...

Ray

[KL_FEIGLING]

Also ich habe ROO III ziemlich am Anfang geladen, danach OI inclusiveSupreme Magica und danach (weils so schön ist *fg*) LAME

Läuft alles zusammen

Gruß

Feigling

[Satsuma]

Das Ding muss weit an den Anfang...

Ray

...

Irgendwie hab ich mir schon gedacht das du mir antworten wirst
Ja ok, dir als Macher von ROO werde ich dann mal glauben, und deinen "Rat" befolgen.

mfg

[Lady Rowena]

Eigentlich, wollte ich mich aus ROO raushalten.
Aber wenn ich so etwas lese.
Kann ich einfach nicht.
Hier zum nachlesen
Installationsanleitung
Noch mal. OI , wird direkt vor ROO geladen. Ausnamen Knights und Kvatch verändernde Mods nach OI laden.
So etwa
Esms
Deine Mods
OI
Knigths
Kvatch
Roo
Alles was zu ROO gehört
Magieaddons (wie Lame)
Magieaddons immer nach ROO laden.
Bei Better Cities und UL kann ich nichts dazu sagen.
Habe ich wegen der hohen Fehlerquote nicht genutzt.

[NewRaven]

Das Ding muss weit an den Anfang...
Ray

...

Nö... OI kann weit an den Anfang, wenn man WB inkl. passender Tags einsetzt (was leider eher die Ausnahme als die Regel ist...), andernfalls sollte OI immer "so spät wie möglich*" geladen werden.

* Was so spät wie möglich bedeutet, steht in der Readme (nicht nur die Installationsanleitung lesen ) und hängt von den verwendeten Mods ab. Das einzige, was nach OI kommen sollte, sind - ohne WB - diverse Overhauls (ja, auch dein Ding, aber auch spezifischere Dinge wie Lame), Landschaftsänderungen, Replacer und einige Questmods, die Original-Content ändern. Insofern hat Lady Rowena mit ihrer Ladereihenfolge vollkommen recht

[Satsuma]

OK, Ladereinfolge aktualisiert. danke euch allen

Noch ne frage: wofür ist der "Bashed Patch"? Den habe ich irgendwie seit ich Wyre Bash habe, aber so richtig verstanden hab ich den nicht....

[MacGyver8472]

Auch das steht, wenn auch unter anderer Überschrift, in der OI-ReadMe.

Was bedeuten die komischen Zeichenketten am Ende deiner PlugIn-Beschreibung
(z.B. {{BASH:Names,Stats,Relev,Delev,Invent,Sound}} )?

Das sind sogenannte BashTags für die BashedPatch-Funktion des (unbedingt empfehlenswerten) Tools Wrye Bash. Diese Tags sind sozusagen kleine Steuercodes, die Wrye Bash sagen, wie es Oblivion Improved innerhalb einer BashedPatch-Datei zu behandeln hat. Eine kurze Erklärung dazu: In einer ESP-Datei (also jedem normalen Oblivion-PlugIn) befindet sich zu jedem Objekt ein Eintrag. Eine Interior-Zelle ist ein Eintrag, ein Schwert ist ein Eintrag, ein NPC ist ein Eintrag. Und jeder Eintrag kann nur von einem einzigen PlugIn modifiziert werden. Versuchen zwei PlugIns einen Eintrag zu ändern, werden nur die Änderungen des zuletzt geladenen PlugIns übernommen. Ein kleines, sehr einfaches Beispiel: Wir haben zwei PlugIns

1. PlugIn 1: Blonde Haare.esp - Dieses PlugIn ändert die Haarfarbe von NPC TestChar
2. PlugIn 2: Neues Schwert.esp - Dieses PlugIn fügt NPC TestChar ein neues Schwert im Inventar hinzu

Wird nun PlugIn 1 (Blonde Haare.esp) zuletzt geladen, hat der NPC zwar die neue Haarfarbe, allerdings nicht das Schwert. Wird PlugIn 2 (Neues Schwert.esp) zuletzt geladen, hat er das Schwert, behält aber seine alte Haarfarbe. Man kann also unter normalen Bedingungen niemals beide Änderungen durch die PlugIns im Spiel erreichen. Dies ist der Fall, weil es für Oblivion nur den Eintrag NPC gibt, nicht etwa Unterkategorien wie NPC-Inventar oder NPC-Aussehen. Hier kommt Wrye Bash bzw. dessen BashedPatch-Funktion ins Spiel. Diese analysiert nun beide (oder auch drei, vier, zehn oder fünfzig) PlugIns, bemerkt, das bei beiden ja eigentlich, trotz gleichem Objekt (NPC), völlig verschiedene Dinge (Haarfarbe und Inventar) geändert werden und vereint diese Änderungen dann. Selbst mehrere PlugIns, die dem gleichen NPC verschiedene Items ins Inventar packen sind so möglich. Das sieht in der Praxis so aus, das in der Wrye Bash-eigenen BashedPatch.esp ein neuer NPC-Eintrag zu unserem NPC TestChar zu finden sein wird, bei dem sowohl das Inventar geändert wurde (die Waffe) als auch die Haarfarbe. Diese BashedPatch.esp wird immer zuletzt geladen und überschreibt somit die einzelnen NPC-Einträge der jeweiligen OriginalplugIns mit der zusammengefassten Variante. Auf diese Art ist es möglich, PlugIns zusammen zu spielen, die andernfalls absolut inkompatibel zueinander wären. Man stelle sich einmal vor, was passieren würde, wenn PlugIn 2 kein neues Schwert hinzufügen würde, sondern den Schlüssel zu einem neuen Dungeon. Läd man dann PlugIn 1 danach, würde niemals irgend jemand den Dungeon betreten können, weil der NPC schlicht den Schlüssel nie besitzen würde. Sicherlich könnte man das in diesem Beispiel relativ einfach beheben, indem man einfach die Ladereihenfolge der beiden PlugIns tauscht (wenn man es denn weiß), weil es ja im Beispiel bei PlugIn 1 nur um die eher vernachlässigbare neue Haarfarbe ging, auf die man notfalls sicher verzichten kann, allerdings könnte auch PlugIn 1 etwas deutlich Wichtigeres am NPC ändern (ihm ein Script anhängen, ihm ein neues AI-Package geben, ihm ebenfalls einen Schlüssel geben u.s.w.) und dann hätte man ein ernstes Problem und eine ohne Wyre Bash nicht ohne weiteres zu behebende Inkompatibilität. Die Bash-Tags dienen je nach einzelnem Tag den folgenden Zwecken: Wyre Bash beim Erstellen der BashedPatch.esp zu sagen, welche Einträge es in dem entsprechenden PlugIn erwarten kann (bei den meisten Dingen nimmt Wyre Bash eine solche Zusammenführung erst vor, wenn die PlugIns entsprechend getagt sind) und auch ggf. zu markieren, welches PlugIn die höhere Priorität hat, wenn wirklich mal mehrere PlugIns exakt das Gleiche ändern - in diesem Fall werden die betreffenden konfliktfördernden Einträge der anderen einfach ignoriert, selbst wenn die PlugIns selbst später geladen werden als das PlugIn mit dem vorhandenem Bash-Tag, was auch bei der Ladereihenfolge von PlugIns sehr hilfreich sein kann. Leider sind nach wie vor die wenigsten PlugIns direkt von ihren Autoren selbst schon mit den nötigen Bash-Tags ausgestattet, so das man leider selbst die nötige Arbeit investieren muss, wenn man seine Oblivion-Installation auf diese deutlich erweiterte Kompatibilität optimieren will. Natürlich besitzt Wyre Bash neben der Bashed Patch-Funktion noch Tonnen weiterer praktischer und größtenteils einzigartiger Features. Nachzulesen ist das alles auf der Webseite zum Tool (englisch)

EDIT:
Die QUOTE-Funktion ist ja echt miserabel hier. Die schneidet Wörter ab...

[Mr_Tea]

Ich persönlich lade OI direkt vor ROO, also:

OI
ROO.esp
ROOxyz.esp (alle anderen ROO esp`s)

Das hat bisher immer geklappt, und so werde ich es auch weiter handhaben.

Edit:
Schließlich sehe ich in ROO das Overhaul, und dessen Inhalte sollten wenn es seien muss OI - Inhalte überschreiben.

[NewRaven]

@Mr_Tea: Ist ja auch völlig richtig so - im Gegensatz zu der viel zu generellen und somit sogar falschen Aussage, das "das Ding weit an den Anfang" muss