Accurate automatic doors?

I'm setting up a number of automatic doors in a current build, and to save on resources, I've got one central prim that uses a sensor every 30 seconds or so, then keeps the keys in a list until the person is out of range. I've a regular timer keeping track of the person's position via llGetObjectDetails.

My current doors will open once the person is near them. That's not what I want, as I'll have doors opening up along a hallway as I pass. What I would like, is that should the person's velocity point specifically towards the door, that it would then open. I'm reading up on intersecting line algorithms, and seriously, I'm hoping there is an easier way in LSL than these very long winded equations? perhaps I'm going about it the wrong way?

Any suggestions would be great.

volume detect doormat method? basically a door mat that's close to the door, but surrounds it, and detects avatars on collision(intersection really)... bad thing, it's +1 prim per door to be automated... but it's dog simple to code.

as for your intesecting... actually it's not TOO hard to calculate... just add a range to it

targeting = llVecNorm( llDetectedVel( 0 ) ) * 2 + llDetectedPos( 0 );
//-- compare with door positions
if (llVecDist( targeting, door ) < 2){
open the door we're testing
}

if you have lots of doors you'll want to build in some way to select which doors to test (possibly a larger version of the volume detect mats, which cover several doors, on the plus side you could even eliminate the sensor)

See, it already works this way almost, just without the extra prim. It detects through llGetObjectData(agentKey, [OBJECT_POS]) to see how close the person is to the door, then opens if under 1.5m, but using this, the door will open if you walk past it. What I really wanted was to only open if you were walking directly at the door.

I have good luck getting that apparent effect using collision_start as the trigger.

Set it to 0.5m and have really wide corridors.

you can change the scale of detection... I used 2 to demo it, you'd want something smaller, and probably ignoring the z element. (oh and that second 2 should only be a 1, it should be half since it's a radius number)

how you get the values is completely up to you, the welcome mat style will you instant response without polling though, which may make a huge difference in proccessing time/amount with multiple users, but has the obvious extra prim overhead, which might be negated by incorporating it in the floor. the total system idle will be a bit higher than single detection, but the running level should be MUCH lower.