PeterAims

Thank You everyone for your help, it looks like my learning progress should be a lot smoother from here on. @ LepreKhaun Yeah, switching states simplified the code. I can already see the limits of using states for certain things but it helps a new scritpter to look at simpler code. I stumbled onto a script that toggled the listener really well without switching states but it ivolved much more code using techniques i haven't began to touch so I went with this instead.

This is the simplest code I can manage at the moment for my listener. When I looked up some information on llListen I noticed the wiki mentioned that a state change would release any listeners in a state. By changing state it solved two problems for me, toggling edit modes and turning off the listener. I was also able to remove some code and it seems much simpler for a learning scripter like me. I did use llOwnerSay and llSetTex to confirm states were changing. If everything seems fine I should be able to continue working on these on my own and build more complicated scripts. key owner;//placeholder for the owner's uuidinteger chan = -12345;default{ touch_end(integer total_number) { if(llDetectedKey(0) == llGetOwner()) // if the owner touched it, then state EDIT_ON; // change state }}state EDIT_ON{ state_entry() { owner = llGetOwner();//get the owner's uuid llListen(chan, "", NULL_KEY, ""); //listen to messages from anyone on 1234 llSetTimerEvent(60.0); // keep the listener alive for one minute } touch_end(integer total_number) { if(llDetectedKey(0) == llGetOwner()) // if the owner touched it, then llSetTimerEvent(0.0); // clear the timer state default; // change state } changed(integer change) { if (change & CHANGED_OWNER) //if the owner changes { owner = llGetOwner();//get the new owner's uuid } } listen(integer channel, string name, key id, string message) { llSetTimerEvent(60.0); // keep the listener alive by resetting the timer if (llGetOwnerKey(id) == owner) // if the message is from an object belonging to my owner, or from my owner, { if (message == "tex1") llSetTexture("xxxxx-xxxxx-xxxxx-xxxxx-xxxxx", ALL_SIDES); } } timer() { // we haven't heard anything so, llSetTimerEvent(0.0); // clear the timer state default; // change state }}

Yes perfectly, thats the basic understanding I had while looking at that part of the code but I wasn't too sure. The more I look at the code the clearer it should get from this point on. Everyone has been so helpfull, its nice to have residents to ask about these things scripting can be pretty intimidating at first. :smileyhappy:

That code looks great. I probably should of been more clear in what I needed, that's my fault. I hope I understand this code correctly, (hopefully) mostly. I'm curious how is llSet TimerEvent(60.0) reset in the following code below? Does it reset the timer with every message that is heard from the HUD, cause that would be ideal functionality so editing mode doesn't close suddenly. Am I understanding correctly or do I also need to add an integer to reset the timer after every button click? listen( integer channel, string name, key id, string message ) { llSetTimerEvent(60.0); // keep the listener alive by resetting the timer // ... other code to interact with HUD here ... }

LepreKhaun wrote: You could have the listener default to off in the object and only turn on for (say) 60 seconds when touched by it's owner. With just one listener ever active when the HUD started chatting, you'd never have a problem. @ Vexacion That's another good solution, sadly it sounds a little complicated for my level of scripting. Maybe at a later time when I'm a little more experienced. @ LepreKhaun That is an elegant and simple solution LepreKhaun!! :smileyvery-happy: Touch an object to activate edit mode by turning on its listener that is brilliant. I think that's simple enough for me to script to have only the owner activate it. This also makes it trouble free to only edit the objects you want when there close to each other, for instance walls or columns and only specific walls or columns that are touched. First touch turns on listener and activates timer >> Second touch shuts off listener. If the listener is shut off early by a really quick edit, I wonder does the timer also need to be shut off? Or it probably wouldn't be a problem, maybe.

I really appreciate the help, its really great, but some suggestions here can get pretty technical for a person just starting to do this. Isn't llSay or llShout with llGetOwner enough for a simple functioning HUD? I recently just read a little about llRegionSayto, and please excuse my ignorance but wouldn't llRegionSayto also control multiple objects if there duplicated next to eachother? That is what I'm hoping for, controlling an object only when I'm close to it. I might not understand alot but llSay or llShout with llGetOwer seems like it should be enough.

I'm using llGetOwner like Innula Zenovka suggested, shouldn't that prevent conflicts between multiple HUD's? Is there a trade off of localized influence and running HUD's without conflicts? Both is not possible? http://community.secondlife.com/t5/LSL-Scripting/llGetOwner-breaks-my-tiny-script/td-p/2720976

@Nova Convair I thought of making a 20 meter sphere, make it 75% transparent with a reddish tint and attach it to myself to always see a 10 meter diameter around me. LOL Primitive thinking seems to offer the simplest solutions. But using your code is pretty awesome too.

That is very helpfull, thank you.

I was pretty content with some scripts for an HUD and its object I had working, but then I realized if I rez duplicates of my object, my HUD will control all of them. I was wondereing if there was an alternative to llRegionSay that works only at near distance so that I can control objects only when I'm near them.

Wow. This works fine, I can't thank you enough. This makes giving away functional objects so much more enjoyable. P.S. "If the new owner changes, get the new owner's uuid" I had missed that on first looking at it. lol

Oh right, I am so new, it was a small hurdle coming up with this on my own. This is good homework to study with, your help is invaluable for a new mind trying to understand scripting. I just remembered one last question. I this script properly suited for giving it away to others, or when a owner changes?

Oh I hope I'm getting it, the UUID place holder is for the UUID of the HUD object itself? Ok I'm going to try this, thank you so much.

A key owner place holder seems like It won't be suited for giving the HUD and receiving object away to others. From what I seem to under stand a key owner place holder would restrict the HUD to only working for me.

I opologize, I didn't think of including the HUD script beleiveing it wasn't the problem also. Here is the sending script. integer channel = 1234; default { touch_start(integer total_number) { if (llDetectedLinkNumber(0)== 2) llRegionSay(channel, "tex3"); } }

I have a tiny listener script that breaks when I change it to llGetOwner. I have read that I need to add this function because its appropiate for HUD's, but it seems to break my listener script, please help. This works: default { state_entry() { llListen(1234, "", NULL_KEY, ""); } listen(integer channel, string name, key id, string message) { if (message == "tex3") llSetTexture("xxxxx-xxxxx-xxxxx-xxxxx-xxxxx", ALL_SIDES); } } When I change NULL_KEY to llGetOwner it stops working default { state_entry() { llListen(1234, "", llGetOwner(), ""); } listen(integer channel, string name, key id, string message) { if (message == "tex3") llSetTexture("xxxxx-xxxxx-xxxxx-xxxxx-xxxxx", ALL_SIDES); } }