Perhaps the SL damage system could be made so that it will function only with a scripted system intigrated into it, not on it's own, either all the time, or when such an option is selected in land options. Furthermore, combat system creators would need to get in contact with LL to intigrate their systems. The combat system would provide the healthbar, healing, damage taking methodology, and other features, and when death is to come, would communicate with the SL damage system to trigger a death simulation.

Having the actual death handled by the game itself rather than scripts opens up possibilities such as disabling object rezzing when dead, not allowing the user to "fix" death by just detaching their combat system, as they would just stay dead once it's removed, but now have no way to reset it, as that would be a function of the scripted system. Ontop of all that, having death handled by the game would also make it possible, and actually not difficult, to impliment the "ragdoll" system that Havok 4 is capable of, and that everyone has been raving about, thereby allowing combat systems to trigger this ragdoll via intigration with SL damage. This, of course, would allow for more realistic death sequences, and physically pushable bodies that would soar through the air like ragdolls when killed, or thrown after death, by explosions or large calibur weapons.

In short, I think this idea here, though rough, has some merit. Moreso, actually, than the other posts that this one has been linked to. You have my vote, and I'll spread the word.

I'm not sure that I see any major gain from this. Currently, the sole advantage of the default SL Damage system is that it is simple and easy to set up, and has universal rules that apply across all sims. This makes it useful for things such as military roleplay combat, where having a simple and universal system independent of any of the various competing factions is desired. By implementing this request, you would wind up removing the one useful advantage of the default SL Damage system, and replacing it with new features that basically clone what is already available in SL today.

Of course, if you're in the business of sellling a particular combat system, or weapons tuned for one, you wouldn't like this idea.

As the improvements asked for in this request are already available via scripted, resident-designed systems, this feature strikes me as falling under the category of "would be nice to have," but I wouldn't rate it as a top priority. More importantly, I'm not certain that the risks would necessarily be worth the gains.

Now, one major advantage to this that I can see is that the current Damage system does cause quite a bit of network and database lag when it involves large numbers of residents being teleported around. By eliminating the death teleport, this could relieve some of the lag involved. And of course, since land tools already offer options such as "Freeze" I suppose that some version of that functionality could be used here. So I don't think that this ticket is infeasible. However, I would be worried about the effect that autokillers and other various devices already in existence would have in such a situation. One would be killed, and then upon being revived, killed again, etc etc.

Also, the reporter of this ticket might wish to know that there is already a default "dead" animation. No need to add that, although I suppose I can see little harm to adding "dead2" and "dead3" or something so as to give more options. It's ok, I honestly hadn't realized that there was a default "dead" animation either until recently, when I was going through a new resident-designed combat system and saw a call for llStartAnimation("dead"); I searched through the object inventory for an animation called "dead" and was initially rather confused when I didn't find it. For a moment, I couldn't understand why it wasn't giving me a script error telling me that the animation wasn't found, until it hit me: AHA! A default animation it must be!

For more information on the available default animations (and there are surprisingly very many of these animations), please see:

http://wiki.secondlife.com/wiki/Internal_Animations

And as we've said before, we think more people would use the native damage system if it was just a little more flexible than "you died, TP home".

Anything that reduces script load, especially in a combat sim where we already rely on scripting for the operation of weapons and vehicles, has got to be beneficial.

If you think there's a lot of ruckus about script time now (and even more so now that that estate managers can see how much time each avatar's attachments are burning), just you wait until the planned per-avatar and per-parcel limitations on script memory are in place.

My experience with combat in SL is that weapons (and vehicles, if applicable) tend to contribute far more script load on a simulator than the combat system itself in many cases. Of course, this depends upon the combat system used. However, I have seen poorly scripted weapons create situations in which there was far greater script time, EPS, and overall lag in Damage-based combat sims than in some places with scripted health-meters.

Certainly anything that lowers the script load on a simulator is a good thing. And actually, where I see the greater savings in this proposal is in eliminating the teleport home feature, since that seems to add a significant database load. Having avatars constantly teleporting into and out of a sim, or even teleporting within a sim (when a sim has a public homepoint within it) is not a good thing.

Scripting a basic meter that would accomplish the changes requested here would be unlikely to add a significant amount of script load. I understand that you are rightly concerned about script load when looking at combat meters such as DCS or CCS, which have a large amount of functions and communicate frequently with off-world databases, but scripting a basic combat system to do what you are asking here is rather trivial.

Here's a basic starter concept:

integer health = 100;
integer percentage = 10;
key owner;
float deathtime = 15.0;
integer dead = FALSE;
string ownername;

settext()
{

if(!dead)

else

}

default
{

state_entry()
{

owner = llGetOwner();
ownername = llKey2Name(owner);
if(llGetAttached() != -1)

}

collision_start(integer hit)
{

if(llVecMag(llDetectedVel(0) >= 25)
{

if(!dead)
{

health = health - percentage;
if(health <= 0)

settext();

}

}

}

timer()

on_rez(integer param)
{

if(owner != llGetOwner())

}

I mean, that's fairly basic, obviously there's plenty else that can be added. But my point is that it's not overly difficult to do, nor should it necessarily cause a serious script load to implement.

However, I do see the point of giving the option to eliminate death teleports, given the amount of strain that they can place on a region and on the database, as well as the problems that occur in Damage-enabled regions when teleports get screwy due to overload.

EDITED: minor mistake in the code

But the idea here was not to devise yet another scripted combat system (which always seems to result in stupid power games, marketing lock-ins, profiteering and political machinations on the part of the systems and weapons sellers) but to make a currently mostly un-useful feature already in the simulator code more useful.

Given the priorities currently driving the Linden devs, I don't think you need to worry about it being implemented anytime soon.