Paththrough UseSwitch

From omni-bot
Paththrough Main Page Paththrough UseSwitch


UseSwitch

The UseSwitch type of paththrough is typically used for enabling bots to press switches or buttons that open doors or call elevators along their way. It requires a Switches table in the map script, similar to the following example:

 Map = 
 {
 	Door1Status = 0, //door is closed initially
 	Switches =
 	{
 		door1 =
 		{
 			Enabled = true,
 			Priority = 0, //always set to 0 when using path through
 			WaypointName = "door_1switch",
 			Timeout = 2000,
 			AimPosition = Vec3(-4552.238, -6960.125, 4064.353), // Optional 0.8x only, use /bot aim_pos to get aim vector. Replaces the unreliable waypoint facing.
 			Wait = function() // optional. used to have the bot wait a bit for slow moving doors / elevators
 			{
 				if ( Map.Door1Status == 1 )
 				{
 					//wait 1.5 secs while the door opens
 					sleep(1.5);
 					return true; 
 				}
 				//always return false unless the door is open:
 				return false;
 			},
 		},
 	},
 };

In order for the goal to be used, a paththrough property must be set on a waypoint that the bots will reach as part of the path going to a destination beyond the switch. In this example, the goal is UseSwitch_PT and the switch to be used is door1 ( from the switch table ):

 /bot waypoint_setproperty paththrough UseSwitch_PT:door1

Script and waypoints should be set up similarly to the old useswitch goal from Omni-bot 0.71, except that there can be a Wait() function in the table for each switch, and Priority should be set to 0. Availability of the switch should be set similarly to the normal useswitch goal as well

 Door1_Moving = function ( trigger )
 {
 	if ( trigger.Action == "opening" )
 	{
 		Map.Door1Status = 1; //open
 		Map.Switches.door1.Enabled = false;
 		//print("door is opening");
 	}
 	else
 	{
 		Map.Door1Status = 0; //closed
 		Map.Switches.door1.Enabled = true;
 	}
 },

Note that the switch is disabled when the door opens, so the bots will stop pressing it.

In the following example image, the command

/bot waypoint_setproperty paththrough UseSwitch_PT:door1

was used at waypoint A. Now a bot that is trying to reach waypoint B via A is instructed to go to waypoint C (named "door_1switch") and press the switch S. Once the door starts opening, the bot stops pressing the switch because it is disabled, waits 1.5 seconds to give the door time to open properly, and then moves on normally.

Paththrough1.jpg

Note that the use of one-way connections between waypoints is often required when using paththrough. In our example, the bots would otherwise unnecessarily use the switch when passing waypoint A from the opposite direction. Also, it is important that A and B don't have the blockwall flag set, because the bots would consider the unidirectional path from A to B blocked and hence unusable if that flag were used.

The same basic principle can be applied to elevators in many cases. In the following two images, there is a one-way connection leading from waypoint A to waypoint B on the next floor (not visible). Again, the paththrough property set on waypoint A makes the bot press the switch S, rather than trying to move towards B directly.

Paththrough2 1.jpg Paththrough2 2.jpg

In the above example, the command applied to waypoint A could typically read
/bot waypoint_setproperty paththrough UseSwitch_PT:elevator