Thunder Rahja

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.

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.

Perhaps this might be partially resolved by a new type of permissions request, e.g. "llRequestPermissions(llGetOwner(), PERMISSION_ADJUST_DAMAGE)" that, upon (automatic) granting, revokes the same permission from other scripts attached to the same avatar. Scripts that call llAdjustDamageAmount without this permission should shout an error message on DEBUG_CHANNEL.

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

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.

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.

I think it would be really cool if animations and attachments had physics simulation, so that when you swing a sword, for example, anything (or anyone) in its visual path would be detected as a hit, rather than the common method of using a (relatively) short range sensor. However, this is a very expensive suggestion to implement and would drastically change not just combat but the entirety of Second Life avatar interactions. To my knowledge, avatar bounding boxes (as reported by llGetAgentSize and llGetBoundingBox) are based solely on height, with a fixed width and depth. Avatar physics shapes (measured using llCastRay and math) are another story altogether, but appear to be generally shaped like a pill. To hit a target 100 m away (a typical engagement range during LLCS combat) at 800 m/s, it would take 0.125 seconds, which might as well be no time at all once you take script delays in a busy combat region into account. Because of the roughly 200 m/s velocity limit, as Amalia describes, the closest method we have to real world bullet speeds is hitscan using math, and sensors, position/angle comparisons against all agents in the region via llGetAgentList, or purely raycast in the direction fired. I actually find the 200 m/s limit more enjoyable because it allows for some small reaction time to quite literally dodge a bullet that usually would do 100 damage. When using hitscan/raycast rifles (often one of Wulfie's), I aim very slightly ahead of a moving target to compensate for script/ping delays.

Allow me to chime in here, Ryo. While this is true for most cases, collision events may take more than a few frames before the script can call llDie, especially when there are many other scripts firing events at the same time in a full homestead region, causing delays in even well-written scripts. The difficulty with that is that while avatar collisions with prims containing llDamage are handled instantaneously, collisions with land and objects is not, and so it is common for bullets to bounce off of surfaces or even stop completely before making contact with an avatar, resulting in death when it would not have happened in a full sim with 100% "scripts run" in the statistics window. Having collisions with land and objects handled as quickly as collisions with avatars would be a huge plus, not just for homesteads but for full regions under strain as well. llCollisionFilter affects only collision* events and has no impact on llDamage. Objects configured to ignore collisions with their owner but are assigned more than 0 damage with llDamage will still be able to damage their owner on unsafe parcels. Hitscan (a.k.a. "raycast") weapons are much more varied in their detection and delivery methods than what you described, but yes, that is also an area of improvement. If, instead of just a number, we could pass a string to a rezzed object as its rez param, it would eliminate the need for communication between a projectile and its rezzer and potentially reduce events per second in a combat region.

It's really not. If you focus more on the script EPS and script time, scripts run shouldn't be dipping like that. A couple of months ago, the only time that scripts run dipped below 90% was when someone entered or logged in in the region. The full sim I help manage typically had 1400-1600 EPS and script performance was steady. We were forced to cut back on script use since then, but even today with script EPS at 800+ it doesn't drop below 90% scripts run. In spite of the few changes that have been made within the homestead sim over the last ten years of its life, its performance has never been worse.

I understand that homestead regions are given only a fraction of the resources afforded to a full region, but this is ridiculous. The attached screenshot was taken a few minutes after a manual sim restart.