Help with faster "triggers"

[kresjah 1]

I'm in the process of polishing and optimizing my script for automatic doors. Whilst it works as intended, there is certainly a lot of room for improvement in terms of performance, and minor visuals. There are some parts in particular I've been trying to resolve, but I'm coming up empty-handed here.

 

The effect I'm trying to achieve is essentially that there is a sensor detecting people (or other things for that matter) near the door. The door opens, stays open for a set amount of time, then closes again. Now, if someone remains within the sensor area when the door is about to close, it should start closing for about 0.1-0.2 seconds then reopen. Imagine it as if the sensor shutting itself off when it detects a person (to conserve power or "increase" its lifetime), stays off while the door is opened, and the reactivates itself shortly after the door starts closing. I've added a video to the end of the post to help clarify.

 

This works mostly like I intend to. The biggest problem here is that I've been using a trigger as my door sensor. On the basis that it is an engine-native functionality alone I'd assume it would be better in terms of performance than a scripted solution, but it has the drawback of only checking its condition every 0.5 sec. This is often more than enough time for a player to run into the trigger's area and reach the door and get stopped before the trigger evaluates its condition.

 

I have an FSM running for the door which checks the trigger when the door is in the "closed". If it detects someone, it moves to the "opening" state where it disables the trigger with an enableSimulation false command. It waits in an "open" state for a preset time, then moves to a "closing, no sensor" state for a tiny bit (something akin to 0.2 seconds). During this entire time from the "opening" state to "closing, no sensor" state the sensor remains disabled (no simulation). The next state, "closing", reactivates the sensor. Unfortunately, due to the timing of triggers, this can mean that if someone is within the trigger area, instead of the intended 0.2 second timing from it starts to close until the the trigger actually evaluates its condition, it can also take half a second (or more maybe) after the door starts closing before it starts reopening, which is ample time for it reach around the half-way point before reopening.

 

As far as I know there is no way to individually set the timing of any trigger below 0.5 seconds (if I'm wrong, feel free to correct me). Is my only option here a heavier script-based solution? Any suggestions on how to implement such a solution?

 

Video of script (and timing issues) in action

https://youtu.be/Xy3rXCx40AY

 

Image of FSM with some details

http://imgur.com/wBfvjPy

[dr death jm 117]

it seems to me if your looking for something realism , you have it.. no sliding doors open as fast as a person jogs, not even walking .. 99% of the time a person has to stop and wait.. even at a hospital ..

unless theres something in video I'm not seeing?

[kresjah 1]

I am indeed aiming for at least some level of realism. You're right in that jogging would certainly make you hit the door. I realize now that I might have to add a few extra details.

 

It's not so much the fact that the player is bumping into the door as it is the fact that the delay due to trigger intervals is far too high. I have been forced to counteract this with a fairly large radius on the trigger simply to allow it more time to detect a presence before it reaches the door. I honestly doubt that most downwards facing sensors that hang over the doors (like on the Altis airport) would have a detection radius of 4 meters. That puts someone quite far from the door when it starts opening. If I had it at what I'd imagine are more realistic ranges the delay before opening would be even worse.

 

That said, I admit I haven't found and gathered any data on actual sensor ranges.

[beno_83au 1362]

Instead of using a trigger, would it help to put it all in a script and have the script wait until someone is within range of the sensor? Something like:

waitUntil {(count nearestObjects[_sensorPos,"man"4]) > 0};

//open the door

Then to close it, maybe roll straight into:

sleep 3; //however long the door is to stay open

while {(count nearestObjects[_sensorPos,"man"4]) > 0} do {
     //close the door
     sleep 0.5; //wait while the door begins to close
     //open the door
     sleep 3; //however long the door is to stay open again
};

//close the door 

Sorry, I could probably do that better but my right hand is out of action and it's making everything difficult.

[dreadedentity 278]

Sorry, I could probably do that better but my right hand is out of action and it's making everything difficult.

Too much Valentine's Day fun, eh?

[beno_83au 1362]

Too much Valentine's Day fun, eh?

 

:D But alas, no. Far from entertaining myself, it's an epic story of self-sacrifice in the face of adversity, or close enough to it anyway.

[EO 11236]

If you are looking for ways to refine your script, may i suggest a PM to Heeeere's johnny!, he is the creator of Automated Doors, which works flawlessly.  ;)

[kresjah 1]

@Evil Organ

I did look around for such scripts before starting my own and found that exact one. Took a peek through the code. However, I found that it was focused on a more player practical, whereas I am aiming for a somewhat more realistic approach. Frankly, whilst they do similar things, the approach and techniques (for lack of better words) we aim for are very different.

 

@beno_83au

Trying to tame your anaconda can be quite a hazardous business. :P

 

Jokes aside, I starting to think this is the only solution, although I've been trying to avoid it. I haven't benchmarked it (which I might have to do at a later point), but I imagine that it will actually will eat a significant chunk of perfromance compared to using triggers. The only way I could save a bit of performance as far as I see would be to change it to nearObjects to save some processing by not sorting the array. After all, I'm not looking for the nearest object, just if there are any objects at all in range.

[dreadedentity 278]

Is your script meant for players only? If so, doing local evaluations would be much less taxing. You could even easily get away with a while {true} do loop with no sleep at the end with minimal performance impact. You could create triggers on the server, or locally for each player, but only check locally for each player whether they are near a door.

if (!isServer) then
{
	ALL_TRIGGERS = [];
	//create a trigger
	_trig = createTrigger ["EmptyDetector", _position, false]; //last parameter makes trigger local to player
	_trig setTriggerArea [2, 5, _directionDoor, true]; //assuming you know the direction the door is facing and you saved it to a variable called _directionDoor
	ALL_TRIGGERS pushBack _trig;
	DOOR_CHECK = [] spawn
	{
		while {true} do
		{
			{
				if ([_x, player] call BIS_fnc_inTrigger) then
				{
					//do sequence
				};
			} forEach ALL_TRIGGERS;
		};
	};
};

Something like that should get you started nicely. Hope that helps

[st_dux 26]

I haven't benchmarked it (which I might have to do at a later point), but I imagine that it will actually will eat a significant chunk of perfromance compared to using triggers. The only way I could save a bit of performance as far as I see would be to change it to nearObjects to save some processing by not sorting the array. After all, I'm not looking for the nearest object, just if there are any objects at all in range.

 

It won't. waitUntil loops run only once per frame, which would have a negligible impact on performance for such a simple check, and the while loop that beno provided had significant sleeps in it, making the performance hit there absolutely negligible.