I remembered seeing player.pl somewhere..I had thought it was a plugin, but my bad.

Yeah, I see what they're doing there. I'll muse over the different means and see what comes up (that Gyrospire code is
pretty tight though.) Unless someone finds a problem that I missed during testing, the remaining door issues should lie
between the player.pl and database values.


U

bd,
Try my posted 'multiple door fix' with your script to see if that helps. I'll be offline until later tonight, but I'm going
to throw your script in real quick and see how it works (I put in Trev's untested ForceClose fix too.)

I don't see an issue with the 4-part doors now. I was going into Gyro Z..which doesn't have a quest folder yet.
(although they appear to be twin zones.)


U

Well the Vergalid lift I was testing with before no longer bounces in an erratic manner so that is an improvement. My attempts to make the lift, ropes and levers work together with a script yields only 50% success which is not good enough. Gonna keep messing with it as my script or logic is probably off and I am just not seeing it yet. Still gotta try database control as well.

(You should try having two or more clients at the lift with the test code enabled, but the type 40 check disabled
in the Process() procedure..you think it has erratic behavior with one client..hah!)


If you're using only the lever actuator, I saw only one problem that required two clicks. I'm pretty sure your script
is right. The problem lies in ForceOpen and ForceClose.

I'm working on those, but I think this is the problem:

ForceOpen - we want to force a door open no matter what. The action for an open door case should be to
restart the timer, not to close the door. This creates dis-syncronous operation between the server and client
(we just sent an open door command to the client..why do we want the server to think it's shut now?)

ForceClose - your catch on the 'open door' action was correct. With that, and Trev's suggested fix, the only thing
that might need to be done is to add a zone 'close' broadcast to ensure a closed door really is closed.

I'm still looking at these, which is why they didn't make my patch. I don't want the changes to interefere with
any working scripts that have already accounted for a broken 'ForceClose.'

I didn't make the changes in the database that you suggested yet, which is probably why I can still click a rope and
have it activate alone.


U

I need a dev pow-wow on this one...


Some scripted doors that use ForceOpen (i.e., gyrospireb 4-part doors in ..\quests\gyrospireb\player.pl) are designed
to us it to toggle the door state and not necessarily force it open.

On the other side, I can't help blackdragon with the vergalid mines lift issue without knowing what the actual design of the
function calls are.


My questions are these:

What are the intended purposes of these two functions, and should they be changed even if it affects many scripted
actions? (Every script will need to be reviewed to determine if a ForceClose action is needed.)


U

Write a new export with the new functionality. Do not break every script in the SVN.

Understood.

Can always use the existing function and just add an argument to it with a default set to how it currently works.


ForceOpen(leave_open=false)

or that :P

I'll keep that in mind, thanks!


Sidenote on GFay lifts though...

I'm wanting to test some scripting without hard-coding this since it only affects (currently) one zone.


Is there a default script file that loads/can be loaded when a zone is initiated?

I guess any npcs that I create could eventually be committed to peq, but a zoneload.pl type of file would be less intrusive. I could
have it 'spawn' the npcs and then just have script files ready for them.


Thanks!
U

I would suggest that you break down your issues to individual issues and fixes. the whole lift collision thing is something I can not replicate easily, and thus really do not care about. But the levers working the lifts on a single click are a nice little fix.

Sorvani, I think I just fully realized what you said last time about not seeing the error...

I misinterpreted that as you hadn't seen the bug before the fix. But, if you're still not seeing..I wonder if I'm the only one (or few) who can.


I thought, at one point, that I may have damaged my processor. (I've spent some serious time calculating primes and had many 10+ hour
sessions.)

I noticed that some of my fp calculations weren't accurate, so I switched from using SQR(n) to n^(1/2) and the error went away.

I know that P4's still used the original Pentium math co-processor, that had the fp error, up through P4 mobile.


If this is a hardware issue, which would explain the odd fp calculation behavior I've been observing, and it doesn't affect the majority
of players, then consider the GFay issue CLOSED. (I have an idea..oh god, there he goes again..on how to fix the the click->no movement
of activator issue, but that is LOW priority atm.)

(If any servers admins are having players complain about this 'missing the lift' bug, I'll accept pm requests to continue working on it and post
anything that I find in the 'custom code' forum. I will judge continuation based on the number of requests that I receive between today
(date of this posting) and the next 60 days.)


U