Jump to content

Lateral Aim Correction


Recommended Posts

This question regards bow weapons used in combat in Gorean sims.

I have a bow that has, as one of its features, "Lateral Aim Correction". As described by the vendor, when this feature is not enabled, the avatar's lateral motion (sideways motion of avatar with respect to the direction the avatar is facing), pushes the arrow sideways, causing the shooter to have to compensate aim for this. While this feature is enabled the claim is it is no longer necessary to compensate for this sideways push while aiming.

To understand this I created the attached velocity vector diagram, and did calculations in a LibreOffice spreadsheet file which can be downloaded from:

https://www.mediafire.com/file/w1a314s3ql6uwnu/1-1_Lateral_Correction.ods/file

The calculations are based on the arrow's ground speed is a constant 60 m/s.

The equation used is:

Val = Va sin( atan( Vl/Va ) )

Where:

  Val = Arrow lateral velocity component
  Va = Arrow velocity
  Vl = Avatar running speed.

For:
  Vl = 5.13 m/s
  Va = 60 m/s

The calculated result is:
  Val = 5.11 m/s

I did some In-World testing with some bow weapons. While running laterally I shot at a stationary avatar with Lateral Aim Correction off. If the arrow is shot while the crosshairs are at canter of the targeted avatar's hitbox from a distance of 60 meters, according to the above, that arrow should miss that hitbox center by 5.11 m. But this is not what I saw. Judging from a hitbox frontal width of 0.6 meters, the arrow missed by about 0.3 meters because it grazed the hitbox's side. 0.3 meters was confirmed when I shot when the crosshair was on the hotbox's edge, and got a hits near the hitbox center. I believe this 0.3 hitbox center has more to do with a bit of lag between a left mouse button click, and arrow rez. This seemed to be confirmed with shots done at 30 m.

I appears to me that the arrow flight path is already where aimed when shot even without "Lateral Aim Correction" in effect, and the avatar's lateral motion does not introduce a lateral velocity component.

I did testing with Lateral Aim Correction enabled, and could not see what difference it made.

I am interested in hearing from weapon developers, and others who have detailed knowledge of this, about why I did not get the expected result, and what benefit, if any, "Lateral Aim Correction"  has.

 

1:1 Lateral Correction.png

Link to comment
Share on other sites

http://wiki.secondlife.com/wiki/LlRezObject

as far as I can see, the claim that

10 minutes ago, agentronin said:

avatar's lateral motion (sideways motion of avatar with respect to the direction the avatar is facing), pushes the arrow sideways,

is itself hogwash, and there is no need for a "lateral aim correction" to fix a problem that doesn't exist. it's just a mind trick.

  • Like 1
Link to comment
Share on other sites

When I have built something like that into systems, I have added a random llApplyImpluse to the projectile's script, or have simply added a bit of randomness to the llRezAtRoot velocity vector to make the projectile less predictable.  No fancy formula.

  • Like 2
Link to comment
Share on other sites

On 7/20/2021 at 8:58 AM, agentronin said:

I appears to me that the arrow flight path is already where aimed when shot even without "Lateral Aim Correction" in effect, and the avatar's lateral motion does not introduce a lateral velocity component.

I did testing with Lateral Aim Correction enabled, and could not see what difference it made.

I am interested in hearing from weapon developers, and others who have detailed knowledge of this, about why I did not get the expected result, and what benefit, if any, "Lateral Aim Correction"  has.

 

1:1 Lateral Correction.png

 

it depends on how the rezzer device is scripted. Specifically the velocity parameter of llRezObject

a quick example of a projectile fired from a moving vehicle/avatar simulating real world inertia

// rez a standard sphere, name it ball, make it physical
// put the sphere in the Contents of a standard box prim
// put this script into the box prim also
// touch the box prim
//
// when the region is runnning ok then
// the box prim will move
// as it is moving the ball on rez will be thrown up into the air
// and then fall back down onto the moving box prim
//
// the ball will follow a parabolic curve when observed from a stationary point
// and if we followcam the moving box the ball will appear to go straight up and straight down
// simulating how inertia works in the real world


integer hnd;
vector pos;

default
{
    state_entry()
    {
        llSetStatus(STATUS_PHYSICS, FALSE);        
        llSetRot(ZERO_ROTATION);
        
        pos = llGetPos();
    }

    touch_start(integer total_number)
    {
        llSetRegionPos(pos);
        llSetRot(ZERO_ROTATION);      
        
        // target some distance away on the Y axis for the box to move to
        vector target = <pos.x, pos.y + 20.0, pos.z>;
        hnd = llTarget(target, 1.0);        
        
        llSetStatus(STATUS_PHYSICS, TRUE);   
        
        llMoveToTarget(target, 4.0);
        llSetTimerEvent(1.0);
    }
    
    at_target(integer num, vector tar, vector pos)
    {
        llSetStatus(STATUS_PHYSICS, FALSE);
        llStopMoveToTarget();
        llTargetRemove(hnd);
    }
    
    timer()
    {
        llSetTimerEvent(0.0);
        
        // toss the ball straight up
        // the important thing here is to add the velocity of the ball to the velocity of the moving vehicle
        
        vector velocity = llGetVel() + <0.0, 0.0, 4.0>;
        llRezObject("ball", llGetPos() + < 0.0, 0.0, 1.1>, velocity, ZERO_ROTATION, 0);            
    }
}

 

Edited by Mollymews
tyosp
Link to comment
Share on other sites

On 7/20/2021 at 12:48 AM, Rolig Loon said:

When I have built something like that into systems, I have added a random llApplyImpluse to the projectile's script, or have simply added a bit of randomness to the llRezAtRoot velocity vector to make the projectile less predictable.  No fancy formula.

The thread starter mentioned Gor which can be pretty competitive when it comes to combat. I don't think anyone would enjoy finding out that there is randomness added to their bows while other bows are more precise. You could argue that it might make sense if everyone were using a bit of randomness in their scripts. But there would also be arguments against it. A can of worms.

Edited by Noelle Delaunay
  • Sad 1
Link to comment
Share on other sites

7 minutes ago, Noelle Delaunay said:

The thread starter mentioned Gor which can be pretty competitive when it comes to combat. I don't think anyone would enjoy finding out that there is randomness added to their bows while other bows are more precise. You could argue that it might make sense if everyone were using a bit of randomness in their scripts. But there would also be arguments against it. A can of worms.

Fortunately, I have never scripted anything for Gor.  In fact, it's the farthest thing from my mind.  ;) 

Link to comment
Share on other sites

4 minutes ago, Noelle Delaunay said:

The thread starter mentioned Gor which can be pretty competitive when it comes to combat. I don't think anyone would enjoy finding out that their bow has randomness added to their bows while other bows are more precise. You could argue that it might make sense if everyone were using a bit of randomness in their scripts. But there would also be arguments against it. A can of worms.

yes

with combat arenas then is important that all the players are using the same combat arena weapons system.  The safeguard for this is that a projectile launched by non-system method doesn't register as valid (is invalidated) by the combat arena system

the use of random can be built into the system to simulate atmospheric resistance, typical of weather systems. For example, wind gusts and rain should affect the velocity of an arrow. Tail wind should push the arrow to move faster lengthening its range. Headwind slow it down lessening its range. Side wind resistance should cause the arrow to drift.  A wet bow string should reduce the velocity of the arrow. And so on

these can all be calculated and encoded into the velocity parameter

can be quite sophisticated to do all this, and can be quite challenging for the players to master weapons in these kinds of systems, but some players quite enjoy the challenge that these systems can impose

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Mollymews said:

and can be quite challenging for the players to master weapons in these kinds of systems, but some players quite enjoy the challenge that these systems can impose

It's a very complicated topic. There are 3 big issues that immediately come to my mind when it's about making a weapon more realistic / more challenging to use.

1) Don't forget that there are a lot of users from outside of the US. When you make a weapon more difficult to use, for example, instead of the projectile being registered in a splash radius it needs to hit directly, it's getting fun and challenging for someone with a latency of 50ms. But for someone with a latency of 200ms it's getting ridiculous in comparison, especially when you put those 2 players against each other.

2) There are often multiple weapon types involved. Making one weapon more realistic/challenging could mean literally nerfing it. Combat may be shifting towards other weapon types instead, creating a new meta. Which can be good or bad.

3) The more challenging you make a weapon, the more predetermined roles will be. Someone with a bad computer, with a bad latency, with a bad aim is more likely to lose against other players. In my opinion the gap between the best skilled and the worst skilled players shouldn't be made as big as possible if this combat is still based in a roleplay scenario.

Link to comment
Share on other sites

18 minutes ago, Noelle Delaunay said:

It's a very complicated topic. There are 3 big issues that immediately come to my mind when it's about making a weapon more realistic / more challenging to use.

1) Don't forget that there are a lot of users from outside of the US. When you make a weapon more difficult to use, for example, instead of the projectile being registered in a splash radius it needs to hit directly, it's getting fun and challenging for someone with a latency of 50ms. But for someone with a latency of 200ms it's getting ridiculous in comparison, especially when you put those 2 players against each other.

2) There are often multiple weapon types involved. Making one weapon more realistic/challenging could mean literally nerfing it. Combat may be shifting towards other weapon types instead, creating a new meta. Which can be good or bad.

3) The more challenging you make a weapon, the more predetermined roles will be. Someone with a bad computer, with a bad latency, with a bad aim is more likely to lose against other players. In my opinion the gap between the best skilled and the worst skilled players shouldn't be made as big as possible if this combat is still based in a roleplay scenario.

i don't disagree with any of this, they are all valid considerations when owning a combat arena. Considerations which begin with: Who is theintended audience for the combat arena I own ?

if we intend it to be easy-to-use, easy-to-gain-proficiency and is intended for casual fun then we can ignore things like inertia and resistance, and make all our weapons accordingly. Basically every non-scripted physical projectile behaves as if it was launched from a stationary platform. More basically every projectile behaves like a bullet. No matter if is a bullet, an arrow, a missile, a snowball, or a couch

doing this is fine and quite a lot people prefer easy-to-use

a similar situation is with boats.  Some people prefer boats that drive like cars.  Some other people like yachts drive like power boats. And others like yachts that sail like yachts according to the design of the yatch within the vagaries of the built-in weather system

 

Edited by Mollymews
eit mro
Link to comment
Share on other sites

8 minutes ago, Mollymews said:

Considerations which begin with: Who is theintended audience for the combat arena I own ?

For sure. In Gor you have the added complexity that there are pretty much many combat arenas (if a sim may be called this way), owned by different people, connected to each other. "What does my audience want?" becomes a "What does my group want?" and combat becomes politics. The perfect example for politics was, what I had mentioned before, the progression from arrows hitting in a splash radius to hitting directly. Which wasn't done because it's more realistic but because it gave more combat related groups more advantages.

Link to comment
Share on other sites

Noelle, i get what you mean about the drama that can sometimes come with differences between parcel owners and their patrons, particularly when the owners and players conversations can descend into purity arguments over a genre

i think tho from a arena creator perspective then we set all this aside and make our arena system in a way that works for us , our story, our narrative, and then say this is it and who wants to play on the arena as we have designed it

sure we can accept feedback from our players on how to improve the offering, but the thing is that as the person paying the tiers (when nobody else does or will) then we have to be happy every time we login to our parcel. As when we aren't because purity drama then we better off shutting the place down and make/rez something else that makes us happy to login to

 

  • Like 2
Link to comment
Share on other sites

The physics engine might be disregarding what it considers "negligeable quantities". As an test, try firing arrows at targets with the wind and across the wind, and see if wind effects are being accounted for by the physics engine. If not, then I suspect low-velocity avatar sideways motion is also going to be disregarded.

Link to comment
Share on other sites

My aim is iffy enough that features like this make no difference. What I need are Homing Arrows. And in fact, I HAVE something like that. I have a .45 automatic, and one type of ammunition it fires are bullets that attack their designated target as long as the bullet and the target are in the same region.

 

  • Like 1
  • Haha 1
Link to comment
Share on other sites

19 hours ago, Profaitchikenz Haiku said:

The physics engine might be disregarding what it considers "negligeable quantities". As an test, try firing arrows at targets with the wind and across the wind, and see if wind effects are being accounted for by the physics engine. If not, then I suspect low-velocity avatar sideways motion is also going to be disregarded.

i haven't made anything like this since since the days of going to the public Weapons Testing sandbox 14 years about

where some of us used to make HUD-controlled battlebots and fight them

whiz the battlebots all round the sandbox trying to smash the other person's battlebot off the region with non-scripted projectiles, as it was seen in that circle as a bit lame to make tracking bullets. Just physical projectiles from cannons and blasters and stuff. Heaps of noise and particles and spent prims all over littering up the whole place til the temp on rez kicked in. Was quite fun to do this when younger person than I am now

as I remember I am pretty sure we have to script in the weather effects of the built-in linden weather system

using llWind and factoring this also into the velocity of the projectile rez and then once rezzed the projectile scripted to get its own initial velocity and then if is targeted to  go a long way then read llWind as it travels

Link to comment
Share on other sites

  • 1 month later...

Since starting this thread I have realized the diagram I posted is wrong. The arrow, when shot, does not pick up a lateral velocity component from the shooting avatar's sideways motion as it would in RL. The lateral correction compensates for the lag between mouse button click, and arrow rez time, by rezzing the arrow where the avatar was when the mouse button was clicked.

When the dynamic aim correction is enabled the arrow trajectory's point of origin is where the avatar was when the mouse button was clicked,

When the dynamic aim correction is disabled the arrow trajectory's point of origin where the avatar is when the arrow rezzes.

I do not know right now what happens to the trajectory's direction in either the enabled, or disabled, cases between the time instant the mouse is clicked, and the instant the arrow is rezzed, if in this time the mouse is moved on its pad, and so the direction the avatar faces is changed. It the mouse does not move, definitely the trajectory's direction is as aimed.

  • Thanks 1
Link to comment
Share on other sites

On 8/26/2021 at 4:28 PM, agentronin said:

Since starting this thread I have realized the diagram I posted is wrong. The arrow, when shot, does not pick up a lateral velocity component from the shooting avatar's sideways motion as it would in RL. The lateral correction compensates for the lag between mouse button click, and arrow rez time, by rezzing the arrow where the avatar was when the mouse button was clicked.

I haven't raided in Gor for years, so far as I know 'lateral correction' hasn't been a thing since the 'AC G3' bows back in 2008. Those bows held an incredibly tight trajectory, probably the next competitor in line were the iPwn bows which flew visibly wider, absent correction.

The point is, we did equally well with either bow because it's not the script making adjustments so much as the player's brain.

In a raid you wanted to fight from 60+ meters, it gave you ample space to maneuver and most weren't comfortable fighting from a distance. But the caveat is you have more to mentally process:

  • The arrows arc down over a distance, the further your target the higher you aim
  • When you have high latency, things aren't where you see them so you compensate by aiming ahead of your target
  • When you're moving side to side, your arrows have the effect of curling around so you aim to the side of your target
  • Simulator performance falters during raids, along with personal latency you're constantly, constantly adjusting for sim lag too
  • Lastly your target is also moving through evasive patterns and you're intensely tracking them to predict their position in 0.xx seconds to aim there

These are calculations you make every 0.7 seconds, with an arrow in flight you're already targeting for the next. And it literally takes months of sparing until muscle memory and instinct takes over. The payoff is, you're going up against multiple opponents and whether they have lower pings, higher FPS, lateral correction on bows, none of it matters. You're going to walk through them.

One European centric group I raided with around 2014 was alarmingly efficient, we all had high pings, some at 250-300ms, but, our communication and control over the battle meant 5 of us were routinely defending against 30-40 raiders. And that's the difference between SL Combat and FPS games like Counter Strike. SL Combat has a higher emphasis on prediction than directly aiming.

It's why bows with minimal scripting and no correction (like the VFX) are now preferred, because the mind is compensating and not the script. None of which matters any longer since Gorean raiding scene died a grizzly death years ago. But it was a thrilling PvP experience whilst it lasted.

 

On 7/22/2021 at 3:19 AM, Noelle Delaunay said:

For sure. In Gor you have the added complexity that there are pretty much many combat arenas (if a sim may be called this way), owned by different people, connected to each other. "What does my audience want?" becomes a "What does my group want?" and combat becomes politics. The perfect example for politics was, what I had mentioned before, the progression from arrows hitting in a splash radius to hitting directly. Which wasn't done because it's more realistic but because it gave more combat related groups more advantages.

For what it's worth, it was the casual groups who pushed for direct damage. Which I always found counter-intuitive since splash damage gave everyone a fairer chance.

  • Splash damage = 3.5m radius around the player's feet, landing an arrow within this circle damages them
  • Half-splash = 1.75m radius
  • Direct damage = Hitting the avatar directly

Initially a couple of GE groups switched to Half-Splash, which made for interesting raids but didn't grant them any particular advantage. Later, the LCS meter released in BTB sims and since it only supported direct damage, was seen as rebalancing combat in favor of melee weapons (this wasn't the case).

Regardless, I feel a lasting legacy of LCS was all sims eventually switched to direct damage only. Believing it would balance the field between competitive and casual groups, but in reality I think those with lower latency(US residents) benefited most from the change.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...