(I wrote this offline last night and realize that some of my points have already been implied above.)
When I play around with the Crescent Reach lifts, the cycles all begin and end on the bottom. I'm assuming this is
the closed state since they work with the way they are coded (yes, I am aware of the difference in coding for
triggertypes 1/255 versus 0/0.)
However, GFay lifts begin at the top, then cycle down and back up. Is it possible that the default state should be
open and not closed for them? (Are these the only ones in-game that start at the top and/or still don't currently
work properly?) And does the client send the actual door state or just a click event for activation?
I'm also assuming that the GFay 'levers' are in a closed state since they're all down, like Crescent's (except for
orc-top for some reason - SoF client.)
(Side note: you can change the direction of GFay and Crescent lifts, but not the non-triggered sliding doors that
I tested, while they're in operation with multiple clicks. Is this expected behavior?)
If you let all of the timers reset between clicks (waiting ~18 seconds (down), ~18 seconds (up), and 5 seconds
(close_timer)), the lifts themselves never activate. Only when you click multiple times during this ~41 second
period (first ~18 seconds most likely) do they ever work. This sounds like a logic conflict in the state of the
doors (lifts) themselves and not a fault in the code, especially since 'normally closed' doors seem to work
correctly and the Crescent lifts work using essentially the same logic.
I want to tinker around with the code for this, but everything is coded for instant open, timer close. I might try
adding a conditional to 'SetDoorState(i.e., ! doorid = (one of these: 69, 77, 80) ? true : false)' in the
'close_timer' function and some other checks in 'HandleClick' and 'Process' to see if I get any change in lift
operation for the specified lift id.
(Thought: If the client sends the lift state (as open when up) after a move action, then ::Process is turning off
the 'close_timer' when the lift is up (called by handle acutation - maybe it should trigger closed instead) and
setting the state to closed with no move action associated with it..which is why the lift doesn't come down after
the close timer should be processed and without multiple clicks 'fooling' the server and client about the logic
state of the door. I could be wrong...) (The close timer code is expecting the door to be open, not already
closed.)
Does anyone happen to already have any data showing actions and states from the client? I'd like to set up a
truth table based on doors states and events, and then check it against the code logic to determine what the
actual resting (initial) states should be. I haven't gotten to the point where I can collect packet info and
understand what's going on there just yet.
I'm going to tinker around with this for awhile, but if anyone with more experience than I wants to add suggestions,
please feel free to.
U