Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

integer llDetectedDamage(integer number)

Sylph Lightworker
Registered User
Join date: 2 Dec 2005
Posts: 8
03-11-2006 23:55
As things stand now, the only way for a non-avatar(ie: target dummy, vehicle, drone robot, non-combat-zone consentual damage system, whatever) to suffer damage is to implement its own health system(which is perfectly fine and doesn't need LL to help with), and then track damage by one of two methods:

A) How fast a projectile hits or moves close to it.
B) Listen on an obscure channel for proprietary weapons to broadcast how much damage it should take, via whisper/say/shout.

Problems with both of these methods:
A) This doesn't work for weapons that make use of slow or unmoving damagers. Damage done generally has little bearing on how powerful the weapon's creator thinks it should be. (Though granted, there aren't a lot of weapons around in SL that don't kill instantly anyhow. -_-)
B) All of the systems utilizing this tend to be closed-source, and generally incompatible with each other. They also tend not to "hit" very logically. Won't go into detail about that.

I propose a new function with the following definition:
integer llDetectedDamage(integer number);

As should be obvious(but I'll explain anyhow, for those who might be a bit sketchy on such things), this would return useful information only in the collision_start, collision, and collision_end events, since there's no way to do damage in SL except through collision with an object or the ground. (And while it wouldn't be consistent with the rest of the llDetected* functions, having it work in the land collision events would be convenient. (Say something gets pushed into the ground hard enough to take damage.) Failing that, publishing a formula for calculating damage from llGetVel() in a land collision would work fine. :))

Anyhow, in the events collision_start/collision/collision_end llDetectedDamage() would work just like the other llDetected* functions. That is, take as an input parameter an index to the object causing the event, and return the amount of damage that object has just dealt.
If this is used in an attachment, it should detect and return the amount of damage that was attempted to be dealt to the avatar. This function should work in safe land, and be completely independent of avatar health-tracking!

This pretty much solves both of the problems mentioned above(though I'm sure the loss in sales for those peddling L$1000+ proprietary damage-tracking systems will upset some. :)), and I think will open up some new doors in the realm of combat in SL. Why should it be all about forcing someone to teleport home? Lots of other games make it fun!

Post the vote URL in a moment. :)
Sylph Lightworker
Registered User
Join date: 2 Dec 2005
Posts: 8
03-12-2006 00:00
Vote URL here: http://secondlife.com/vote/index.php?get_id=1131
Sylph Lightworker
Registered User
Join date: 2 Dec 2005
Posts: 8
03-14-2006 07:43
Well.... I've got to admit I'm kind've curious what others at least think of this, lol. :) So far all I've heard is "omg that's a good idea!", "I'm too drunk to read it right now." and "it sucks because it isn't proposing a complete overhaul of the SL damage system"... ^^;
Anyone? :P
Draco18s Majestic
Registered User
Join date: 19 Sep 2005
Posts: 2,744
03-14-2006 11:02
It's up there in the that would be useful and that would be cool catagories, although I myself have no need for it. Good luck.
grumble Loudon
A Little bit a lion
Join date: 30 Nov 2005
Posts: 612
03-14-2006 18:26
CODE

collision_start(integer num_detected)
integer i;
for (i=0;i<num_detected;++i)
{
key AKey = llDetectedKey(i);
float Speed = llVecMag(llDetectedVel(i));
float Damage = Speed * llGetObjectMass(AKey);
//Send damage to combat controller
//llShout(1234,
};
}


Edit:
My view is that the damage system should be implimented by the land owner via SL script and that a new event should be implemented that triggers whenever something on the land colides.

And then add a llSetHealth(key id, health) that would then adjust the avitar's health.

One of the reasons the other systems are not open source is that if anyone knew the channel they could cheat.
Sylph Lightworker
Registered User
Join date: 2 Dec 2005
Posts: 8
03-15-2006 15:33
grumble, this code is already what's done... Calculating damage from speed and mass while llSetDamage() exists does not work consistently between avatars and non-avatars. Why would you have two entirely separate systems if you can help it?
The reason behind shout/say/whisper systems being closed source is fairly self-evident, too. :P Same reason all the systems are incompatible with each other. No one trusts anyone else with their channel information. And of course a shouted amount of damage does nothing to an avatar either.
I don't see why damaging avatars should be strictly under the control of the land owner, either--if they turn damage on, it should work consistently. Not... in Sim A, everything kills you instantly, while in Sim B it takes an hour to kill someone... and if a land owner wants someone to go away, use llAddToLandBanList() or whatever... if not, damage them like everyone else. Your own comment doesn't seem to make any points about damagnig non-avatars, either? :/
grumble Loudon
A Little bit a lion
Join date: 30 Nov 2005
Posts: 612
03-17-2006 01:54
There are soo many trade offs when designing a game that I don't see any way around having to use SL.

>grumble, this code is already what's done...
>Calculating damage from speed and mass while llSetDamage() exists [it]
>does not work consistently between avatars and non-avatars.
> Why would you have two entirely separate systems if you can help it?

I agree we need a consistant way of detecting damage, but I don't see the existing system of reaching the point where balanced one playergame could be set up since someone will allways have the latest gee wizz script. This means that in order to actualy make a game that stays balanced you need to be able to take away there ability to bring in any outside toys.

For example. Let's imagine a "Doom 1" game with some non existant LL commands.

1. The game is land based in that the land owner has set up the walls, the monstors and the weppons allowed.

2. You are given a weppon that toses a standard bullet and can be selected into different types, however the LLScript limits you to what weppons the land Control script says you have bullets for since the land control script will not accept "Bullet8" collisions when you don't have any left.

3. You get power ups and weppons by stepping on or walking thrue llVolumeDetect prims.

4. Colisions with monstors would eventualy get them to llDie() due to damage.

5. The land control script would be owned by the land owner and therefore would have acess to llTeleporAgentHome(), however I am hopeing that in the future that the land game script would insted restart you back at the start position.

----
Now on a simpler site where you aren't making a complete game llReturnObject(key ID) would allow the land control script to kill objects it feels that they received enough damage.

It's a bit like D&D where you say you killed me and I say I'm in god mode. nananana

Right now I don't see any way of enforcing any kind of game rules or creating a balanced game.
Sylph Lightworker
Registered User
Join date: 2 Dec 2005
Posts: 8
03-17-2006 14:53
From: grumble Loudon

I agree we need a consistant way of detecting damage,


Right.... So...consistent way of detecting damage. Vote please! :P
The rest of it isn't really possible without overhauling SL's entire damage system--or using a closed-source solution...and is rather beside the point of this thread. :)
Iron Ferris
Registered User
Join date: 10 Aug 2006
Posts: 1
08-14-2006 22:30
This would be nice. Or maybe better, a new event:
damage(key inflicter, integer amount)
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
08-16-2006 05:06
I vote LL remove all the combat features, come up with efficient non-hacky object messaging, and let people implement the ones they want themselves.