attached object die

if you have say a dispenser of some sort that give people an object

they have to wear after say 5 minutes you want them to no longer own it

what do you do?

i know this is possible on say jetskis where you sit on it and when you stand it dies

but how do you manage with attached objects

i think LL are missing a trick here as if it were easy to kill objects in this way it would create for more free games in sl with nice attachments rather than the freebie tat that is often settled for

i have seen people discuss possibilities for say

llDrop()
and so on as a potential idea but is there anyway around this

is it possible to say give a nice attachment as a demo for example so people can try it and then it die after 5 mins or something similar

to not have this option is stupid

JJ

Nope. Can't really do it - but you could do something to damage it or otherwise render it useless to them -- maybe after 5 minutes it goes transparent (making it still exist, but pointless to wear). If the item is "no mod" they won't be able to reset the scripts or set them to not running. So a timer would just go off every 10 seconds or so to ensure that they don't mess with the alpha levels in some other way. <shrug> I'm sure there are more things you can do to make an attachment work for a while - and then make it become undesirable/unusable after a predetermined time. That's just what popped into my head offhand.

float timeout = .01;

default{
  link_message( integer source, integer number, string message, key data ){
    //-- if message = some special mesage
    //-- set a more reasonable timeout from the message
    state sRunning;
  }
}

state sRunning{
 //-- other operating code

  changed( integer vBitChanges ){
    if (CHANGED_OWNER & vBitChanges){
      llSetTimerEvent( timeout );
      timeout = .01;
    }
  }

  timer(){
    //-- set a bunch of prim properties to visually disable it
    llRemoveInventory( llGetScriptName() );
  }
}

activation script (used by the creator to set it up)

default{
  state_entry(){
    llMessageLinked( LINK_ROOT, :: insert special variables here :: );
    llRemoveInventory( llGetScriptName() );
  }
}

this method is immune to script resets, and can check for the name of a special file (and then delete it) to activate as well. for best effect object should be no copy, and no mod will prevent all attack vectors.

Meanwhile... Please vote for these:

https://jira.secondlife.com/browse/SVC-2281
LSL Function - > Object -> llDrop

https://jira.secondlife.com/browse/SVC-2282
LSL Function - > Object -> llDieAttached

https://jira.secondlife.com/browse/SVC-2454
LSL Function - > Object -> llDetachFromAvatarAndTrash

yes die attached is a brilliant idea ))P

I was going to add this as an edit, but then you commented, so I figured I should add it as a new post in the thread to make sure you see it.

as they say what a song and dance when something like attach die or similar could rectify it

Um, most of that song and dance would still be needed if you had llDieAttached, because most of it is deciding when to die.

a simple timer event with die is nothing like as complicated

and its definitely dead too GAWN

Um, that *is* a simple timer event. The complexity is deciding when to start the timer. And you gotta have that in there whether you llDie() or llSetAlpha() and llRemoveInventory() at the end.

i managed to do it another way in the end

simple timer much more simple than ...vBitChanges....

and a delete inventory found here

http://lslwiki.net/lslwiki/wakka.php?wakka=llRemoveInventory

so instead of die simply swapped it for llRemoveInventory

dead simple - all i am saying a lot of scripters tend to 'show off' their skills when something much more simple will do thats beneath them

for newbs to scripting like me who have not studied code or C and the like ever and have no idea what they are looking at i think simple is best

if it works it works

there is a reason for not using a simple timer and llRemoveInventory such scripts might get reset, which as long as the user keeps resetting the script before the timer goes off, they've got it for free.

attack vectors are:
script injection (adding a monitor script or your own messaging script)
script deletion (removing a separate timeout script)
script resets (resetting the script to regain the benefits)
no script land (used to halt scripts to fiddle with things)
+copy (if it's in inventory it just rezzes a new copy)
+mod (used for script injection and hidden prim property checking)

solutions are
-mod (stop both script injection and checking of hidden prim properties)
built-in timer (prevents deletion attacks)
pre-activation of a by separate script with a state change (prevents reset attacks)
-copy (duh)

the script above is actually the simplest case to cover ALL the basic attacks (though it won't stop copybots from duplicating the prim structure/textures, but we're talking scripts here)

it CAN be much more complex, using prim creator check, inventory creator checks, hashing and true authentication on auth script, and multiple hidden prim property checks. all tricks I've been incorporating in my own Demo-Use scripts.

thanks for the explanations that really helps that said the item is no mod its not a problem using the simple code - i think - even if they reset it if part of the inventory is gone its not much use X) - plus you can have a message linked telling textures to bork

why a message linked? why not llSetLinkTexture, llSetLinkAlpha, or llSetLinkPrimitiveParams

on a side note. if you're one of those builders that does demo hair or other attachments with one of those silly signs hovering over the avatar's head. make sure you don't have any alpha in the demo sign, cause that can be covered with an invisibility prim

I believe the best scripter was proven to be SQL Miles

Wait.. that makes me Qui-Gon Jinn. Aside from making me unexpectedly male.. this makes me the Jedi who doesn't listen to anyone, does whatever he wants, bends the rules just.. you know.. cause, whose obvious gambling problem leads him into betting whole starships he doesn't even own on the motorsports equivalent of a back country cock-fight... and then gets unexpectedly cut in half by some no-talent hack painted red, with no speaking lines, a penchant for wire-flying, and an obviously-over-compensating-for-something light saber. And then, at the end of it all, has a death scene that breaks the entire mythos of Jedi fading away.

Of course.. that does mean I get to be Liam Neeson.

So, maybe I'm okay with this.

Clearly we just need more female Jedi role-models.

lmao

my ego loves to hear this, but seriously I'm not that great... ya wanna know who I look up to as far as coding and digging into everything that's available (and posting about it for all our benefit)?
Argent Stonecutter, Strife Onizuka, Nexii Malthus, Ordinal Malaprop, Jesse Barnett, Talarus Luan, and about a dozen others that frequent here.

my only claim to fame is tutoring, unique perspective (looking for workarounds), and spending way too much time scripting in second life, and posting way too much on this forum. everything else is down to picking up effective tricks for SL since being here shortly after they went public (and that was an ACCIDENT!)

regardless who it is though, question everything (me especially since my memory isn't so great, and I miss new stuff)

PS I was born on the dark side (maybe more like Atris at heart, A bit of Kreia'a planning, and a lot of The Exile's affinity for picking up new things... and I shall now hide in shame for sharing that)

My ego thanks your ego.

The rest of the Jedi Council...

I too see posts from these folks, and they offer up good advice too. Especially all the hard work Strife puts into the wiki. My main point though was to advise the newbie to ask why rather than make bold statements like he was. Like I said before, even though I'm a seasoned scripter, I tend to (and always have since coding in Level II Basic on the TRS-80 Model I) study other peoples code to see what I can pick up. I recently taught myself Adobe Flash, and the best way to learn is by studying other peoples code. One of the nice things about the internet now a days is that you can often times, especially here in SL, chat directly with the coder for further advice.

good point and very similar philosophy...examine everything and ask why =) it is nice to be able to get info straight from the person using it. (or to be able to suggest more efficient ways)

Jedi Council, me? Yeah, right! Just think of me as JarJar! I have never been a good scripter, none the less, a great one, I am simply just a hard headed old bitch. I might take days to get a script how I want it while someone else could do it in a couple of hours. Flashes of brilliance are extremely rare, I simply throw everything at it until I beat the script into submission That coupled with A LOT of debugging; create a simple example, test, add a layer, test, correct, add more, test, correct, rinse & repeat.

Now back to the OP.......... First off we would all like to welcome you to the Scripting Forum Junglejim! A couple of nice threads from you already here and we hope to see many more. Also hoping at some point you take the knowledge that you already have and will gain and share it with others. The ranks of those answering questions have diminished over the years and we would love to see the input of another.

Now about the "over complicated" bit. First thing you learn in LSL is that there are a lot of constraints, the biggest constraint of all is the size limitation. For this reason, NO ONE ever over complicates a script or adds more then necessary. The points Void made were not based on a special insight of the language, unfortunately each one was learned by a content creator that lost their hard work. I guess at some point we should make a wiki page about the various attacks used against scripts, until that point we just use our memories gleaned from sorrowful tales told by creators.

Hope to see some wonderful creations from you soon with no accompanying tales of tragedy. Post a link if you have a store in world or on XStreet, I would love to check them out.

ya know that's an excellent idea, though where on the wiki it should go is another question entirely (and should probably be limited in how the attacks work) some of those are content issues, but many of them are script issues... need some time to think about it.

PS. you are are still script jedi now... even if you spend all your time running around discovering things, and teaching the new recruits

and I can't believe I forgot HeeWee Zetkin in my list.... amazing coder, despite or differences of opinion in style =)