It looks like the sony forums were purged at some point because I can't find anything there on the model bug. This post
is the only thing that I could find that alludes to something being wrong with the actual lift model. (Pretty sure it popped
up during a Kunark or Velious live patch.)
http://www.project1999.org/forums/sh...1&postcount=16
I guess this theory could be tested with two clients. Since I created a second account for the type 40 checks, I'll
see if I can pinpoint the area this is happening (if it is at all.) (I still have my original pre-Kunark install disc. I may try
copying the object file over to see if that helps.)
I'll also see what I can do with the actuator issue. I saw the same multiple click issues, but attributed it to the trigger and
triggertypes being [0, 0] versus the Crescent lifts which are [1, 255]. If you enable the test code, you will see that a
server door state change event does occur, but there is no movement client-side. (Remember, the server state changes
after 5 seconds, before the lift travels all the way down, but the client takes the door model cycle time, or at least one
direction, to reset both the lift and the actuator. Whereas with the Crescent actuators, they reset after 4~5 seconds.)
I still believe the logic is sound (for any inverted state door change), but I'll dig deeper into the cause. It may take
some database value changes, and possibly player.pl, to get the GFay lifts to work absolutely correct. I don't believe
it is just one issue.
U
Threaded Mode
