The Crusade against Havoc is over!

Since around V7 where the museum began to fill up to an alarming degree, I have been battling with issues surrounding havoc because of displays which use models that are normally dynamic moving objects in game being used for static displays, the game just doesn’t like to play nice with them. The game’s havoc system is rooted in the actual NIF model, and while the game makes a variety of efforts to mitigate havoc and make things seem static, it falls flat on its face every time. The game tries to stop havoc with a “don’t havoc settle” check box on all references and in creating a “static” object using a dynamic model the game “tries” to inherently stop it from moving when placed, but again, it’s always iffy at best. Then enter the all too useless DefaultDisableHavoc script which allows you to turn off havoc on an object and define if it will react to being hit, bumped, grabbed or otherwise impacted. The script works ok if you have one or two items in a cell that need to be made to stay put but something the scope of the hall of heroes with 6 times the maximum recommended cell resource usage and over 300 displays in that cell alone, forget about it.

So around V8 I learned my lesson, that a large number of models could not be managed by the game’s provided means, so I resigned myself to creating what I coined as “TrueStatic” models which are versions of dynamic models with their havoc shut down at the NIF level. Everything seemed to work much better, but I always had a white whale of sorts in the back of my mind which was to allow weapon displays to change depending on what model replacement mods you are using, which is not possible with the TrueStatic model. After converting every model in the museum to a TrueStatic I became more hopeful that perhaps a few models could be managed in the traditional way and allowed to be locked up placements of actual items so they changed if you altered the weapon’s model.

It seemed I was on to something, but a part was missing. I fiddled for the better part of a day or so and eventually developed this little script which actually managed to handle true disabling of havoc from within the game. I came to learn that the “disable” havoc script in vanilla is actually not really a havoc disabling script as much as a havoc management script that says “when” a model should havoc and found a few key elements within that script which were just plain wrong for a script designed to purely stop a model from ever moving.

I originally tried to set up the motionsystem to set the model as a “fixed” havoc system model but that didn’t seem to work properly, and I still to this day have no idea why because “fixed” is what native static objects use, but whatever, more weird stuff that should work as advertized but doesn’t, big surprise.

I eventually began to think about the game engine’s processing priorities and thought back to how my old paperweight laptop had no problems with the native havoc management working while other folks who had powerhouse computers were seeing objects jumping off the walls and freezing mid fall. Basically the way the game runs is that it starts loaded scripts and 3D simultaneously, and throws it’s hands up and waits to see what happens. Issue is that the vanilla havoc script is set up to only function when the 3D is fully loaded, even though the motion system of the nif and reassingment of said motionsystem statuses doesn’t require it. So basically the havoc script just shoots itself in the foot because a powerhouse computer (or even just a decent one with a good video card) will probably load the cell resources before the scripts finish firing because the player attaches to the cell after all the 3D loads andit’s THAT event which controls a TON of script functions, havoc includes.

Basically the run down is this

  1. if the 3D is fully loaded, the default procedure for NIFs is to run their havoc system
  2. if the script hasn’t fired yet which freezes the object, the object will move prior to being stabilized.
  3. The vanilla script even if set to disable all havoc conditions will STILL allow models to default to their inherent havoc system
  4. The vanilla havoc script only applies havoc management AFTER the model has been fully loaded

See the problem? the Vanilla script basically creates a gap where models can slip into their default havoc mode simply because the script and 3D don’t load in sync.

Behold my solution.

Scriptname DBM_DynamicDisplayScript extends ObjectReference  

Event OnInit()
        setMotionType(Motion_Keyframed, FALSE)

EVENT onCellAttach()
    setMotionType(Motion_Keyframed, FALSE)

EVENT onLoadGame()
    setMotionType(Motion_Keyframed, FALSE)

Basically I determined that two elements are missing from the vanilla. First is that the “Motion_Keyframed, TRUE” line which allows models to slip into their default havoc behavior should actually be set to FALSE so that the model will not do so. It also prevents the OnHit, Grab, and Activate actions from releasing the model to havoc. Secondly I added a MoveToMyEditorLocation which will reset the model to it’s original spot so encase the 3D loads before the script is done, it will slap it back AFTER it’s been fully stabilized, effectively acting as a fail safe.

I tested this script on over a dozen actual weapon object references placed in the hall of heroes which is nearing 1GB in cell size (156mb being the recommended max). So effectively, this script seems rock solid as an ACTUAL havoc disabling script.

I’ve also added the BlockActivation() function because I use this on actual items at times, which prevents them from being taken.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s