[Uleat]

(Mostly for info purposes in case someone in the future tries to work on these, but feel free to post suggestions.)

After some extensive testing with the GFay lifts, I still believe the inverted doors fix is the correct action for using invert_state = 1.


However, there is a bug with the animation of the lift. I can induce this same bug without using the inverted door close fix. I have
tried adjusting the z-position of the lift to various heights with no resolve and tested with doorisopen values mimicking those in Crescent
Reach with the same failures.

I also tried setting the activator door triggerdoor to '0' in hopes of seeing if GFay was coded to handle certain lift conditions based
on the value of of its activator. This didn't pan out. (Even moved the additional lifts out of zone in case they 'might' be interferring.)

Crescent Reach uses the exact same values (with the exception of buffer - tried that too...) as do the GFay ones, yet they work
(comparing to the elevated dragon lifts.)

(Also tried changing player #size to values between 1 and 100 with no difference.)


The best that I can figure is that the Animation handler for the lifts is miscoded. Something about clicking the handle multiple
times seems to temporarily reset the state of the collision detection values. It seems like the values don't change during the normal
movement of the door, but forcing it open/closed when the animation is over is what is reseting it.

(It's almost like the door travels one tick further than the collision detection value do. At the current PEQ settings, I'm getting
about a 0.000681 difference in player z-value between working and non-working positions. PEQ drops the '1' and doesn't allow
me put in an accurate door position adjustment. It could be that the door is traveling 100% of the way, but the detection only
travels ~99.999%)


I'm going to try two last possibilities and see if either work.

First is changing the door timer to 7 ~ 8 seconds (server timer seems to run out just before the lift actually reaches the bottom)
and then adding a md-action = 'open door.' (Yes, it could send the lift down from the top depending on when the activator was
clicked..will need refining if it works.)

The Second is using a proximity detector and adjusting the z-value of the player when they within the bounds of the lift.


U