Hello,

I have a floating object that seems to disable havok on a short distance of the player, maybe 50 to 100 meters. It normally bounces up and down in the water until the aforementioned distance, and then freezes. It is always at exactly the same distance, as if the engine decided havok is no longer needed. As soon as I approach it again, it recovers it's havok and refloats. Is this a hardcoded feature and can it be overriden for a specific object?

I thought at first it might be persistance, so I added a constant OnUpdate event to the object, but didn't help... I need this object to keep floating even when the player isn't near.

Have you tried attaching the default script, defaultdisablehavokonload

To the object?

Isn't that script useful for just the opposite? Can it be inverted??? My object needs to keep it's havok enabled constantly and always float, independent of distance to the player.

Adding this script freezes it. I tried beenSimmed = True, but I get erratic behaviour.

If you drop a regular basket or some other similar object in the water, and then step away from it, does the same thing occur? If not, why not?

I'm going to try that. I did try dropping my basket from a mountain, and it did roll quite far. I'm going to try this in the water with another floating object, something like a vanilla broom...

If your object is a MovableStatic or an Activator, there is a checkbox labeled "Must Update Animations". I believe that causes the object to remain in so-called "high" memory and animate even when the player can't see it. Perhaps that will keep the Havok running as well? Just a shot in the dark.

On a similar note I have a market trader that seels armour, I've put 3 cuirasses hanging from his stall. On entering the cell they are fine but leaving the cell and returning they are on the floor. Also there is a noctice board with notes "attached" (don't havok settle) they hang fine until an NPC moves past and they fall. Anyway to stop this happening?

Verteiron, thanks for the try, but it didn't work.

Tested with vanilla objects, and they are affected by the same issue. If anyone can think of a workaround, I'll highly appreciate it. Until then, I'll have to rewrite things to account for this...

I found why the object looses it's havok. It seems that objects with a clutter layer inside the rigidbody are handled as unimportant by the engine and it's havok get's disabled at a certain distance of the player (2000 units). It makes sense, as it probably saves quite a lot of resources... Objects set to Anim_Static do keep their havok regardless of distance.

The problem with ANIM_STATIC is that I just can't get the object to float with this layer, while clutter layer objects float fine.

I fear that this is hard coded, as I couldn't find any function in any script that might be checking for distance and changing the objects motion type to keyframed. If anybody knows where this is being called, that be great. Also, is there a way to handle a clutter object as an anim_static? My tries with the nif files have all failed...

Does the object have any Havok behavior at all all when set to anim_static? Or does it just behave like a keyframed object? You might try using FloatyObject.SetMotionType(FloatyObject.Motion_Dynamic) and see if it behaves better as an Anim_static that way.

Otherwise you can try cycling through all the layer selections in the hopes that maybe there's one that does what you want. Do severed heads float in water? Try OL_HEAD

Actually, by further testing, I fear it's the water and not the layer... Maybe a combination of both. The object behaves fine on land at any distance, but in water it freezes or gets stuck at a distance of the player. I'm going to investigate further down this line. Could be that at a certain distance, water might just be LOD.

Now to study how water works...

Antstubell, I've been fighting this exact problem with my apple trees for a few days now. You will need to add a script to your stuff to disable the Havok, otherwise it'll keep falling down. There are a couple vanilla scripts you can use that will disable the physics until the object is hit (like by an arrow or a spell) but I'm not sure if that's what you want. If not, you'd need to copy one of those scripts into a new script of your own and modify the bit that turns Havok back on when the object takes a hit.

Also, just so you know, the script will only work if the cell in question hasn't been loaded already, which can be a pain in some circumstances. It's fairly simple to tweak the script to avoid that particular snag, but that just goes back to having to create your own script rather than use a existing one. I wish I'd known how it worked BEFORE I hung a vanilla script on approximately 73 individual apples.

Glad you got it sorted in the end mate what is the script you eventually ended up using?

Sorry to hear you hung so many apples, I'm thinking of making a Xmas tree so I can see what'll happen to the baubles. Thing is with the Town Notice Board the notes have to stay there all the time. Some will be disabled initially and enabled as Quests become available but players will be in and out of this cell a hell of a lot, its a market place. Could I make the Notes STATIC and run some kind of script on them similar to the OnRead they are using now? At the moment they are MISC hence they fall with a gust of wind. And what script were you talking about in your post?

Hello antstubell,

The script he's talking about is defaultDisableHavokOnLoad. It's probably easier to just copy the nif of your object and renaming it to something of your own. Then change it's rigidbody layer to OL_STATIC, motion system to Keyframed and motion quality to fixed. You can also set mass to 0. Duplicate your note in the CK and point it to your new nif. I think this should solve it...

I think branch deleting the whole bhkCollisionObject should also do the trick.

I had to use the beehive script's code as a base and modify it to work on savegames where the cell might already be loaded. Added an identical block using OnInit instead of OnLoad and now it works fine.