switches & levers controlling doors

blackdragonsdg · #1 04-29-2011, 04:03 AM

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);

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** · #2 04-29-2011, 04:41 AM

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
{

	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 · #3 04-29-2011, 05:53 PM

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

blackdragonsdg · #4 05-02-2011, 04:53 AM

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)
{
    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

Code:

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** · #5 05-02-2011, 06:30 AM

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) {
		close_timer.Start();
		isopen=true;
	}
	else {
		close_timer.Disable();
		isopen=false;
	}

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

Code:

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

blackdragonsdg · #6 05-02-2011, 05:20 PM

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 · #7 05-02-2011, 11:56 PM

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** · #8 05-03-2011, 05:27 AM

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** · #9 06-10-2012, 10:39 PM

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 · #10 06-10-2012, 11:28 PM

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
{
	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

Code:

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.

Code:

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** · #11 06-11-2012, 12:31 AM

(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

**Uleat** · #12 06-11-2012, 05:44 PM

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 · #13 06-12-2012, 12:13 AM

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.

**Uleat** · #14 06-12-2012, 12:55 AM

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

**Uleat** · #15 06-13-2012, 08:09 AM

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