Changes to llSetDamge to better implement Ammo and reduce clutter

FIRST DRAFT

First to start I'll make sure everyone understands the Way Ammo for the Guns seems to work (or at least the ways i've seen it work).

This is what i've seen in the majority of Gun Scripts (including the Popgun).

When Fired the Gun Script Creates a new primitive (usually just a sphere) for the shell. This cost $10.

Then the shell travels at velocituy. Since it has llSetDamage assigned to it, if it hits an Avatar it will be destoryed. You get your 10$ back. IF it did not hit an avatar it would continue to live.

But scripts like The Popgun script will destory the Shell after a few seconds, and again you get your $10 back. It has applied an auto-unrez to the bullet.

However Some gun scripts do not apply this auto unrez and you lose $10. And the ammo i suppose is just laying around cluttering up the server.

this poses a couple problems:

1) Ammo is essentially free if you hit your target or have an auto un-rez applied to the ammo in the script.

2) Ammo that is not auto un-rez must be littering up the servers.

So I think the desired effects of ammo would be:

1) Ammo does cost money for each shell
2) Ammo does un-rez quickly.
3) Optional: It would be cool if you had to buy ammo before using it.

this could be achieved by making a few changes to llSetDamge function.

First add a new arguement.

llSetDamage (float damage, float time);

The time arguement determines how long the object will live until unrezzed. This should be in a range of 1-10 second or something close to that.

So that means anything that does damage will be forced to autp-unrez, even if it MISSES its target.

Second make any object that has llSetDamage applied to it unrez without refund.

When Primitives unrez they refund thier cost back to the owner. Thier needs to be a way so that llSetDamage flips a flag so the Ammo does NOT refund its cost.

This could be done by making llSetDamage make the primitves go PUBLIC. So they dont have an owner to refund too.

So now all ammoe would cost money.


However this might mess up future features to allow damage tracking (who did what damage to whom).

Just for you info: you can make bullets that do not unrez after a time but are always destoryed. There is also an event for when the bullet hits the ground and also you get set it do die when it goes out of the sim's.

So if you put llDie() in the ground collision function you can have bullets that live until they hit *Something* or leave the sims...

True..

But i was thinking about a more uniform way...
Being that currenlty you can make unlimited free ammo.

AND there are those who do not always make thier scripts unrez the ammo...

Anyway... maybe it is not needed. But I thought I'd throw it out there.

Here's a pretty old thread discussing some llSetDamage issues
/invalid_link.html

I'm not sure I like the idea of making llSetDamage not refund your money, or have an auto-die timer, because (believe it or not) it can be used for things other than bullets.

(Typical Wednesday rant follows)
This ties in to theories about language design. That is, do you give the user a power saw, hammer, belt sander and a pile of wood, knowing full well that they are equally likely to make a house, cut their thumb off or do something wonderful that you didn't imagine, or do you give them an E-Z-Build-House-Panel kit and let everyone be nice and safe, but miss out on the unexpected wonderment. I fall firmly in the thumb-cutting-off camp, that is, good general purpose tools, not specific tools for specific tasks.
(/rant)

True again..

If you read my other thread... Pay by value scripting... it could make this thread not needed.

If the FUNCTION llSetDamge cost money to call. then it could be the price for ammo. and you could still be refunded for the primitives.

My point is that ammo should cost money. Now this might seem to be limiting the games people could make. But my main concern is economic.

With a fuacet and drain economy like we have (we get stipends from out of no where) we need all the drains we can get.

I suppose the only real drains that i can see are taxes and uplaoding files.

Im pretty new.. but it seems that is the case to me.

if they charged for using certain(or all) functions including llrezobject(), weapons could become balanced by the price it takes to use them. check out kurt's other thread he started.

By the way, people who do not unrez their bullets will run out of money eventually

off topic:
I think the prices of physics objects should also be much more expansive then primitives.

So if you put physics on you would loose like 50$, if you put if off again you gain 50$, that will encourage people to use the processing intensive physics objects less.

How about this: llRezBullet(float damage) We keep the llSetDamage the way it is, because there are things that do damage toehr than bullets, but if we could create a static, optomized "bullet" object, we could do so much.

Pros:

-Easier to make admin tools to detect who kills who
-No one ends up with their first clumsy bullets with no die cluttering up the world.
-easier to add balance to deathmatches - you could tie this in with a guns "energy" limiting them, making it so not everything was one shot kill.
-make it less likely people are going to make cut hollow torii bullets (and proabbly make deathmatching easier to "optomize" for.
-Make it a lot easier to learn how to script guns - I remeber, back in the day, when I had to figure out how to use llSetDamage, because there were no examples to learn from yet.
-Could do fun particle thingies when bullets hit various materials, because there is no llDetectedMaterial" to tell it if it should create a blood fountain, or the sparks of a riccocet (SP?)



cons:

- More work for poor code monkeys at LL

good idea BBC, or maybe they could make it so that there doesn't even need to be an object. It'll be just a gunshot that instantly gets there. Kinda like most fps's do it anyway.

Of course if we want to make a homing missile that would still be up to us.

Another possibility:

MORE OBJECT OPTIONS!

Right now in the edit window we can set an object as a physics object or not. If we had more options, bullets would not have to be scripted.

I'm thinking phantom, damage (where damage done is some function of size, speed and material), die-at-edge, etc.

It kills me to say this, but eventually there'll probably have to be limits on llRezObject.

As far as I can see, there are many possibilities for creating virus-like scripts. Let's say someone gets a wad of cash over time, $10,000 or so. He could create an object that spawns two copies of itself every second, and activate it on a server with people he doesn't like. After a few seconds, there's a couple hundred objects and the server starts lagging out. Sure, he'd run out of money, but if he was a smart griefer he'd set the boxes to auto-destroy when he told them to, and then he could start it over again whenever he wanted.

So far, I've seen few things on this level of parasitic activity (have seen some out-of-control server-lagging smoke bombs), but it WILL be a problem.

i'm actually pondering making a gun where you have to buy "ammo" as well. i'm not sure how to implement it JUST yet (haven't spent any time looking at the problem), but basically the gun would have a counter (i.e. ammo count), and when you buy an ammo clip, the clip would somehow communicate with the gun how much ammo to add, and then llDie(), thus, if you wanted 5000 rounds for your gatling gun, you'd have to buy 50 boxes of ammo.

is there a way to make objects attached to an avatar communicate directly with other objects attached to the same avatar?

Actually, you can't. Because you can only rez from an object's contents, and because an object includes its contents, you can't put an object inside itself.

But yes, there are bad things you could do with llRezObject. There are bad things you could do with almost any script call. There are things you can do without using any scripts that will totally lag servers. If you take away the possibility to do anything bad, you take away the possibility to do anything good, and you end up with something like TSO.

While Im not a scripter (yet) I do know that you DO "buy" ammo when you fire a weapon. So, isnt it in YOUR best interest to create/ buy a weapon that has ammo that is efficient? Efficient meaning it dies at sim edges and dies in X sec if it fails to hit a target. This then solves the litter issues.

Maybe Im missing the point here but I fail to see how extra fees & outside controls fixes anything. It's our world, script responsibly. If you find someone who hasnt, lend them a hand.

Can't you just kick over a timer in onrez of the bullet with an interval of say 1.5, put a counter in the timer event, when that counter gets to say 3, llDie()?

or just set the timer event to 4.5 sec

you do "buy" ammo, in terms of the rez cost of the bullet. however, on WELL-SCRIPTED guns, the bullets die after a while, and you get the rez cost back. what we're discussing here is a PERMANENT cost for the ammo, i.e. even when the bullet goes away, you still experience a net loss of L$, because you purchased the ammo clip (mentioned in my 1st post in this thread), and THEN had to pay the [temporary] rez cost of each self-de-rezzing bullet.

Seriously though Phil, why? I guess I dont get it. Why would rounds be subject to permanent loss of $ where other prims are not?

Yeah Phil true that. My bullets do other things that require counters but the one-shot timer would probably do for most.

The idea of ammo permanently costing money isn't without merit. If you build an object then hurl it at somebody with incredible force, you are going to damage that object (and the "somebody" along with it). This should likely result in the loss of the hurled item (unless you are figuratively prepared to pry the bullet out of a tree or corpse with a knife and melt it back down/reload it ;p).

Maybe consider anything moving over a certain velocity to be AMMO by default, and then subject to non-remimbursement on delete, unless maybe it goes off world...?

Simple, efficient Bullet Script:

float damage = 25.0;     // 100 will kill in 1 shot

default
{
   state_entry()
   {
      llSetDamage(damage);    //Makes the bullet able to damage
      llSetBouyancy(1.0);          //Makes the bullet float (remove for "realistic" guns)
      llSetStatus(STATUS_PHYSICS | STATUS_DIE_AT_EDGE, TRUE);      //Turns on physics, makes it so you don't have a buncha (offworld) junk in your inv.
   }

   on_rez(integer param)
   {
      llSetTimerEvent(3.0);     // set the lifetime of the bullet
   }

   timer()
   {
      llDie();  //if the bullet has not hit an av yet, it dies - you get your money back
    }
}

This is a no frils bullet - no fancy collision sounds or particle effects - and in turn, probably less likely to generate lag.

ps I just wrote it here, so it might have some misspellings or something.

charging for ammo would be entirely up to the gun scripter, but i think would help to cut down on grief-killing. i know that, the other day when i was editing an object, i was killed at least three times, and was claimed as a "prisoner of war" once (i then promptly killed my captor, thus ending that problem). i can't help but wonder if the grief-killers* would have shot me if it would have cost them money to do so... i was standing, unarmed, with the standard line issuing forth from me indicating i'm editing something.

* (i suppose the POW guy was doing it in a quasi-legitimate fashion - at least he didn't just run up and shoot me while it's obvious i'm not interested in fighting at the moment)

besides, charging for ammo is a way for gun makers to ensure a continued source of revenue, even after everyone in SL has bought one of their guns

Good Points all around.

After thinking about it I do agree making AMMO primitives non refund LIMITS the players too much.

I originally wanted a global forced cost on ammo becuase that is the kind of game I want to play (and it makes since).
I think it is kinda silly even to try and make a game with combat without limitations on what you can usea s weapons.

However, SL has large potential for players to make up thier own games.

I think that we need a more robust SCRIPT FILTERING system. I think it could be accomplished with a SIM LEVEL 'outside scripts' system.

Read my thread ''Outside Script' switch in regards to sim self-government and the Outlands. ' and please comment.


But I do still agree that Scripts should be taxes based on functionality.
Not only does it give us one more thing to spend money on but it also gives scripters another goal (making cheap scripts) which will be a distinguishing factor between good scripters and bad ones.