Add PRIM_HEALTH, OBJECT_HEALTH (prim params) for objects.
complete
dantia Gothly
After playing with the new lsl functions with my pathfinding bot I found a use case in which I could have for example a combat npc and a medic npc.
Objects can be given a default health primitive param value of 0.0-100.0
at the moment this only works for agents but I see no reason for it not to work on objects.
llGetHealth(llGetKey());
Health management could be param based and easlily called and modified as needed.
Object health regen could be scripted on a timer or a loop of some sort.
llSetLinkPrimitiveParamsFast(0,[PRIM_HEALTH, float healh_value]);
list info = llGetLinkPrimitiveParams(0,[PRIM_HEALTH]);
Allowing objects to detect the health values of another object:
list info = llGetObjectDetails(object_id, [OBJECT_HEALTH, link_num]);
With this my medic npc can detect if a nearby npc needs health and attempt to go over and render aid. Or could be used to set the health of various components of a vehicle like tank treads etc.
This would also cut down on the amount of llRegionSay() and listen events required for such a system to exist.
Log In
This post was marked as
complete
Rider Linden
in progress
Thunder Rahja
This appears to be implemented as of Combat2 2024-05-02.8929584012:
llSetPrimitiveParams([PRIM_HEALTH, float amount])
llGetObjectDetails(key id, [OBJECT_HEALTH])
Thunder Rahja
A potential conflict I can see is whether an object's health is limited to 100 and represents a percentage of its total health, or if that object's health is its literal health value (without a maximum defined) on the same scale used by llSetDamage and avatar health. Existing armor systems (particularly LBA and its derivatives) supply both current and maximum health as part of the object description CSV. If there is a health value for an object, there should be a maximum health value for it also, and both should be as accessible and easy to retrieve as the object description.
Also, perhaps only the root link of the linkset should have health, and any reading or changes should be performed on the root and not any child link.
Wulfie Reanimator
I agree. I don't think the prim param should have any kind of logic (eg. min/max value) to it. It should just be a value we can get/set.
There are objects that have even negative health in the SLMC, if they're meant to be "broken" things intended to be repaired to go away (like breached walls).
Adding to that, llDamage is able to deal more than 100 damage in a single hit, so having objects with more than 100 health would fit right in with historical use and the new functionality.
Wulfie Reanimator
Having this kind of simple a prim param would be a really nice universal and
synchronous
way of communicating "health" between objects, whether it's armor on a tank, energy in a shield/battery, or other similar concepts.It would not need to get automatically changed by damage prims or
llDamage()
, scripters can take care of updating the param when it suits them. Countless scripted objects already need to keep track of their own health during combat (and tend to display it as stylized hovertext), it would be very useful to also update it as a proper... property.Currently, health needs to be communicated over listen events (or by parsing
PRIM_TEXT
...) which makes interoperatibility pretty complicated and fragile.