COMMITTED: Multiple Door Fixes

[Uleat]

I'm pretty sure that I've got a couple of the door issues (inverted and opentype 40 doors) ironed out. I want to do
some more testing with a second client (I'll have to make one) to ensure that my fixes aren't just single-client.

In addition, since I've already posted a doors.cpp patch for this revision (2145), I don't want to post another one on
top of it. Someone might get confused about which/what to patch.


Is there a dev that I can talk to in pm about handling this?


U

[sorvani]

just post a complete diff against the current rev. any one who has commit authority will understand it.

[Uleat]

This patch incorporates both the 'inverted' door fix and the 'opentype 40' door fix. (patched, compiled, verified)

(If you applied my previous inverted door patch, make sure you apply this to the revision file and not the patched file. If you don't
know how to revert, just delete your doors.cpp and then svn update to get it back to revision.)


doors.cpp.patch

Index: doors.cpp
===================================================================
--- doors.cpp	(revision 2145)
+++ doors.cpp	(working copy)
@@ -31,6 +31,8 @@
 
 #define OPEN_DOOR 0x02
 #define CLOSE_DOOR 0x03
+#define OPEN_INVDOOR 0x03  // U: Added inverted
+#define CLOSE_INVDOOR 0x02 // action definitions
 
 extern EntityList entity_list;
 extern WorldServer worldserver;
@@ -120,7 +122,22 @@
 {
     if(close_timer.Enabled() && close_timer.Check() && IsDoorOpen())
     {
-	triggered=false;
+		// U: Added zone broadcast 'close door' action to satisfy opentype 40 close requirement.  Otherwise, all clients (tested)
+		// will spam the server with 'click' events until it is reset.  This method ensures a 'close' action is broadcast to each
+		// client in zone regardless of who originated the request.  If the close_timer is ever disabled in code without allowing
+		// Process() to handle a broadcast, and the procedure also issues a md->action = 'open door' command, then it should be
+		// written to account for having to deal with this repeating 'bounce' issue. (i.e., Doors::ForceOpen())
+		if (opentype == 40)
+		{
+			EQApplicationPacket* outapp = new EQApplicationPacket(OP_MoveDoor, sizeof(MoveDoor_Struct));
+			MoveDoor_Struct* md = (MoveDoor_Struct*)outapp->pBuffer;
+			md->doorid = door_id;
+			md->action = invert_state == 0 ? CLOSE_DOOR : CLOSE_INVDOOR;
+			entity_list.QueueClients(0, outapp);
+			safe_delete(outapp);
+		}
+		
+		triggered=false;
         close_timer.Disable();
         SetOpenState(false);
     }
@@ -143,6 +160,15 @@
 	//TODO: add check for other lockpick items
 	//////////////////////////////////////////////////////////////////
 
+	// U: I left in my test code in case someone needs to work on trigger doors in the database. It can be removed from
+	// revision if it's not warranted to be here. All test code is suffixed with: '// U: Test code'
+
+	//sender->Message(4, "door:%i->doortype (dty:%i) [start]", door_id, GetOpenType()); // U: Test code
+	//sender->Message(4, "door:%i->doorstate (ds:%s | ti:%s)", door_id, IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
+	//sender->Message(4, "door:%i->trigger (tid:%i | ts:%s | tty:%i)", door_id, trigger, triggered ? "T" : "F", GetTriggerType()); // U: Test code
+	//sender->Message(4, "door:%i->triggerdoor (tdid:%i)", door_id, GetTriggerDoorID()); // U: Test code
+	//sender->Message(4, "door:%i->client (xp:%f | yp:%f | zp:%f)", door_id, sender->GetX(), sender->GetY(), sender->GetZ()); // U: Test code
+
 	//TODO: ADVENTURE DOOR
 	if(IsLDoNDoor())
 	{
@@ -200,11 +226,13 @@
 		{ // this door is only triggered by an object
 			if(!IsDoorOpen() || (opentype == 58))
 			{
-				md->action = OPEN_DOOR;
+				md->action = invert_state == 0 ? OPEN_DOOR : OPEN_INVDOOR;
+				//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [objtrgd]", door_id, invert_state == 0 ? "open" : "invopen", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 			}
 			else
 			{
-				md->action = CLOSE_DOOR;
+				md->action = invert_state == 0 ? CLOSE_DOOR : CLOSE_INVDOOR;
+				//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [objtrgd]", door_id, invert_state == 0 ? "close" : "invclose", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 			}
 		}
 		else
@@ -221,11 +249,13 @@
 	{	//door not locked
 		if(!IsDoorOpen() || (opentype == 58))
 		{
-			md->action = OPEN_DOOR;
+			md->action = invert_state == 0 ? OPEN_DOOR : OPEN_INVDOOR;
+			//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [unlckd]", door_id, invert_state == 0 ? "open" : "invopen", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 		}
 		else
 		{
-			md->action = CLOSE_DOOR;
+			md->action = invert_state == 0 ? CLOSE_DOOR : CLOSE_INVDOOR;
+			//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [unlckd]", door_id, invert_state == 0 ? "close" : "invclose", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 		}
 	}
 	else
@@ -243,6 +273,8 @@
 				strcpy(tmpmsg, "Door is locked by an unknown guild");
 			}
 			sender->Message(4, tmpmsg);
+			// safe_delete(outapp);
+			// U: Does this need to be added? All other 'fail' returns seem to have one - not tested (deletable message)
 			return;
 		}
 		// a key is required or the door is locked but can be picked or both
@@ -252,11 +284,13 @@
 			sender->Message_StringID(4,DOORS_GM);
 			if(!IsDoorOpen() || (opentype == 58))
 			{
-				md->action = OPEN_DOOR;
+				md->action = invert_state == 0 ? OPEN_DOOR : OPEN_INVDOOR;
+				//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [gmkey]", door_id, invert_state == 0 ? "open" : "invopen", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 			}
 			else
 			{
-				md->action = CLOSE_DOOR;
+				md->action = invert_state == 0 ? CLOSE_DOOR : CLOSE_INVDOOR;
+				//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [gmkey]", door_id, invert_state == 0 ? "close" : "invclose", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 			}
 		}
 		else if(playerkey)
@@ -270,11 +304,13 @@
 				sender->Message(4, "You got it open!");
 				if(!IsDoorOpen() || (opentype == 58))
 				{
-					md->action = OPEN_DOOR;
+					md->action = invert_state == 0 ? OPEN_DOOR : OPEN_INVDOOR;
+					//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [keyitem]", door_id, invert_state == 0 ? "open" : "invopen", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 				}
 				else
 				{
-					md->action = CLOSE_DOOR;
+					md->action = invert_state == 0 ? CLOSE_DOOR : CLOSE_INVDOOR;
+					//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [keyitem]", door_id, invert_state == 0 ? "close" : "invclose", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 				}
 			}
 		}
@@ -295,11 +331,13 @@
 					{
 						if(!IsDoorOpen())
 						{
-							md->action = OPEN_DOOR;
+							md->action = invert_state == 0 ? OPEN_DOOR : OPEN_INVDOOR;
+							//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [picklock]", door_id, invert_state == 0 ? "open" : "invopen", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 						}
 						else
 						{
-							md->action = CLOSE_DOOR;
+							md->action = invert_state == 0 ? CLOSE_DOOR : CLOSE_INVDOOR;
+							//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [picklock]", door_id, invert_state == 0 ? "close" : "invclose", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 						}
 						sender->Message_StringID(4, DOORS_SUCCESSFUL_PICK);
 					}
@@ -333,11 +371,13 @@
 				sender->Message(4, "You got it open!"); // more debug spam
 				if(!IsDoorOpen() || (opentype == 58))
 				{ 
-					md->action = OPEN_DOOR; 
+					md->action = invert_state == 0 ? OPEN_DOOR : OPEN_INVDOOR;
+					//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [keyring]", door_id, invert_state == 0 ? "open" : "invopen", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 				} 
 				else
 				{ 
-					md->action = CLOSE_DOOR; 
+					md->action = invert_state == 0 ? CLOSE_DOOR : CLOSE_INVDOOR;
+					//sender->Message(4, "door:%i->%s(ds:%s | ti:%s) [keyring]", door_id, invert_state == 0 ? "close" : "invclose", IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
 				} 
 			}
 			else 
@@ -361,11 +401,14 @@
 		SetOpenState(false);
 	}
 
+	//sender->Message(4, "door:%i->timer(ds:%s | ti:%s) [end]", door_id, IsDoorOpen() ? "O" : "C", close_timer.Enabled() ? "E" : "D"); // U: Test code
+	//sender->Message(4, "---end of call---"); // U: Test code
+
 	//everything past this point assumes we opened the door
 	//and met all the reqs for opening
 	//everything to do with closed doors has already been taken care of
 	//we return because we don't want people using teleports on an unlocked door (exploit!)
-	if(md->action == CLOSE_DOOR)
+	if((md->action == CLOSE_DOOR && invert_state == 0) || (md->action == CLOSE_INVDOOR && invert_state == 1))
 	{
 		safe_delete(outapp);
 		return;
@@ -439,9 +482,14 @@
 	}
 }
 
+// U: I am looking into a proper fix for 'NPCOpen,' 'ForceOpen' and 'ForceClose.'  I have not incorporated the opentype 40
+// fix into the current code to avoid introducing erratic scripting behavior, but I did correct the 'md->action =' and
+// changed 'ForceClose' to the untested suggestion that Trev gave last summer.
+
 void Doors::NPCOpen(NPC* sender)
 {
 	if(sender) {
+		// U: NPC's should probably not be allowed to open type 40 doors either.  Just ForceOpen the actual door. 
 		if(GetTriggerType() == 255 || GetTriggerDoorID() > 0 || GetLockpick() != 0 || GetKeyItem() != 0 || opentype == 59 || opentype == 58 || !sender->IsNPC()) { // this object isnt triggered or door is locked - NPCs should not open locked doors!
 			return;
 		}
@@ -449,7 +497,7 @@
 		EQApplicationPacket* outapp = new EQApplicationPacket(OP_MoveDoor, sizeof(MoveDoor_Struct));
 		MoveDoor_Struct* md=(MoveDoor_Struct*)outapp->pBuffer;
 		md->doorid = door_id;
-		md->action = OPEN_DOOR;
+		md->action = invert_state == 0 ? OPEN_DOOR : OPEN_INVDOOR;
 		entity_list.QueueCloseClients(sender,outapp,false,200);
 		safe_delete(outapp);
 
@@ -469,7 +517,7 @@
     EQApplicationPacket* outapp = new EQApplicationPacket(OP_MoveDoor, sizeof(MoveDoor_Struct));
 	MoveDoor_Struct* md=(MoveDoor_Struct*)outapp->pBuffer;
 	md->doorid = door_id;
-	md->action = OPEN_DOOR;
+	md->action = invert_state == 0 ? OPEN_DOOR : OPEN_INVDOOR;
 	entity_list.QueueClients(sender,outapp,false);
 	safe_delete(outapp);
 
@@ -488,15 +536,11 @@
     EQApplicationPacket* outapp = new EQApplicationPacket(OP_MoveDoor, sizeof(MoveDoor_Struct));
 	MoveDoor_Struct* md=(MoveDoor_Struct*)outapp->pBuffer;
 	md->doorid = door_id;
-	md->action = OPEN_DOOR;
+	md->action = invert_state == 0 ? CLOSE_DOOR : CLOSE_INVDOOR;
 	entity_list.QueueClients(sender,outapp,false);
 	safe_delete(outapp);
 
-    if(!isopen) {
-        close_timer.Start();
-        isopen=true;
-    }
-    else {
+    if(isopen) {
         close_timer.Disable();
         isopen=false;
     }

This patch should fix door-state logic issues, but not any scripted or database value problems.


U

[sorvani]

Applied this and here are my observatinos in GFay:
The lifts generally work better. When I zone in I see all the lifts traversing up to the top from the down position. Thus the whole inverted state thing I guess.
A single click on the lever brings it down.
Once it reaches bottom, a single click on lever toggles the lever but nothing happens. A second click toggles it again. A third click toggles the lever and sends the lift up.
Had no issues with having to be a certain place on the platform. never have.

edit: some of the time only 2 clicks is required. basically the lifts only actuate when the lever goes from down to up. When that happens the lift will being moving, or if already moving it will reverse direction.

edit2: waiting for the lever to reset (to down position) before clicking again, will cause the lift to move on a single click.

[Uleat]

It looks like the sony forums were purged at some point because I can't find anything there on the model bug. This post
is the only thing that I could find that alludes to something being wrong with the actual lift model. (Pretty sure it popped
up during a Kunark or Velious live patch.)

http://www.project1999.org/forums/sh...1&postcount=16

I guess this theory could be tested with two clients. Since I created a second account for the type 40 checks, I'll
see if I can pinpoint the area this is happening (if it is at all.) (I still have my original pre-Kunark install disc. I may try
copying the object file over to see if that helps.)

I'll also see what I can do with the actuator issue. I saw the same multiple click issues, but attributed it to the trigger and
triggertypes being [0, 0] versus the Crescent lifts which are [1, 255]. If you enable the test code, you will see that a
server door state change event does occur, but there is no movement client-side. (Remember, the server state changes
after 5 seconds, before the lift travels all the way down, but the client takes the door model cycle time, or at least one
direction, to reset both the lift and the actuator. Whereas with the Crescent actuators, they reset after 4~5 seconds.)


I still believe the logic is sound (for any inverted state door change), but I'll dig deeper into the cause. It may take
some database value changes, and possibly player.pl, to get the GFay lifts to work absolutely correct. I don't believe
it is just one issue.


U

[pfyon]

I actually think I remember the switches at the gfay lifts working where the lift would only go up if the switch moved from the down to the up position, and vice versa.

[sorvani]

well i do not really care which way the switch goes, it is just nice to most be able to make a single click and the damn things move.

[Uleat]

Ok, testing with doors.ppp (revision), I changed the inverted state for the doors to 0 in the database. With the lifts now in the
default down position, the lifts still exhibit the same 2/5ths - 3/5ths issue, if you don't cycle the handle.

Switching back to doors.cpp (my patch) and changing the database inverted state values back to 1 (for doors 69, 77 and 80)
resulted still shows the same buggy result.


Even though I couldn't duplicate the action that was described on the link that I posted, I have found a way to view the bug.
(I can't be sure that it's the lift and not the ramp though. It could be that the ramp z-pos needs to be lowered 0.10 ~ 0.15.)


To view the bug, try this (you don't need to activate any test code):

- Go to the POD lift and get as close as possible to /loc 135.13, 240.07, xx. You should be about half-on/half-off the ramp.
(I'm, using the barbarian model, but that really shouldn't matter.)

- Annotate your z-pos (should be approx. 9.53 - same height as the ramp)

- Now click the lift activator to bring the lift down, but watch your character. After you click it, you drop down
a hair. Your z-pos is now about 9.42.)

- Without clicking again, wait for the handle to return down. As soon as it does, you rise back up to 9.53, and as soon as
the lift begins traveling upward, you miss it.

Now wait until the lift has had a chance to completely recycle and try this:

- Same position as above.

- Click the activator and wait for the lift to come down.

- Once it has, click the the activator three times, but watch your character as you click (do it before the activator handle
goes back down.)

- On the first click, the handle does not move, but notice that you dropped down to the 9.42 z-pos.

- On the second click, the handle goes down, but the lift does not go up nor do you move up in z-axis.

- On the third click, the handle comes up and the lift goes up, with you on it.

You only seem to be able to get on the lift at z-pos 9.42. Standing completely on the ramp, your z-pos is 9.53
regardless of how many times you click the handle. There's something about cycling the handle that seems to clear the
bug temporarily.

I've not been able to pin it to a "step gate" on the ramp or a problem with the lift model itself. Hard to say it's the ramp
since it also happens coming down from Kelethin. With that, maybe the there's a "step gate" up top as well. I think if
it's a mis-alignment of the lift, instead of moving the ramp down 0.10 ~ 0.15, we could try moving the lift up by that amount.
A mis-alignment would explain top and bottom behavior, but so would a model error.

As far as the activator handles, I'll continue to work those (a door type change may fix those.) I still stand by my
inverted doors patch submission though, especially since the bug can be duplicated without it when the doors are not
set inverted

(And I'll see if I can do a workaround using player.pl for these lifts if I move the model location and that doesn't fix the
issue.)

I'm heading off to Permafrost to check the lifts there. I hear they have the same problem as the Greater Fay ones did


U

[Uleat]

Ok, I tried the database z-axis changes and that was a no-go.

I wound up lowering the lift by 0.11 and then by 0.12. The first may not have been enough to account for rounding, but the second should have definitely caught it.

I'll see what I can do with the player.pl scripting.


(btw, is there any consistency on which gets handled first? The player doorclick op or the scripted action in a player.pl file?)


U

[Uleat]

Ok... I think I have a good path to follow for this.


I posted on this thread (and somewhere else) that I was looking for a lift model bug based on the behavior that I saw
in my buggy behavior post above. I think I might have found the issue that is causing a player to miss the elevator
unless they play with the activator handle.

I went back into gfaydark_obj.s3d this evening and discovered a model name "ELESTEP_DMSPRITE." This model
does not have a door_id in the database, but this rings right with what I was saying above on this thread. It looks like
it could be hard-coded into client to open/close with any lift activator click/model timer event.


I noticed that there are a lot of "empty" doors, especially around the FAYLEVATOR and FELE1/2 entries.

When you guys were collecting packet information, did you run across any that could be tied to this "ELESTEP"
'door?'

I want to try and find a way to invert it (or ! it) during zone load to see if this restores the lift operability.


U

[Uleat]

Disregard previous post. I tore apart the lift and ramp models and didn't find what I was looking for. I was hoping there
was an invisible layer that was acting as a 'step' to ensure the player was actually on the lift, but there went any extra
polygons...

I guess there's an offset that's added to the player z-axis that isn't object-related and is coded into the client.


Back to a workaround...


U

[Uleat]

(Mostly for info purposes in case someone in the future tries to work on these, but feel free to post suggestions.)

After some extensive testing with the GFay lifts, I still believe the inverted doors fix is the correct action for using invert_state = 1.


However, there is a bug with the animation of the lift. I can induce this same bug without using the inverted door close fix. I have
tried adjusting the z-position of the lift to various heights with no resolve and tested with doorisopen values mimicking those in Crescent
Reach with the same failures.

I also tried setting the activator door triggerdoor to '0' in hopes of seeing if GFay was coded to handle certain lift conditions based
on the value of of its activator. This didn't pan out. (Even moved the additional lifts out of zone in case they 'might' be interferring.)

Crescent Reach uses the exact same values (with the exception of buffer - tried that too...) as do the GFay ones, yet they work
(comparing to the elevated dragon lifts.)

(Also tried changing player #size to values between 1 and 100 with no difference.)


The best that I can figure is that the Animation handler for the lifts is miscoded. Something about clicking the handle multiple
times seems to temporarily reset the state of the collision detection values. It seems like the values don't change during the normal
movement of the door, but forcing it open/closed when the animation is over is what is reseting it.

(It's almost like the door travels one tick further than the collision detection value do. At the current PEQ settings, I'm getting
about a 0.000681 difference in player z-value between working and non-working positions. PEQ drops the '1' and doesn't allow
me put in an accurate door position adjustment. It could be that the door is traveling 100% of the way, but the detection only
travels ~99.999%)


I'm going to try two last possibilities and see if either work.

First is changing the door timer to 7 ~ 8 seconds (server timer seems to run out just before the lift actually reaches the bottom)
and then adding a md-action = 'open door.' (Yes, it could send the lift down from the top depending on when the activator was
clicked..will need refining if it works.)

The Second is using a proximity detector and adjusting the z-value of the player when they within the bounds of the lift.


U

[Uleat]

(GFay Lift Issue marked for closure -> http://www.eqemulator.org/forums/sho...3&postcount=27)


I think that I've got the coding correct for any and all of my door submissions and am about to start in-depth testing. I don't plan on
any more door submissions after this unless there's an error I need to fix. (This should cover any existing and near-future issues.)

If this works, do you want to see one final 'diff' file, or each change presented in its own 'diff' file? Dis-incorporation may be a little
difficult since some of the changes overlap each other..but I can try if that's what you want to see.

I'll test it as much as I can, just remember it will be on a 32-bit Win os. I'll test as many existing doors as possible with an SoF
client and try out my changes/addition to the door action scripting.


U

[Uleat]

Ok, most of the major testing appears good (no errors, no crashes, proper functionality.) I'll do some more specific testing this
evening and run a 'diif' file off of 2149 and merge back before I post (hopefully, later tonight..sans remarks and test code.)

(bd, I've got a really simple fix for the Vergalid lift..I'll post it over in 'Quests' when I get finished with this.)


U

[Uleat]

(Server code submission in the following post)

This submission only covers the server code required to see improvements in door function. Some changes to database values will need to
be made, as well as some modifications to quest *.pl files, to fully realize the potential of this fix. It should not break any exisiting files or
functionality in its implementation.

Inverted Doors:
[Source:] Added conditional checks to determine if door is in an inverted state and to send appropriate client commands based on
requested action.

[Database:] Elevator actuators can now be placed in the inverted state based on asthetics and server admin preferences while maintaining
proper elevator function.


Opentype '40' & 'Dead-Click' Doors (handles/levers):
[Source:] Added code to Doors::Process() to handle zone broadcast closures of opentype '40' doors to eliminate the client(s)-server spam
events. Also added triggertype '1' to conditional check for zone broadcast to help maintain client-server door syncronization and reduce
the occurence of first-click->no-action ('dead-click') events.

[Database:] It is recommended that elevators/lifts & their owning activator doors be placed in the triggered-only state ([255/1] versus
[0/0]) to eliminate activation by 'lift-clicking' and to ensure that Doors::Process() handles the syncronization event described above.

(This fix is effectively redundent for opentype '40' doors if triggertypes are changed to [255/1], but should allow single/custom
opentype '40' door implementation as well as the option not to change types.) (If you see a 'dead click' with the very first activation
of a lift, but normal operation resumes afterwards, then database changes need to be made. I will coordinate with cavedude and see if I
can submit updates to him.)


Changes to 'NPCOpen', 'ForceOpen' & 'ForceClose':
[Source:] Modifed the structure of these handlers to accept (sender, alt_mode). The delegates have been coded to pass a 'false'
value in the case of existing programming structure, while allowing a 'true' value to be passed in the event that the alternative
'ForceOpen' or 'ForceClosed' action is desired. Changed timer disable and isopen=false statements to 'close_timer.Trigger();' to
eliminate the need for additional opentype '40' checks and procedures..Doors::Process() will now handle these.

[Note:] The modification to NPCOpen does not affect the expected action in <entity.cpp> EntityList::OpenDoorsNear().


Changes to 'forcedooropen' & 'forcedoorclose':
[Source:] Added the appropriate code to handle the scripted changes associated with the above source code updates. Again, 'altmode' is
not required for default operation.


Added 'toggledoorstate' & 'ToggleState':
[Source:] Included these new functions to change a door state without initiating a 'close timer.' Allows triggering of single-action type
doors (such as the Vergalid Mines lift) while maintaining client-server syncronization. No 'modified action' schema is designed or needed
in this function. Some restriction is incorporated, but useability ultimately depends on programmer's knowledge of client door operation.


Usage:
[Code]
NPCOpen(NPC* sender [, bool alt_mode=false])
ForceOpen(Mob *sender [, bool alt_mode=false])
ForceClose(Mob *sender [, bool alt_mode=false])
ToggleState(Mob *sender)

[Script]
forcedooropen(doorid [, altmode=0])
forcedoorclose(doorid [, altmode=0])
toggledoorstate(doorid)


Actions:
NPCOpen(sender) - client open action, current server toggle action with timer activation if appropriate
NPCOpen(sender, false) - same as NPCOpen(sender)
NPCOpen(sender, true) - client open action, set door state to open, start timer (restart if isopen already true)

ForceOpen(sender) - client open action, current server toggle action with timer activation if appropriate
ForceOpen(sender, false) - same as ForceOpen(sender)
ForceOpen(sender, true) - client open action, set door state to open, start timer (restart if isopen already true)

ForceClose(sender) - client close action (change from open action), current server toggle action with timer activation if appropriate
ForceClose(sender, false) - same as ForceClose(sender)
ForceClose(sender, true) - client close action, set door state to closed, disable timer (close_timer.Trigger())

ToggleState(sender) - toggles server door state, sends client appropriate md->action command, no timer activity

(Script actions should not need explaining...)


U