SL features for combat gameplay.

[animats]

There was some discussion today at Server User Group about what LSL and viewer features would help weapons and combat gameplay.

Bullets are a problem. If you rez as temporary as fired, they may take time to rez. If you rez before firing, temporaries may time out before being fired.

There's a sizable delay which seems to be applied randomly. Scripts in bullets add overhead and take a while to start. Old style interpreted scripts seem to start faster than Mono scripts.

Bullets which are particles aren't detectable as hits, so, not too useful.

One of the Lindens suggested "llProjectile", or some way to designate a prim as a projectile. It's just the ability to shorten the maximum lifetime on a temporary object and delete on collision start without a script. This would allow scriptless bullets, higher rates of fire, and fewer duds. At last, More Dakka. With a reasonably modest change.

But nobody at Server User Group this week was a combat sim expert. Who can comment about this? Some people from that community are needed at Server User Group and Creator User Group. There seems to be some receptivity to features in that direction right now.

On visual quality, we're already there.

It's a way to get more gamers into SL. SL will never be a great FPS, but it can be an OK one.

[Love Zhaoying]

I know your first post is mainly about Bullets, but is it OK with you if we also discuss (in this thread) other "LSL and viewer features would help weapons and combat gameplay"?

Edited November 23, 2022 by Love Zhaoying
Added ("in this thread") meant here, not discuss at the meeting!

[Wulfie Reanimator]

12 hours ago, animats said:

But nobody at Server User Group this week was a combat sim expert. Who can comment about this? Some people from that community are needed at Server User Group and Creator User Group. There seems to be some receptivity to features in that direction right now.

When are the next couple SUGs scheduled, or where are the schedules listed? I could try to attend, if not get some currently active developers to come as well.

 

12 hours ago, animats said:

One of the Lindens suggested "llProjectile", or some way to designate a prim as a projectile. It's just the ability to shorten the maximum lifetime on a temporary object and delete on collision start without a script. This would allow scriptless bullets, higher rates of fire, and fewer duds. At last, More Dakka. With a reasonably modest change.

This sounds interesting and maybe worth iterating on. A standard bullet does a couple more things, here's an example: (specifically a bullet, this script does not apply to special cases such as low-velocity throwables, missiles, or projectiles with special effects at the point of impact such as visible explosions.)

default
{
    state_entry()
    {
        llCollisionFilter("", llGetOwner(), FALSE);
        llParticleSystem(bullet_trail); // bullet trail (ribbon particle)
        llCollisionSound("", 0);
        llSetDamage(100);
        llSetStatus(14, FALSE); // status_rotate_x/y/z
        llLoopSound("whizzing in the air", 1);
    }

    collision_start(integer total_number)
    {
        llSetStatus(STATUS_PHANTOM, TRUE);
        llSetStatus(STATUS_PHYSICS, FALSE);
        llTriggerSound("impact", 1);
        llDie();
    }

    land_collision_start(vector no)
    {
        llSetStatus(STATUS_PHANTOM, TRUE);
        llSetStatus(STATUS_PHYSICS, FALSE);
        llTriggerSound("impact", 1);
        llDie();
    }
}

 

• The state_entry event is triggered before the projectile is put into a weapon. It does not trigger again when the projectile is rezzed.
• Projectiles in SL will often run the risk of hitting the person who created it, especially when running forward while firing. (Always Run is the standard in SL Military Communities (SLMC))
  • Bullets are rezzed a few meters in front of the avatar, because bullets must be fairly long (usually 5 meters) due to high velocity and low physics framerate.
  • They can't be too far, otherwise you can't hit someone close to you (and that's why melee weapons are also worn as a backup).
  • When there's significant sim lag, the avatar may end up bumping one end of the projectile and hit themselves.
• Sometimes, in high-fire-rate weapons, bullets will filter each other instead, so they don't detect collisions with other bullets rezzed at the same location.
  • Projectiles can't ignore collisions with both, the owner's avatar and other projectiles. This is not ideal, since two people firing at each other can block each others' projectiles.
• Many projectiles use a particle system as a visual indicator of the projectile, not all projectiles are very visible on their own.
• The same goes for sound, it's more conductive to combat when you can hear you're being fired at, but only a single "impact" sound should be heard.
  • The default collision sound is disabled because it's client-side and the projectile may collide multiple times before disappearing.
  • Some projectiles use a different sound for hitting an avatar instead of something else.
• Physical rotation of the projectile is disabled to prevent it from becoming a "spinning blade of death" or wildly bouncing around after colliding something.
  • That's why the script also enables phantom and disables physics on collision. These may not happen immediately due to sim lag and event overhead.

There are so many more bullet points (pun not intended...) I can keep adding about physical projectiles, but those are the reasons for the lines in that script.

 

To summarize, if the goal of a function like llProjectile is to enable scriptless bullets, I think these features are absolutely essential before anyone would consider it a viable option in the LL Combat System (LLCS), in order of priority:

• Set a damage value.
• Cause the object to be deleted on collision, while allowing a sound to be played.
  • Disable physics/collisions after the first collision, if deleting the object can't happen in the same frame.
• Disable physical rotation of the projectile.

Doing just those things alone might not get us to a "scriptless bullets for most" situation, but if llProjectile used a list of properties (similar to llSetPrimitiveParams or the Vehicle Functions), it could be expanded over time with more configurable values (such as everything in the above script's state_entry).

 

This may be unrelated, but rezzing is still required for mostly the same reasons even in the case of raycast weapons. Improvements to this would definitely help, since the SLMC have been really hesitant to adopt raycast weapons due to balance issues and how difficult they are to implement due to llCastRay time budgets and actually damaging the target. (There's no "remote damage", we can only rez prims with llSetDamage.)

• If a raycast weapon hits an avatar, a "kill prim" must be rezzed, which is usually rezzed somewhere out of the way, and has to find out which avatar was hit by the weapon. This is usually done in two ways:
  1. The on_rez parameter includes the beginning of the target's key. The bullet will then llGetAgentList and search for the first match and set its position to that avatar's location. This is usually done in a loop to ensure the prim collides with the target, because sim lag may let the target move out of the way if the prim is too small (and if it's too big, it may hit someone else near the target).
  2. The prim has an open listen channel, and receives the full key of the target so it doesn't have to search through every avatar. I prefer this method, since it's simpler to implement and there is a technique which ensures the rezzer does not send the key until the prim's script is ready, without two-way-communication.
• If a raycast weapon doesn't hit an avatar, there must be some way to indicate your shot, because it's not fair that you get to shoot at someone without them knowing about it.
  • An invisible, non-physical, phantom prim is rezzed in front of you.
  • This object uses a ribbon particle (and emits the first particle where it rezzed).
  • This object is very large (64m for example) because particle visibility is based on the scale of the source. This allows people far from it to see the particle effect.
  • This object moves to the point of impact of your shot via llSetRegionPos, plays the impact sound, and stays there until a timer event triggers llDie in a few seconds.
  • The result is a visible ribbon particle stretching across the entire path of your shot, acting as a visual and aural indicator to the opponent.

Another thing that's sorely missing is support for negative values for llSetDamage. There's no way to apply healing without custom scripting, so 100% damage is the standard for LLCS.

Edited November 23, 2022 by Wulfie Reanimator

[animats]

4 hours ago, Wulfie Reanimator said:

When are the next couple SUGs scheduled, or where are the schedules listed? I could try to attend, if not get some currently active developers to come as well.

Simulator User Group is every Tuesday at noon SLT in Denby. Creator User Group is alternate Thursdays at 1 PM in Hippotropolis. Here's the official SL calendar. Creator User Group is mostly viewer-side issues, right now mostly puppeteering, rendering, and uploading.

4 hours ago, Wulfie Reanimator said:

A standard bullet does a couple more things...

That's useful. Try to boil what you need down to a simple plan. Don't overdesign. The simulator side is hard to work on and fragile, so it's very hard to get LL to make significant changes.

[Lucia Nightfire]

In regards to aesthetics, just holding a rifle correctly currently requires a specific body shape and/or adjustments since we do not have IK support.

This is just one of many applications where IKs are needed, particularly, script compilable, target key/bone, offset pos/rot, weighting and point/line/plane constraint inputs along a keyframe timeline.

• Skeleton A bone to skeleton A bone
• Skeleton A bone to skeleton B bone
• Skeleton bone to object/attachment key

[Wulfie Reanimator]

2 hours ago, animats said:

Simulator User Group is every Tuesday at noon SLT in Denby. Creator User Group is alternate Thursdays at 1 PM in Hippotropolis. Here's the official SL calendar. Creator User Group is mostly viewer-side issues, right now mostly puppeteering, rendering, and uploading.

That's useful. Try to boil what you need down to a simple plan. Don't overdesign. The simulator side is hard to work on and fragile, so it's very hard to get LL to make significant changes.

Yeah, it was a pretty big info-dump on the what/why. That's why I added a summary.

llSetDamage is not a prim property and requires a script, so llProjectile must be able to handle that.
And when a damage prim hits an avatar, it never exists beyond that frame. Getting that behavior for any collision is ideal.

There would still be a need for scripts in bullets, but this would reduce a lot of jank from common bullets.

Edited November 23, 2022 by Wulfie Reanimator

[animats]

2 hours ago, Wulfie Reanimator said:

There would still be a need for scripts in bullets

Why? The idea is to reduce the overhead associated with rezzing a bullet.

[Wulfie Reanimator]

46 minutes ago, animats said:

Why? The idea is to reduce the overhead associated with rezzing a bullet.

A projectile should not be able to collide with its owner in combat, or other projectiles (especially those rezzed by the same source).
For that we have to use llCollisionFilter in the bullet, but even that function it can't prevent collisions with projectiles and the owner at the same time.
A high rate of fire is meaningless if the projectiles cease to exist when one is rezzed on top of another.

A projectile should not be able to turn into a boomerang when it bumps into something, like another projectile (whose collision is filtered).
For that we use llSetStatus with STATUS_ROTATE_X and STATUS_ROTATE_Y and STATUS_ROTATE_Z set to false.

llSetStatus is an object property, so you'd have to put a script into the projectile and then delete it. Having this set by llProjectile would be a convenience.

Edited November 23, 2022 by Wulfie Reanimator

[animats]

47 minutes ago, Wulfie Reanimator said:

A projectile should not be able to collide with its owner in combat, or other projectiles (especially those rezzed by the same source).
For that we have to use llCollisionFilter in the bullet, but even that function it can't prevent collisions with projectiles and the owner at the same time.
A high rate of fire is meaningless if the projectiles cease to exist when one is rezzed on top of another.

A projectile should not be able to turn into a boomerang when it bumps into something, like another projectile (whose collision is filtered).
For that we use llSetStatus with STATUS_ROTATE_X and STATUS_ROTATE_Y and STATUS_ROTATE_Z set to false.

llSetStatus is an object property, so you'd have to put a script into the projectile and then delete it. Having this set by llProjectile would be a convenience.

OK, so all those things are properties you want to set when the projectile is rezzed.

What this is starting to look like is that we need a call like llRezObject with a list of initial properties. That would have other uses, and probably isn't too hard to do. Then there's no delay waiting for script startup before the properties turn on, and no waiting for script launch.

Useful test: try unscripted vs scripted bullets. Do unscripted bullets rez faster and more reliably? If so, this is worth doing.

Edited November 23, 2022 by animats

[Istelathis]

Perhaps expanding upon the particle system would lead to bullets being unnecessary to begin with, with my hope of giving us the ease of raycast weapons without the lag of hundreds of scripted bullets flying through the air. In addition, those particle effects would be adjustable via the viewer to help users with slower computers from lagging out.  Most of the visual effects would take place client side, although llCastRay would probably have to be expanded upon to have a more accurate methodology to pinpoint where those particles (complete with sound effects)arrive at.  Shooting at a 64 meter wall, should hit (or rather send particles)in the general direction you have your weapon pointed at. 

Edited November 23, 2022 by Istelathis

[Wulfie Reanimator]

1 hour ago, animats said:

OK, so all those things are properties you want to set when the projectile is rezzed.

What this is starting to look like is that we need a call like llRezObject with a list of initial properties. That would have other uses, and probably isn't too hard to do. Then there's no delay waiting for script startup before the properties turn on, and no waiting for script launch.

Exactly. 🙂 There is quite a bit of shared desirable behavior for all basic damage bullets (or even arrows, throwing knives, etc.), which could be standardized into this purpose-built function.

1 hour ago, animats said:

Useful test: try unscripted vs scripted bullets. Do unscripted bullets rez faster and more reliably? If so, this is worth doing.

The main problem with bullets is generally not the speed at which they rez initially (we don't need to get into the topic of rez-queue), but rather that the objects won't de-rez on collision (because the script which calls llDie takes a while to start up, and can only execute code when the script scheduler allows it).

Edited November 24, 2022 by Wulfie Reanimator

[animats]

2 hours ago, Wulfie Reanimator said:

but rather that the objects won't de-rez on collision

Ah. Now that's the sort of info LL needs. Flushing dead objects out of the system fast is considered a good thing by the simulator devs.  They're concerned about tying up resources.

Somebody in the SL armaments business might try a dakka test. Try scripted vs nonscripted bullets, and fire off a clip, fast. See what breaks.

Visuals work fine. but can you hit anything?

[animats]

OK, so suppose we had a rez function with a list of prim properties that are applied when the object is rezzed. This is based on the scripts above. The idea is to set up all those properties as part of the rez, rather than starting a script on rez. This would both reduce script start overhead and make sure those properties are turned on at rez. Useful if you need to shoot someone at short range. So, how does this look?

Function: llRezObjectWithParams( string inventory, vector pos, list rezparams, integer param);

Rezparams cover the things people do in bullet scripts. These are all optional.

• REZ_VEL vector         // initial velocity
• REZ_OMEGA vector // initial rotation speed, for spinning axes, chakras, etc.
• REZ_ROT quaternion // initial orientation
• REZ_ACCEL vector // acceleration
• REZ_LIFETIME float   // delete after this long seconds
• REZ_DAMAGE float // apply this much damage on hit
• REZ_SOUND string // play on rez
• REZ_LAND_COLLISION_SOUND string // play if hits land
• REZ_COLLISION_SOUND string // play if hits something else
• REZ_DIE_SOUND string // play when object dies
• REZ_SOUND_VOLUME float //  volume for collision sounds
• REZ_FLAGS integer // see below

Useful flags:

• REZ_FLAG_TEMP // rez as temporary
• REZ_FLAG_PHYSICS // rez as physical
• REZ_FLAG_PHANTOM // rez as phantom
• REZ_FLAG_COLLIDE_OWNER // can detect collision with owner (turn off if bullet might hit owner going out)
• REZ_FLAG_DIE_ON_COLLISION // rezzed object self-deletes on collision

Does that cover everything a bullet needs to do in SL?

 

[Wulfie Reanimator]

1 hour ago, animats said:

OK, so suppose we had a rez function with a list of prim properties that are applied when the object is rezzed. This is based on the scripts above. The idea is to set up all those properties as part of the rez, rather than starting a script on rez. This would both reduce script start overhead and make sure those properties are turned on at rez. Useful if you need to shoot someone at short range. So, how does this look?

Function: llRezObjectWithParams( string inventory, vector pos, list rezparams, integer param);

Rezparams cover the things people do in bullet scripts. These are all optional.

• REZ_VEL vector         // initial velocity
• REZ_OMEGA vector // initial rotation speed, for spinning axes, chakras, etc.
• REZ_ROT quaternion // initial orientation
• REZ_ACCEL vector // acceleration
• REZ_LIFETIME float   // delete after this long seconds
• REZ_DAMAGE float // apply this much damage on hit
• REZ_SOUND string // play on rez
• REZ_LAND_COLLISION_SOUND string // play if hits land
• REZ_COLLISION_SOUND string // play if hits something else
• REZ_DIE_SOUND string // play when object dies
• REZ_SOUND_VOLUME float //  volume for collision sounds
• REZ_FLAGS integer // see below

Useful flags:

• REZ_FLAG_TEMP // rez as temporary
• REZ_FLAG_PHYSICS // rez as physical
• REZ_FLAG_PHANTOM // rez as phantom
• REZ_FLAG_COLLIDE_OWNER // can detect collision with owner (turn off if bullet might hit owner going out)
• REZ_FLAG_DIE_ON_COLLISION // rezzed object self-deletes on collision

Does that cover everything a bullet needs to do in SL?

Yup, something like this would be tremendously useful! It should be enough to get rid of scripts in most cases and for the vast majority of rezzed projectiles/bullets.

[Amalia Irata]

22 hours ago, animats said:

OK, so suppose we had a rez function with a list of prim properties that are applied when the object is rezzed. This is based on the scripts above. The idea is to set up all those properties as part of the rez, rather than starting a script on rez. This would both reduce script start overhead and make sure those properties are turned on at rez. Useful if you need to shoot someone at short range. So, how does this look?

Function: llRezObjectWithParams( string inventory, vector pos, list rezparams, integer param);

Rezparams cover the things people do in bullet scripts. These are all optional.

• REZ_VEL vector         // initial velocity
• REZ_OMEGA vector // initial rotation speed, for spinning axes, chakras, etc.
• REZ_ROT quaternion // initial orientation
• REZ_ACCEL vector // acceleration
• REZ_LIFETIME float   // delete after this long seconds
• REZ_DAMAGE float // apply this much damage on hit
• REZ_SOUND string // play on rez
• REZ_LAND_COLLISION_SOUND string // play if hits land
• REZ_COLLISION_SOUND string // play if hits something else
• REZ_DIE_SOUND string // play when object dies
• REZ_SOUND_VOLUME float //  volume for collision sounds
• REZ_FLAGS integer // see below

Useful flags:

• REZ_FLAG_TEMP // rez as temporary
• REZ_FLAG_PHYSICS // rez as physical
• REZ_FLAG_PHANTOM // rez as phantom
• REZ_FLAG_COLLIDE_OWNER // can detect collision with owner (turn off if bullet might hit owner going out)
• REZ_FLAG_DIE_ON_COLLISION // rezzed object self-deletes on collision

Does that cover everything a bullet needs to do in SL?

 

This relates to SVC-5716, SCR-213, SVC-6641, SVC-1606 and SCR-191 which were all opened over a decade ago. Most of them, rather ironically, were also closed at the start of this same month. These have been long-requested features with a plethora of partial workarounds. If LL is going to finally take action, that's great, but it's confusing to see related function requests closed almost immediately before this came up.

In order to accomplish having a truly no-script projectile, it seems clear that a large number of settings need to shift towards being primitive parameters. At that point, it would be extremely useful to expand upon the options in a prim/object's build menu to let us set these options without needing to use script functions in either the projectile or the rezer.

That being said, while everything in this thread would apply perfectly towards rapid-rez projectiles like bullets, there are other edge-cases like projectile explosives which will still require having a script. While these are typically only rezed in smaller numbers and tend to have larger delays between projectile dumps, we need to ensure that there's still compatibility going forward. The major differentiation from a standard bullet is the usage of a series of commands on collision. For example: Disable physics, rez child object(s) for damage and/or visual effects, llSensor, llCastRay, llParticleSystem (for a duration rather than a single burst). While you won't typically see all of these in the same projectile, you'll certainly see various combinations. The child prim(s) that are rezed may also use similar combinations. Even then, this assumes the projectile in question is dumb-fire. There are a number of munitions (such as missiles) that may employ functions on a timer to change the rotation/velocity mid-flight, or to continually get the position of a target if it's locked on to something (like a jet).

As far as viewer enhancements, you're likely to spark a rather lively conversation as to what's considered "fair". A great example is the evolution of the "Combat Features" options currently available in a number of TPVs. In the early days, this would render arrows over all avatars within a certain distance, regardless of their position relative to you. This quickly led to having markers that told people precisely where to shoot at to hit people through a wall. It was eventually changed so that arrows would only be rendered for people outside of your current FOV; arrows will show around the edges of your screen while in mouselook to indicate that you need to turn. If someone comes into the screen space (even if while behind a wall), their arrow goes away. Another example of a combat feature that came and went, was in the form of automated mass-teleports. Someone could keybind a teleport offer command to send teleports to any number of people simultaneously, but the viewer would also automatically send a teleport request to anyone who sent an IM simply saying "tp".

I think a lot of people would like the ability to set a custom crosshair in the viewer, though. Doesn't need to be anything more fancy than supplying a texture UUID or a local file path. I can see applications for this outside of the combat community as well.

Edited November 30, 2022 by Amalia Irata
Additional clarification

[Vesca Starlight]

I'm not the most apt with forums but I'll try to give some insight...

As someone who currently is developing content for both LLCS (the in-built system used by the SLMC) and VICE both commercially and for groups/commission I can pretty well say that the idea of "bullets are a problem" is kind of wrong if you script them properly. Perhaps if you follow conventions of 2008 or overload them with complexity you'll be having issues with lag and reliability but for the most part nowadays (and especially after the AWS switch) not even homesteads run into lag issues when 20 people are slinging prims, the exceptions being when folks are doing the former and using old poorly scripted/outdated things.

Regarding raycast its also a matter of preference and backwards compatibility, like with VICE we can't effectively move to RC even to "wallsafe" explosives (so they don't kill through stuff) because its a closed system with its limitations and physical rounds are 100% needed, in LLCS wallsafe stuff is the norm. On the matter of preference RC is direct point-to-point (literally drawing a line and seeing what you hit) and has a few caveats such as an inability to simulate very minor drop in munitions due to line of sight (I personally give pistols a bit more drop to reduce effectiveness at range while rifles have a flatter trajectory) and the fact that the scripting for raycast guns is significantly more complicated due to the need for clamping your end point to the sim edge or it will fail 90% of the time, which requires a lot more math than basically anything you are doing on a prim gun. Combined with the other caveats Wulfie mentioned its a good idea on paper but in practice it will gatekeep even harder than the current need-to-knows are with scripting for the community today.

Lastly I will point out that most scripters in the SLMC and SL in general tend to be a clever lot and a lot of the issues have been resolved in one way or another, better scripting practices means bullets reliably delete and the sim doesn't lag, I personally do a velocity factored rez offset so I can rez under one meter ahead and not run into my bullets by just increasing the distance based on my current speed so that tends to also a non-issue.

Also fun fact bullets are usually at least 4.5-5 meters long because of some fun math revolving around simulator framerates and collisions, you need 1 meter of bullet for every 50m/s of speed with a little over just for reliability sake. This is because a bullet at 200m/s will travel 4.4-ish meters (200 divided by the simulator FPS of 45) per frame and thus check to see if its collided with an object, its also why you should never press your avatar against cover unless its at least that thick.

[Thunder Rahja]

2 hours ago, RyokoTensaki said:

As someone who currently is developing content for both LLCS (the in-built system used by the SLMC) and VICE both commercially and for groups/commission I can pretty well say that the idea of "bullets are a problem" is kind of wrong if you script them properly. Perhaps if you follow conventions of 2008 or overload them with complexity you'll be having issues with lag and reliability but for the most part nowadays (and especially after the AWS switch) not even homesteads run into lag issues when 20 people are slinging prims, the exceptions being when folks are doing the former and using old poorly scripted/outdated things.

Allow me to chime in here, Ryo. While this is true for most cases, collision events may take more than a few frames before the script can call llDie, especially when there are many other scripts firing events at the same time in a full homestead region, causing delays in even well-written scripts. The difficulty with that is that while avatar collisions with prims containing llDamage are handled instantaneously, collisions with land and objects is not, and so it is common for bullets to bounce off of surfaces or even stop completely before making contact with an avatar, resulting in death when it would not have happened in a full sim with 100% "scripts run" in the statistics window. Having collisions with land and objects handled as quickly as collisions with avatars would be a huge plus, not just for homesteads but for full regions under strain as well.

On 11/23/2022 at 5:24 AM, Wulfie Reanimator said:

• Sometimes, in high-fire-rate weapons, bullets will filter each other instead, so they don't detect collisions with other bullets rezzed at the same location.
  • Projectiles can't ignore collisions with both, the owner's avatar and other projectiles. This is not ideal, since two people firing at each other can block each others' projectiles.

llCollisionFilter affects only collision* events and has no impact on llDamage. Objects configured to ignore collisions with their owner but are assigned more than 0 damage with llDamage will still be able to damage their owner on unsafe parcels.

Hitscan (a.k.a. "raycast") weapons are much more varied in their detection and delivery methods than what you described, but yes, that is also an area of improvement. If, instead of just a number, we could pass a string to a rezzed object as its rez param, it would eliminate the need for communication between a projectile and its rezzer and potentially reduce events per second in a combat region.

Edited November 30, 2022 by Thunder Rahja

[TimKoul]

In no way whatsoever will Second Life ever be considered an "ok" fps platform in the gaming community. It's good for clowning around but that's it. 

[Wulfie Reanimator]

2 hours ago, TimKoul said:

In no way whatsoever will Second Life ever be considered an "ok" fps platform in the gaming community. It's good for clowning around but that's it. 

If you have nothing to contribute, don't. Whether or not Second Life compares to modern shooters is irrelevant to what's being discussed here.

[Love Zhaoying]

Animat's title and much of the OP was broadly about "combat" in SL. I didn't see a reply to my ask "can we discuss something besides bullets", so here goes!

Is there any plan for (more/better) "hand-to-hand" weapon combat support? I realize hand attachments have a non-deterministic location due to animations..

Here's a "for instance". What if, a) an attachment (weapon or shield) expanded your avatar's bounding box, and b) an edge/area of the expanded bounding box could be associated with the attachment?

And then, c) if you could detect collisions of those bounding box areas associated with the attachment (weapon or shield), that may provide a method to detect the collision of an attached weapon with another avatar (or their attachment "shield")?

[Amalia Irata]

7 minutes ago, Love Zhaoying said:

Animat's title and much of the OP was broadly about "combat" in SL. I didn't see a reply to my ask "can we discuss something besides bullets", so here goes!

Is there any plan for (more/better) "hand-to-hand" weapon combat support? I realize hand attachments have a non-deterministic location due to animations..

Here's a "for instance". What if, a) an attachment (weapon or shield) expanded your avatar's bounding box, and b) an edge/area of the expanded bounding box could be associated with the attachment?

And then, c) if you could detect collisions of those bounding box areas associated with the attachment (weapon or shield), that may provide a method to detect the collision of an attached weapon with another avatar (or their attachment "shield")?

Devil's advocate here, but what's to stop people from attaching a megaprim either by their own intent or by a potentially malicious experience? There would need to be limits to the collision box modifications, certainly.

[Katherine Heartsong]

16 hours ago, RyokoTensaki said:

Also fun fact bullets are usually at least 4.5-5 meters long because of some fun math revolving around simulator framerates and collisions, you need 1 meter of bullet for every 50m/s of speed with a little over just for reliability sake. This is because a bullet at 200m/s will travel 4.4-ish meters (200 divided by the simulator FPS of 45) per frame and thus check to see if its collided with an object, its also why you should never press your avatar against cover unless its at least that thick.

This part is cool but that's slow for a real world bullet.

The muzzle velocity, for example on the NATO standard 1980s rifle (in my case, the FNC1A1), is 2,650 feet per second, or over 800m in a second. That means 16m bullets. Are these velocities slowed down because it's SL?

Edited November 30, 2022 by Katherine Heartsong

[Amalia Irata]

7 minutes ago, Katherine Heartsong said:

This part is cool but that's slow for a real world bullet.

The muzzle velocity, for example on the NATO standard 1980s rifle (in my case, the FNC1A1), is 2,650 feet per second, or over 800m in a second. That means 16m bullets. Are these velocities slowed down because it's SL?

Yep. Simulators clamp anything over 200 back down to 200.

[Thunder Rahja]

5 hours ago, Love Zhaoying said:

Is there any plan for (more/better) "hand-to-hand" weapon combat support? I realize hand attachments have a non-deterministic location due to animations..

Here's a "for instance". What if, a) an attachment (weapon or shield) expanded your avatar's bounding box, and b) an edge/area of the expanded bounding box could be associated with the attachment?

And then, c) if you could detect collisions of those bounding box areas associated with the attachment (weapon or shield), that may provide a method to detect the collision of an attached weapon with another avatar (or their attachment "shield")?

I think it would be really cool if animations and attachments had physics simulation, so that when you swing a sword, for example, anything (or anyone) in its visual path would be detected as a hit, rather than the common method of using a (relatively) short range sensor. However, this is a very expensive suggestion to implement and would drastically change not just combat but the entirety of Second Life avatar interactions. To my knowledge, avatar bounding boxes (as reported by llGetAgentSize and llGetBoundingBox) are based solely on height, with a fixed width and depth. Avatar physics shapes (measured using llCastRay and math) are another story altogether, but appear to be generally shaped like a pill.

1 hour ago, Katherine Heartsong said:

The muzzle velocity, for example on the NATO standard 1980s rifle (in my case, the FNC1A1), is 2,650 feet per second, or over 800m in a second. That means 16m bullets. Are these velocities slowed down because it's SL?

To hit a target 100 m away (a typical engagement range during LLCS combat) at 800 m/s, it would take 0.125 seconds, which might as well be no time at all once you take script delays in a busy combat region into account. Because of the roughly 200 m/s velocity limit, as Amalia describes, the closest method we have to real world bullet speeds is hitscan using math, and sensors, position/angle comparisons against all agents in the region via llGetAgentList, or purely raycast in the direction fired. I actually find the 200 m/s limit more enjoyable because it allows for some small reaction time to quite literally dodge a bullet that usually would do 100 damage. When using hitscan/raycast rifles (often one of Wulfie's), I aim very slightly ahead of a moving target to compensate for script/ping delays.

Edited November 30, 2022 by Thunder Rahja

[Love Zhaoying]

1 hour ago, Thunder Rahja said:

6 hours ago, Love Zhaoying said:

Is there any plan for (more/better) "hand-to-hand" weapon combat support? I realize hand attachments have a non-deterministic location due to animations..

Here's a "for instance". What if, a) an attachment (weapon or shield) expanded your avatar's bounding box, and b) an edge/area of the expanded bounding box could be associated with the attachment?

And then, c) if you could detect collisions of those bounding box areas associated with the attachment (weapon or shield), that may provide a method to detect the collision of an attached weapon with another avatar (or their attachment "shield")?

Expand  

I think it would be really cool if animations and attachments had physics simulation, so that when you swing a sword, for example, anything (or anyone) in its visual path would be detected as a hit, rather than the common method of using a (relatively) short range sensor. However, this is a very expensive suggestion to implement and would drastically change not just combat but the entirety of Second Life avatar interactions. To my knowledge, avatar bounding boxes (as reported by llGetAgentSize and llGetBoundingBox) are based solely on height, with a fixed width and depth. Avatar physics shapes (measured using llCastRay and math) are another story altogether, but appear to be generally shaped like a pill.

Yes! I know the "really cool" solution wouldn't probably fly so, didn't ask.