CollisionBox moves on disable/enable cycle

[syscrusher]

I have a customized trap in my mod that relies on an invisible static CollisionBox object (from the vanilla meshes) that is disabled and enabled by a script to control the behavior of the trap.

The problem is that the collision box renders in a slightly different location after it is disabled and reenabled for the first time, even though its numeric coordinates are not changed. I verified the numeric coordinates with GetPos calls and a diagnostic console printout. The offset is in the +Z direction, and is about 35~40 game units and fairly predictable. It also only happens on the first disable/enable cycle; that is, it does not accumulate additional offset each time the script cycles.

I have worked around the problem by having my script disable and then immediately enable the CollisionBox when the cell is initialized, and then I compensate the +Z offset by placing the CollisionBox slightly low in the CS. This has solved my immediate issue, but I am wondering (1) if anyone else has seen the problem, (2) if I can rely on this behavior being present on other people's systems, and (3) what might be causing the game engine to render a collision mesh at a location different from its official coordinate position.

Any ideas?

[WindmillTilter]

I've definitely never run across anything like that before.

Can't see anything too unusual in the NIF either. I did notice that the Node containing the collision is dropped on the Z axis and then the collision's RigidBody is pulled up to compensate. No reason that should cause a problem but it would be interesting to 0 them both out and see if you're still having the issue.

WT

[syscrusher]

I've definitely never run across anything like that before.

Can't see anything too unusual in the NIF either. I did notice that the Node containing the collision is dropped on the Z axis and then the collision's RigidBody is pulled up to compensate. No reason that should cause a problem but it would be interesting to 0 them both out and see if you're still having the issue.

WT

That certainly sounds as if it might be related. I'll give it a test run and post the result.

BTW, sorry for the delayed reply. For some reason I missed the email notification on this thread.

[syscrusher]

I've definitely never run across anything like that before.

Can't see anything too unusual in the NIF either. I did notice that the Node containing the collision is dropped on the Z axis and then the collision's RigidBody is pulled up to compensate. No reason that should cause a problem but it would be interesting to 0 them both out and see if you're still having the issue.

WT

I am at work and could only spare a minute for a quick test, but preliminary results are very promising. I zeroed out the translation on the node and the rigid body, saving the new NIF to my own directory rather than replacing the vanilla NIF, then updated my mod to use a new object based on this NIF.

A quick test shows correct behavior now -- the collision mesh appears to stay exactly where it was placed in the CS. This object is persistent in my mod, so I need to generate a new test character who hasn't "seen" it before, to be very sure, but so far it looks as if this may be a fix.

[syscrusher]

Confirmed! I retested this last night with a fresh character that didn't have the persistent object in the gamesave, and the behavior is correct with the modified NIF.

So, @Windmill Tilter: and thanks!

[WindmillTilter]

Excellent! Glad we got it working. Having the node repositioned really SHOULDN'T cause that, but Ob does funny things sometimes.

WT