i need input is this possible

i need to know if it possible to write a script that would alow a peoson to fire a object like a gun any kind of gun and do damage to a object

know you cant really daage it but is it possible to put a counter in it so that when you fire at it the counter increases and it changes it texture after so many counts and same with a repair gun

Tricky, but absolutely possible.

Something similar to this is used for the dogfights, so yes, it's possible. Just takes a fair bit of coding.

Actually not tricky at all. Here's two basic forms...there are more, but these are good places to start.

1. Basic bullet shout

Set up a variable to track HP on the object to be damaged. (iHP = 100);

When a bullet hits something, you can make it shout (set the collision_start event in the bullet script to shout something like "damage," + the detected key of the thing it hit). Make sure your bullets die immediately after the shout.

On the object that you want to take damage, set up a listener that listens for the call "damage," + it's own key.

So, if the bullet hits some random object, it will shout "damage," + some random key. The object that needs to take damage will ignore it, since it is listening for "damage," + it's own key (llGetKey());

When the object to take damage hears "damage," + it's own key, that means the bullet hit that object, so subtract the object-to-be-damaged's HP from the HP variable (HP = HP - whatever). When HP hits 0, llDie.

2. Basic Bullet recognition

Name your bullets something recognizeable (i.e., "My Uber Bullet".

Set up the collission event on the object to be damaged to check for the name of the object colliding with it (so now the bullet never needs to shout).

If something hits the object to be damaged, check the llDetectedName of the object. If that name is "My Uber Bullet", then the object knows it has been hit by a bullet, and you subtract HP. Note that this method can be spoofed (people can create objects named My Uber Bullet). There are ways around this though, but for now we keep it simple.

These are the MOST basic methods to get you started. Naturally, you can also feed in damage dynamically, check for ownership to prevent spoofing, use more filters to reduce shouting, and so on. I do a great deal of this sort of thing in the games I build in SL.

To avoid most spoofing, I'd suggest this.

Bullet, when rezed to fire, shouts a command.

Target has two global list variables, bullets_heard and bullets_hit. It has listen and collision event handlers. When either is triggered, the key of the bullet is added to one of the lists and both lists are compared for matches. If there's a match, the target was hit. Remove the match from the lists and react to the damage.

Only objects that have shouted the secret command on the secret channel and then hit the target will be counted.

The reason for the global variables being lists is to allow for multiple bullets to be tracked at once.

With the new MD5 thumb-printing, you can make this impossible to spoof. As a variable to the bullet's shouted command, combine the bullet's key with a known constant and MD5 it. This listen handler on the target also knows the constant and the bullet's key, so it can combine and MD5 them and compare to the shouted parameter. If they don't match, it's not a valid bullet.

Well, I'd have a number of questions about what you propose. With any real time system (or as real time as SL can get), less is better. Duplicate calls and queuing bullet info may work to a point...

But one thing I'm pretty confident of is the encryption thing. I seriously doubt that will be practical for the same reason that encryption is often not practical in a high performance system (and thereby requires you to architect around it)...encryption is notoriously resource intensive and slow. In the Vorgao, for instance, I would be processing hundreds of encryption calls every few minutes. If they process on the same level as link messages (or even twice as fast), they're not good. Same thing with dataserver calls...SLOW. Practical for bursts of periodic info, no good for getting hit 5 times in 3 seconds.

I'll of course test it, but I know a thing or two about using encryption vs. not using it, and can't imagine the general principals of degraded performance wouldn't apply.

But the question was regarding the basic concepts of if this could be done. I think the above outline provides the best starting point for ze grasshoppah.

I'll tell you though, this is EXACTLY why I so so so wish we had llDetectedCreator, or that you could attach an object without owning it (so something like a "borrowed" flag). It would solve so many of these sorts of problems.