Precision aim with llSensor in mouselook

Hi all,

I'm trying to figure out a way to make a narrow Mouselook llSensor more accurate. The problem I'm running into is that while I aim with my eyes, the sensor fires from my hips, creating a degree of vertical innacuracy, particularly at short range. For reference, this is initially going to be used for a proprietary combat system, but has other applications as well (directed info scanners and such).

Now, I know it's been said that it's "impossible" to accomplish what I'm trying to do, but I know of at least one (not so favorable) method that would work perfectly, aim-wise. Aside from that, I'm stuck. As a beneficial exercise, I'd like the rest of you to brainstorm, if you feel like it, but please refrain from the "that's not possible" responses.

Also, I'm trying to avoid having to rez prims of any kind. For what I'm trying to do, if I had to rez a prim, I might as well just use the prim's collision events to do what I'm after.

For reference, the most viable solution I've encountered so far involves using an animation to literally stick my avatar's head up his ass so that his eyes and my hips are in the same place. Perfect aim, but not so stylish.

Ready? Go!

Thanks.

It's fairly possible to calculate where your eyes are in relation to your hips by getting your avatar's height. It's not perfect, animations can introduce error, but they could in any case.

The issue, unfortunately, is that I don't know of any functions or cheating workarounds to set the origin of the sensor to that height. Since the sensing object is an attachment, sensor sweeps originate from the "root" of the avatar (hips).

Why wouldn't you just add the script to some nice sun glasses on sensor worn on the head ?


NVM that, I see what your saying, All attachments scan from the hip. ( didn't know that sorry .. )

I would, if that worked, and I wish it did. Again, anyattachment that uses sensors will sweep from the hips, regardless of where it is attached. If someone can prove me wrong on that, I'm begging you to do so.

Could you use a wider sensor cone, and then in the event handler, reject sensed objects that are too far to the sides or below, but include objects that are above you? So turn it into a narrow and tall cone in the event handler, in a manner of speaking. And then you could maybe do some trig on the sensed object's distance and position to see if the sight line from the av's eye height, rotated by the mouselook direction, would intersect that object at that distance.

Or something like that.... I won't even try to write out the math

-- Cheap Hack Alert --

Ok, I don't know if this works, I havent tryed it... But what would happen if you changed the center of mass of the person by attacking a large phantom transparent block above there head, This should then change where it will scan from.

Prolly will also screw with the physics tho..

Attached things have no effect on mass, center of pass, or scan origin. There is no way to move the sensor origin to eye level. You can broaden the cone to catch everyone in your field of view and then do calculations based on their detected position and your eye level.

Ger, you should talk to Seifert. I think he was working on something that might work for ya last time I spoke with him.

I have some code to check if a given point is inside a cone, doesn't involve any trig (trig seems to be avoidable in some way for most applications) and its not horriibly slow. I don't have it on me right now but can get hold of it when I get home.

I like Ziggy's method, the main issue I can see is failing to sense things right in front of your head when aiming forward, since they'd miss the cone from your hip unless the angle of the cone was very wide. Perhaps a second short sensor to get that blind spot would work.

Yeah, I was thinking about that too. You could get around it by using a really wide cone, but then the 16 detected object limit would effectively limit the scan distance. I was thinking of something where the av tells the scanner 'short range' vs. 'long range', and the scanner adjusts accordingly. Your solution of using a second sensor sounds better.

Also, I don't know if the application needs to work at short distances. Manual aiming shouldn't be too difficult for a target right in front of the av

Whoa, thanks guys! I honestly thought this was a shot in the dark (pun intended).

This is going to be for a proprietary combat system, so for the moment, it's just going to detect avatars, which will marginalize the need to be concerned about the 16 object limit unless it's -really- crowded.

The bit with not being able to hit what's right in front of you might actually be a nice balancing element, since I'm going to have melee weapons that -will- hit something right in front of them. If you let a tomahawk-swinging maniac get in your face while you're holding a gun, you deserve what's coming.

So do attachments always detect as if they were pointing forward relative to the avatar, from the pelvis? Is there any way to have a rearward facing sensor?

Attachments always detect from the avatar's pelvis, based on the direction the avatar is facing, yes. You can increase the radius of the sweep to include the area behind you, of course, but I'm not aware of a way to aim it -only- behind you.

[left]Here is the code that ive been tinkering with. i start with a wider sensor,then narrow it down with by using the llrotbetween function. its still unfinished and still needs work,but thought id offer up what ive got so far in case it might help anyone
[/left]

               float rotaim(vector vObjPos) {
 rotation rAim= llRotBetween(llRot2Fwd(llGetRot()), llVecNorm(vObjPos - llGetPos()));
 vector vAim=llRot2Euler(rAim);
 return llFabs(vAim.z);
 }
               

then inside the sensor event i compare the aim with a global fGunAim=.05

               sensor(integer num_detected){
       float fAim;
       for (x = 0; x < num_detected; x++){
       fAim=rotaim(llDetectedPos(x));
       if (fAim < fGunAim) pow(); //its a hit
       }
     }

sorry for the poor formatting,my 1st post with code and dont know the the tricks of it yet. the more i tried the worse it got rofl

Since math calculations seem to be the way to go, how well do you think this would work:

1. Sensor sweep in a forward arc.

2. Using llGetCameraPos and llGetCameraRot, define a mathematical line representing the avatar's line of fire (from his eyes). I've forgotten most of my advanced math skills, so I'll need some outside help or research on this.

3. Determine which detected agent is closest to this line. See above statement about math skills.

4. Determine whether the line intersects that agent's bounding box. Again, math stuff.

I -think- the camera detection stuff should work in mouselook. If not, there are other more established ways of determining eye height and direction in mouselook.

Also, doing it this way means that the arc can be wider than I'd previously tried, allowing hits on closer targets.

1. Forward from the attachment pointing in the direction of the mouselook right?

2. Yeah this is possible.

3. Yep, possible.

4. Yeah... though easier I think to see if the line gets within a certain range of the target.

Couple of issues:

You could have avatars A and B both be in the line of sight, B further away and closer to the line. Then B would be hit rather than A, which seems wrong.

Having a wider sensor arc may not be good - as Ziggy said, you could hit the 16 detected limit. It'd also slow things down always checking lots of avs.

I built a mouselook targetting system recently that works pretty much along those lines - though it's really meant to find the closest target to one's forward vector, rather than ones intersecting the box.

You can get the distance from the targetted point to the appropriate point along the forward direction with some basic trig. The trouble with dealing with bounding boxes, though, is that IIRC they are not uniform, which makes the maths a lot more complicated (I was sketching this out at work today). I'd have to think about that a bit.

1. Yes, from an attachment while in mouselook, which for the purposes of scripting might as well be considered the avatar's hips.

If I do wind up using bounding boxes, I can have it determine which bounding box on the line of sight is closest to the sensor, having it disregard all others for the purposes of calling hits.

Also on the subject of bounding boxes, directed at both Seifert and Ordinal: I'd like to use bounding boxes rather than "distance from the line to an avatar's center" for the exact reason that avatars come in different shapes and sizes, which is something that would be difficult to approximate with any other method

Keep in mind that this won't be a rapid-fire sensor, so it should be less laggy than those constantly updating full-range HUD radars so many people wear. I don't imagine the sensor cone being more than 0.2 or 0.3 radians, anyhow.

If you want to be able to get people at very close range you'll need at least a PI/2 cone really; at least that's what I found.

I tell you what, if I work something out I'll post it up. I'm not promising anything though because (a) the whole thing is complicated by the fact that you have to rotate the box on the basis of the target's rotation as well, and (b) I am easily distracted.

Did I mention I can't express enough how much I appreciate the help I'm getting on this? I ought to take you all out to a Caledon pub for some virtual beers when it's done.

Hrm... How much do avatar bounding boxes really rotate, aside from on their Z-axis, and how extreme is the scale difference between their X and Y dimensions? This sounds like it might be a job for number fudging

I'm going to be working late tonight, but now I want to go run all kinds of bounding box experiments. Come on, weekend... get here sooner!

(edited for slightly more proper grammaticalness)

Yes, bounding spheres are much easier than bounding boxes (or bounding elliptical sphereoids for that matter).

So, who is going to write up the feature proposal for LL that moves the sensor origin to be aligned with the crosshairs when in mouselook? SOMETHING obviously needs to be done about this.

I'm just surprised that nobody has publicly tried to figure this out before. I guess there's a fine line between "convenient for other reasons" and "too much effort to be worth it".

I did a similar thing myself, except that my auto-aim scripting is in my bullets instead of my gun. It basically gets its velocity vector, becomes non-physical, looks at who's around, and figures out whose position is the closest to the line formed by following its former velocity vector. Whoever's closest to the line, if they aren't far away, is determined to be the target, and the bullet then *pops* to their location using warpPos. That's all done using fairly simple math.

My most advanced bullet script also observes the target for long enough to determine how much their position changes between each sensor check, how much they are rotating while moving (e.g. if they are going in circles), and their acceleration after rotation (in case they are speeding up, slowing down, etc), and then it attempts to *pop* to where they are *going* to be.

The purpose of the most advanced bullets is to be used to combat griefers, say, by removing them from the area.

Although these bullets can auto-target extremely well (and could be fired from a turret and informed to target a specific person, rather than determining who's closest to their path), and they can penetrate all shields with impunity, the ironic thing is that they can't really DO a whole lot to the target when they hit them. If it's a damage-enabled area, they can kill the target, but most places aren't damage-enabled. They can't push either, since most places are anti-push. They could spawn a metric [Censored!]ton of particles, but that doesn't do anything much other than annoy the target and anyone near them. Caging and escorting the target away is turning out to be rather more complicated than I expected. Making the cage rez high enough that it isn't penetrating the ground is tough, and if there is any furniture or other non-physical objects around, the cage gets stuck. And, shields can hold the cage down so it can't take the target away. Not to mention, if the griefer is sitting on a non-physical object in a non-damage-enabled area, there's basically nothing at all that can be done to them, as far as I can tell.