switches & levers controlling doors
So I got the bright idea to try to make some various lifts function correctly. I thought this would be fairly simple but I was wrong.
I was testing the following in Vergalid Mines door 41 = lever at zone in door 40 = main lift doors 38 & 39 = ropes for main lift Initially the main lift and the ropes are in a closed state. Both the lift and the ropes are at the bottom of the shaft. player.pl Code:
my $doorstate = quest::isdooropen(40); The problem is quest::forcedoorclose() doesn't seem to be working. Don't know if I used it wrong or if it is actually broken. Any input would be appreciated. |
First, don't use "my" when defining variables outside of a sub event. Second, if you define your variable outside of the sub like you did for checking door state, it won't update ever again after the script is initially loaded. This means it won't know if the door state has changed. If you use the script below, that will at least resolve those 2 issues:
Code:
sub EVENT_CLICKDOOR |
Ok I moved the variable declaration. It corrected my bad usage but didn't alter the end result of the script.
|
Well I figured out how to make the lever, ropes and platform work all at once. There appears to be an error in doors.cpp.
default doors.cpp Code:
void Doors::ForceOpen(Mob *sender) Now changing md->action = OPEN_DOOR; to md->action = CLOSE_DOOR; as it is below allows Doors::ForceClose() to work a little better changed doors.cpp Code:
void Doors::ForceOpen(Mob *sender) If anyone can see a better way to fix the odd bounce effect besides changing opentype I am all for it otherwise I will keep looking for a better solution. |
Nice catch. I think the issue may be again with those commands being copies of each other. This section here probably needs to be adjusted for the ForceClose:
Code:
if(!isopen) { Code:
if(isopen) { |
I tried the suggested change and got mixed results. It will work fine one minute and then it goes back to its random behavior. It seems like it is getting confused.
|
i stuck all the above changes in my build and the Kelethin lifts still do not work every click. Yes I'm making sure they finished traversing up or down before clicking again.
|
I think those lifts are a whole different issue all together. Those things have never worked properly, and I don't think they use scripts anyway so it is not relevant to this thread.
|
I'm looking at this in my spare time. I'm sure blackdragon's fix for ForceClose is correct and I will add my inverted door fix as
well..and submit sometime after the next revision. I just need to double-check the logic table to make sure it won't be buggy the way it's coded atm. In regards to the mines' lift issue (and other multi-part doors), something similar to his fix for player.pl is probably correct as well. you would just need to add each door with its corresponding ones to the check (i.e., clickdoor(1)->forceopen(2,3,4), clickdoor(2)->forceopen(1,3,4), etc...) Lever activated versus direct click would need some attention though. (Is there a way to add player.pl-type script to a zone's quest directory?) Door type 40 is a whole other beast. I'm getting click events as late as 10 minutes after I've activated it. Is it possible that this door type is sending a 'click' event of some type after it resets, and flipping the server door state in a 'bounce' effect? If it is sending a 'toggle' event, the server code shouldn't be setting a close_timer for this type of door. It should be waiting for the return event to set the current state of the door. (Still thinking through the possibilities..client LD's might be a problem and require some attention.) I'm not packet savvy, but I'd like to know if there are client events being sent during this 'bounce' period. U |
The lifts and such in Vergalid mines behave in an erratic manor and I am sorry to say I never found a good fix for them. I did hold onto some of the work I did before.
All the following applies to the very first lift you encounter in the zone. Assuming the door id's haven't changed this should still work. player.pl Code:
sub EVENT_CLICKDOOR Code:
update doors set triggerdoor = 0 where doorid = 38 and name = 'OBJ_ELEVPLAT'; If I remember correctly it was also possible to control the lifts, ropes and levers without the need for a script which is what I believe the following changes will do. Code:
update doors set triggerdoor = 39 where doorid = 38 and name = 'OBJ_ELEVPLAT'; The bounce effect as you put it is the same erratic behavior I saw when messing with the lifts. If that bounce effect can be removed then the rest should be pretty easy to figure out. |
(This is an afterthought to the 'bounce' effect.)
Since my 'sender->message()' debug code was stricly inside of 'HandleClick', does the fact that I'm getting those messages during these events indicate that a client-side action is being performed when the 'bounce' occurs? (And thanks for posting your full code. You already had what I was contemplating!) :) U |
Quote:
|
(I went ahead and assumed that it is, since I'm getting sender-related messages that should only be generated if I click
something, and came up with this.) I believe the 'bounce' effect is the result of the type 40 door model having an internal 'state_timer' expire without receiving a close action from the server to indicate proper status. The door itself is then sending interval repeated (spamming) 'ClickDoor' events, possibly using some of the OP_ClickDoor' unknown00x values, to request a close door action. The number of 'bounces' that you receieve are probably proportional to lag and server load. (I'm hypothesizing all of this based on my observations.) (It was Colonel Mustard in the Dining Room with the 'HandleClick' Code..err... Sorry..late night...) I came to this conclusion by doing the following: In addition to sending the 'md->action = OPEN_DOOR' during normal checks, I also initiated a new packet and sent a 'md->action = CLOSE_DOOR', during the same 'HandleClick' call, to the client. The bounce effect was negated, but no lever travel occured. (I'm up to 45 minutes with no call-backs.) If it were possible to send a close action back to the same client when 'close_timer' expires, this 'bounce' effect could probably be absolutely negated and still allow proper lever travel. This should be able to coded into Doors::Process(), but it might take a sender/timer storage array to handle multiple client actions..or, even better, a general zone-wide broadcast, which I have no knowlegde (yet) of how to do. I will look into the zone-wide broadcast aspect and see if I can come up with something. I know what to do in Doors::Process(), I just need figure out how to send the entire zone a 'md->action = CLOSE_DOOR' action. If I can get all of these fixes working, I'll bump this back to Code Submissions and roll off a diff patch of doors.cpp against the current revision and see what dev to contact about having them tested and implemented. I'll have to learn some more about the scripting aspect, but I think your fix for the lift is definitely the way to go. I'm still not sure about putting it in players.pl since the muli-part doors in the Gyrospires would work the same way (and any custom content), but there may be no other way around it. U |
Ok, I have a working fix for the opentype 40 door. Once I have tested it as much as I can, I'll look at multi-part doors in the
database and see if I can put those into player.pl using your (blackdragon) implementation. U |
The player.pl I posted was for testing on a specific lift in Vergalid. It may not work for any other door or lift. Take a look at the player.pl for gyrospireb in your quests directory...I think that might be a better way to deal with multi part doors.
|
All times are GMT -4. The time now is 08:19 PM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.