I couldn't care less if the damage system was just retired. It's really pointless.

Disagree with the rest of it.

LINDENS PLEASE BE ADVISED: The vote count is so high because objects are being left in world that advertise this Jira issue with statements like "Vote to make combat more fun!!!!!!1"

Lack of comments suggests that no one's actually RTFJ.

clarknova i placed 1 on each combat island.. as it is those people who fight there to be made aware, this issue will affect the combat island will it not ...

thanks aran.

if you have any more ideas to add please IM me and ill add them.

Of course the few lines of information in the description of this issue arn't 'the' solution, but some of the 'possible' solutions. Each one capable of adding further dynamics to this under developed but overtly enjoyed segment of Second Life. Having tested a system in world that aims to work towards the goal of improving/replacing the old Land damage system, it's clear that there are great benefits to be had by adapting to a more usable system, one that creates a fairer, more controlled and less abused environment for all users.

Rectifying the issue of a lacking damage and realism system will help to establish a more realistic Virtual world to those who require it, whether they be combat orientated or not. It's nice of you to bring up the proposed Mercza system (which as far as I know is almost a replica of the system that spawned the reasoning for this issue to be created). Unfortunately systems developed in world cannot 'fix lag issues', they can work around them or ignore them but often in most cases its a matter of juggling priorities to create a system that suits its intention best whilst minimizing any negative impacts, it would not be a universal system that bypasses the need for work arounds as the suggestions in this JIRA Issue would begin to allow.

Being an experienced 'Merczateer' yourself, it would seem you would be in an exceptional position to offer valuable suggestions about this issue, I'm left wondering why you've not chosen to do so in favour of off-topic self advertisement.

I have closed this issue because all of the requested functions can be made using the existing LSL commands. The health function can not be implemented without cheaters constantly setting their health to 100 and thus never being killed.

Darling.

Avatars are a box! There are no arms, legs, head etc. The collision surface for an avatar is nothing more than a box with the size of <0.45, 0.6, zzz>. With the only variable being yoru height. It is not possible to assign damage to different body parts because we dont have different body parts to damge! This function can not be done.

*llSetHealth(); = gives 10 health every second from the object with the lsl script in it.

This function can be abused. Anyone can put 10 scripts into an object they are wearing and have all 10 scripts constantly rezzing one of these health balls on top of them. That means at any given time they will be receiving 100% health.
Any function that increases health via a script will result in unkillable avatars, and a HUGE load on the asset server as people constantly rez health balls on top of themselves. This function can not be done.

*Oxygen Meter = if in water oxygen lowers and at high altitudes(exception when avatar is sitting)

If you want to simulate a reduction in health when under water/altitudes, make a script with a timer to rez a prim with xx % damage on the person every xx seconds. Scripts can already work out the water height and if the avatar is sitting which is all your fucntion needs to know. Your players can etiher wear a HUD or you can have an invisible object following them around to drop damage prims on them when needed.

*Be able to set 2 or more spawns (for arrivals, and the landowner)

You can set different spawn points by cutting out a 16m parcel and setting a landing point on it. Estates have telehubs too. This function is already possible using the tools we have.

*on death > get the option to be sent to the spawn or sent home.

Your home is your spawn point. You can change is whenever you like. If your in combat and want to set your spawn to the combat area you can already do this. Being asked a question in a time critial moment like a death teleport is going to mess up the flow of the game for you and the person shooting you.

*constant killing / auto killing - add a pause on the teleport so you don't crash, so you are able to ban greifers who auto kill you on your land.

The only reason you would die the moment you teleport in is if you didnt teleport into the safe area. I understand Michael Linden has fixed this so all people teleporting into the linden combat sandbox will be placed in the safe location. If you use a private sandbox who didnt do this, ask them to. Again there is no need to change how things work, just use the tools we have properly.

*Sitting on a object gives the object health thus having to kill the object first then the avatar.

This is a very bad idea. What if your sitting in your house, does your house die? What abotu no-copy objects, do they die?
We can simulate damage to objects using the collision events so there is no need to have the simulator force it onto people who dont want it.

This JIRA needs to be closed. There is nothing in it we can not already do, and the things we cant do, we should not be able to do.

All of the issues in this JIRA should be addressed by content creators not linden labs.

Darling.

I'm an admin at a privately owned combat sim where we've had just such a system for...oh dear, at least a year now. The only part of this proposal that we don't have is the body-part damage, for the reasons that Darling mentions. A hit is a hit is a hit, there's no way to tell where on the av the collision occurred.

However, if you're using a health-meter attached to the HUD, the meter can subtract a set amount each time you get shot. Ours is set to only allow collisions from physical, non-phantom bullets travelling faster than 25 m/s. Additionally, we have some guns such as sniper rifles that have bullets specially scripted to cause extra damage (although this has to be carefully controlled, for obvious reasons). We've even scripted explosives and melee weapons to work with it.

We have an oxygen meter on the HUD too that senses when you are underwater and begins lowering. if it gets below zero, you start losing health. Upon surfacing, the oxygen meter slowly rises.

We have medkits that you can walk over that will restore some health. Additionally, there is an infirmary where you can lay on a bed and will have health restored to you. Additionally, you gain health slowly on your own.

You have the choice of two spawn points, both well above the combat zone (you parachute down). This can be set via a menu on the HUD. The HUD is also configured so that it will only receive damage when you are in the combat zone (we have set this at any altitude below 120m within the sim). This means that you cannot be killed while respawning, and you cannot be killed if wearing the HUD while out of sim.

Additionally, the system checks for anyone not wearing a HUD (essentially cheating by being invincible). If they are not wearing the HUD, a translucent sphere is placed around them to prevent them from disrupting the game, and they are given a dialog message stating that they need to wear a HUD. They are given the option of clicking on the sphere to be taken up to the safe zone (platform above the respawn points) to get a HUD. They are told that if they do not click on the sphere or put on a HUD within 45 seconds, they will be teleported to their home location. Aside from this, or from a teleport home issued by an admin for disruption/griefing or extreme rules violation, there is no other way to be involuntarily teleported home. Note also that the trap set by the system does not hold the avatar for longer than 45 seconds, and in any event offers them a method for removing it.

Because combat can only occur when the HUD is active, and that only occurs below 120m, it is easy to have a teleport point up top, as well as a safe zone for people to rest from combat, purchase weapons and gear, read the rules, obtain a HUD, or go AFK if needed.

Unlike DCS, we do not utilize an off-world database, which cuts significantly on the lag induced by the system. We also don't have "experience points" earned by being in the sim nor do we have a large number of "modifiers" like stamina, luck, etc. All of these things, while certainly enhancing for roleplaying, tend to add lag and are unnecessary for simple combat.

Our system, as described, is very low lag, contributing a base of maybe 3-4k IPS on its own. We find that most of the lag generated by combat comes not from the system but from the guns, which is why we limit them to only those which we have approved as meeting specific requirements for lag, magazine size, reloads, etc. A general guideline is that even dual-wield fully automatic guns should not go much over 10k IPS. I can script a single-wield automatic rifle to pull anywhere from 2-4k IPS. Turning off muzzleflash, shell ejection, and other useless "tacticool" features will similarly help. Thus, one can easily implement this system without any lag (unless you count the occasional 0.99 time dilation as lag).

I guess what I'm trying to say is that this ticket is fairly unnecessary, as all of the changes asked for here, and many more, have already been implemented by private content creators. This is how the free market works. A need is perceived and individuals move to meet that need. To some extent, I fear the problem is the SL Damage system itself, which provides a distraction, causing people to try to find a way to make it work instead of simply scrapping it and doing it themselves. Privately created combat health systems also have the advantage of having fewer exploits, since the code is proprietary, whereas everyone knows how SL Damage works.

Issue re-closed