Scope-less Anti-Material Rifle crashing Fallout NV

[LennyHayes7]

Hey all.

 

So after finally installing Blender, NifScripts, Python and pyFFI I modelled myself a neat looking Anti-Material Rifle and exported it as a NetImmerseFile (.NIF)

 

I loaded the weapons mesh over the original AMR and made a copy so that everything would work fine because the strips were simply changed. No Nodes, BSShaders etc.

 

I can view the weapon in GECK, it doesn't crash Fallout New Vegas on startup.

 

In fact it only crashes when I enter the cell I placed it in or equip it (If I get that far)

 

I'm using.........

• Python 2.6
• Blender 2.49b
• NifSkope 1.1.3
• BlenderNifScripts 2.5.9
• Lastest FNV GECK.

I've tried to localize the issue by comparing the Original NIF to the modded NIF and found the load order was wrong, I corrected it by moving the BSShaderPPLightingProperty, NiTriStripsData and NiMaterialProperty back to the same order as those in the original.

 

I noticed the small numbers next to the Original are:

• 15, 41 and 43

Whilst the Scopeless one has:

• 42, 44 and 41

Any shred of help would be pretty amazing... This is the LAST BRICK WALL in the way of my mod project and it's killing me.

[jazzisparis]

Double-click on AntiMaterialRifle [28], change the value to 12.

Looking at the attached image, I'm guessing there is no header string with the index 28.

[neomonkeus]

The nif format is comprised of blocks.

The small number basically the "id" for that block.

If you hit the "Rest Block Detail" button you will be presented with the "List View" which will show you all the unique blocks in your nif.

 

The main "Tree VIew" presents the structure of the nif, because blocks are interconnected using links or parent-child relationship.

 

Its a tree structure because there is a root block, the same way a tree has a root, and blocks blocks which have children have branches.

The block id is to identify which block the link points to.

 

One of the reasons these id's might be different is just down to the order they were processed, so instead of object_1 getting the written to the nif object_2 got their first, so it was given id's first.

 

With having the "List View" open you should see 2 additional block, NiHeader & NiFooter, these contain extra information about the nif file itself. Much in the same way we can reuse block by reusing the "id" value, blocks of text, "strings" can also be reused. Here you willl see the strings and their associated id's.

As @jazziparis has said, check to ensure that the block is not referencing a non-existant string id.

 

Something else I spotted, as a general rule of thumb don't export as NiTriStrips as they provide no benefit and can in the worst case could degrade performance overall. Officially we no longer support their export.

Edited November 28, 2013 by neomonkeus