Poll: damagable objects w/ get_damage() & damage event! Devs please read!!

Note: Please read all the way through b4 voting, especially if you have partially read my other post on this subject. This a vast improvment on that.

I suggest that Linden Lab devs enable objects to recieve damage in the form of a damage event. The damage amout should be retrieved with a function (i.e. llDetectedDamage(integer num) ) and handled by a get_damage event handler.

*get_damage(integer num_detected) added to event handlers
*llDetetedDamage(integer num) added to the deteted library

This damage system would not automatically effect a health status for the object, but allow for the script to handle damage however the author wants.

This would enable (amoung other imaginative things):
* damagable objects that work with all weapons
* different bullets to inflict different amounts of damage,
(i.e. a pistol can do less damage to your ship than a proton torpedo)
* let you limit or control how much damage can be done in each hit.

An example of code with all three of these advantages is below.

(i.e.)
// Paradigms damage system which
// works with the built in damage functions
//  that controls how much damage can be recieved
//  and is compatible with all weapons
//  and that the lindens should push to the devs
//  NOW (please)


integer health = 215;

default{

     state_entry()
     {

     }

     get_damage(integer num_detected)
     {
          integer damage = llDetectedDamage(0);      

          if (damage > 20)
               {
                    health = health - 20;
               }
               else
               {
                    health = health - damage;
               }

          if (health <= 0 )
          {
               llDie;
          }
}


}

Other examples of this you could do if this were implemented include:

*vehicles/APCs/objects that change apearance at different levels of damage
*objects that say things at different levels of damage
*shields that absorb a limited amount of damage

The list goes on. I realise there are systems out there that do similar things, however they either don't work with all weapons, or take the same amount of damage from a weapon nomatter what the weapon is. This built in system would allow such flexibility and cost nothing. I believe it would be a great improvement with a positive economical and social impact.

hmmm
if you want people to take your poll serriously it shouldn't be self flattering and give more options. I found it a turnoff to your otherwise pretty decent suggestion.

Second life has been down all morning, I have the shakes, I'm constipated, I'm cold and irratable. Now is not the best time to tell me how to run my poll.

/restrain self


Most people here like to voice their opinions and would take this opportunity to express any valid reason for voting "No" unless it was just be silly or spite me in some way (as if ). Seeing as the "No" votes haven't posted anything it probably means that they don't want to be identified or otherwise weren't serious and we can probably discount the those votes.

So far only 3 people have voted, and they voted no I don't know what their motives are for that because they didn't leave a message explaining why they don't like the idea. But on the bright side they all think I'm a genius!!

However I have found one single issue with this feature implementation, and it is that llSetDamage objects (objects which cause damage,) currently disapear after their damage is done to an ave. Yet I don't know if this will work as easily with objects because since not all objects will be damageable objects. How will it know whether it has hit a damagable object and therefor needs to die, or if it has hit a regular object that it should bounce off of? We probably would not want a bullet to hit our damageable object multiple times.

Since I don't really know anything about coding Second Life I would just hope the devs will find it worthwhile to find a solution to this if they like the idea. However, an idea I have is to also add a llTakeDamage() function which simply tells the world that damage causing objects should die after they cause damage to the damageable object. Also I imagine that when damage is taken or delivered some sort of event is triggered that causes the damage causing object (the one with llSetDamage)) to die... and that would solve this issue.


-- One comment about the poll. The purpose of the pole is an attempt to get the attention of the Devs., and let them know if you guys support this idea. I don't see why anyone would vote "No" other than a joke because implementing this would bring MUCH more interactive game play to Second Life. If you do have a valid reason for voting "No" then please list it here so that I and the Devs can take your "No" vote seriousely.
-- Thanks

P

I think it would be better to merge llDetectedDamage with the collision events. As this would make the most sence, instead of creating a new event; as any high speed collision with your avatar causes damage.

Isn't this already possible? I could see it working in thie following manner:

A projectile collides with a target and triggers a collision event. The projectile is named "025 Damage Bullet" or "060 Damage Torpedo." The collision event calls llGetSubString(llDetectedName(0), 0, 2). The function returns the amount of damage based on the projectile's name. Change it to an integer and subtract from your health total. That's a simple method, and I'm sure there's a more complex method as well.

No need for a new set of functions to do this, and no I didn't vote.

Funnly enough I was just thinking of posting somethng similar.

DoteDote,

The trouble with your system is that the bullets have to have specific names. So yes, you can create a propriatry system that way, but its not generic. I want my object to take damage from everything with damage enabled.

So I vote yes to the principle. I suspect there might be a bit a fair bit of coding behind the imnplementation tho'. You may have to have a new attribute for evey object!

It seems that any system would need to be proprietary - or at least controlled - to function properly. Sure, I can shoot a bullet at your wall, but is my bullet a BB or a nuke? The damage inflicted has to be programmed into the projectile somehow so that the handlers in the target know the extent of the damage.

See my signature for my reply to this thread

DoteDote,
I agree that is still a problem in that area. But being able to detect whether or not an object is set to cause damage is still useful without that.

I dont think that there is a need for a separate damage event, Strife's suggestion of llDetectedDamage would meet my needs.

The fact that objects with damage set die after colliding is a separate irritating problem. Unless its an anti griefing measure Im not sure why it isnt left up to the scriptor to decide.

Hiro,
Sorry mate, your going to have to explain that.

It means the poll didn't provide options for every possibility.

Ahh Good point Catfart! I see that now. You could just llGetDamage(0) in the collision event, and handle it there. True! Well that would be great! And it would be usefull for sensor events aswell. I.E. llSay(0," Hazardous obsicles ahead ";

Thanks for your contribution!

You are a genius and I fully support this product and/or functionnality.