luthienanarion

It's crashing in some Havok collision code. Try removing mods related to ragdolls.

I make changes to forms at runtime, not via plugin record overrides or even GECK scripts. If you don't want the Vault 101 kids to remain children, don't play as a child race.

Fix, my ass. Delete that and any other d3d9.dll file you may have installed in your game folder. If hair won't render, it's because the game is selecting a DX8 shader package for your driver which does not support the hair rendering the game uses. Open up <My Documents>\My Games\FalloutNV\RendererInfo.txt and post the contents.

It has nothing to do with the model. You cannot modify the form record for the Sturdy Caravan Shotgun, period. The game engine will not load any record overrides from any plugins for injected records. It loads the record data once and then fails to resolve the FormID each time that an overriding record is loaded from a subsequent plugin. Blame Obsidian for an awful design choice that I'm sure someone thought was clever at the time.

The records in the pre-order pack ESMs cannot be overridden properly because they are injected.

That error means that an object with the "Has TreeLOD" flag was disabled, which crashes the game engine. I'm willing to bet you trusted LOOT and its bad advice to "clean" deleted references from plugins using Edit.

That's a Steam error code. Make sure that Steam is running and that it recognizes FNV as installed.

That's in NVSE 5.1 as ShowLevelUpMenu when it gets released. SetInCharGen was only ever used to keep the player from leveling up before having the chance to re-customize their character before leaving Vault 101.

http://geck.bethsoft.com/index.php?title=SetInChargen

Windows f*#@ing Update. This was fixed in WDDM months ago.

Turning actors invisible is what that shader effect does. It just does it in a fancy, graphical way. Your screenshot is of a different effect.

Auto-purge mods will cause issues (not necessarily those described above) all by themselves and should not be used. The game clears old cell memory when more is needed to load a new cell. If you want the game to clear the cell buffer more aggressively, enable bPreemptivelyUnloadCells and bSelectivePurgeUnusedOnFastTravel in your INI settings. NEVER use the PurgeCellBuffers (PCB) command. It's a debugging tool used for testing cell and reference loading, not a magic fix for memory problems.

There is no way to globally affect actors that are not currently loaded. To kill all NPCs, you would have to call KillAll every time the player changes cells.

If you're playing at an extremely high or non-standard (ten years ago) resolution, stop.

It's not a bug or a glitch; it's by design. ENB disables some effects in menu modes because they look terrible or make text unreadable. The flicker is from the effects being reapplied.

I would just call DisableButton, which prevents the game from detecting the button but allows scripts to. I'm probably a bit biased.

Correct. I'm not sure if there is a limit to using && to add expressions to one IF condition; that limit is for nesting IF...ENDIF blocks inside each other. The GECK will throw an error when compiling (assuming GECK-PU) if you nest them too deep. It's also a lot more complex to convert a single IF to nested IFs when using || (OR) or a combination of || and &&, because you end up having to repeat some of them. It's a mostly negligible performance difference, unless you perform multiple heavy or slow function calls to determine whether or not to run a block of code in a script that runs often (an object script, for example).

There's no telling why the release version of the FNV GECK has all warnings disabled, or why the game itself was compiled in a debug configuration. Obsidian were never the development studio everyone wanted them to be.

It should be noted that the engine actually evaluates ALL expressions in a condition, regardless if one has already evaluated to FALSE. if someVar == 7 && npcRef.GetDead && GetStage VCG01 == 100 ; do stuff endif In that example, if someVar doesn't equal 7, GetDead is still called on npcRef, GetStage is still called on VCG01, and the return value of GetStage is still compared to 100. It's uglier code to nest IF statements, but it's more efficient because of how asinine the compiler is: if someVar == 7 if npcRef.GetDead if GetStage VCG01 == 100 ; do stuff endif endif endif In this rewrite, execution moves to the line after the last ENDIF after only determining that someVar is not 7, skipping the other evaluations.Note that IF statements can only be nested inside each other 10-deep. If you're comparing a variable or function return against 0, it's more efficient to use ELSE than to make the comparison using the == operator: if someRef.GetDisabled else ; do stuff, because the ref isn't disabled endif The scripting engine does a lot of things differently from actual programming languages and compilers.

Reference flags are actually flags on the reference form, so some of the flags have different effects if the form is a reference. On a regular form, flag 1024 marks a quest item and makes it impossible to drop, not count toward encumbrance etc. On a reference, it marks it as persistent. Most data modifications made by NVSE functions do not persist through game sessions, because the game engine doesn't know that any changes are made and thus doesn't save them.

SetPersistent simply sets or unsets flag 1024, so you could do that without any NVSE plugins.

I must have missed Get/SetFlagsLow/High when 4.6.3 was released; probably too excited about strings, arrays, and events! If you're going to use it as a reference for the flags with Get/SetFormFlag or Get/SetRefFlag, ignore the page for GetFlagsHigh.

All scripts must begin with the ScriptName command. Scripts cannot be saved without a name, as the name is used as the EditorID in the GECK. http://geck.bethsoft.com/index.php?title=Scriptname Your script compiles fine, otherwise.

Do note that writing to a file on disk is one of the slowest things a program can do, and enabling logs will hurt performance in a small way. If you're not going to dig through those logs or understand their contents, you're better off leaving them disabled.

Did you recompile NoiseScript? Open the ESP in the GECK (loaded by NVSE), open the script, and click save. Then save the plugin.