switches & levers controlling doors

[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