"Unknown" Errors with probable consequences

[RealmEleven]

I don't know if this is the right forum, but I've seen other tech support posts for the GECK here. Please let me know if there is a more appropriate forum for GECK Tech support queries.

 

Introduction: Underlying Tech-Specs

Presently, I a working on a mod with the GECK v. 1.1 for Fallout New Vegas v. 1.2.0352 (on Steam). The operating system is the 64 bit variation on Windows Vista Ultimate updated to service pack 2 running on an old 3 GHz AMD Athlon 6000 dual core 64 bit processor with 4Gb RAM, 250Gb SATA main drive with disc caching assigned to an 80Gb drive on a separate SATA channel. The video is handled by an old NVIDIA GForce 9800 GT.

 

Mod Location

To date, the mod has two additional interior cells but is currently specified to add three internal cells. Externally, the mod is centred on a cluster of seven exterior cells, namely; (-2, 5), (-2, 6), (-3, 4), (-3, 5), (-3, 6), (-4, 5), & (-4, 6). The main topographical features in question are:

1. the spur that strikes west from the northwest sector of Blackmountain and, additionally,
   
2. the low lying terrace extending south from the part of south slope nearest the end of the spur in question.
   

 

Current Mod-Development Activity

So far, I am just laying the groundwork and haven’t begun work on characters (which will probably go in a separate master file). Nor am I up to the stage of inserting themes or quests into the mod just yet. Right now, my focus is just the objects in play, gameplay enhancements, “balanced” item playability and all the related scripting that goes with it.

 

FNVEdit has been an indispensable resource. Not only does it fix errors introduced by bugs in the GECK, such as random object deletions and duplications (which do have FPS and game-stopping potential). It also can be used to identify errors that are permanently fatal to the mod itself if allowed to propagate with development. I.e. where the only solution is to roll back to the last uncorrupted version of the mod file. I’ll expand on this when discussing those “probable consequences”.

 

Formally Identified Errors in the Mod

The errors in question are two:

 

The simplest concerns the FNAM error flags in map marker data and come up as “<unknown>”. FNVEdit describes them as:

 

[00:00] Checking for Errors in [01] 1011-BlackSpur.esp

[00:00] FNAM - Flags -> <Unknown: 2>

[00:00] Above errors were found in :Map Data

[00:00] Above errors were found in :zkzzXyM [REFR:01003931] (places MapMarker [sTAT:00000010] in GRUP Cell Persistent Children of [CELL:000846EA] (in WastelandNV "Mojave Wasteland" [WRLD:000DA726] at 0,0))

[00:00] Above errors were found in :GRUP Cell Persistent Children of [CELL:000846EA] (in WastelandNV "Mojave Wasteland" [WRLD:000DA726] at 0,0)

[00:00] Above errors were found in :GRUP Cell Children of [CELL:000846EA] (in WastelandNV "Mojave Wasteland" [WRLD:000DA726] at 0,0)

[00:00] Above errors were found in :GRUP World Children of WastelandNV "Mojave Wasteland" [WRLD:000DA726]

 

Is there a particular naming convention that must be followed, or is it possible that where the radius of one map marker overlaps another it is described as a naming error? The map marker in question is situated in Cell (-3, 5) and specifies a radius of 1024 length units (the equivalent of roughly 31.25 metres). I’ve got a couple more tests to run on this one, but I think something might have been left out of the documentation for map marker deployment. If I find anything useful, I’ll post back on this thread just in case anyone else has had the same problem.

 

Update ("EDIT")

Firstly, 1024 game length units probably corresponds to something more like 16 metres than 31.25! Doors are roughly 2m high or 128 game length units making 64 game length units per metre and cells 64x 64x 64 metres. So much for being roughly accurate before espresso-time...

 

Secondly, I checked for radius overlap between the map marker placed by my mod (i.e. the one that raises the error flag) with adjacent or otherwise large radius mapmarkers (e.g. Niel's Shack, NCR Safehouse, Blackmountain, etc.) There is no overlap that I can detect so that leaves me just as mystified by this error as the data error that follows. Has anyone else had map marker errors like this?

 

The most obscure problem (and the one I haven’t a clue about) is a nested chain of DATA flags that FNVEdit identifies in the GRUP Top. The entry reads thusly:

 

[00:00] Checking for Errors in [01] 1011-BlackSpur.esp

[…]

[00:00] DATA - Flags -> <Unknown: 7>

[00:00] Above errors were found in :WastelandNV "Mojave Wasteland" [WRLD:000DA726]

[00:00] Above errors were found in :GRUP Top "WRLD"

[00:00] Above errors were found in :[01] 1011-BlackSpur.esp

[00:00] All Done!

 

There are no immediate consequences to gameplay that I know of. However, this mod that I am working on has the tendency to incite some rather peculiar behaviour in the GECK.

 

Probable Consequences

If I place an object in certain cells (e.g. 7, 7 - 188 Trading Post) the GECK takes matters into its own hands and alters the cell further than intended.

 

This does not affect gameplay at this stage, however, the additional object sometimes shows up and sometimes fails to show up during testing. FNVEdit, on the other hand, identifies (at this stage) two or three nested errors in my mod that lack any effective remedy. The root of these errors is the fact that the newly added object is orphaned i.e. does not have a parent node in the object hierarchy. This is the point where I now terminate the current mod version as corrupt, and roll back to the last mod version that FNVEdit was willing to save. Here’s why:

 

When the corrupted mod is subsequently opened in the GECK, the exterior cell is misidentified as an interior cell and the GECK proceeds to replace the cell coordinates with the word “interior” – although the cell itself still displays in the exterior cell list.

 

The consequence in subsequent game-testing is that the cell in question has completely vanished from the game’s exterior world, and usually causes the game to discontinue rather suddenly. I would hesitate to describe it as a crash, per se, because the game can be subsequently restarted – especially if the corrupted mod is not loaded. However, it is much more serious than what most people describe as a "CTD" because in order to get back to the descktop, the Windows instance has to be exited, the task manager invoked and the process terminated before full desktop access is regained.

 

At this point FNVEdit flags every object native to the former exterior cell as orphaned and the cell as being separated from the GRUP Top. I think that this is rather telling given that the seven above-quoted nested DATA errors that FNVEdit can’t seem to fix, are also in the GRUP Top. According to what I have on version control for this mod, it has been plagued by these various GRUP Top errors right from the start.

 

I think that everyone using the GECK would be screaming about this problem if it was not peculiar to my mod’s “unknown” GRUP Top related errors and, moreover, I’ve been unable to find anything that remotely describes the problem, much less solves it.

 

Temporary Counter-measures

I’ve invested a lot in this mod, so at the moment, I’m looking for a solution that doesn’t involve starting from scratch. For now, I’ve hacked my way around this issue by placing the object intended for the NavPath shadow at the 188 Trading Post (Cell 7, 7) in Cell (-3, 4), setting the Initially Disabled flag and having a script move the object to its intended location and then enable it in-game. Although this is a very effective way of circumventing the bug, I think it is fairly obvious that it also won’t be taken into account by software intended to detect positional conflicts (such as objects from two different mods occupying the same worldspace).

 

As you can imagine, I’m looking for solution to this little problem, but I’ll take any information on this or related GECK behaviours that just happen to have escaped pre-release documentation (i.e. bugs).

 

Thanks in Advance…

 

--

Tim

RealmEleven

Edited March 9, 2011 by RealmEleven

[RealmEleven]

The reason for this update is that, although I haven't found a better solution for the "probable consequences", outlined in my original post, (I am yet to try modifying cells in different regions as separate mods and subsequently merging them with FNVEdit), I have found a solution of sorts for the "<Unknown: X>" error flags - which is worth reporting here just in case the same problem is driving someone else to banana midories.

 

In the first case;

 

[00:00] Checking for Errors in [01] 1011-BlackSpur.esp

[…]

[00:00] DATA - Flags -> <Unknown: 7>

[00:00] Above errors were found in :WastelandNV "Mojave Wasteland" [WRLD:000DA726]

[00:00] Above errors were found in :GRUP Top "WRLD"

[00:00] Above errors were found in :[01] 1011-BlackSpur.esp

[00:00] All Done!

 

Using the information displayed above, I navigated the object tree, in the left pane of FNVEdit, to:

[01] 1011-BlackSpur.esp > Worldspace > 000DA726

And in the View tab of the right pane, there was a dropdown checklist hidden in the Data - Flags field of the [01] 1011-BlackSpur.esp column. I say "hidden", because it did not become apparent until I opted to edit the field. The checkbox items on the dropdown list or ComboBox were as follows:

 

Small World

Can't Fast Travel

<Unknown: 2>

<Unknown: 3>

No LOD Water

No LOD Noise

Don't Allow NPC Fall Damage

<Unknown: 7>

 

As you can see, the "<Unknown: 7>" was not an error code but a flag value whose purpose was unknown at the time FNVEdit was released. By unchecking "<Unknown: 7>", I made the error notification go away (which seemed pretty safe because we are talking about checkboxes - implying optionality. Had the item been one of a necessary selection, the convention is to use a set of option buttons, which cannot be unchecked without checking another option).

 

This solution arose from solving;

 

[00:00] Checking for Errors in [01] 1011-BlackSpur.esp

[00:00] FNAM - Flags -> <Unknown: 2>

[00:00] Above errors were found in :Map Data

[00:00] Above errors were found in :zkzzXyM [REFR:01003931] (places MapMarker [sTAT:00000010] in GRUP Cell Persistent Children of [CELL:000846EA] (in WastelandNV "Mojave Wasteland" [WRLD:000DA726] at 0,0))

[00:00] Above errors were found in :GRUP Cell Persistent Children of [CELL:000846EA] (in WastelandNV "Mojave Wasteland" [WRLD:000DA726] at 0,0)

[00:00] Above errors were found in :GRUP Cell Children of [CELL:000846EA] (in WastelandNV "Mojave Wasteland" [WRLD:000DA726] at 0,0)

[00:00] Above errors were found in :GRUP World Children of WastelandNV "Mojave Wasteland" [WRLD:000DA726]

 

Using the information displayed above, I thereby navigating the object tree, in the left pane of FNVEdit, to:

[01] 1011-BlackSpur.esp > Worldspace > 000DA726 > 000846EA > Persistent > 01003931

Then, in the View tab of the right pane, there was a similar dropdown checklist hidden in the FNAM - Flags field of the [01] 1011-BlackSpur.esp column. I unchecked <Unknown: 2> and checked Can Travel To option. As it turned out, after testing, this solved the problem without making the map marker available prior to discovery.

 

So, now when I run a check for errors, FNVEdit no longer flags these items, and the mod otherwise seems to be running correctly. I checked to see if these modifications had any effect on other bugs such as the "probable consequence" described in my original post, and the white body bug (which seems to be rather widespread). Neither bug is affected and so, those "probable consequences" I mentioned in my original post are probably not so consequential after all - and are more likely to be a symptom of a completely different problem.

 

Other than placating FNVEdit, I'm not sure what this little fix really achieves (if anything). In any case, that takes at least some of the mystery out of the game of using the GECK.

 

I hope this information helps someone out there, as it took a lot of stuffing around and endless hours of procrastination (which I promise to stop - when I get around to it; tommorrow)

[RealmEleven]

Solution for Disappearing Objects (including cells), as labelled "Probable Consequences" in Original Post

 

Probable Consequences

If I place an object in certain cells (e.g. 7, 7 - 188 Trading Post) the GECK takes matters into its own hands and alters the cell further than intended.

 

This does not affect gameplay at this stage, however, the additional object sometimes shows up and sometimes fails to show up during testing. FNVEdit, on the other hand, identifies (at this stage) two or three nested errors in my mod that lack any effective remedy. The root of these errors is the fact that the newly added object is orphaned i.e. does not have a parent node in the object hierarchy. This is the point where I now terminate the current mod version as corrupt, and roll back to the last mod version that FNVEdit was willing to save. Here’s why:

 

When the corrupted mod is subsequently opened in the GECK, the exterior cell is misidentified as an interior cell and the GECK proceeds to replace the cell coordinates with the word “interior” – although the cell itself still displays in the exterior cell list.

 

The consequence in subsequent game-testing is that the cell in question has completely vanished from the game’s exterior world, and usually causes the game to discontinue rather suddenly. I would hesitate to describe it as a crash, per se, because the game can be subsequently restarted – especially if the corrupted mod is not loaded. However, it is much more serious than what most people describe as a "CTD" because in order to get back to the descktop, the Windows instance has to be exited, the task manager invoked and the process terminated before full desktop access is regained.

 

At this point FNVEdit flags every object native to the former exterior cell as orphaned and the cell as being separated from the GRUP Top. I think that this is rather telling given that the seven above-quoted nested DATA errors that FNVEdit can’t seem to fix, are also in the GRUP Top. According to what I have on version control for this mod, it has been plagued by these various GRUP Top errors right from the start.

 

The problem of objects disappearing in the game can be explained by the partial loss of the object's header, or of a parent object's header. Why this occurs, I have been unable to ascertain. However, FNVEdit’s “View” tab clearly shows the missing header portion in the cell prior to any other editing.

 

At this point it would seem to be a matter of manually inserting the missing header records. However, FNVEdit is not capable of performing this particular task. Manual edits fall to TESnip, which now ships as part of FOMM.

 

In the left pane of TESnip, the faulty object appears immediately under the root node, in amongst all the top level GRUPs – where it is obviously out of place. This occurs because the faulty object has no parent specified in its header (as FNVEdit points out when attempting to clean up the mod). Thus, solving this problem simply boils down to identifying the GRUP node where the orphaned cell (or other object) belongs, and moving the orphaned object and all its children to that GRUP node.

 

You can’t miss it; it’s labelled “GRUP” (along with every other parent node in the object hierarchy). However, you can identify which GRUP your object belongs to by looking at the objects contained in the GRUP nodes and identifying the orphaned object’s siblings. In the case of my missing exterior cells, it was not hard to find other exterior cells that I’d modified, and that identified their parent GRUP as the proper parent for the orphaned cell and its children. These, if present, are located in the GRUP object that follows immediately after the orphaned object as the very next sibling.

 

Although not always drag and drop capable, TESNip does allow one to cut (Ctrl-x) and paste (Ctrl-v). Cutting the cell (or other orphaned object) along with its assigned GRUP object (which contains all the orphaned object’s children) and then pasting them to the GRUP object containing the orphaned object’s siblings has offered me a means of correcting this problem whenever it is introduced by the GECK.

 

While this means I have my work cut out for me, I hope that this might be of use to other people experiencing problems with disappearing objects. Just don't forget to back up your mod before editing. Provided you have a backup to roll back to, you can always afford to risk making fatal mistakes.