reset3Dstate not updating collision

[Lanceor]

Short version:

I'm moving static objects using setpos followed by reset3Dstate. As the floor beneath the player moves downwards, the player can get stuck to it and can't swim upwards. (Also, some other collision isn't updating at all.)

Long version:

The effect I want is that the player falls into a shaft. A gate closes off the top of the shaft and the shaft begins filling with water. The player will drown unless there's a deus ex machina.

Because the water level cannot be raised dynamically, I'm sinking the dungeon instead. I've designed it so that there are only six visible meshes that need moving. Using a modified version of the script found in the CS Wiki is creating the effect very nicely. The collision appears fine when viewed with TMG in the console.

In practise though, the horizontal floor is behaving strangely - the player can get "stuck" to it and can't swim upwards once he's underwater. The collision for the vertical surfaces are not moving at all, though I have a workaround for this if it isn't fixable. The ceiling collision seems to be updating fine though.

What I've tried:

• Replacing the meshes I'm using with various vanilla meshes
  
• Using activators instead of statics
  
• Spacing out the reset3Dstate commands to one per frame
  
• Disabling and re-enabling the meshes on alternate frames (I fell through the floor and they stayed disabled so I didn't explore the idea further)
  

Any ideas?

short Triggered
float Timer

short xStdSpeed
short xSpeed
short xMaxDisplacement
ref xObject1
ref xObject2
ref xObject3
ref xObject4
ref xObject5
ref xObject6
float xPosZ1
float xPosZ2
float xPosZ3
float xPosZ4
float xPosZ5
float xPosZ6
float xPosMin1
float xPosMin2
float xPosMin3
float xPosMin4
float xPosMin5
float xPosMin6
float xPosMax1
float xPosMax2
float xPosMax3
float xPosMax4
float xPosMax5
float xPosMax6

BEGIN ONTRIGGER

if (Triggered == 0 )
Playsound TRPSwitchMetallicStart
set Triggered to 1
endif

if xObject1 == 0
; First time only: set vars
;======================
; xStdSpeed positive: Object will initially go up
; xStdSpeed negative: Object will initially go down
;======================
set xObject1 to aaKOTNR04WaterGateRef
set xObject2 to aaKOTNR04ShaftRef
set xObject3 to aaKOTNR04FloorGateRef
set xObject4 to aaKOTNR04BlackMaskRef
set xObject5 to aaKOTNR04TunnelRef
set xObject6 to aaKOTNR04DoorRef
set xStdSpeed to -5; <<< Change to your liking (units per second)
set xMaxDisplacement to 450 ; <<< Displacement limit
set xPosZ1 to xObject1.getstartingpos z
set xPosZ2 to xObject2.getstartingpos z
set xPosZ3 to xObject3.getstartingpos z
set xPosZ4 to xObject4.getstartingpos z
set xPosZ5 to xObject5.getstartingpos z
set xPosZ6 to xObject6.getstartingpos z
if xStdSpeed > 0
set xPosMin1 to xPosZ1
set xPosMax1 to xPosZ1 + xMaxDisplacement
set xPosMin2 to xPosZ2
set xPosMax2 to xPosZ2 + xMaxDisplacement
set xPosMin3 to xPosZ3
set xPosMax3 to xPosZ3 + xMaxDisplacement
set xPosMin4 to xPosZ4
set xPosMax4 to xPosZ4 + xMaxDisplacement
set xPosMin5 to xPosZ5
set xPosMax5 to xPosZ5 + xMaxDisplacement
set xPosMin6 to xPosZ6
set xPosMax6 to xPosZ6 + xMaxDisplacement
else
set xPosMin1 to xPosZ1 - xMaxDisplacement
set xPosMax1 to xPosZ1
set xPosMin2 to xPosZ2 - xMaxDisplacement
set xPosMax2 to xPosZ2
set xPosMin3 to xPosZ3 - xMaxDisplacement
set xPosMax3 to xPosZ3
set xPosMin4 to xPosZ4 - xMaxDisplacement
set xPosMax4 to xPosZ4
set xPosMin5 to xPosZ5 - xMaxDisplacement
set xPosMax5 to xPosZ5
set xPosMin6 to xPosZ6 - xMaxDisplacement
set xPosMax6 to xPosZ6
set xStdSpeed to -xStdSpeed
endif
endif
if xPosZ1 <= xPosMin1
set xSpeed to xStdSpeed
else
set xSpeed to -xStdSpeed
endif
END

BEGIN GAMEMODE

if (Triggered > 0 )

set Timer to Timer + GetSecondsPassed

if ( Timer > 10 ) && ( Triggered == 2 )
aaKOTNR04WaterFillingSound.enable
set Triggered to 3
elseif ( Timer > 5 ) && ( Triggered == 1 )
aaKOTNR04WaterGateRef.playgroup backward 0
set Triggered to 2
endif

endif


if (Triggered > 2 )

if xSpeed == 0
return
endif
set xPosZ1 to xObject1.getpos Z + xSpeed * getsecondspassed
set xPosZ2 to xObject2.getpos Z + xSpeed * getsecondspassed
set xPosZ3 to xObject3.getpos Z + xSpeed * getsecondspassed
set xPosZ4 to xObject4.getpos Z + xSpeed * getsecondspassed
set xPosZ5 to xObject5.getpos Z + xSpeed * getsecondspassed
set xPosZ6 to xObject6.getpos Z + xSpeed * getsecondspassed
if xPosZ1 > xPosMax1
set xPosz1 to xPosMax1
set xPosZ2 to xPosMax2
set xPosZ3 to xPosMax3
set xPosZ4 to xPosMax4
set xPosZ5 to xPosMax5
set xPosZ6 to xPosMax6
set xSpeed to 0
endif
if xPosZ1 < xPosMin1
set xPosZ1 to xPosMin1
set xPosZ2 to xPosMin2
set xPosZ3 to xPosMin3
set xPosZ4 to xPosMin4
set xPosZ5 to xPosMin5
set xPosZ6 to xPosMin6
set xSpeed to 0
endif

xObject1.setpos Z xPosZ1
xObject2.setpos Z xPosZ2
xObject3.setpos Z xPosZ3
xObject4.setpos Z xPosZ4
xObject5.setpos Z xPosZ5
xObject6.setpos Z xPosZ6

xObject1.reset3Dstate
xObject2.reset3Dstate
xObject3.reset3Dstate
xObject4.reset3Dstate
xObject5.reset3Dstate
xObject6.reset3Dstate

endif

END

scn aaKOTNR04WaterTrapScript

[WillieSea]

It would be best if you turned the 'shaft' into an animation that goes down or up. That way, the collision moves with the mesh. No, I don't know how to do that.

Other than that, I only knew about the 'enable/disable' trick to update collision. And you should do them both in the same frame, not alternate frames. And it must be enabled before leaving the frame.

[WindmillTilter]

Doing the enable/disable trick in one frame, and Reset3DState in the following frame worked for me on a single object. I also changed the havok properties to animated, which shouldn't really be required when moving via script but it seemed to help. On your bhkRigidBody set the "Motion System" to MO_SYS_KEYFRAMED and your quality type to MO_QUALITY_KEYFRAMED.

That said combing the tunnel into a single NIF and animating would a much cleaner solution if you can. The complexity of the havok shape seems to come into play too. I wound up troubleshooting an animated NIF used for the same purpose (dropping to simulate water rise) and had to replace the havok shape with a simpler one to get it to work reliably.

Good Luck,

WT.

[Meo]

How big of a mesh are we talking here? Its doable, its more complexe than making statics or clutter or doors, but doable.

[Lanceor]

Thanks for your tips Willie and Windmill, and thanks for having a look Meo.

I've tried the various disable/enable tricks with reset3Dstate in the same or in different frames without luck (and prematurely drowned a few characters who got stuck). Updating the motion system and quality didn't seem to make a difference either.

Here's what I have so far, made up of pieces of vanilla meshes that I've modified in NifSkope:

I've scripted it so that this is what happens:

1. Player falls into shaft
   
2. 5 seconds later, the gate at A slides shut
   
3. At 10 seconds, the whole lot begins to move downwards into the water
   
4. At around 25 seconds, an NPC appears at the top of the shaft and shouts to the player that he's going to try to open the escape door.
   
5. At around 50 seconds, the whole lot is underwater. The sliding wall at B lines up with a static corridor/door behind it, and slides out of the way allowing the player to escape.
   

This is ideally what I'd like to achieve and I've managed to do it through scripting alone, but unfortunately the Gamebryo engine isn't digesting it too well. If some kind soul is able to create the animate mesh, I'll implement it this way, but if not, I'll try to think of another devious deathtrap.

[Meo]

Could you please send me the modified nifs, i'll experiment in max. No promises though.

[Lanceor]

Sure, no problems Meo. Thanks for checking it out.

[HeyYou]

I built a dwemer dungeon for morrowind once upon a time, and used a static as an elevator. It would sink down a shaft, to various levels, and I didn't have any of the problems you seem to be experiencing here...... wonder if the lack of havoc made my life easier?

[Lanceor]

I had sliding doors for my previous dungeon and there were no havok problems with those either. It seems that the engine is unable handle all but the simplest of mesh position changes and even though the collision boxes for this water trap is just a bunch of rectangles, it was already too complex.

After some experimenting, Meo and I have abandoned the idea. The good news is that I've come up with another trap that's just as scary and probably more unique.