Construction Set Neue Erkenntnisse in Sachen Absturz

Seid gegrüßt,

trader2 schrieb:

... Aber einfach undeleten ist ja nicht. Da muß leider mehr gemacht werden. ...

Zum Vergrößern anklicken....

Na schön, dann gibt's noch einen Nachschlag :-D
In den meisten Fällen reicht das "undelete and disable References" von TES4Edit völlig aus. Man muss sich halt darüber im klaren sein, dass das nur eine Zwischenlösung ist bis der ursprüngliche Modder mal Erbarmen zeigt und seine Mod noch mal durchsieht. Der ist nun mal der einzige, der weiß was mit den gelöschten Referenzen beabsichtigt war.

Es gibt jetzt zwei grundsätzliche Methoden, damit umzugehen:

• Man setzt die auf "initially disabled" und sorgt mit ein paar zusätzlichen Bedingungen dafür, dass die auch nicht mehr störend in Erscheinung treten. Das ist das, was die Automatik von TES4Edit macht. Wird eine so bearbeitete Referenz von einer später geladenen Mod angesprochen, erkennt die Engine, dass die Referenz noch vorhanden ist und macht weiter keinen Stress.
• Man reaktiviert die Referenz. Das macht Wrye Bash mit "undelete Refs" oder das CS, wenn man im Datei-Menü in der Detail-Ansicht gelöschte Referenzen markiert und "delete" drückt. In beiden Fällen werden die Referenzen zunächst auf "Ignore" gesetzt und nach einem Abspeichern der Mod im CS sind diese Referenzen aus der Mod entfernt. In diesem Fall sind also wieder die ursprünglichen Referenzen aus der Oblivion.esm die aktuellen und auch hier ist die Engine glücklich.

Modder sollten auf jeden Fall sehen ob das, was sie so angestellt haben, wirklich alles nötig ist und Spieler sollten einfach sehen, was ihnen mehr liegt. Einerseits macht es Spaß, Mods noch ein wenig an die eigene Spielweise anzupassen und außerdem lernt man selbst eine ganze Menge, wenn man fremde Mods mal durchflöht, andererseits HAT sich der Modder was beim löschen gedacht und darauf sollte man auch vertrauen, also TES4Edit gestartet, Filter setzen und disablen.
Selbst die zitierte Hammerfell-Mod kann auch mit "initially disabled" behandelt werden. Wenn zusätzlich zwei wichtige Bugs beseitigt werden (die Zelle 3/3 und das Interior "IC" [0002C80D] müssen aus der Mod gelöscht werden), ist der Rest eher Kleinkram und hauptsächlich für einen etwas lichteren Wald verantwortlich.


mfg
Rentner

Erneuter Dank. Da kann man sich beinahe schon auf weitere zukünftige Entdeckungen der Profis freuen. Obi scheint außen wie innen für allerlei Überraschungen gut.

Nachschlag is immer jut, wenn´s schmeckt, wa.

Castle Varaldo

Zum Vergrößern anklicken....

Wie kommt ein Modder auf die Saublöde Idee diesen Interior aus der Oblivion Masterdatei per PI Eintrag zu löschen?
Ihn für eigene Zwecke zu verwenden, ist ja noch nachvollziehbar, aber wozu sollte dass den gut sein?
Es ist schon schlimm genug, dass diverse Hausmods Zellen und Objekte "verändern", die mit ihnen rein gar nichts zu tun haben. Aber dass ist ja wohl der Gipfel der Dummheit.

NNW

Ich glaub das hattet ihr noch nicht hier im Thread:
Lu's DV Mod Cleaning Tutorial

Hi!

Ich hab noch ne Frage zu diesem Thema.

Folgendes Szenario: Ich öffne eine Interior-Zelle aus Vanilla-Oblivion, markiere ein paar Objekte, drücke Strg+C und füge diese Objekte dann in eine von mir neu erstellte Interior-Zelle. Führt das zu Problemen? Irgendwo war die Rede davon, dass da keine Kopien erzeugt werden, sondern die Original-Objekte in die neue Zelle verschoben werden o.ä.. Kann aber auch sein, dass ich das nur falsch verstanden hab. War etwas schwammig formuliert und nicht genau auf mein geschildertes zenario bezogen. Bitte um Erleuchtung
Um die Frage noch ein wenig zu präzisieren: Wird die Vanilla-Referenz bei meinem beschriebenen Vorgehen in eine andere Zelle verschoben? Wär ja blöd irgendwie, weil Kopieren ist nunmal Kopieren.

EDIT: Übrigens liebe ich solche Threads, in denen einem echt technisches Know-How vermittelt wird. Sollte es mehr von geben. Das von Fenni verlinkte Tut ist auch sehr nützlich.

T-Rip schrieb:

...

Folgendes Szenario: Ich öffne eine Interior-Zelle aus Vanilla-Oblivion, markiere ein paar Objekte, drücke Strg+C und füge diese Objekte dann in eine von mir neu erstellte Interior-Zelle. Führt das zu Problemen? Irgendwo war die Rede davon, dass da keine Kopien erzeugt werden, sondern die Original-Objekte in die neue Zelle verschoben werden o.ä..

...

Zum Vergrößern anklicken....

Vermutlich war da noch was anderes gemeint. Wenn Du im Cell View-Fenster einem Interior einfach eine neue EditorID gibst, wird die OHNE WARNUNG akzeptiert. Du bekommst in dem Fall allerdings kein neues Interior sondern das Original IST WEG. Entsprechend sind dann natürlich die Vanilla-Refs in die "neue" Zelle verschoben. Erst wenn Du auf "Edit" klickst, bekommst Du die Möglichkeit, auch direkt neue Zellen zu erzeugen.

Rechtsklick und "Duplicate Cell" erzeugt eine genaue Kopie der Ausgangszelle in Deiner Mod, mit der Du dann tun und lassen kannst was Modder halt so anstellen. Hast Du eine Zelle kopiert, bekommt die eine neue EditorId - <Name des Ursprungs>COPYxxxx - und eine neue FormID. Die ersten zwei Ziffern der FormID geben die geladene Mod an, aus der etwas stammt. Erst an der FormId erkennst Du also, ob die Zelle zu Deiner Mod gehört. Entsprechendes gilt für die Einrichtung Deiner Zelle. Du kannst aus jeder anderen Zelle alles kopieren was Du willst. Dabei werden in Deiner Zelle Duplikate der Referenzen erstellt - auch Duplikate von NPCs, questrelevanten Gegenständen und Uniques, pass also auf was Du kopierst.

Diese Zusammenhänge kann man sehr gut in TES4Edit nachvollziehen. Im linken Fenster zeigt das Programm an, WAS geändert wurde und im rechten, WIE es geändert wurde und in welcher Datei. Man kann also auch einfach mal alle PIs laden und sehen, wo überall z.B. die Vanilla-Rassen geändert werden. (Sowas wird richtig lustig, wenn man anschließend in den Readme-Dateien nachsieht ob das auch vermerkt wurde). Alle Änderungen an Vanilla-Content sind farbig hinterlegt, alles Neue ist ohne farbige Darstellung.

Wichtig: Änderungen sind nur auf ihrer eigenen Ebene immer erkennbar. Wird also z.B. in ein Interior noch ein NPC eingefügt, muss im Programm erst mal die entsprechende Zelle gefunden werden und dann der Baum bis "Temporary" aufgeklappt werden (nicht meckern, versucht sowas mal im CS).

TechBlah zum Schluss: TES4Edit arbeitet mit Toleranzen. Die vierte Stelle hinter dem Komma wird z.B. in meiner Arbeitsversion (TES4Edit_2_3_0_EXPERIMENTAL) bereits ignoriert. Das hat Vorteile, da z.B. auch minimale Unterschiede bei Pathgrids - die das CS nicht immer identisch abspeichert - noch als identisch akzeptiert werden. Nachteil ist, dass die Fog Near-Variable ebenfalls als identisch angesehen wird, obwohl die im Nvidia-Patch (und hofffentlich jeder anderen Mod auch) definitiv geändert ist wenn der Vanilla-Wert für Fog Near, -Far und -Clip-Dist 0,000000 ist. Die aktuelle TES4Edit_2_5_1_R2 arbeitet wieder "less-fuzzy", also eigentlich genauer als die Toleranzen im CS. Wenn in verschiedenen Versionen des Programms also unterschiedliche Änderungen aufgelistet werden, sollte auch die Doku mal gefragt werden ob das vielleicht Absicht ist.


mfg
Rentner

Kontaktier die Jungs doch mal explizit. Vielleicht haben sie den thread wirklich noch nicht gesehen/gelesen. Wäre doch schön wenn UL weniger Abstürze verursachen würde. Das war nämlich auch der Grund warum UL bei mir rausgeflogen ist. (ohne die Mod an sich verunglimpfen zu wollen) Ich hätte es gern genutzt, aber die Abstürze haben sich halt sehr gehäuft.

EDIT: Ok, haste ja schon im UL-Thread.

Was in diesem Zusammenhang auch noch sehr interessant und wissenswert ist:

Malachit schrieb:

Das Tool TES4LODGen ist ein sehr praktisches und leicht zu bedienendes Werkzeug, wenn es um's pure Vanilla geht. Bei den UL-Mods werden jedoch teilweise bestehende Objekte gelöscht, andere kommen hinzu. Wenn man vor dem Generieren der LOD die Einträge der gelöschten Objekte nicht aus den betreffenden esp's entfernt (z.B. mit dem Tool TES4Edit/View), werden sie beim Generieren der VWD-Objekte wieder sichtbar gemacht. Da durch die UL-Mods teilweise Höhenveränderungen vorgenommen wurden, sind diese eigentlich gelöschten Objekte in der Entfernung schwebende Objekte.

Zum Vergrößern anklicken....

Man hat nach Nutzung von TES4LODGEN also die gelöschten Vanilla-Objekte wieder in der LOD hängen, wenn's dumm läuft. Hat mit UL jetzt nicht unmittelbar was zu tun. Betrifft ja alle Esps, in denen Vanilla-Objekte gelöscht wurden.

Wenn die in einer Tiefe von -30000 sind beachtet das Spiel die Objekte nicht mehr.

Rentner schrieb:

"Deleted Records" sorgen für den Crash beim beenden von Oblivion, sind also auch ein vermeidbares Ärgernis. Diese können mit TES4Edit automatisch "entlöscht", nach z=-30.000 geschoben (damit sind die außerhalb des Renderbereichs und spielen im Hinblick auf Performance keine Rolle mehr) und auf "initially disabled" gesetzt werden (damit sind sie nur für andere Mods noch "vorhanden", führen also nicht zu dem Crash bei beenden).

Zum Vergrößern anklicken....

Das ist der Sinn der Sache.

Edit: Zum Glück ist Valenwood Improved eine Beta. Valenwood Improved durchgefallen.

Setz es meinetwegen erstmal auf die Liste. Es wird noch etwas dauern bis ich das behoben habe. Ich mach jetzt erstmal Urlaub.

Dein Valenwood Improve stürzt ab. Das ist aber sehr traurig. Soll ich es vorne auf die Liste setzten oder arbeitest du gerade daran, dass es den Test besteht?

Zum Vergrößern anklicken....

VI ist eine Beta, und deshalb ist es m.E irrelevant ob es den "Savetest" besteht. Eldarie weist auch in ihren Threads ausdrücklich darauf hin.

JA denkt man, aber die Objecte sind bei -30000 noch genauso zu sehen wie bei -3000.

Zum Vergrößern anklicken....

Nur im CS. Oblivion selber ignoriert und rendert solche Objekte erst gar nicht.

Und ich galub kaum, das die dann irgenwie noch die Performance beeinflussen. Auch wenn sie bei -3000 stehen meine ich.

Zum Vergrößern anklicken....

Kann, muss aber nicht sein. Aber wozu ein vermeidbares Risiko eingehe?

Allerdings wenn man sich die Ladelisten mancher so ansieht, spielt es bei den ganzen uncleanen und verbuggten PIs darin sowieso keine Rolle mehr :-D

Da gibt es mal neue Updates von UL und was muss ich feststellen. Die können nicht lesen oder haben meinen Thread noch nicht entdeckt oder wollen es nicht glauben.

Zum Vergrößern anklicken....

Oder es interessiert sie nicht wirklich?
Vielleicht schreckt auch der Aufwand dies zu beheben ein wenig?

Als ich darauf aufmerksam gemacht wurde, dass in unserer gemergten ESP von Serie 1 alle Pathgrids flöten gegangen waren, war Ich auch kurz davor dass Handtuch zu schmeissen... :shock:

NNW

Seid gegrüßt,

robinH schrieb:

Da gibt es mal neue Updates von UL und was muss ich feststellen. Die können nicht lesen oder haben meinen Thread noch nicht entdeckt oder wollen es nicht glauben.
...

Zum Vergrößern anklicken....

deutsche Mods auf chinesischen Servern, russische Mods auf amerikanischen, dem Netz sind Grenzen egal. Das gilt auch für die ULs. Die haben ihren Release-Thread hier und bearbeitet werden - wie bei allen anderen Moddern auch - halt Fehlermeldungen aus den eigenen Threads. Du kannst von niemandem erwarten, dass er weltweit alle Server abgrast um zu sehen was irgendwer irgendwo herausgefunden hat, selbst die diversen UL-Threads dürften den meisten UL-Moddern schlicht unbekannt sein :lol:.
Zur Zeit werden alle UL-Mods überarbeitet und dabei wird nicht nur die Automatik von TES4Edit genutzt sondern auch manuell geprüft, welche Änderungen eventuell unnötig sind und wie es mit der Kompatibilität zu anderen Mods aussieht. Das ist der Grund, warum diese Aktualisierung so zeitintensiv ist - die Modder haben zusätzlich noch ein rL und andere Projekte. Auch zu den gerade bereinigten Mods gibt es bereits wieder erste Meldungen, die werden gesammelt, geprüft und kommen auf die Liste für die nächste Runde, auch Du darfst Dich da gern anschließen.
Auf deutschen Servern findest Du "nur" Übersetzungen, was an sich schon arbeitsintensiv ist und die Möglichkeit, über die ULs zu diskutieren. Vielleicht ist auch das allgemeine Interesse an einem Beitrag IN DEN UL-THREADS groß genug, dass der Inhalt an den entsprechenden Modder weitergeleitet wird. Erwarte aber nicht, dass irgend jemand wegen möglicher Probleme mit den ULs ausgerechnet hier nachsieht oder jemand, der 9 Zeitzonen weiter weg ist diesen Thread überhaupt lesen kann.

Land-Edits, Pathgrids etc:
Macht eine Mod mit viel Neuland sauber - Valenwood, Elsweyr, Hammerfell, einige von den ULs -, ladet die im CS und sichert die einfach wieder. Eigentlich sollte es zu der gerade gesäuberten keinen Unterschied geben aber seht einfach selbst mal nach...


mfg
Rentner

Noch eine Frage zum Thema cleanen. Ich hab in diesem Tutorial, das Rentner mal verlinkt hat, von der Funktion 'Remove "Identical to Master" gelesen und hab sie natürlich auch in Tes4Edit schon gesehen.
Kann man das bedenkenlos über die Mods drüber laufen lassen, oder kann das zu Problemen führen? Oder anders gefragt, gibt es in Mods einträge die identisch zur Masterdatei sein MÜSSEN?
So rein von der Logik her könnte man ja meinen, dass jeder identische Eintrag überflüssig ist, da er durch die Oblivion.esm ja eh geladen wird. Allergins könnte ich mir auch vorstellen, dass die Sache nen Haken hat.
Die identischen Einträge führen zwar nicht zu Abstürzen, aber die einzulesende Datenmenge würde sich halt reduzieren, wenn man die Einträge aus den Mods entfernt.

Grüße T-Rip!