[BUG-10581] llObjectHealth(), llDetectedDamage(), and OBJECT_DAMAGE parameters for superior vehicle simulation

[sl-service-account]

How would you like the feature to work?

This system would allow objects to toggle the Vehicle Health feature. The feature would consist of two new function calls, llObjectHealth(integer boolean) and llDetectedDamage(integer number) and one new constant, OBJECT_DAMAGE.

llObjectHealth(integer boolean) does the following: If TRUE, damage that strikes the link-set is not applied to avatars that are attached to the link-set.

default
{
   state_entry()
   {
      llObjectHealth(TRUE);
   }
}

  If FALSE, damage that strikes the link-set is applied to avatars that are attached to the link-set.

default
{
   state_entry()
   {
      llObjectHealth(FALSE);
   }
}

llDetectedDamage(integer number) does the following: In the collision event, the integer damage set by llSetDamage(integer number) is reported as an integer.

default
{
   collision_start(integer c)
   {
      integer damage = llDetectedDamage(0);
   }
}

OBJECT_DAMAGE does the following: It is a parameter retrievable with llGetObjectDetails() that returns the integer damage the object is set to. If it is not set to any damage or an agent key is presented, returns FALSE.

default
{
   state_entry()
   {
      llSetDamage(100);
      list details = llGetObjectDetails(llGetKey(),[OBJECT_DAMAGE]);
      integer damage = llList2Integer(details,0);
   }
}

Why is this feature important to you? How would it benefit the community?

This would allow for highly simplified damage systems for all vehicles in Second Life. Currently, systems in safeland require a listen or collision parameter like name or object description transfer the information for damage. Systems in damage land must have an even more complex system of a volume detect vehicle that is followed or follows a non phantom 'hitbox'.

These scripting calls allow very simple transfer of damage information that is already part of the LL Damage system for use with vehicles that otherwise die the moment the vehicle is struck by a 100 damage prim.

Possible argument: This allows for invincible non phantom objects.

Counter argument: This is already possible with llVolumeDetect. This offers no additional issues beyond current fully phantom systems. Land return and object return would still entirely remove the offending prim.

Possible argument: This includes no system for counting health in a vehicle.

Counter argument: Correct, it does not. That is left to the designer to create. Giving them the tools to do so enables content creators to make much more user friendly vehicles, and thus vehicles easier to create and sell.

Possible argument: This makes all vehicles currently designed for llVolumeDetect systems obsolete and require huge re-scripting of objects.

Counter argument: This makes the job of any vehicle scripter VASTLY easier. Additionally, current system will still function, this will simply be a superior system that scripts would naturally gravitate towards. If a system does not wish to convert, there is no requirement to. Nothing with llVolumeDetect is broken by this.

Lastly, the ENTIRE combat community would greatly benefit from this, allowing damage land to be more functional and make vehicles far more simple, functional, less script intensive, and fun to use.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-10581 | | Summary | llObjectHealth(), llDetectedDamage(), and OBJECT_DAMAGE parameters for superior vehicle simulation | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Labels | health, damage, combat, object | | Reporter | Raideur Ng (raideur.ng) | | Created at | 2015-10-29T19:47:00Z | | Updated at | 2017-05-08T23:02:27Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2015-10-29T14:53:37.334-0500', 'How would you like the feature to work?': 'This system would allow objects to toggle the Vehicle Health feature. The feature would consist of two pieces, the llSetObjectHealth(integer boolean) and llDetectedDamage(integer number).\r\n\r\nllSetObjectHealth(integer boolean) does the following:\r\n If TRUE, damage that strikes the linkset is not applied to avatars that are attached to the linkset. \r\n If FALSE, damage that strikes the linkset is applied to avatars that are attached to the linkset.\r\n\r\nllDetectedDamage(integer number) does the following:\r\n In the collision event, the integer damage set by llSetDamage(integer number) is reported as an integer.\r\n\r\n', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "This would allow for highly simplified damage systems for all vehicles in Second Life. Currently, systems in safeland require a listen or collision parameter like name or object description transfer the information for damage. Systems in damage land must have an even more complex system of a volume detect vehicle that is followed or follows a non phantom 'hitbox'.\r\n\r\nThese scripting calls allow very simple transfer of damage information that is already part of the LL Damage system for use with vehicles that otherwise die the moment the vehicle is struck by a 100 damage prim.\r\n\r\nPossible issue: This allows for invincible non phantom objects.\r\nCounter arguement: This is already possible with llVolumeDetect. This offers no additional issues beyond current fully phantom systems. Land return and object return would still entirely remove the offending prim.\r\n\r\nPossible issue: This makes all vehicles currently designed for llVolumeDetect systems obsolete and require huge rescripting of objects.\r\nCounter arguement: This makes the job of any vehicle scripter VASTLY easier. Additionally, current system will still function, this will simply be a superior system that scripts would naturally gravitate towards. If a system does not wish to convert, there is no requirement to. Nothing with llVolumeDetect is broken by this.\r\n\r\nLastly, the ENTIRE combat community would greatly benefit from this, allowing damage land to be more functional and make vehicles far more simple, functional, less script intensive, and fun to use.", } ```

[sl-service-account]

LindaBaby3000 commented at 2015-10-29T19:53:37Z

I vote for that.

[sl-service-account]

Lucia Nightfire commented at 2015-10-29T21:25:57Z, updated at 2015-10-29T21:26:45Z

I would also suggest constants for llGetObjectDetails() such as OBJECT_HEALTH and OBJECT_DAMAGE so a central combat system can be used to monitor/regulate fair/allowed health/damage based on other factors, like object bounding box and/or object mass and/or prim count. With the functions and constants, Linden damage "may" become more manageable/flexible.

[sl-service-account]

Raideur Ng commented at 2015-10-30T01:39:45Z

OBJECT_HEALTH isn't a thing that currently exists and would require an additional variable attached to an object. It would likely benefit scripters to have this managed internally with their own systems rather than a strict one. This feature just allowed vehicles to record said damage applied. I do agree with the OBJECT_DAMAGE part though.

[sl-service-account]

velani.karu commented at 2015-10-30T01:55:58Z

This feature would be very very useful. It has my full support.

[sl-service-account]

ron.bleac commented at 2015-10-30T02:12:59Z

Please do this.

[sl-service-account]

Fei Soulstar commented at 2015-10-30T02:19:00Z

I second that.

[sl-service-account]

vagak.zemenis commented at 2015-10-30T03:09:47Z

This can optimize combat by an incredible amount. This will probably reduce the toll on the regional servers as well, and this should definitely be looked into.

[sl-service-account]

Garruss commented at 2015-10-30T08:04:41Z

I vote for this too.

[sl-service-account]

Jason Backer commented at 2015-10-30T13:02:57Z

Please do this.

[sl-service-account]

glitzern.fiertze commented at 2015-10-30T13:15:20Z

Just do it.

[sl-service-account]

Valaska Svendsen commented at 2015-10-31T01:26:35Z

They're never going to do this lol

[sl-service-account]

Kyle Linden commented at 2015-11-09T18:28:00Z

Hello Raideur,

Thank you for your suggestion. We've reviewed your request and determined that it is not something we can tackle at this time.

Please be assured that we truly appreciate the time you invested in creating this feature request, and have given it thoughtful consideration among our review team.

This wiki outlines some of the reasoning we use to determine which requests we can, or can't, take on: http://wiki.secondlife.com/wiki/Feature_Requests

Thanks again for your interest in improving Second Life.