Muss Form ID unique sein?

Ich bin imer noch auf der Suche, warum Wegnehmen eines Baumes in der Welt einen CTD verhindert, den ich ansonsten in einer bestimmten Zelle (Dungeon "Steinhalle" in Chanterelle) erhalte, wenn ich die Map (M) aufrufen will. (Regulär müsste dann lokal der "sichtbare" Bereich der Dungeon-Zelle und im Hintergrund die Welt Chanterelle gezeigt werden.) Eine Behziehung hab ich bislang nicht gefunden, außer einer, aber dabei weis ich nicht, ob ich mit meinem Verdacht überhaupt richtig liege:

Es geht um Chanterelle World.esp - bei -20,-22 ist der tote Baum aaCHBlubboDeadTree01 [STAT:050B6C2A]
Wenn ich nach der ID suche (ohne die ersten drei Stellen für die loadorder) = B6C2A erhalte ich
[REFR:000B6C2A] (places MineScaffoldBase4Sided01 [STAT:00045598] in GRUP Cell Temporary Children of EmbershardMine01 "Glutsplittermine" [CELL:000B6BE6])
Suche ich nach der ID mit der Loadorder, in dem Fall also 050B6C2A, erhalte ich
aaCHBlubboDeadTree01 [STAT:050B6C2A]

Aber hier endet mein Knwo How, ist das so OK oder ist das kritisch, wenn eine Referenz mit derseben ID ganz woanders hinzeigt, und kann das einen CTD beim Laden der Map in dem Dungeon erzeugen?
(Wenn ich nicht von der Welt Chanterelle aus reingehe, sondern von der anderen Welt, Halle des Bergkönigs, dieses Dungeon hat zu beiden einen Ausgang/Eingang, dann erhalte ich keinen CTD wenn ich M drücke, sondern schön die Map des bekannten Dungeons und in Hintergrund die Welt von MK. Es muss also irgendwie an der Welt Chanterelle liegen.

NetScriptFramework Crashreport führt als eizige mögliche Ursache den Baum auf, nehme ich den raus (und damit natürlich auch die Referenz auf die Glutsplittermine, erhalte ich keinen CTD.

Allerdings sagt Vactrol, er könne von jeder Seite reingehen und habe immer sauberes Laden der Map mit der Welt im Hintergrund, von der aus er reingegangen ist.)

Spoiler

Unhandled native exception occurred at 0x7FF6115F96A9 (SkyrimSE.exe+8E96A9) on thread 4176!

FrameworkName: NetScriptFramework
FrameworkVersion: 15
FrameworkArchitecture: x64
GameLibrary: SkyrimSE
GameLibraryVersion: 18
ApplicationName: SkyrimSE.exe
ApplicationVersion: 1.5.97.0
VersionInfo: Successfully loaded
Time: 02 Nov 2022 15:42:13.550

Possible relevant objects (6)
{
[ 0] TESObjectSTAT(FormId: 120B6C2A, File: `Chanterelle World.esp`)
[ 0] TESObjectREFR(FormId: 120C1A29, File: `Chanterelle World.esp`, BaseForm: TESObjectSTAT(FormId: 120B6C2A, File: `Chanterelle World.esp`))
[ 1] NiNode(Name: null)
[ 6] TESObjectSTAT(FormId: 0001751F, File: `Skyrim.esm`)
[ 6] TESObjectREFR(FormId: 1220A740, File: `Chanterelle World.esp`, BaseForm: TESObjectSTAT(FormId: 0001751F, File: `Skyrim.esm`))
[ 11] TESObjectCELL(Name: Wildnis, FormId: FF001D91)
}

Probable callstack
{
[0] 0x7FF6115F96A9 (SkyrimSE.exe+8E96A9) unk_8E9630+79
[1] 0x7FF6115F90D5 (SkyrimSE.exe+8E90D5) unk_8E8E10+2C5
[2] 0x7FF6115F45B7 (SkyrimSE.exe+8E45B7) MapMenu::unk_8E44A0+117
[3] 0x7FF611BCF46A (SkyrimSE.exe+EBF46A) MenuManager::unk_EBF260+20A
[4] 0x7FF6112C3620 (SkyrimSE.exe+5B3620) Main::Update_5B2FF0+630
[5] 0x7FF6112BF4F4 (SkyrimSE.exe+5AF4F4) MainLoop_5AF3D0+124
[6] 0x7FF6112BCC05 (SkyrimSE.exe+5ACC05) BSGeometryListCullingProcess::unk_5ACBD0+35
[7] 0x7FF61205B17A (SkyrimSE.exe+134B17A) unk_134B05C+11E
[8] 0x7FFACEF37034 (KERNEL32.DLL+17034)
[9] 0x7FFACFB02651 (ntdll.dll+52651)
}

 

Einfach mal so ins Blaue eingeworfen, da ja die Glutsplittermine eine vanilla Instanz ist, könnte ich mir vorstellen, dass die Chanterelle world.esp schlicht und ergreifend nicht frei von "dirty edits" ist. Und dies mit autoclean vielleicht beseitigt werden könnte. Grundsätzlich gehe ich aber davon aus, dass Du auf die Idee selber schon gekommen bist und ein autoclean bereits hinter Dir hast!

Ich sage das auch nur, weil man die offensichtlich einfachsten Ansätze manchmal einfach vergisst, weil es zu einfach ist

 

Kurz gesagt: Nein.
Wenn es so sein sollte, wäre ja quasi jedes kleine plugin (geflaggt als esl - sprich "espfe") inkompatibel miteinander, weil dort der erste record immer mit 800 beginnt, der Rest bestimmt die ladereihenfolge.

 

Du könntes mal testweise Way of the Monk installieren, und schauen, ob die Referenz auf die Glutsplittermine immer noch problematisch ist.
Grundsätzlich ist die Gegend rund um Flusswald und Helgen problematisch. Warum, weiß ich nicht. Eine Erklärung fällt mir echt nicht ein außer: Referenzen sind ja Jumps. Nun gibt es auch Sprungvorhersagen. Möglicherweise haben bestimmte Sprünge einen Vorzug, hardwaretechnisch gesehen.

Was man allgemein sagen könnte, das ist: in dieser Gegend sollte man möglichst keine Questmods anlegen.
Das wird aber doch gerne gemacht, aus ähnlichen Gründen wie in Oblivion mit Anvil - weil das da eine sehr schöne Gegend ist.
Die Gegenden die Andy oder Aspiria (in Oblivion) gewählt hatten, waren viel besser.
Kvatch Rebuild (Oblivion) ist recht Absturzheischig und penibel. Dreimal darfst du raten, warum wohl.

 

Aus mehreren Gründen jap.

 

also falsche Fährte. OK, es ist auch nicht "in der Gegend" der Glutsplittermine gemacht bei der Mod, deshalb umsomehr fiel mir das auf, weil es eine externe, separate Welt mit einem Dungeon ist und nur der Baum diese Referenz hat und für miich unverständlich ist.
Aber Vactrol hat gerade ein Fix versucht (noch nicht getestet). Der Baum ist zu "Statik" gelistet, nicht zu "Trees", was er nun geändert hat.. Ob es das war, werde ich sehen.

 

Ich sage nicht, dass das die Lösung ist, aber wenn ich keinen Plan habe und noch nicht autoclean verwendet habe, dann ist das manchmal die Lösung, vor allem, wenn irgend ein Gegenstand, ob Tree oder Static mit "vanilla content" in irgend einer Weise verknüpft ist und wenn es auch nur eine Referenz ist! Hast Du denn schon autoclean darauf angewendet?

 

ja und Check errors in SSEEdit.exe - ist nichts. Aus unerfndlichem Grunde verursacht der Baum ein CTD, wenn ich in dem Dungeon die Map aufrufen will und von der Chanterelle-Seite reingekommen bin und nicht von der MK-Seite.
In der Welt links unten "Steinhalle" (gelb)

 

Dann würde ich den Baum in der Mod löschen und schlicht und ergreifend durch einen neuen ersetzen! Aber nicht mit "suchen und ersetzen", denn dann werden alle lokalen Einstellungen des Baumes den Du löschen willst übernommen!

 

In SSEEdit hab ich den Baum gelöscht. Das Ergebnis war auch zunächst scheinbar das Gewünschte: kein CTD mehr.
Aber das ist der Baum (s.u.), und der hat ein Baumhaus mit Aufzug und Mapmarker, ist sogar als einzelnes Modell auf der Weltkarte mit DynDoLod sichtbar (im Bild rechts unten gelb umrandet), also keine einfache Lösung. Der Baum muss da wieder hin, halt ohne CTD zu verursachen.
Zusätzliches Mysterium ist, dass Vacrol sagt, bei ihm träte das Problem nicht auf. Nun entwickelt er in LE und er hat nicht gesagt, ob er das auch in SSE getestet hat oder nur in LE. Wobei dann ja noch die Frage wäre, wieso/wodurch das dann bei LE und SSE unterschiedlich wäre.
Also suchte ich bei mir erst mal nach einer Ursache, aber ohne Erfolg. Bei dem Baum sehe ich nichts, dass kritisch sein könnte, und meine Kenntnisse sind erschöpft.
(womit ich nichts anfangen kann, nicht weiß, was das ist, das ist die Zeile bei NSF "[ 1] NiNode(Name: null)". Recherche im Internet war nicht sehr ergiebig, außer dass das wohl so auch nicht richtig ist. "null" soll da wohl nicht stehen, aber ich weiß nicht, was das ist. (Btw: ich habs auch ohne DynDoLod getestet, ist dasselbe Ergebnis)

 

Kann es sein, dass das Mesh ein Problem hat? Ist es nicht für SSE optimiert? NiNode ist ja Bestandteil eines Meshes.

 

Dann würde das mesh aber nicht nur beim aufrufen der Map einen CDT verursachen, würde ich mal vermuten. Nichts desto trotz kannst Du (@dreifels) mal den "SSE nif optimizer" drüber laufen lassen um sicher zu gehen!

@dreifels Wenn Du den Baum drinnen lassen willst, und nicht versuchen willst schlicht die genaue Position zu ersetzten (Du könntest Dir die Koordinaten notieren), dann solltest Du alle lokal gemachten Einstellungen, die nicht gebraucht werden und auf vanilla Content zielen, löschen!

Edit: Nur mal so als Hinweis, falls Dir das nicht klar war, Du MUSST SSE-Nif-Optimizer verwenden, wenn Du von LE nach SSE portierst (oder umgekehrt), da die meisten oder viele meshes schlicht nicht in SSE verwendbar sind und dann zwangsweise Fehler auftreten können oder werden. Gleiches MUSST Du mit den Texturen machen. Dafür verwendest Du dann auch SSE-nif-optimizer, da ist eine entsprechende Funktion mit drin!

 

Also das glaube ich nicht. SSE unterstützt Texturen mit besserer Kompression, kann aber mit der ganzen Palette von älteren DDS-Formaten arbeiten. D.h. es ist gut, wenn man es macht, man muss aber nicht.

 

also, das ist ein SSE-Paket von Vactrol. Trotzdem hab ich Nif Optimizer 3.0.14 drüber laufen lassen, und CAO konvertiert ja ggf. von LE nach SSE automatisch und optimiert, aber doppelt gemoppelt ...
Nix, keine Fehler entdeckt, nichts geändert (Vergleich nach Inhalt gemacht)
War ja mein erster Verdacht, dass das Nif oder DDS einen Knacks hat.

Nun hatte ich ein ähnliches Problem mal bei Shumer, und da sagte agerweb, er habe noch eine Referenz eingefügt, und danach war der CTD weg. (Keine Ahnung, was er konkret gemacht hat)
Jedenfalls versucht das System wohl, bei M irgendwas zu laden. Der CTD kommt nicht instant, sondern nach ca. 1-2 Sec., also was gesucht und nicht gefunden. Zudem eben, dass der CTD nur augtritt, wenn ich von der Chanterelle-Welt, aus reingehe, nicht aber, wenn ich von der MK Welt reingehe (der Dungeon hat Eingänge von beiden Welten.) Ist der Baum raus, kann die Welt geladen werden (Hintergrund der local Map des Dugeons).
Damit erscheint mir mittlerweile naheliegender, dass es nicht an dem Nif oder DDS liegt, sondern an dem ESM, darin was falsch ist, diesen Baum betreffend. (der ist nicht tree sondern static, und das habe Vactrol nun geändert, aber ich hab das noch nicht zum Test). Dabei immer noch die Grundfrage: Wieso Problem bei mir und nicht auch bei ihm? (Leider gibt es dazu keine Usermeldungen, ob ja/nein die das Problem auch haben, also eben, ob das ein Problem meiner Installation ist oder nicht.)

 

Konvertiere die immer routinemäßig mit, aber kann sein, dass Du da recht hast.

Bin mir ziemlich sicher, dass der Engine das egal ist, ob der Baum als Static oder als Tree vorhanden ist. Vor allem, da dieser Baum mit Sicherheit keine Anims beinhaltet, aber selbst wenn, dann ist das meiner Erfahrung nach egal.

Du solltest Dir die Koordinaten und das Scaling des Baumes einfach notieren, den Baum in der ESM schlicht löschen und den selben Baum dann einfach neu einsetzen und mit den Koordinaten versehen, dann sind alle handgemachten Referenzen Scripte oder was weiß ich was weg, zumindest die "lokalen"!

 

und da bin ich mir nicht sicher, ob ich weiß, wie das geht. Bäume in CK pflanzen hab ich noch nie gemacht. (also was für morgen oder so.)

und da müsste ich vollständig passen, obwohl da nur wenige Sripte sind, aber ich kann keine Scripte lesen. Null Ahnung davon.

 

Nachtrag: Screenshots von Baumhaus/Baum in CK Cell view - Cell View - Object Window - SSEEdit = k.A. was ich da wie machen soll
[REFR:050C1A29] (places aaCHBlubboDeadTree01 [STAT:050B6C2A] in GRUP Cell Persistent Children of [CELL:05030807] (in aaChanterelle1 "Chanterelle" [WRLD:05012544]) at -20,-22)
landscape\trees\BlubboDE Aspen\BlubboForVactrolTree1.nif

 

Ohne jetzt zu wissen, ob es was damit zu tun haben könnte oder nicht, aber:
Die Object Bounds auf Screenshot 4 zu sehen...die sind ja..."riesig".

Ich habe mal testweise die ESM-Flag vom Plugin entfernt, es im CK geladen und per Rechtsklick auf den entsprechenden Record "Recalc Bounds" gemacht.
Nach dem erneuten Laden in xEdit sind die Werte nun wie folgt:

-117
-28
-117
117
28
117

Ob das nun gut/schlecht ist oder überhaupt etwas damit zu tun hat, kann ich leider nicht sagen. Ich vermute vorher waren die Werte so hoch, weil der Baum ja auch entsprechend groß ist.
Die Reference zu diesem Baum (Static) ist allerdings nicht in der Größe editiert, weshalb diese wohl durch das Mesh ansich bestimmt wird.
Da auch die Navmeshes durch die Object Bounds beeinflusst werden, könnte es ja etwas damit zu tun haben...einen Versuch wäre es ja zumindest mal Wert.
DynDOLOD hat ja auch bei der Erstellung für GrasLODs Probleme, wenn die Object Bounds nicht korrekt sind, wer weiß wie das dann bei diesem Baum ist.

Gerade noch mal in das Mesh geschaut...dieses hat eine eingestellte Größe von 85 (Standard wäre 0).
Eventuell müsste diese auf 1 gesetzt werden (allerdings nicht soooo einfach, weil dann auch das Collision Mesh angepasst werden müsste) und dann im Plugin beim Rerference-Eintrag die Größe des Baumes festgelegt werden. Dann könnten vermutlich auch die Object Bounds passen.
Gerade selbst getestet, macht keinen Unterschied, die Object Bounds bleiben auch dann identisch.
Ingame getestet hab ich dies jedoch zu keiner Zeit, dass müsstest du dann machen.

Ist aber wie gesagt nur ein Schuss ins Blaue, dass es damit zusammenhängt, wissen tue ich das nicht.

 

Deins nachgemacht, bekomme dieselben Werte, aber immer noch CTD, hat also keinen Einfluß darauf.
Das Einzige, was mir noch auffällt, kann aber auch belanglos sein, ist, dass das Base Obekt = Baum auf sich selbst eine Referenz hat
SSEEdit: aaCHBlubboDeadTree01 [STAT:050B6C2A]
CK show: 050C1A29
SSEEdit: [REFR:050C1A29] (places aaCHBlubboDeadTree01 [STAT:050B6C2A] in GRUP Cell Persistent Children of [CELL:05030807] (in aaChanterelle1 "Chanterelle" [WRLD:05012544]) at -20,-22)

 

Das ist vollkommen in Ordnung so, ist nur komisch ausgedrückt. Referenz so und so platziert Baum so und so.

Wo steht das mit Grösse 85? In der Referenz unter 3D Data? Soweit ich weiss, kann man die Grösse eines Objekts in der Referenz nur bis 10 stellen, d.h. verzehnfachen. Kann es sein, dass dies es crashen lässt? Möglicherweise hat er das in XEdit vergrössert.