Pew! Pew! Pew! Linden Damage & Combat 2.0

[Rider Linden]

2 minutes ago, Lucidius Flanagan said:

 I dont see an llsethealth call just llgethealth but I may be missing something.

llApplyDamage(-100) would do it. 

[elleevelyn]

1 hour ago, Rider Linden said:

llApplyDamage(-100) would do it. 

is -100 a target for the region regen system to slave toward ? Or is it a constant apply ?

if is constant then we all pretty much be invulnerable. Example:

state_entry
{
   llApplyDamage(-100.0);
   llSetTimerEvent(1.0/45.0);
}

timer()
{
   llApplyDamage(-100.0);
}

 

 

[Cesar Goland]

1 hour ago, Wulfie Reanimator said:

All custom on-death and "revive" functionality could be done by setting the sim's Death Consequences to nothing, like Rider's proposal described. You could play death animations, disable controls, keep the avatar where it is, set their health to a specific starting amount, etc.

I wonder what should happen to health regeneration and on_damage events if an avatar's health is at 0... It would probably make sense to (optionally?) disable health regeneration for avatars at 0 health. Then again, someone had the idea of interpreting avatar health as "mana/energy/stamina" and not having deaths at all. I can't think of any real benefit for disabling on_damage events at 0 health.

 

For sure we could write a "revive" functionality by ourselves, however my question is about what would automaticly happen when health becomes 0, can we keep It zero (and what would be the consequences of it, like a person walking/shooting with 0 health)? It would be weird to control a "death state" manually while having your "health" meter restored to whatever happens after you die. Determining the "death" state should be consistent to what is displayed on the viewer

 

For instance right now on LSL Damage do our health is even displayed at 0%? (I never actually notice) but I know that when It is calculated to 0, we just get teleported home and health is set back to full

[Cesar Goland]

Maybe I am going a little more offtopic here, as I am thinking on using this system not only for combat, but also for a survival aspect, and having the "health" part be used more affected more than just "pew pew pew" (don't get me wrong, I also love the 'pew pew pew' part)

Personally one of the greatest things that happened to me here was the Experience update, creating a whole scenario and integrated system has become my favorite thing here. and pretty much that I am describing is already built using meters, but having these kind of integrations direct on Second Life's health system would be awesome in performance. Not having to deal with hud keys, managing listeners to deal with damage, dealing that much possible breachs that cheaters could try to use, all that would be simplified a lot with this framework.

Plus having bullets working direct with health without having to worry about exchanging chat messages for damage, or bullet description or whatever the "work around" method that we use for meters.

[Miles Doge]

I was told to drop my face into this thread to share an stretch of an idea i had swirling in my mind, which would allow for creating variation in how bullet behave with their defined damage amounts. I don't really know what it would take to have something like this done, but on paper, it sounds like it could be a great addition to many gun-slingers across the grid, and even bring about some additional suggestions to be added to the overall concept!

Before that though, let me start off by saying, the events & functions that have already been discussed thus far are QUITE exciting to read, and i do hope to see them in action!! I also do apologize if this is a suggestion that was already brought to mind previously in some way, as i (admittedly) did kind of excitedly read through the pages at the discovery of this thread. But without further ado, the idea in question:

Using llSetDamage() just as a basis of reference for the concept being presented here...what if we could define a list of BULLET_PARAMETERS that adjusts how a users bullets adjust its damage? Some very basic examples i can think of for this would be:

llSetDamage(float damage, list params); 

BULLET_DEFAULT //keep it at default! no fancy effects needed for the bullet.

BULLET_FALLOFF, float falloff_distance, float falloff_amount_per_meter(??) float max_fall_off

"float falloff_distance" would refer to how far the bullet needs to travel from its initial on_rez before beginning to take away from "float damage", using the defined "float falloff_amount". "float max_falloff" is the threshold the bullet is allowed to adjust its damage down to.

BULLET_CHIP_DAMAGE, float chip_amount, float chip_per_second(???), float chip_linger_time(???)

"float chip_per_second lets u define how quickly to chip health off the affected target using the "float chip_amount". "float linger_time" would refer to how long the chip damage takes from your health before stopping. As an additional fun note to BULLET_CHIP_DAMAGE, bullets that "heal" a target could also be used to immediately "extinguish" the lingering chip damage effect.

(A SLIGHT edit here for the sake of consistency with the presented example: "float chip_amount" would probably just use "float damage" instead if it were actually implemented under llSetDamage. I defined float chip_amount as its own separate thing, because i wrote this idea out under the assumption that the parameter would be under an entirely separate lsl function from that of llSetDamage)

These are just a few basic ideas i thought of off hand, but I'd love to see what further input it brings about!
 

Edited December 7, 2023 by Miles Doge
Slight explanation adjustment to bullet_chip_damage. oops

[Lucidius Flanagan]

11 minutes ago, Miles Doge said:

Using llSetDamage() just as a basis of reference for the concept being presented here...what if we could define a list of BULLET_PARAMETERS that adjusts how a users bullets adjust its damage? Some very basic examples i can think of for this would be:

llSetDamage(float damage, list params); 

BULLET_DEFAULT //keep it at default! no fancy effects needed for the bullet.

BULLET_FALLOFF, float falloff_distance, float falloff_amount_per_meter(??) float max_fall_off

"float falloff_distance" would refer to how far the bullet needs to travel from its initial on_rez before beginning to take away from "float damage", using the defined "float falloff_amount". "float max_falloff" is the threshold the bullet is allowed to adjust its damage down to.

BULLET_CHIP_DAMAGE, float chip_amount, float chip_per_second(???), float chip_linger_time(???)

"float chip_per_second lets u define how quickly to chip health off the affected target using the "float chip_amount". "float linger_time" would refer to how long the chip damage takes from your health before stopping. As an additional fun note to BULLET_CHIP_DAMAGE, bullets that "heal" a target could also be used to immediately "extinguish" the lingering chip damage effect.

These are just a few basic ideas i thought of off hand, but I'd love to see what further input it brings about!
 

this completely slipped my mind but was an idea I also shared. an easy way to handle damage falloff (damage reduced over time of flight) as well as other properties you mentioned could be super neat. Kinda goes against the llRezWithParams update to feature scriptless bullets but that's on each region/parcel to manage if it's worth the resource cost or not. Really dig this idea. Maximum damage and damage falloff rate as well as minimum damage is the foundation for most triple a shooters these days.

 

3 hours ago, Rider Linden said:

llApplyDamage(-100) would do it. 

Is this subject to the damage threshold or would there be a separate healing threshold? Dont want to just add a ton of ratchets to twist but just a thought that sprung to mind, otherwise this makes sense.

Edited December 7, 2023 by Lucidius Flanagan

[Miles Doge]

35 minutes ago, Lucidius Flanagan said:

Is this subject to the damage threshold or would there be a separate healing threshold? Dont want to just add a ton of ratchets to twist but just a thought that sprung to mind, otherwise this makes sense.

This was something that did cross my mind amid writing out the idea, but i wasn't entirely sure how it might be handled functionality side. All in all though, i don't see any reason not to allow healing bullets to function the same for being able to gradually drop their heal effectiveness!

Heck It could even be kinda funny to encounter a gun who's bullet could damage you one moment at a certain distance, and then suddenly adjust its numbers into a defined (negative) max_falloff, to heal someone the next.

 

Edited December 7, 2023 by Miles Doge

[Rider Linden]

41 minutes ago, Miles Doge said:

Using llSetDamage() just as a basis of reference for the concept being presented here...what if we could define a list of BULLET_PARAMETERS that adjusts how a users bullets adjust its damage? Some very basic examples i can think of for this would be:

llSetDamage(float damage, list params); 

BULLET_DEFAULT //keep it at default! no fancy effects needed for the bullet.

BULLET_FALLOFF, float falloff_distance, float falloff_amount_per_meter(??) float max_fall_off

[snip]

BULLET_CHIP_DAMAGE, float chip_amount, float chip_per_second(???), float chip_linger_time(???)

Interesting, I think I'd want to handle something like this through llSetPrimParams and llRezParams, but I like the concept.  The projectile would need to be able to track how far it had traveled from its rez point... but I believe it is doable. 

 

31 minutes ago, Lucidius Flanagan said:

Is this subject to the damage threshold or would there be a separate healing threshold? Dont want to just add a ton of ratchets to twist but just a thought that sprung to mind, otherwise this makes sense.

I think a healing limit could be added as well.  I'd do it as a region/parcel parameter. 

[Wulfie Reanimator]

1 hour ago, Miles Doge said:

BULLET_CHIP_DAMAGE, float chip_amount, float chip_per_second(???), float chip_linger_time(???)

"float chip_per_second lets u define how quickly to chip health off the affected target using the "float chip_amount". "float linger_time" would refer to how long the chip damage takes from your health before stopping. As an additional fun note to BULLET_CHIP_DAMAGE, bullets that "heal" a target could also be used to immediately "extinguish" the lingering chip damage effect.

"Damage over time" (DOT) and "healing over time" (HOT) are very commonly seen in games and would be really nice to have in a standardized way like this, instead of every dev making their own implementation. A set of damage/rate/duration parameters would be perfect.

One immediate question I have is "how will these stack?" As in, what happens if the same weapon hits the same avatar twice in a row? Should the avatar take double the damage over time, every hit adding an extra DOT? What if we don't want that, or get hit by multiple sources with different damage types?

Some games have a sort of "global timer" for over-time effects. For example, every second, all damage/healing over time gets accumulated (even if they have a faster rate) and dealt as one instance of damage, which is the total amount since the previous "tick." (This would be useful to avoid overflowing events.) Different damage types would be accumulated separately, so you can still differentiate damage types.

Damage stacking is often prevented completely. If the same source applies damage again, the duration is reset but the amount of damage per "tick" stays the same.

Edited December 7, 2023 by Wulfie Reanimator

[Miles Doge]

2 hours ago, Wulfie Reanimator said:

One immediate question I have is "how will these stack?" As in, what happens if the same weapon hits the same avatar twice in a row? Should the avatar take double the damage over time, every hit adding an extra DOT? What if we don't want that, or get hit by multiple sources with different damage types?

[--cut--]

Damage stacking is often prevented completely. If the same source applies damage again, the duration is reset but the amount of damage per "tick" stays the same.

Another very good question, and something i was hoping would be prompted to have others here input what they want to see, because depending on the weapon & person, one MAY WANT to continuously stack more chip damage... but at the same time, maybe someone else would like to have the option to not allow this from the receiving end or so forth.

Though personally, I'm on board for it functioning the way a friend proposed as an example, below:

Quote

"You stand in a fire, it does 25 damage over 3 seconds.  If you step back into the fire before the timer expires, the timer goes from whatever it is now, to 0 and restarts the 3 seconds once more."  "Basically relighting yourself."

 

 

 

Edited December 8, 2023 by Miles Doge

[elleevelyn]

8 hours ago, Wulfie Reanimator said:

"Damage over time" (DOT) and "healing over time" (HOT) are very commonly seen in games and would be really nice to have in a standardized way like this, instead of every dev making their own implementation. A set of damage/rate/duration parameters would be perfect.

i like this. As region/parcel settings then scripts applying +/-Damage cannot exceed the parameters (they can apply less tho). As you say it creates a standards-based system out-of-the-box

a parameter setting I wouldn't mind seeing is the maximum amount of +/-Damage that one player's scripts in total can apply to the same target per "tick"

[elleevelyn]

8 hours ago, Rider Linden said:

I think a healing limit could be added as well.  I'd do it as a region/parcel parameter. 

i vote for this

[Thunder Rahja]

Agreed. If there are limits on damage amount per hit, and damage/healing over time is added, then there should be a limit on how much damage/healing can be done per second and how long the effect can last, in region settings.

Edited December 8, 2023 by Thunder Rahja

[Vesca Starlight]

In relation to damage limitations one major concern I have with hard-setting such limits at a regional/parcel level would be when things are supposed to one-hit, stuff like for instance a tank's main gun vs infantry or a point-blank grenade explosion. I'm unsure if there will ever be a good solution to the problem but its very much a concern since due to experience I don't like the idea of (current) SL combat being a purely twitch-shooter-rifles-only affair when the fact it isn't as controlled an environment as most AAA games means client graphics lag or a myriad of other problems severely disadvantages some players over others on a purely technical level in such instances. I've brought up the issue in the past including in the JIRA where such limits were proposed (and IIRC accepted by LL).

A lot of my experience with combat in SL has been in combined arms gameplay (LLCS/VICE/etc), where vehicles are a major factor; and with the changes planned thats also a major section where myself and others are looking at potentially more commercial interests with making VICE vehicles and such functional in LLCS since we shouldn't need a full rescript and janky follower system just to make them work. One major concern I would have is someone limiting the damage cap for purely infantry-focus while still allowing vehicles, and the discouraging bad reviews or other matters from customers who are bothered their tank that rightfully should be effective is rendered ineffective by an abusive or just unaware combat area owner, a problem I've already seen simply by trying to balance things for fairness already.

I'm not trying to be overly negative but I do think a proper cost-benefit analysis should be given for every implemented feature to avoid unintended ripples and effects that might end up bringing a small amount of positives while overall negatively affecting or preventing access for a larger amount of people.

Edit: Fixed redundancy.

Edited December 9, 2023 by Vesca Starlight

[Quistess Alpha]

7 hours ago, Vesca Starlight said:

a tank's main gun vs infantry

The ability to have different limits for different damage types or different limits for attachments (and things rezzed by them) and non-attachments (and things rezzed by them) might be useful, but Idunno how easy to implement or if that would be too fiddly for land owners.

[elleevelyn]

following on from Quistess about different types of damage

dialogs with lots of environment settings can be disconcerting for the new person and is also true that they can be abused, but I don't think this should inhibit the experienced persons

a way to assist parcel/arena/map owners could be to allow damage environment settings to be set by parcel owner-only script. Something like: llSetEnvDamage(list environment). Knowing that the parcel/arena/map already has default Damage 2.0 environment settings obtainable with: list environment = llGetEnvDamage();

creatives can then either build wholely custom games which can be bought and mounted by a parcel owner. And in the game pack is a Damage Environment script which when rezzed sets up the parcel for the game

while at the same time groups like LLCS/Vice/etc could work together to standardise an environment setting script module for their activities. Work together in the same way head/body makers worked together to establish the universal neck standard. Such groups may/not reach a consensus on a standard, but the possibility that they might/could is available to them

get/set environment scripts also allow the arena to set up for different modes - like Social/Competition/etc which makes it easier to run an Event calendar. Damage/Healing scaled up/down depending on the event. While also realising that types of damage can not only be scaled, individual types can be disabled completely for an event also (Damage for this Type = 0)

for me there are two things of most importance

1) The ability for the parcel owner to set up their parcel/arena/map as they determine
2) Avoiding an arms race. Arns race kills everything, as device creators sometimes reluctantly, sometimes not, quickly scale their devices (no matter what they are) to full power to remain 'competitive' in the market. The arms race killed Damage 1.0 and it killed the Battle Orbs market. And I don't think is a good idea to set up Damage 2.0 to get killed

basic example: Arena is set up for 18th century sailing ship battle. Person turns up with a 20th century battleship. That battleship isn't going to outgun the sailing ships

is getting a bit long this post, so just like to add that when is only 1 continuum +/-Damage then is going to be tradeoffs. Is just a question of what they are. And parcel environment settings by type can help to distribute/balance the tradeoffs

edit add: for weapons makers reading they probably already worked out that their weapons would llGetEnvDamage() and script their weapon to behave accordingly

Edited December 10, 2023 by elleevelyn

[Madison Foyston]

I am not a scripter so I most ignorant of  some of the functionality of SL so please forgive me of that but I thought some additions to the system might make it more interesting.  On death consequences giving the player an options to choose where they spawn back in might be neat to add if the land owner provides multiple options.  Also it would be would be if we could teleport to certain objects or maybe a vehicle apon death.  I am also wonder if it be possible to have a durabillity system for attachement apart of this system with attachements having their own hp pool ? Apon reach zero the attachements will detach or stop working ?  

Would it be possible for damage categories can detect different body parts and do different damage depending on what body part you do ? 

I am wondering if for land owners to a set a white list of armaments that can do higher damage  then set for the region threshold ? 

 

[Quistess Alpha]

9 minutes ago, Madison Foyston said:

On death consequences giving the player an options to choose where they spawn back in might be neat to add if the land owner provides multiple options.

That should be possible with a bit of custom scripting and the new on_death() event

10 minutes ago, Madison Foyston said:

I am also wonder if it be possible to have a durabillity system for attachement apart of this system with attachements having their own hp pool ?

Yes, that should be possible with the current proposal.

12 minutes ago, Madison Foyston said:

Would it be possible for damage categories can detect different body parts and do different damage depending on what body part you do ? 

specific hit detection isn't really accurate due to animations being client-side, but using llDetectedPos() in the on_damage event should let scripts in attachments have a rough idea whether the damage might be to head/chest/legs.

20 minutes ago, Madison Foyston said:

I am wondering if for land owners to a set a white list of armaments that can do higher damage  then set for the region threshold ? 

My guess is probably not. AFAIK, it's not really possible to 100% identify if a given attachment even is a specific weapon; 'cheaters' could make a different weapon with the same name and creator as one in the whitelist.

[Arduenn Schwartzman]

On 12/6/2023 at 2:23 AM, Rider Linden said:

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)

Yes please. Much needed, to allow detection of projectiles that are rezzed by vehicles that are not owned by the driver/shooter. Since on_rez has a delay of 2 seconds now, projectiles currently don't have the time to rename themselves or otherwise adopt a unique source identifier other than the owner.

[Miles Doge]

On 12/9/2023 at 6:09 PM, elleevelyn said:

edit add: for weapons makers reading they probably already worked out that their weapons would llGetEnvDamage() and script their weapon to behave accordingly

As someone with a personal idea in mind to put together a seemingly harmless little drone (containing equally as lethal "combat modes" to fit & adapt to various situations), i VEEERY MUCH like how much this LSL could seamlessly fit into that idea! 

Edited December 11, 2023 by Miles Doge

[elleevelyn]

7 hours ago, Miles Doge said:

As someone with a personal idea in mind to put together a seemingly harmless little drone (containing equally as lethal "combat modes" to fit & adapt to various situations), i VEEERY MUCH like how much this LSL could seamlessly fit into that idea! 

or Myriad Manifestation Umbrella

i am not sure from the strawman proposal as to whether an object can do damage when not attached or when not a vehicle upon which an agent is seated

a good case can be made for this - NPCs, automated fighting vehicles/drones, obstacle course traps, etc

the case against is again arms race

a story from 2007 in another life. On Lime region on the border next to the olden days Plum Welcome Area was a small parcel where stuff could be rezzed. Back in those days there were quite a few clans into doing battle in public spaces - we were all 16-17 years  younger then so yanno

Plum was seen as a safezone - no shooting on Plum - people building, newbies opening boxes, etc.  Lime was considered neutral ground - a meeting place for the clans. Stand round, chat, socialise. General rule: No shooting til someone started it, some else retaliated, then it was all on

so one day somebody rezzed a soccer pitch. So a few of us started playing. Physical ball no script, run and bump the ball into the goal, bump the other players off the ball.  Simple game

one guy got miffed as he kept getting bumped off the ball so he starts shooting, nek minit is all on.  Orbiters, cagers, kickers, defenders and shields up all over. Some people ran for Plum, others sat down, and others just got into it, me included. My defender is rezzing a new instance of a battle orb auto-targeting whoever hit me and unloading on them as fast as it can rez. As are everyone else''s. Stuff all over the place - people getting mad on the voice.  People teleporting their friends and clan members to join the battle. Total mayhem

then a guy teleported in with two friends. First time I saw a blitzer. Which completely broke (obsoleted) every weapon ever built previously

so eventually word gets out about how blitzer works. So people start to make their own and we all now into MADD it seems. Which then pose the question: how do you beat a person with a blitzer ? Given that rezz is restricted to 0.2 secs per

one answer was to rez a heap of battle orbs/drones each of them blitzing away, but is inefficient.  So level up to a cluster blitzer. Link 31prims and rez as one object, and then unlink them on_rez. You shoot at me with your single blitzer bullet then don't miss, I am not going to miss ever

so too my point

should Damage 2.0 be even half-way decent (relative to other games) then for those of us from back in the day, we are not going to get into what we did then, mostly because we are now closer to 40 years old than we are to 20 years old. We grow up

but yeah, when you young then is all fun and games. Clanning up and pushing the platform to the max and beyond. And if Damage 2.0 is halway decent and the goal of it is to attract more people to Second Life and this happens then the young (and older hooligans who should know better) will come to play and push it to max

bump damage (collisions) can be controlled, rez limits and push/bump distance

the proposal as written doesn't have any controls over the application of damage. The thing is that we don't need to rez objects to apply Damage 2.0. Is purely a script function - same as llPushObject is, which is restricted

again I think that the ability to apply damage should not be cost free. So energy. Agents and scripted objects could (I think should) have an Energy allocation which depletes every time damage is applied. Energy can regen in the same way that Health does.

coupled with all scripts owned by the same agent can only inflict one lot of damage to the same target in the the 'tick'. llPushObject works similarly, we can shove as many llPushObject scripts as we like, but they don't apply more that one push  on the target

with Energy we can make a MADD weapon. One hit 100 Damage don't miss. But we can't fire off another one 0.2 seconds later when it takes 3 minutes to regen the energy to do so.

and with Energy we can have NPCs. drones, etc, knowing that they are not going to turn into a cluster blitzer

 

Edited December 12, 2023 by elleevelyn
31

[Cesar Goland]

On 12/11/2023 at 1:02 PM, Quistess Alpha said:

That should be possible with a bit of custom scripting and the new on_death() event

 

My concern here is that lets say that the user has a dialog to choose his spawn, but what state is their life on the moment his health reach 0 and until they clicks a dialog option? Would he be alive again waiting (taking more shoots while the person didn't choose a respawn point?)? These kind of situation was  why I suggested that we should be able to remain dead, so we can better control the dead consequences

[Quistess Alpha]

1 hour ago, Cesar Goland said:

My concern here is that lets say that the user has a dialog to choose his spawn, but what state is their life on the moment his health reach 0 and until they clicks a dialog option? Would he be alive again waiting (taking more shoots while the person didn't choose a respawn point?)? These kind of situation was  why I suggested that we should be able to remain dead, so we can better control the dead consequences

Right, at the moment, it would probably have to be set up so that they choose their spawn point before they die, at the beginning of a match or something.

ETA: or, when they die, they could be teleported to a non-combat 'lobby' area with a system for teleportation to the main combat area spawn points.

Edited December 13, 2023 by Quistess Alpha

[Lucidius Flanagan]

Just musing but would it be possible to change the velocities at which agents receive damage? Once you start moving too quickly you start taking like "fall" damage from bumping into the floor which has a hard cap on avatar movement speeds. Would it be possible without modifying the physics engine at all to change that property? Maybe some one wants to address the "verticality" of sl building by making severe falling damage, or people want to have agents sprinting across sims quickly without grating themselves on the cement like a cheese grater? 

 

This may be out of scope but just thought i'd mention it as these are hard caps intrinsic to ll damage that could be tweaked depending on the region's experience they are trying to foster/deliver.

[Thunder Rahja]

1 hour ago, Lucidius Flanagan said:

Just musing but would it be possible to change the velocities at which agents receive damage? Once you start moving too quickly you start taking like "fall" damage from bumping into the floor which has a hard cap on avatar movement speeds. Would it be possible without modifying the physics engine at all to change that property? Maybe some one wants to address the "verticality" of sl building by making severe falling damage, or people want to have agents sprinting across sims quickly without grating themselves on the cement like a cheese grater? 

 

This may be out of scope but just thought i'd mention it as these are hard caps intrinsic to ll damage that could be tweaked depending on the region's experience they are trying to foster/deliver.

This is somewhat easily possible to do with the existing Experience tools or even just a separate script altogether monitoring avatars in the region. My group has has been using a hard landing detector/enforcer script for years now and it could easily be tweaked to penalize hard landings with damage proportional to the velocity before stopping.

It's probably out of scope for this project, but having fall damage as an additional feature would be nice to add to the collection. However, as things are, people can easily tap spacebar just before landing to prevent being stunned or damaged altogether, so the ability to disable hovering will need to be included with this option.

Edited December 13, 2023 by Thunder Rahja