Pew! Pew! Pew! Linden Damage & Combat 2.0

[Lucidius Flanagan]

3 minutes ago, Thunder Rahja said:

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.

While these are possible to implement, sim performance would be better possibly without tracking the positio and velocity of every agent in the sim every second to apply fall damage if we had more control in the region settings and it was handled by each client or piped into how the system handles things directly I suspect.

 

re: spacebar, this is something that can be accounted for and planned around like the mentioned enforcement of disabling wireframe and other aspects. The goal of this project and others presently is to make creating new games in SL possible and easier, and locking basic aspects of linden damage behind a bunch of scripting is counter to that. Especially if it's something that can just be like "velocity maximum before damage is appled (0-202m/s)" instead of making some localized server to track agent velocities every .1s.

[TheDarkhand]

[09:20] Rider Linden: (Saved Mon Dec 11 17:20:39 2023)Initially my position has been to use llCastRay + llDamage, But, with that system I think you'd lose the ray's intersection with the target.  Perhaps something like llDamageRay which would cast a ray and deliver damage.  That would allow you on the receiver's end to get to the point of intersection.

 

 

Edited December 14, 2023 by TheDarkhand

[Lucidius Flanagan]

On 12/14/2023 at 1:12 PM, TheDarkhand said:

[09:20] Rider Linden: (Saved Mon Dec 11 17:20:39 2023)Initially my position has been to use llCastRay + llDamage, But, with that system I think you'd lose the ray's intersection with the target.  Perhaps something like llDamageRay which would cast a ray and deliver damage.  That would allow you on the receiver's end to get to the point of intersection.

 

 

I like this idea and thoght it'd be out of scope but the ray cast ***** returns way too much data when most combat folk just want to check LOS to apply damage. Some people even ban raycast from being full auto because it pulls so much un-needed data. 

People might be more receptive to it if there was like an llFastRay or llLineofSight(integer boolean) that just returned line of sight as a boolean or something when paired with a sensor (for grenades and special effects) or guns (mouse look ray on crosshair)

I suspect RP people would find this useful for reducing issues where ablities and effects go throgh walls also. Could even bake it into sensors as a "requires line of sight to detected object" boolean that can be flipped on and off with a default of off so old stuff is retroactive? 

[Miles Doge]

On 12/13/2023 at 2:35 PM, Lucidius Flanagan said:

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? 

--cut--

Honestly forgot about the oh so fun "Taking damage from scooting across a prim floor too fast" bit with LL damage & It would be an nice addition if we could have some kind of "intangibility" toggle to prevent this sort of thing, just to avoid the need to have a script [ever so slightly] lift the avatar above the ground for fast moving mechanics or sprinting.  

 

 

[Cesar Goland]

Just wondering, is the new released function llRezObjectWithParams related to this topic? because if so, that was fast...

[Vesca Starlight]

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

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

...

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

Despite the fact I make stuff for it VICE is a crappy deprecated system that people keep trying to turn into things its not instead of just doing QoL stuff and has been abandoned by its devs for longer than I've been on SL, its good enough for what it is and pretty much carries on because nobody wants to buy a slew of new stuff for a new/unknown system or other reasons of social politic (most of the experienced folks who could make a good replacement without falling into the same pitfalls have been around long enough for detractors on principle).

LLCS has a lot of communities built around it which all have different interpretations of what should and shouldn't be so I think wanting to reach a consensus is unrealistic at best, people in a zombie community probably aren't going to agree with people in the SLMC (both Military Community and Motorcycle Community) or internally within their own due to tribalism, simple differences is opinion/agenda, or my favorite the ages old superstitions that come from 07 when people didn't have a clue how SL worked but its been repeated enough to become law for some.

In short a consensus is unrealistic at best, and each system often has a ton of small communities and ideals around it. Damage 1.0 wasn't perfect but nothing will be, the idea is to just give tools that allow as many communities as possible to flourish without breaking things too badly elsewhere.

On the point of arms race, it can and will happen no matter how closed off a system is /someone/ will find a way to game it or get around it so its one of the main reasons I push for moderation/diagnostic tools more than trying to make a system more closed down. To prevent an arms race you essentially need a strong enough personal willingness or community backing for "hey no thats dumb don't do that" when someone makes a bunch of gear that does unfair things. Though it is important to still be open to ideas that could be beneficial so you don't end up in total stagnation and fear of improvement (see LBA). In LLCS as it is you can easily make a non-phys invulnerability chair that nukes the sim at the press of a button, but most sims will ban you for it because they often have rules against it even if the system technically allows it. Its a common rule in the LLCS areas I partake to see "you must be vulnerable at all times" with further clarification that armor systems should be realistic to damage, IE not requiring large negative values or such and working with most available launchers.

TL:DR Childproofing never works, sim owners should and always will still have to actively moderate.

On 12/16/2023 at 11:21 AM, Lucidius Flanagan said:

Some people even ban raycast from being full auto because it pulls so much un-needed data.

I've literally never seen this as the cause, usually its because raycast is instantaneous so you don't really have to account for travel time and lead (at 200m/s or max speed a bullet still takes a second to go across sim, which means an avatar could have moved 3.25-5.12m roughly) which can have a huge impact on gameplay turning it into a point-and-click adventure while everyone else is having to shoot ahead of others or have a delay before hitting.

[elleevelyn]

12 hours ago, Cesar Goland said:

Just wondering, is the new released function llRezObjectWithParams related to this topic? because if so, that was fast...

Damage 2.0 evolved out of Rider Linden's work on llRezObjectWithParams

Damage 2.0 is currently a thought exercise which Rider is leading - If there was a Damage 2.0 what could it look like and how might it work ?

Rider Linden has been clear that no Linden resources have yet been allocated to Damage 2.0. Only llRezObjectWithParams

[elleevelyn]

8 hours ago, Vesca Starlight said:

On the point of arms race, it can and will happen no matter how closed off a system is /someone/ will find a way to game it or get around it so its one of the main reasons I push for moderation/diagnostic tools more than trying to make a system more closed down. To prevent an arms race you essentially need a strong enough personal willingness or community backing for "hey no thats dumb don't do that" when someone makes a bunch of gear that does unfair things. Though it is important to still be open to ideas that could be beneficial so you don't end up in total stagnation and fear of improvement (see LBA). In LLCS as it is you can easily make a non-phys invulnerability chair that nukes the sim at the press of a button, but most sims will ban you for it because they often have rules against it even if the system technically allows it. Its a common rule in the LLCS areas I partake to see "you must be vulnerable at all times" with further clarification that armor systems should be realistic to damage, IE not requiring large negative values or such and working with most available launchers.

TL:DR Childproofing never works, sim owners should and always will still have to actively moderate.

i kinda diasgree with this premise. At this time the only social management tool provided is the parcel eject/ban hammer. This is what we are used too

it doesn't always have to be this way. This system can be a step toward providing tools that can regulate and enforce behaviour at least in this parcel setting

for example:

a system where upper limits are known and can't be exceeded, while at the same time allowing the arena/parcel owner to set up their own environment parameter limits to best suit their game. llGetEnvDamage/llSetEnvDamage

something like:

DAMAGE_HEALTH_REGEN_TIME, 300.0, -120.0, // seconds. 300.0 = 5 minutes. It takes 5 minutes for the system to regenerate health from 0.0 to 100.0
                                         // -120.0 = 2 minutes. It takes 2 minutes for negative damage (healing) to regenerate health from 0.0 to 100.0  

DAMAGE_HEALTH_REGEN_TIME,  60.0, -60.0   // 1 minute for system and healing

DAMAGE_HEALTH_REGEN_TIME,  0.0,  0.0   // health does not regenerate, neither system nor healing

DAMAGE_LAND_COLLISION, 10.0            // inflict 10% of 100.0 damage when fall down and hit the ground/surface

DAMAGE_PROJECTILE_1, 1.0, -2.0       // inflict 1% of 100.0 damage. Hit the target 100 times to finish them
                                     // inflict -2% of 100.0 damage. Heal the target 50 times to completely heal them
DAMAGE_PROJECTILE_2, 5,0, -5.0       // 5% of 100.0 damage. 20 times to finish, 20 times to complete heal

DAMAGE_PROJECTILE_3, 100.0, 0.0      // 100% of 100.0 damage. 1 time to finish

DAMAGE_ARMOR_1, 1.0, -2.0 // takes 1% of 100.0 damage. Armored Target has to be hit 100 times for it to fail
                          // Armor healed at -2.0. It takes 50 applications to fully heal the armor          
DAMAGE_ARMOR_2, 2.0, -2.0  // 50 hits to fail. 50 applications to heal

DAMAGE_ARMOR_3, 20.0, -10.0  // takes 20% of 100.0 damage. Five hits to fail
                             // -10. Can be healed. It take 10 applications to fully heal
DAMAGE_ARMOR_4, 0.0, 0.0  // armor_4 is ineffective in this game. Applicable to all types of armor

DAMAGE_ENERGY 0.2, 0.2, 0.2  // 0.2 = time in seconds between physical rez.
                             // 0.2 = time in seconds between casting ray.
                             // 0.2 = time in seconds between casting spell. Spell = purely script application of llSetDamage/llApplyDamage
DAMAGE_ENERGY 1.0, 0.0, 0.0  // 1.0 = 1 second between rez. Slow it down. 0.0 = cast ray disabled, 0.0 = spell disabled

DAMAGE_ENERGY 0.0, 1.0, 0.0  // 0.0 = disabled (no rezzing). 1.0 = 1 second between cast ray. 0.0 = spell disabled

PROJECTILE and ARMOR could have a 3rd parameter - rate at which damage decays over distance

and a 4th parameter: DAMAGE_ENERGY could be a environment property of each PROJECTILE type

for example in a game setup:

PROJECTILE_1 (bullet) can rez at rate of 0.2 seconds
PROJECTILE_2 (mortar) can rez at rate of 1 second

0.2 would be the Linden limit. But we (arena owner) can slow this down

in this example model, Energy is unlimited. Is restricted tho by the firing rate

a person might script their own armor to 0.00000001 - taking relatively no damage. But it gets overriden by the environment setting. Same if they fire DAMAGE_PROJECTILE_1 applying 100.0. The arena environment can limit this down to 1.0 (or whichever the arena owner determines)

noting also that weapons/armor can be scripted to use less than the environment limits. They just can't exceed the limits. This actually unlikely to happen - weapons makers will go to the max. to be "competitive" in the market

effectively max. damage is regulated by the arena environment settings. Which means that the issue of arms racing is negated from the outset. Which in turn means that the need for social management (parcel banning) is lessened

 

ps add: We have been here twice before with Damage 1.0 and Open Damage (collision). The weapons makers broke them both. I think would be a big mistake to allow them to break it again, throwing it back on the arena/parcel owner to socially manage players brandishing overkill weapons made by weapons makers, when this doesn't have to be the case

 

 

 

Edited December 19, 2023 by elleevelyn
format

[Gunwald Constantine]

On 12/7/2023 at 9:16 AM, Cesar Goland said:

I have a RPG system with some combat features on an experience (and other damage dealing features, like hunger and diseases, that would also benefit from this framework), but all usable weapons are specifc for the sim, I would love to use this, performance wise it would be awesome, but I think that being able to limit stuff to a specific experience would be needed, like preventing a on_damage event from even triggering if its damage source is not from a experience (not filtering it in the event, but not even triggering)

An example that I can think is that even if we can use on_damage and llDetectDamage to filter out some damage sources the event itself would still be triggered, like spamming the on_damage event enough to prevent some damages to enter?, lets say, If I overload someone with llDamage(...,0,...) preventing other damage events would that specific person be Immortal?

Honestly I got so interested in this framework that in almost 15 years of Second Life this is my first post on the forum

(English is not my main language, sorry for anything)

I also have similar system with life hud, crafting, so would be nice to limit the scripts to approved ones like experience.

[Amalia Irata]

@Rider LindenIs there going to be native support to pull owner info from group-owned objects, or will we still need to jump through hoops like we do now?

[Vesca Starlight]

On 12/18/2023 at 6:10 PM, elleevelyn said:

i kinda diasgree with this premise. At this time the only social management tool provided is the parcel eject/ban hammer. This is what we are used too

it doesn't always have to be this way. This system can be a step toward providing tools that can regulate and enforce behaviour at least in this parcel setting

...

ps add: We have been here twice before with Damage 1.0 and Open Damage (collision). The weapons makers broke them both. I think would be a big mistake to allow them to break it again, throwing it back on the arena/parcel owner to socially manage players brandishing overkill weapons made by weapons makers, when this doesn't have to be the case

You missed my point, people WILL find a way around it plain and simple. LL limits rezzing objects via an enforced sleep and that doesn't stop people, literally any sort of scripted or coded system I can pretty well guarantee someone will be determined enough to eventually crack it and from there you'll see a spiral downwards if you rely solely on code enforced limits, on top of making it so closed down and locked up that it'll absolutely destroy the ability for creators to make fair and proper stuff too.

Lets say you limit damage so nobody can one-shot-kill to enforce a partial damage combat, well now when John Newbie takes the tank he just paid $8-$12 for and the main gun doesn't kill someone like it says it should that creator needlessly gets a bad review. Optionally you can script in a system to detect the maximum allowed damage and adjust accordingly which adds more script load needlessly but protects the creator from bad reviews for stuff out of their control... however this also bypasses the scripted rules enforcement of the sim. Applying the same logic to a gun you just make every bullet do that check and now you have very bad things happening to the sim so someone can get away with something they aren't supposed to be able to do.

Limit RoF, more nodes. Limit damage, more damage prims. etc. Life finds a way. I'm a huge fan of tools for users to moderate their own experiences like damage/hit reporting but putting up barriers so you don't have to moderate a sim will never work. Ultimately if users can put on a HUD/etc that reports whats going on like who is hitting them with what and how fast (on_damage event) it gives them tools to essentially pick up their toys and leave if they aren't happy, and sim owners generally try to cater to their users/visitors unless they like paying hundreds monthly for a sim that doesn't get any traffic which is their prerogative.

[elleevelyn]

9 hours ago, Vesca Starlight said:

Lets say you limit damage so nobody can one-shot-kill to enforce a partial damage combat, well now when John Newbie takes the tank he just paid $8-$12 for and the main gun doesn't kill someone like it says it should that creator needlessly gets a bad review. Optionally you can script in a system to detect the maximum allowed damage and adjust accordingly which adds more script load needlessly but protects the creator from bad reviews for stuff out of their control... however this also bypasses the scripted rules enforcement of the sim. Applying the same logic to a gun you just make every bullet do that check and now you have very bad things happening to the sim so someone can get away with something they aren't supposed to be able to do.

arena owners will not be changing their arena environment settings every 0.2 seconds. They will set it up one-time for the duration of the play. So the weapon need only check the environment settings once when the player enters the region (typically to the safe zone) 

any arena owner who has scripted their arena to randomly change the environment,, will not as you say get anybody to stick round - unless the players are masochists - which some people are. Be like fighting in a storm where you don't know if your weapon will fire from one moment to the next. Kinda fun to do in the right company but basically pretty nuts

where environment settings are most likely to change from one setting to another, is for example: when the arena can be set up for Tournament play. Different environments for different plays.  With a Social environment setting for times outside of the Tournament Event schedule

just add. I mention this before, iI will say it again in light of what I wrote last. Slowing down rez times (damage application times) is a mechanic for when the Damage-Health meter is on a single continuum which has unbounded ability to inflict damage. However if was up to me (and it isn't) then I would have two continuum meters: Health and Energy. It costs Energy to deliver damage. Linden do have institutional dev knowledge of energy application, so I think would be doable

Edited December 30, 2023 by elleevelyn
more clearer

[Tactical UwU]

On 12/29/2023 at 9:24 PM, Vesca Starlight said:

You missed my point, people WILL find a way around it plain and simple. LL limits rezzing objects via an enforced sleep and that doesn't stop people, literally any sort of scripted or coded system I can pretty well guarantee someone will be determined enough to eventually crack it and from there you'll see a spiral downwards if you rely solely on code enforced limits, on top of making it so closed down and locked up that it'll absolutely destroy the ability for creators to make fair and proper stuff too.

It's ultimately up to sim/arena owners to set up and enforce what they want to permit in their respective combat zones. There will always be bad actors as a result of malice, incompetence, or both. If people want to preserve creativity and a content creator's ability to make unique items, then it's going to be up to both the owners and content creators to work together on a solution.

It's going to take time for people to figure out how to best utilize these new features, and that's with any new system so this should be nothing new to most people who have participated in any combat community for any significant length of time whether that be VICE, LLCS, or one of the dozens of -CS systems.

My primary concern regards auditing system interaction which so far looks very solid. This will allow people to create a lot of tools for identifying and addressing bad actors, especially with other existing features such as region experiences. This could very well include some forms of automated administration as well in extreme cases of abuse.

One issue I do have is with the anti-grief @Rider Linden. Creating a prompt for teleporting home could actually lead to the grief being worse. Many combatants in LLCS already have to disable certain features like loading screens for teleports due to the prompt locking up the client when spammed due to failed teleports, rapid teleports (ie. getting spawn camped), or region/client latency. Instead, a better solution would be allowing sim owners to define a grace period after respawn inwhich the avatar cannot be damaged, aka spawn invulnerability. The anti-grief itself could simply be a forced grace period as well which will allow participants an opportunity to address or decide how to deal with the ongoing situation.

Though to be blunt, if your spawn zones have damage enabled that's more of a sim design issue than a griefing issue.

[animats]

If it can be done efficiently and securely with a script, it should be done that way. llRezObjectWithParams was needed because the overhead of starting a script for each bullet was slowing things down. There may be a need for built-in damage tallying, because that has to happen on each hit.

Beyond that, LSL scripts should do the work. The main security problem is making sure all players are using the same script. That can be done through the experience system. Different combat areas will want different scripts, of course.

Are there other system functions that need to be optionally locked out by an experience or parcel? Parcels can already lock out "fly".  How about "click to teleport?" Camming? Other than first person viewpoint? Wireframe mode? Player locations on the map?

It's really hard to change all the simulators and viewers, but it's easy to change scripts. The system should have the bare-bones features upon which combat systems can be built, but not, itself, be a shooter game.

 

[Love Zhaoying]

.

 

Edited January 3 by Love Zhaoying

[Vesca Starlight]

On 12/30/2023 at 4:03 AM, elleevelyn said:

arena owners will not be changing their arena environment settings every 0.2 seconds. They will set it up one-time for the duration of the play. So the weapon need only check the environment settings once when the player enters the region (typically to the safe zone) 

any arena owner who has scripted their arena to randomly change the environment,, will not as you say get anybody to stick round - unless the players are masochists - which some people are. Be like fighting in a storm where you don't know if your weapon will fire from one moment to the next. Kinda fun to do in the right company but basically pretty nuts

where environment settings are most likely to change from one setting to another, is for example: when the arena can be set up for Tournament play. Different environments for different plays.  With a Social environment setting for times outside of the Tournament Event schedule

just add. I mention this before, iI will say it again in light of what I wrote last. Slowing down rez times (damage application times) is a mechanic for when the Damage-Health meter is on a single continuum which has unbounded ability to inflict damage. However if was up to me (and it isn't) then I would have two continuum meters: Health and Energy. It costs Energy to deliver damage. Linden do have institutional dev knowledge of energy application, so I think would be doable

I flat out never stated arena owners would rapidly change settings, the point is more if the item on sale says or logically implies it does X which by all means it should script wise, but the sim settings means it does Y, now the product is not doing X as advertised or believed it should and people leave bad reviews which means people don't buy it and thus people don't make stuff for the system anymore because they get review bombed for stuff out of their control. The way around it would be to detect or for lack of ability to, default to just doing multiple hits every hit to compensate for any settings that make a product behave not as intended, this causes more problems than it fixes which was the point of my post to be wary of good ideas with bad ripple effects.

On 1/3/2024 at 10:10 AM, Tactical UwU said:

My primary concern regards auditing system interaction which so far looks very solid. This will allow people to create a lot of tools for identifying and addressing bad actors, especially with other existing features such as region experiences. This could very well include some forms of automated administration as well in extreme cases of abuse.

One issue I do have is with the anti-grief @Rider Linden. Creating a prompt for teleporting home could actually lead to the grief being worse. Many combatants in LLCS already have to disable certain features like loading screens for teleports due to the prompt locking up the client when spammed due to failed teleports, rapid teleports (ie. getting spawn camped), or region/client latency. Instead, a better solution would be allowing sim owners to define a grace period after respawn inwhich the avatar cannot be damaged, aka spawn invulnerability. The anti-grief itself could simply be a forced grace period as well which will allow participants an opportunity to address or decide how to deal with the ongoing situation.

Though to be blunt, if your spawn zones have damage enabled that's more of a sim design issue than a griefing issue.

Auditing tools are the biggest factor in all of this really, people will find ways around any coded/scripted barriers you put up so being able to simply see "oh hey person X is doing some funky stuff here" you can then deal with them appropriately.

Damage cooldowns after teleport would actually be super cool because it would also prevent the classic issue of "I died while throwing a grenade and now my spawn is full of explosion", though yeah people shouldn't have damage on in spawn to begin with but some folks will always be silly.

[elleevelyn]

5 hours ago, Vesca Starlight said:

I flat out never stated arena owners would rapidly change settings, the point is more if the item on sale says or logically implies it does X which by all means it should script wise, but the sim settings means it does Y, now the product is not doing X as advertised or believed it should and people leave bad reviews which means people don't buy it and thus people don't make stuff for the system anymore because they get review bombed for stuff out of their control. The way around it would be to detect or for lack of ability to, default to just doing multiple hits every hit to compensate for any settings that make a product behave not as intended, this causes more problems than it fixes which was the point of my post to be wary of good ideas with bad ripple effects.

sorry, I inferred rapid changes from a projectile reading the arena settings which is not going to be the case in the new world of scriptless projectiles. For sure some projectiles might be scripted: collision effects, tracker bullets. drones on rez, etc

a thing about not working as expected/intended. It is not expected that a fluffy popgun can take out a physical tank with one shot. yet it can. That such a tank can also take out the fluffy popgunner in one shot, is neither here nor there really in this context. Same with someone turning up to a snowball fight with a rocket launcher. Will still be up to the arena owner to manage their arena aesthetics

to your main point. I do understand your argument. I just point out that if the arena owner has no say in the damage/energy arena settings then is a Linden game system

is not unreasonable for an arena owner to set the maximum damage for hits. Like in a tank battle tournament - one hit - 100% damage and you dead. In a social setting 10% damage, takes 10 hits to get dead. The tank on rez, reading the region settings and making this info available to the tank operator

leveling this up. Tank vs Bradley. Tank can destroy Bradley with one hit. Bradley can destroy Tank with 10 hits say.

Tank uses PROJECTILE_1 = 100%. Bradley uses PROJECTILE_2 = 10%. Nothing prevents either Tank or Bradley from switching between PROJECTILE_ when the weapons maker has scripted it (fluffy popgun)

which is where Energy comes in. Suppose Health is 100 and Energy is 105. (Energy is some percentage greater than Health to prevent zero sum situation). To inflict PROJECTILE_1 100 Damage costs 100 Energy. leaves 5 over. PROJECTILE_2 costs 10 Energy,, leaves 95 Energy after the first shot

the management of Energy (within the rules of the arena - damage env settings) is then left up to the player as it should be. Not to the arena owner, the weapons maker, or Linden

is just a question of how many levels of PROJECTILE there are. Understanding that arena owners may disable some PROJECTILE

for example in a snowball fight arena, all PROJECTILE  are disabled except for say PROJECTILE_8 which arena owner has set to 5%. Have to hit them 20 times with a snowball before they die. Doesn't matter if turn up to the snowball fight with a tank. Any customer that thinks they can take a tank to a snowball fight (fluffy popgun think) is thinking wrong and if they do then they be shown they are wrong

however a tank on a tank battle arena will work as expected

edit add. We getting into sophisticated weapons systems now, but a weapon can be scripted to be under full control of the player. Like the weapons HUD reads the arena env settings. These being max. settings, the player via the HUD can reduce the amount of damage and energy expended. Who would do this ?

one example: An expert helper player showing their  friend how to play. Friend is firing at 10 hits to death. Expert is firing at 20 hits to death. Same weapon delivering at different rates as determined by the player

another example: zombie hunting. The beginner friend can single shot a NPC zombie that is scripted to die at 10% damage. The expert friend chooses to double tap the zombies. They race to see who wins the zombie hunt

 

Edited January 9 by elleevelyn
env

[Wulfie Reanimator]

Rider Linden has opened two combat regions on the beta grid: Gallipoli and Thermopylae

All of the new combat features are going to be tested on those first, for example llGetHealth

[Rider Linden]

A Combat2 Update!

There is a new version of the Combat2 simulator.  By my calculations, this is somewhere around the 1/2 way point.  There is certainly enough there for people to start playing with it and building interesting things!

Functions:
llAdjustDamage
llDamage
llDetectedDamage
llDetectedRezzer
llGetHealth

Events:
on_damage
on_death

Function documentation is already in the wiki and I'll be updating this page (https://wiki.secondlife.com/wiki/Category:LSL_Combat2) early next week with suggestions on how these pieces can be put together. Consider that page the "central clearing house" for combat status. 

There are two regions on the beta grid open and available for testing:
Thermopylae: secondlife://Aditi/secondlife/Thermopylae/235/124/27
Gallipoli: secondlife://Aditi/secondlife/Gallipoli/18/142/27

I'll be looking for feedback at next Thursday's Rooty Tooty Shooty Committee meeting.

[Sammy Huntsman]

On 3/22/2024 at 6:46 PM, Rider Linden said:

A Combat2 Update!

There is a new version of the Combat2 simulator.  By my calculations, this is somewhere around the 1/2 way point.  There is certainly enough there for people to start playing with it and building interesting things!

Functions:
llAdjustDamage
llDamage
llDetectedDamage
llDetectedRezzer
llGetHealth

Events:
on_damage
on_death

Function documentation is already in the wiki and I'll be updating this page (https://wiki.secondlife.com/wiki/Category:LSL_Combat2) early next week with suggestions on how these pieces can be put together. Consider that page the "central clearing house" for combat status. 

There are two regions on the beta grid open and available for testing:
Thermopylae: secondlife://Aditi/secondlife/Thermopylae/235/124/27
Gallipoli: secondlife://Aditi/secondlife/Gallipoli/18/142/27

I'll be looking for feedback at next Thursday's Rooty Tooty Shooty Committee meeting.

Could you guys maybe add proper arrow and bullet drop in this update please? 

[Amalia Irata]

2 hours ago, Sammy Huntsman said:

Could you guys maybe add proper arrow and bullet drop in this update please? 

It's already there, if you change the projectile gravity.