Precision aim with llSensor in mouselook

Well, I don't really worry too much about that aspect. In fact almost all of my weapons for sale use standard damage-enabled physical bullets (or some obscure damage variant, like killer bees). I rather assume that if someone wants to play, they are going to be doing it on damage-enabled land, though I have a few other options around. The "proper" weapons I have don't even look like guns; in fact they're all HUDs (and I don't sell them).

To be honest, I don't know off-hand, but if somebody has wings, say, and they turn side-on to you, it shouldn't be as easy to hit them as if they were facing you.

I would like to make perfectly clear that the combat system I am designing is going to be compatible ONLY with the system itself, and will not have any effect on non-participants (except for the usual visual and audio effects weapons produce).

The reason I'm so focused on a sensor-oriented system is severalfold:

1) When a sensor hits something, it doesn't miss. Physical bullets have a tendency to either pass through targets or not fire their collision events.

2) Sensors don't directly affect anything they hit, making it impossible to "sensor grief", unless maybe you had hundreds of them running at once. (edit: causing lag)

3) The system I'm writing will have a "do it yourself" component to it that I wish to be as compact and secure as possible. Having rezzable bullets will open the system to abuse and complicate the process of adapting third-party weapon models.

4) It's just so darn elegant, novel, and pretty of a solution, don't you think?

Really I'm only concerned with an avatar's true bounding box, via llGetBoundingBox or whatever that function is. I'm about 75% sure attachments don't alter that (I've seen some pretty huge avatars clip through ceilings unhindered). This could cause some problems for things like macro-avatars and non-standard shaped avatars, but I don't even want to think about the complexity of calculating the size of someone's attachments.

Bounding boxes on avatars:

X and Y dimensions are always identical, nothing changes them. Z dimension is altered by the height of the avatar, but the range isn't that much. The bounding box is not altered by animations, so you are as tall sitting down as you are standing up. Things like tinies are made with animations, so as far as the bounding box is concerned, the bounding box is about twice as tall as the av appears. Attachments change nothing. Since avatars only really rotate on the Z axis, so does the bounding box (I think, haven't checked this for sure if one is sitting on something rotating). In short, bounding boxes don't do much. This may all change when the new avatar stuff comes in.

New avatar stuff? Got a link?

Aha! This is the case I had hoped for. It'll make things just that much simpler, even if it's just a drop in the ocean.

To be honest it's much quicker if we assume that the bounding box is actually a bounding cylinder. That way you just have to check the distance on the XY plane, and the distance on the Z-axis, and don't have to bother with rotation.

I've just knocked up a little script which should do that, similar to the other one that I did, but I should test it first.

A bounding cylinder would make more sense, but unfortunately there is no llGetBoundingCylinder function. I suppose a fixed radius and the avatar height function will suffice for this purpose.

My test code gets a radius and a height from the bounding box function by assuming that the width of the bounding box is the diameter of the cylinder.

Ah, that works.

Incidentally, happy "OneWebDay", everyone! Whatever that is...

http://www.wikihow.com/Celebrate-OneWebDay

Thanks Seifert. I had seen that post, but didn't make the connection between that and the current bounding box behavior.

ok dumb qestion
asuming im trying to cause dammage to an av
even if the bounding box it "outside" of the av in the case of minis and micros
if i shoot the bounding box will it still register dammage
or do the physics only aply to the "visible" part of the av
furthermore llGetPos
is that getting a different position
than llGetBoundingBox

Just so you know, what we're trying to accomplish in this thread doesn't actually involve damaging another avatar in the normal sense. That said here's an answer to your question:

For all intents and purposes (at least those involving physics), the bounding box represents the "physical" avatar. What you see is just a visual model, and no matter how elaborate an animation may be, it doesn't affect the position of your bounding box. In order to do damage using the built-in combat system, you will need to hit an avatar's bounding box with a physics-enabled prim that has been set using the llSetDamage function. (You used to be able to do damage just by hitting someone with any physical object, but that seems to have changed.)

Also, llGetPos should detect the center of an avatar, whereas llGetBoundingBox defines two corners of an avatar's bounding box.

Er, any news on this topic? I started to try it on my own, but then I realized my mathematical education has relocated and not left a forwarding address. I got a C minus in calculus for nothing!

Oh, I got it working a few days ago, I think I mentioned it, didn't I? Hold on, I'll have to log in to grab the script.

// Forward sector avatar intersect
// Ordinal Malaprop
// 2006-09-22

// Should report the first avatar whose bounding box "sort of"
// intersects the forward vector of the toucher, adjusted for eye level.

// An assumption is made for simplicity that the box is actually a
// cylinder; this won't make any real difference in practice.

default
{
   touch_start(integer n)
   {
      llSensor("", NULL_KEY, AGENT, 96.0, PI_BY_TWO);
   }

   sensor(integer n)
   {
      // Adjust position for eye level
      vector mypos = llGetPos() + <0.0, 0.0, 0.75>;
      // Current forward vector
      vector fwd = llRot2Fwd(llGetRot());
      integer f = 0;
      key target = NULL_KEY; // key of identified target
      do {
         key id = llDetectedKey(f);
         // This returns a list; we assume the avatar has
         // a bounding box that is symmetrical about their axes
         // and calculate its size based on the maximum corner.
         // Diameter of the "cylinder" is based on width.
         list box_list = llGetBoundingBox(id);
         vector pos = llDetectedPos(f);
         vector box = llList2Vector(box_list, 1);
         // Nearest point along the forward axis to the target's
         // position
         vector nearest = fwd * (fwd * (pos - mypos)) + mypos;
         // Find the distances of this from target pos on the XY plane
         // and the Z axis
         float z_diff = llVecMag(<0.0, 0.0, nearest.z> - <0.0, 0.0, 
pos.z>);
         float xy_diff = llVecMag(<nearest.x, nearest.y, 0.0> - <pos.x, 
pos.y, 0.0>);
         llOwnerSay("Checking " + llDetectedName(f) + " @ " + (string)pos + ", nearest pos " + (string)nearest + ", z_diff=" + (string)z_diff + ", xy_diff=" + (string)xy_diff + ", box=" + (string)box);
         if (xy_diff <= (box.y + box.x) / 2 && z_diff <= box.z) {
            // projection of forward vector within box
            target = id;
            llOwnerSay("Hit " + llDetectedName(f));
         }
      } while (++f < n && target == NULL_KEY);
      if (target == NULL_KEY) {
         llOwnerSay("Missed");
      }
   }

   no_sensor()
   {
      llOwnerSay("Nothing here, you fool");
   }
}

The above responds to touch, so if you put it in a prim and point that prim's forward axis at someone it will work. I think. The sensor() event is the important bit. Anyway, it works as far as I remember.

Nitpick:

llOwnerSay("Hit " + llDetectedName(0));

Should be:

llOwnerSay("Hit " + llDetectedName(f));

oh, well, you know, things happen

You did indeed mention it, but you were rather busy testing a gigantic weapon at the time so didn't press the issue.

Also, THANK YOU, ORDINAL! I believe I officially owe you a favor now, as should the rest of the LSL development community.

Since oft times the simplest solutions are normally left out I figured I'd toss this out there...

You could always make it where (assuming it's a gun-like weapon system) that they AV goes prone (laying down) to shoot, in which case their hips would follow the same line of sight as their eyes and should make for pretty accurate shots.

I have a few ships I've found that use this method for their combat systems...also to make the ships smaller.

While this would be simple and effective in vehicle-based systems, it would kind of take the magic out of a gunslinging atmosphere. Imagine, if you will:

Two rival gunslingers face each other down from opposite ends of the street, each ready to draw when the clock strikes noon. The minute hand clicks into place, the clock strikes and...

...both combatants crumple to the ground and go into sniper poses with their six-shooters.

Also, I think their hitboxes would still occupy the same "standing" space, so aiming gets kind of funny. Also because of this, unless "prone" winds up placing the avatar's eyes at hips-level, we'll have the same problem as before with the viewpoint being offset from the avatar's true position, only this time below it instead of above.

this is for a hud/tag based damage system similar to one i made half a year ago, it is a simple concept after you spend too much time fooling with sensors, dont want the sensor from your hips? use it in a non-primary prim. with the right prims you could even simulate recoil like i have been.

Good point! I'd forgotten about the non-root bit. However, if I use a non-root prim to fire the sensor, that means I lose the advantage of having the sensor fire in the direction that the avatar is looking, no?

One other disadvantage is that due to the conical nature of sensor sweeps, it will be either:

1) Ridiculously easy to hit things at long range.

2) Ridiculously hard to hit things at short range.

The mathematical line method eliminates the aim problem, and isn't as dependent on having a tight sensor beam, so it doesn't need to be mounted directly on an avatar's eye.

That said, I'm not particularly familiar with how non-root based sensors work when in a HUD, but I'd love to find out. If not the hips, what position do they use as a point of origin?