switches & levers controlling doors

[blackdragonsdg]

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

my $doorstate = quest::isdooropen(40);

sub EVENT_CLICKDOOR
{
	if($doorid == 41 && !$doorstate)
	{
		quest::forcedooropen(38);
		quest::forcedooropen(39);
		quest::forcedooropen(40);
	}
	if($doorid == 41 && $doorstate)
	{
		quest::forcedoorclose(38);
		quest::forcedoorclose(39);
		quest::forcedoorclose(40);
	}
}

When the lever is triggered both the lift and the ropes go into an open state and rise to the top of the shaft. Triggering the lever a second time should cause the lift and ropes to enter a closed state and lower back to the bottom of the shaft.
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.

[trevius]

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:

sub EVENT_CLICKDOOR
{

	my $doorstate = quest::isdooropen(40);

	if($doorid == 41 && !$doorstate)
	{
		quest::forcedooropen(38);
		quest::forcedooropen(39);
		quest::forcedooropen(40);
	}
	if($doorid == 41 && $doorstate)
	{
		quest::forcedoorclose(38);
		quest::forcedoorclose(39);
		quest::forcedoorclose(40);
	}
}

[blackdragonsdg]

Ok I moved the variable declaration. It corrected my bad usage but didn't alter the end result of the script.

[blackdragonsdg]

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

void Doors::ForceOpen(Mob *sender)
{
    EQApplicationPacket* outapp = new EQApplicationPacket(OP_MoveDoor, sizeof(MoveDoor_Struct));
	MoveDoor_Struct* md=(MoveDoor_Struct*)outapp->pBuffer;
	md->doorid = door_id;
	md->action = OPEN_DOOR;
	entity_list.QueueClients(sender,outapp,false);
	safe_delete(outapp);

    if(!isopen) {
        close_timer.Start();
        isopen=true;
    }
    else {
        close_timer.Disable();
        isopen=false;
    }
}

void Doors::ForceClose(Mob *sender)
{
    EQApplicationPacket* outapp = new EQApplicationPacket(OP_MoveDoor, sizeof(MoveDoor_Struct));
	MoveDoor_Struct* md=(MoveDoor_Struct*)outapp->pBuffer;
	md->doorid = door_id;
	md->action = OPEN_DOOR;
	entity_list.QueueClients(sender,outapp,false);
	safe_delete(outapp);

    if(!isopen) {
        close_timer.Start();
        isopen=true;
    }
    else {
        close_timer.Disable();
        isopen=false;
    }
}

The above sections are identical which is why Doors::ForceClose() doesn't work properly.
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

void Doors::ForceOpen(Mob *sender)
{
    EQApplicationPacket* outapp = new EQApplicationPacket(OP_MoveDoor, sizeof(MoveDoor_Struct));
	MoveDoor_Struct* md=(MoveDoor_Struct*)outapp->pBuffer;
	md->doorid = door_id;
	md->action = OPEN_DOOR;
	entity_list.QueueClients(sender,outapp,false);
	safe_delete(outapp);

    if(!isopen) {
        close_timer.Start();
        isopen=true;
    }
    else {
        close_timer.Disable();
        isopen=false;
    }
}

void Doors::ForceClose(Mob *sender)
{
    EQApplicationPacket* outapp = new EQApplicationPacket(OP_MoveDoor, sizeof(MoveDoor_Struct));
	MoveDoor_Struct* md=(MoveDoor_Struct*)outapp->pBuffer;
	md->doorid = door_id;
	md->action = CLOSE_DOOR;
	entity_list.QueueClients(sender,outapp,false);
	safe_delete(outapp);

    if(!isopen) {
        close_timer.Start();
        isopen=true;
    }
    else {
        close_timer.Disable();
        isopen=false;
    }
}

That single change didn't completely fix the problem. I think the isopen() and the associated timers are causing a weird bounce effect when used with opentype 40. I changed the database to use opentype 58 so that a click is required to open and close the lever and then the lift and ropes worked as they should have but obviously the lever is frozen in place.
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.

[trevius]

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:

	if(!isopen) {
		close_timer.Start();
		isopen=true;
	}
	else {
		close_timer.Disable();
		isopen=false;
	}

It probably needs to be set something like this (untested):

	if(isopen) {
		close_timer.Disable();
		isopen=false;
	}

[blackdragonsdg]

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.

[sorvani]

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.

[trevius]

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.

[Uleat]

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

[blackdragonsdg]

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

sub EVENT_CLICKDOOR
{
	my $doorstate = quest::isdooropen(38);

	if($doorid == 41 && !$doorstate)
	{
		quest::forcedooropen(38);
		quest::forcedooropen(39);
		quest::forcedooropen(40);
	}
	if($doorid == 41 && $doorstate)
	{
		quest::forcedoorclose(38);
		quest::forcedoorclose(39);
		quest::forcedoorclose(40);
	}
	if($doorid == 42 && !$doorstate)
	{
		quest::forcedooropen(38);
		quest::forcedooropen(39);
		quest::forcedooropen(40);
	}
	if($doorid == 42 && $doorstate)
	{
		quest::forcedoorclose(38);
		quest::forcedoorclose(39);
		quest::forcedoorclose(40);
	}
}

required changes for player.pl to work

update doors set triggerdoor = 0 where doorid = 38 and name = 'OBJ_ELEVPLAT';
update doors set triggerdoor = 0 where doorid = 39 and name = 'OBJ_ELEVROPE';
update doors set triggerdoor = 0, opentype = 58 where doorid = 41 and name = 'OBJ_ELEVSWLEVER';
update doors set triggerdoor = 0, opentype = 58 where doorid = 42 and name = 'OBJ_ELEVSWLEVER';

The above changes should cause the lift, ropes and levers to work with each other.
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.

update doors set triggerdoor = 39 where doorid = 38 and name = 'OBJ_ELEVPLAT';
update doors set triggerdoor = 40 where doorid = 39 and name = 'OBJ_ELEVROPE';
update doors set triggerdoor = 38 where doorid = 41 and name = 'OBJ_ELEVSWLEVER';
update doors set triggerdoor = 0 where doorid = 42 and name = 'OBJ_ELEVSWLEVER';

The suggested change to Doors::ForceClose() is probably correct and it did improve function a bit but I think some of the lifts and such may require additional code support to make them function correctly.

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.

[Uleat]

(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

[blackdragonsdg]

Originally Posted by Uleat

(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?

Well I don't have a clue. Maybe someone with more expertise on the subject can answer that question.

[Uleat]

(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

[Uleat]

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

[blackdragonsdg]

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.