Pew! Pew! Pew! Linden Damage & Combat 2.0

[Rider Linden]

A few ground rules before diving in. 

First: I'm presenting this as a draft strawman design. The design I'm suggesting is not set in stone, no code has been written yet, and the design may change significantly as people give me feedback.

Second: This proposal deals only with a new damage system for Second Life. That is the only elephant that I'm putting on my plate for this discussion.  There are numerous other things that have been put on the roadmap for development, such as being able to adjust avatar hitboxes, additional options for sitting, and several others.  Let's address those in other threads. 

Third: This proposal is not meant to be a complete combat system on its own. I am convinced that you guys can build a better combat system than I can, and so, my goal is to provide the tools that allow you to do that.  (In other words the final product will have a big label that reads: "Batteries not included, some assembly required")

And with all that out of the way.

---------------------------

In Second Life there are a host of combat communities scattered across the grid. These communities use a wide variety of combat systems, HUDs and weapon systems. Some are completely custom, relying on scripts to arbitrate health and damage, while others are based on the Linden Lab Combat System(LLCS).

The goal of the Linden Damage & Combat2 project is to provide a coherent set of tools and systems that allow the residents to create complex and compelling combat systems using a common and easy to use framework.

Linden Damage 1.0, LLCS

(Will Remain Unchanged, but give a short TL;DR for it here)

Second Life wiki combat documentation:

• Combat
• Combat/Systems
• Weapons in Second Life

Linden Damage & Combat 2.0 (LLD&C2)

For backwards compatibility, LLD&C2 will not be enabled on regions by default. It must be enabled by the region owner.

New Concepts in LLD&C2

LLD&C2 introduces a couple of new concepts. Damage Types, Damage Limits, Regeneration Speed, Death Consequences, “Remote”(non-collision) Damage, and Damage Events.

Damage Limits

A damage Limits is the maximum amount of damage that may be delivered by any single hit on an avatar or prim. If the total damage delivered in a single hit exceeds this value, the actual damage delivered will be reduced to this amount. If the Damage Limit is set to 0 then damage is disabled.

Damage Events

Rather than a hit directly applying damage to an object or avatar in world, if a damage event (see on_damage() below.) is present in any script attached to an agent, this event will be called instead.

The event may modify the actual amount of damage being applied before it is applied to the avatar.

Damage Types

Damage Types are information passed along with a successful hit on an avatar or object. The intent is to allow combat systems to assign categories to the damage applied. In order to facilitate interoperability between combat systems Linden Lab provides a list of suggested combat types.

Death Consequences

LLD&C2 provides more options when an agent’s health drops to 0. The region owner may select from a number of options.
1 Teleport Home send the avatar to their home location. This is the same behavior as the old LLCS.
2 Teleport to Telehub. When an agent’s health falls to 0, they are immediately sent to the region’s Telehub.
3 Teleport to Land Point. Similar to being sent to a Telehub, the agent may be sent to the parcel’s landing point.
4 No action. The region will not attempt to reposition an agent reduced to 0 health.

The region owner may also set a brief period of invulnerability for avatars that are reduced to 0 health. During this time the agent may neither deal nor receive damage.

In any event, upon death the agent’s health is returned to 100%.

Griefer Protection

To protect against hostile land owners, if an agent is kill more than 5 times 30 seconds they will be offered the option of teleporting home, overriding any region settings.

Regeneration Speed

The region or parcel owner may specify the rate at which health is regenerated. The default is 1% per second. Setting this value to 0 will disable regeneration.

Remote Damage

Damage may be applied directly to an object or avatar without a collision with a damage enabled object (see llDamage() below.) Damage inflicted this way will only be applied if the target has a script with an on_damage() event in it.

LLD&C2 Features

Combat Event Log

Regions maintain a Combat Event Log that records all damaging events, damage adjustments and kills.
[details TBD]

Region & Parcel Additions

In damage enable regions & parcels a number of new options are available. The region owner may set the Damage Limit for the land and the overall Regeneration Speed on the region. They may also specify the action the simulator is to take when an agent reaches 0 health (see Death Consequences.)

The region may also toggle whether damage adjustments are allowed (see the llAdjustDamage function.)

The Damage Limit and Regeneration Speed may both be overridden on a parcel level.

Additionally, an agent’s current health is maintained during region crossings.

Script and Event Additions and Changes

New Events

on_damage

on_damage(integer count)

The on_damage event is fired in a script when an object receives damage from an outside source. Either damage delivered through a collision or through a call to llDamage() from a script. This event intercepts any damage about to be applied giving the script a chance to modify it. Once all scripts in a linkset have finished processing their on_damage events the damage is either applied to the attached avatar or distributed through the vehicle to all seated avatars. There may be up to 1632 damage events.

The following functions from the llDetected* family are available in the on_damage event.

• llDetectedGroup - TRUE if the damage was delivered by an object in the same group.
• llDetectedKey - The key for the root object delivering the damage. This object may have derezzed, especially in the case that the damage was delivered through a projectile.
• llDetectedLinkNumber - If the damage was delivered through a collision this is the link number that collided.
• llDetectedName - The name of the object delivering the damage.
• llDetectedOwner - The owner of the object delivering the damage.
• llDetectedPos - The last coordinates of the object delivering the damage. (In the case of a projectile the object will have derezzed.)
• llDetectedRot - The last rotation of the object delivering the damage. (In the case of a projectile the object will have derezzed.)
• llDetectedType - The type of the object delivering the damage.
• llDetectedVel - The last velocity for the object delivering the damage. (In the case of a projectile the object may have already derezzed.)
• llDetectedDamage - see new functions.

on_death

on_death()

on_death() is triggered when an agent’s health reaches 0. This can be used to trigger custom actions on death, such as a death animation or in conjunction with an experience to teleport the agent to a custom team respawn point.  This event is only triggered from an attachment.

New Functions

llDamage

llDamage(key target, float damage, integer type)

llDamage sends a damage event to the indicated object or avatar, triggering the on_damage() event. Target is the avatar or agent to damage, damage is the amount of damage being done and type is the type of damage that is to be applied. As with collision damage, negative values are treated as healing.

llApplyDamage

llApplyDamage(float damage, integer type)

If called from a vehicle or other prim with sitting avatars, this function transfers the damage to all seated avatars. If called from an attachment it will immediately apply the damage to the avatar bypassing any further on_damage events.

llGetHealth

float llGetHealth()

Returns the current health of the agent. This must be called from an attachment.

llDetectedDamage

list llDetectedDamage(integer number)

llDetectedDamage is only available inside an on_damage event. This function returns a list with the following information describing the damage.

[float damage, integer type, key deliverer, key owner, key rezzer, float original, integer modified]

• damage - The amount of damage delivered in the event.
• type - The type of damage delivered in the event.
• deliverer - The key for the object delivering the damage. This value is the same as the key returned by llDetectedKey()
• owner - The owner of the object delivering the damage. This value is the same as the key returned by llDetectedOwner()
• rezzer - The key for the object that rezzed the object delivering damage. If the object was rezzed by an agent this value is NULL_KEY. (should we add a llDetectedRezzer() function? It might be useful in general collisions)
• original - The original amount of damage that was delivered.
• modified - This will be TRUE if the damage amount was modified by llAdjustDamageAmount.

llAdjustDamageAmount

llAdjustDamageAmount(integer number, float new_value)

The llAdjustDamageAmount function is only available inside the on_damage event. This function allows the script to alter the amount of damage that will be applied. Any scripts that process their on_damage events after this script will get the new value.

If the region has disallowed damage adjustments this function has no effect.

Additions

llGetEnv

Several new values values are added to llGetEnv.

• "damage_limit" - The region wide damage limit.
• "regen_rate" - The speed of regeneration on the region
• "on_death" - The consequences of reaching 0 health.

llRezObjectWithParams

A new constant for setting damage type on a projectile.

• REZ_DAMAGE_TYPE - The type of damage delivered on a collision.

 

 

[Thunder Rahja]

Hello Rider,

Under the status quo, the new on_damage and on_death events will be extremely helpful in determining when damage is taken (vs a collision from a non-damaging object) and distinguishing teleports from health being reduced to zero vs experience or user-requested teleports.

However, without additional tools to moderate these new features (particularly llDamage, llApplyDamage, and llAdjustDamageAmount), I don't see my group switching to LLD&C2 as proposed. A relatively simple way of controlling these powerful functions may be to include an optional region setting that restricts these functions to a specified land-scope experience to allow the region owner's rules on damage amounts and adjustments to take precedence over the myriad of different scripters with varying opinions on combat.

[Grave]

Hey Rider, these changes are great!

As a long standing member of the combat community within SecondLife, I want to express great gratitude in giving us this chance to have a more complex system that will allow for much more variety in how we do combat in different sims.

I will 100% be enthusiastically calling for all combat sims to not only utilize this new system, but help with revisions to make it perfect for us, and all other communities that might benefit from using these new features in creative ways.

As for my input, if possible, I would like to have many of these features have their own toggles in land or estate options so that specific features can be present or disabled. So if someone doesn't want to utilize healing on their parcel for instance, negative damage could be unchecked.

Thanks again for this Rider! It will help us immensely. I am happily surprised.

[Dread Hudson]

Hi! I keep on missing all these meetings because I work too much, lol, I've been talking with Amalia Irata though via discord and they've relayed some of my thoughts and suggestions. I've been keeping up with the gist of the conversations being had regarding LLCS updates and "CD 2.0" at the very least. I think a lot of people need to realize that these changes aren't just for one community and will help open up using LL Damage across multiple communities that currently have to use a meter for damage types, healing, and custom death events instead.

For CD 2.0 teleport routing are we going to be required to use an experience? if so it might make sense to roll those features into experience, or at least the custom spawn points via CD 2.0. Anything damage mitigation related should have some limits though like only one attachment being able to call llAdjustDamageAmount, or there being an overall maximum for amount of damage adjustment being done per avatar. 

Applying damage via llDamage is concerning though because it doesn't seem very secure at the moment, at least with sending a prim out to someone to bonk them with damage doing anything beyond firing said prim from a gun requires an entry level of know how on communicating target key to damaging prim, i'd be concerned that making it as simple as rezzing a box, and doing while(0) { llDamage(person i'm mad at, 100, 0) } could lead to bad actors ruining the fun even more so than they already do. While yes, a sim admin can look at the combat log, the ease of griefing somebody with this may outweigh the benefits to simplifying damage passing.

llGetHealth(key id) or simplified llGetHealth() for owner only are both A+, having it fetch from a key would be nice functionality for any sims catering to a melee centric, not FPS, experience, as having a health bar (by fetching your target's HP) helps telegraph to new users what's going on, specifying llGetOwner() off of that is such a tiny extra step that I think it would be entirely worthwhile.

On llDetectedDamage though returning a list, I have to strongly discourage that, stick to the age old adage of KISS, keep it simple stupid, that function will be returning a bunch of jargon in sims that don't make use of CD 2.0 when it could be a simple integer returning instead for the raw damage. As documented in your post deliverer and owner are already handled by llDetectedKey and llDetectedOwner respectively, so thats two redundant fields, llDetectedRezzer and llGetRezzer would be immensely useful additions all around and would be absolutely worth adding as actual functions instead of a returning field. Right now we can get rezzer via llGetObjectDetails which handles llGetRezzer, but a llDetected* event for it gives you data that persists beyond the prim dying, which gives you the ability to have verbose hit reports regarding what weapon (llDetectedRezzer(n)) hit you with how much damage (llDetectedDamage(n)). I would also suggest a llGetDamage or llGetObjectDetails field for prim damage since now it's stored as a prim parameter.

[Grave]

Another thing I would like to add on this new system, is restricting certain developer / advanced admin tools that let people Wireframe or enable Hitboxes. If you could add a way to block those systems from being used with this new system or even just in base land settings, that would be great. Currently they are used to cheat / get an advantage in combat by many people.

Another combat related feature that would go well with that is also disabling minimap. If we had the option to disable minimap usage, it would open up a lot more immersive combat experiences. Being able to see where every avatar is at all times is fine, but having the option to try no minimap combat would be nice with everyone sneaking around.

[Thunder Rahja]

Dread made a handful of helpful suggestions, particularly about toggling which specific functions and features may be used to offer a tailored combat experience.

I would also like to add that, under the current system, 1% of health is regenerated every 6 seconds, so setting a regeneration rate default of 1% per second would not reflect previous behavior. If we could also change the health regeneration interval, that would be nice.

During the invulnerability period, disabling control events (and possibly also rez functions) would help to prevent recently killed residents from being able to continue firing or otherwise contributing to combat during their grace period.

The more options that land/region owners have, the better, I think. Having these combat options viewable by non-estate managers would also be helpful so that participants (or at least the party leaders) can know what to expect.

[Istauri Arai]

Hi Rider, a lot of these suggestions sound great.

One potential issue that stands out for me however is with the damage limit.

If damage is limited by putting a cap on damage per event this doesn't quite achieve the goal of reducing how quickly people are able to kill. Instead it incentivises people to maximise the number of events per shot and leads to either shotguns becoming the best damage dealing method or 32 stacks of remote damage being the new norm.

I would propose that instead of a % damage per event limit, a damage throttle be made where a max damage per second or frame (whichever is more appropriate) is set.

This way you could be being hit with the max 32 events worth of damage from spammy weapons or being hit with a stack of remote damage commands but still only take a reasonable amount of damage.

[Raideur Ng]

Truly an incredible and ambitious project and I appreciate all of it.

I agree that having a llGetDamage param makes sense. As to damage types and it being an integer, I'd be curious what you were planning for that.

I'd say a system with the most freedom and ability to create the kind of combat people want is ideal. As stated, this is not a system, it is a set of tools to create a system. The ability to abuse LSL has existed since someone first scripted exploding genitalia and it is up to the community, sim admins, etc to police that system. I hope everyone realizes this and we can get a powerful set of tools that we both create the systems we want, and also create means to police those systems and integrate that with existing parcel systems if we so choose.

[Delly Nayar]

Amazing proposal, and one I'm sure plenty of people will utilize and adore.

I think an additional option for parcel owners in addition to modifying the HP regen could be "Maximum HP" so sim owners could increase, or decrease the maximum HP an avatar can heal to. This could broaden experiences slightly more.

[Thunder Rahja]

1 hour ago, Istauri Arai said:

I would propose that instead of a % damage per event limit, a damage throttle be made where a max damage per second or frame (whichever is more appropriate) is set.

This way you could be being hit with the max 32 events worth of damage from spammy weapons or being hit with a stack of remote damage commands but still only take a reasonable amount of damage.

Theoretically one could prevent damage spam by using llAdjustDamageAmount within the on_damage event, based on the initial proposal.

Edited December 6, 2023 by Thunder Rahja

[BlackBlade Smit]

4 hours ago, Dread Hudson said:

Applying damage via llDamage is concerning though because it doesn't seem very secure at the moment, at least with sending a prim out to someone to bonk them with damage doing anything beyond firing said prim from a gun requires an entry level of know how on communicating target key to damaging prim, i'd be concerned that making it as simple as rezzing a box, and doing while(0) { llDamage(person i'm mad at, 100, 0) } could lead to bad actors ruining the fun even more so than they already do. While yes, a sim admin can look at the combat log, the ease of griefing somebody with this may outweigh the benefits to simplifying damage passing.

I agree with the idea that llDamage could be abused. perhaps it were tied to a single instance per event in the script, and maybe even tied to RayCast. I just see the opportunity for making a simple no rez combat system with this, which could open up all sorts of places for combat that would be fun. No rez would mean less lag, as well, and would minimize the rez queue issues we tend to have. Just my simple minded thoughts on the topic. I do like the concept as posted, for my desires, most of this would work well. But, yes, limiting llDamage from just being able to rez a box and scripting death for someone into it is a good idea. 

 

-EDIT-

 

I also think it would be nice to be able to override the no damage, or "Safe" selection in a parcel for you personally. So you could turn on damage for yourself in a non damage area. So you could feasibly opt-in to combat experiences in places that maybe you don't typically have combat, without making EVERYONE there take part. 

Also maybe remove the llDamage function if you do not have your damage on, so you can't send damage if you can't receive damage.

Another thing is you could tie that option to profiles or at least allow scripts to detect if you're damage enabled, so someone could have a HUD that detects potential combatants on sims. Could add a little cloak and dagger to the combat world, too. 

Edited December 6, 2023 by BlackBlade Smit
Had a good idea to add to my thought and edit was better than sending another comment.

[elleevelyn]

6 minutes ago, Thunder Rahja said:

Theoretically one could prevent damage spam by using llAdjustDamageAmount within the on_damage event, based on the initial proposal.

this is my understanding as well

this into addition to lllDetectedDamage in the on_damage event, we be able to filter out people/object owners who are not in our game, which pretty much eliminates the griefers, and also helps to eliminate random drive-bys, like shooting your team mate in the back for no reason other than that you can

the thing i like about this proposal is that it is going to be a toolkit that doesn't over-presuppose how any game should be played. Which makes it more useful for the widest number of games

[Quistess Alpha]

with the current implementation this could probably be implemented specifically in a script, but it might be nice to add support for a temporary 'damage ban' (a few minutes to a few days no access to the parcel in which the avatar died, same timeperiod for everyone set somewhere in land settings) after death: for some games, you might want "death" to have a longer or shorter "consequence".

[elleevelyn]

the more i think about how Rider Linden wants to go about this the more I like it. For example:

is lots of ways to make games but suppose we wanted character roles as a for instance

1) Make a group. Roles

role 1: Game owner     (Group Owner)
role 2: Game moderator (Group Officer)
role 3: OOC visitor    (Everyone)

leaves 7 character roles - group titles say: Wizard, Healer, Boxer, Shooter, etc

on_damage(integer number)
{   
      // is attacker in our group game ?
    if (llDetectedGroup(0))
    {  // yes they are
       
        // get the attack details
        list dets = llDetectedDamage(0);      
        float damage = llList2Float(dets, 0);
        key player = llList2Key(dets, 3);
        string bumper = llDetectedName(0);
        string role = llList2String(llGetObjectDetails(player, [OBJECT_GROUP_TAG]), 0));

       
        // say who and what they did
        llOwnerSay(title + " " + llGetDisplayName(player) + " bumped me with " + bumper + " inflicting " + (string)damage + " damage."
     }
     else
     {  // no they are not, so cancel that random person
        llAdjustDamageAmount(0, 0.0);

        // note: I am assume that llAdjustDamageAmount(integer number ...)
        // is the same as on_damage(integer number)    
     }
}

 

when I start think thru a proposal I tend to write some pcode and see how it might work/fit

[Wulfie Reanimator]

Just to repeat one thing that's been talked about regarding the on_damage event. There's two concerns about its side-effects.

How do we handle cases where scripts in separate attachments adjust the received damage in different ways? Although llDetectedDamage can give a script the original and currently adjusted amount, there will be unavoidable race-conditions from the script scheduler, and the different workloads in each script. The adjusted damage value can change after a script has checked it.

And now that all attached scripts must finish their event before damage is applied, it'll cause a delay before the avatar actually dies. That allows them to keep going and dealing damage even after receiving a to-be lethal hit. This can be caused unintentionally by the script scheduler or different workloads in each script, or intentionally with llSleep or a "do-nothing" loop.

I'd suggest a maximum time limit until a damage instance is applied. This isn't intended to prevent cheating, but rather to keep combat feeling responsive. The feature already kinda exists in detaching attachments; scripts are allowed a short amount of time to execute code in the attach() event, before the attachment finally gets derezzed. I don't know what would be a reasonable amount of time, but the concept seems solid.

Edited December 6, 2023 by Wulfie Reanimator

[Wulfie Reanimator]

13 hours ago, Raideur Ng said:

As to damage types and it being an integer, I'd be curious what you were planning for that.

The damage type is just an extra value that allows the receiving scripts to do something according to the damage type. On its own, it's just data and doesn't do anything.

For example, if you were a knight wearing plate armor, a script in your breastplate could reduce all Slashing damage you receive by some amount, but Puncture is unaffected. You could take it even further by having your armor lose durability and becoming less effective at reducing damage. Or the script could increase all damage without even looking at the damage type. Or the script could allow damage as-is, regardless of its type.

 

12 hours ago, BlackBlade Smit said:

I just see the opportunity for making a simple no rez combat system with this, which could open up all sorts of places for combat that would be fun. No rez would mean less lag, as well, and would minimize the rez queue issues we tend to have.

While no-rez style combat can work and be fun (I really like a sword-fighting system called CornerStone from 8+ years ago), the problem with long-range combat is the lack of feedback between players. How do you know someone is shooting at you from 100 meters away? Raycast weapons need to create some kind of visual effect on every attack, like a particle-trail (which requires rezzing), regardless of hit or miss.

Edited December 6, 2023 by Wulfie Reanimator

[Grave]

Adding to my input about an option to disable Advanced and Developer tools, as I am aware they are currently client side and might be hard to do a server side block, is there a way we can add a system that detects if someone has Hitboxes enabled? And if they have Wireframe enabled? Being able to see who does would give us the ability to at least deal with cheaters manually via admins. Kind of like being able to see who has show look at enabled. Then there would be no worries about having a no minimap option.

[Istauri Arai]

48 minutes ago, Grave said:

Adding to my input about an option to disable Advanced and Developer tools, as I am aware they are currently client side and might be hard to do a server side block, is there a way we can add a system that detects if someone has Hitboxes enabled? And if they have Wireframe enabled? Being able to see who does would give us the ability to at least deal with cheaters manually via admins. Kind of like being able to see who has show look at enabled. Then there would be no worries about having a no minimap option.

I'd take another look at the second ground rule Rider has put in place for the discussion here:

16 hours ago, Rider Linden said:

...

Second: This proposal deals only with a new damage system for Second Life. That is the only elephant that I'm putting on my plate for this discussion.  There are numerous other things that have been put on the roadmap for development, such as being able to adjust avatar hitboxes, additional options for sitting, and several others.  Let's address those in other threads. 

...

I'd imagine that client based anti-cheat solutions such as disabling wireframe and hitbox visibility are outside of the scope of what Rider's proposing with the new damage system and also very difficult to detect in a world of open source modifiable viewers.

 

Those alternate views (wireframe etc) aren't detectable or blockable currently without using something like RLV to disable them during an activity and would likely have to be part of an experience as they need the user to give consent for the restriction of their viewer. Extra combat relevant Information (hitboxes, avatar positions, look-at targets etc) are something the viewer needs to function so can't be withheld from the viewer by the server; once again I think that restricting parts of the viewer requires consent like with an experience.

A modified viewer would still be able to bypass these restrictions and fixing the issue in a satisfying way has complexities, I think it's outside the scope of LL Damage changes.

 

It would be good to have some better anti-cheat solutions, I'd suggest that you propose them again in the future when things are further along and possibly when a more combat related user group meeting may exist in the new year. You could also try writing up a jira feature proposal for it and maybe even starting up a new thread to discuss it!

[Istauri Arai]

12 hours ago, Thunder Rahja said:

Theoretically one could prevent damage spam by using llAdjustDamageAmount within the on_damage event, based on the initial proposal.

That's true but it then requires combat participants to agree on all using a mutual script when the main reason people use LLCS in the first place is that a lot of SL militaries that use it can't agree on a mutual script/system. A lot of them don't trust their opponents not to cheat with an open system, give themselves an unfair advantage with a closed system, or even agree on what a good system looks like. 

As a middle ground they instead rely on the solution handed down from on high aka from LL and LLCS where they can guarantee its mechanics are handled by a neutral higher authority. It also lowers the barrier to entry for joining in on this type of combat as all you need is an LLCS enabled weapon and you can join the fray.

 

So what you're saying is pretty great for when people are happy to use a mutual script; but there's not a lot to stop someone from using llAdjustDamageAmount to reduce damage to 0 with a low random frequency to hedge their bets and make it so the odd shot "totally missed honest", or even to just create a godmode toggle for themselves.

I imagine most SL military combat regions will disallow damage adjustment once again due to a lack of trust between attackers and defenders. A parcel/region level throttle is able to keep working independently of all of this without a scripted workaround and benefits both sides.

[Wulfie Reanimator]

6 minutes ago, Istauri Arai said:

So what you're saying is pretty great for when people are happy to use a mutual script; but there's not a lot to stop someone from using llAdjustDamageAmount to reduce damage to 0 with a low random frequency to hedge their bets and make it so the odd shot "totally missed honest", or even to just create a godmode toggle for themselves.

The combat event log is one avenue to help moderating things kind of thing, but yeah, my guess would be that the SLMC crowd would opt out of damage adjustments.

I don't think that's necessarily an issue, though. The SLMC is kind of a special case in its wild-westyness. The ability to adjust damage should be a useful feature in broader context, especially in closed systems where most of the potential pitfalls can be designed around.

[BlackBlade Smit]

2 hours ago, Wulfie Reanimator said:

While no-rez style combat can work and be fun (I really like a sword-fighting system called CornerStone from 8+ years ago), the problem with long-range combat is the lack of feedback between players. How do you know someone is shooting at you from 100 meters away? Raycast weapons need to create some kind of visual effect on every attack, like a particle-trail (which requires rezzing), regardless of hit or miss.

Making particle trails does not require rezzing. Rather than rezzing a prim and targeting that prim, have the particles come from the weapon barrel node and target the avatar or object the raycast is "hitting." I'm pretty sure that would work, would it not?

[Wulfie Reanimator]

31 minutes ago, BlackBlade Smit said:

Making particle trails does not require rezzing. Rather than rezzing a prim and targeting that prim, have the particles come from the weapon barrel node and target the avatar or object the raycast is "hitting." I'm pretty sure that would work, would it not?

What if you hit LL ground, or a sim border, or nothing at all (because of limited ray length)? There's nothing for particles to target there.

Maybe your target is in a large mesh room, and the particles from your weapon fly toward the center of that room instead of the wall behind your target (because particles can only move toward the center of objects).

Speaking of your weapon, if that's the source of your particle effect, the trail will move and wiggle around as your avatar moves around, which just doesn't look as good as a trail that stays on the trajectory of the ray.

Edited December 6, 2023 by Wulfie Reanimator

[Jager Burckhardt]

These are some excellent changes, and I think keeping backwards compatibility is a really big plus for folks who would like to play around with it but not commit 100% in their own sims until they develop satisfactory systems with these new tools, especially around moderation.

I know the details for the combat log are still on their way, but we'll definitely want the ability to search / filter that information to look through more easily, particularly if the person moderating a combat parcel doesn't know what things to look for in-world if a particular feature were to be abused, isn't script savvy, etc.

It would also be neat if folks other than land mods could have access to the combat log too, or at least the events which involve their avatar or (wishful thinking) folks with the same group tag. This way moderation could happen from both ends in the case where two or more teams are engaging in a combat event under their own respective Captains or Officers in Charge, and need to moderate their own team or make requests for the other team based on what's happening 'on the field'. Even for the purposes of giving users the ability to point out specific log entries for mods to investigate would be helpful, if they feel they're being abused or something fishy is going on.

Having parcel or estate-based granular toggles for particular features would be helpful as well, especially for things that folks are worried about being abusable / that they might not have tools to mitigate the abuse of, or that simply doesn't align with their intended use.

All in all, can't wait to see this develop further!

[Istauri Arai]

1 hour ago, Wulfie Reanimator said:

The combat event log is one avenue to help moderating things kind of thing, but yeah, my guess would be that the SLMC crowd would opt out of damage adjustments.

I don't think that's necessarily an issue, though. The SLMC is kind of a special case in its wild-westyness. The ability to adjust damage should be a useful feature in broader context, especially in closed systems where most of the potential pitfalls can be designed around.

I agree and I'm not at all opposed to the ability to adjust damage, I think it will be great in a lot of other cases and should go ahead. I do think we need to account for the fact that a rather large section of the people who still depend on LLCS wouldn't be able to make use of it though.

[BlackBlade Smit]

1 hour ago, Wulfie Reanimator said:

What if you hit LL ground, or a sim border, or nothing at all (because of limited ray length)? There's nothing for particles to target there.

Maybe your target is in a large mesh room, and the particles from your weapon fly toward the center of that room instead of the wall behind your target (because particles can only move toward the center of objects).

Speaking of your weapon, if that's the source of your particle effect, the trail will move and wiggle around as your avatar moves around, which just doesn't look as good as a trail that stays on the trajectory of the ray.

Sure, I mean, two things there. That's something that could be changed for one. Set particle location to the resulting area of a castray but even if not, that's not something I'd consider a deal breaker in combat. You don't get to see bullets flying by IRL, you do see them hit walls and such but that isn't a deal breaker. You could play the gun firing audio loudly, then have you're script scan the area for avatars within a certain range, or "near miss" range of the pathway and used llTriggerSoundLimited and play a zing sound around them personally so they hear it whiz by. Ultimately, a NoRez Combat meter not only can be done, it has been done with current systems, but creating a system off LL damage would be ideal Especially if you integrate the ability to opt into turning on damage for yourself anywhere. As I mentioned in my previous post.