Patrick Playfair Posted June 15, 2017 Share Posted June 15, 2017 (edited) I am using Experience permissions to auto-attach an RLV HUD (relay) when visitors come to my sim. After it attaches I issue a "llOwnerSay("@detach=n");" command and the user cannot detach it. It auto-detaches when they leave the sim. It is working fine. However I have a HUD, and a UFO that I use to force sit them, and I use the following commands. To sit them I use the following: string restraints = "@unsit=n|@sittp=n|@tploc=n|@tplure=n|@tplm=n"; string cmdsit = cmdname + "," + (string)id + "," + restraints; llSay(relaychannel, cmdname + "," + (string)victim + "," + "@sit:" + (string)object + "=force"); llSay(relaychannel, cmdsit); It works fine, sits the user, and restricts them from standing & TP'ing. When I unsit them, I use the following: string unrestraints = "@unsit=y|@sittp=y|@tploc=y|@tplure=y|@tplm=y"; string cmdsit = cmdname + "," + (string)id + "," + unrestraints; llSay(relaychannel, cmdname + "," + (string)victim + "," + "@unsit:" + (string)object + "=force"); llSay(relaychannel, cmdsit); It unsits them and removes the restrictions, but it also removes the "@detach=n" restriction. If I add a "@detach=n" restriction to the unrestraint string, the HUD stays RED and says I still have control of it. Any thoughts on how to resolve this? Item number 2..... I use the following dialog menu to select a destination to TP to, I also use a similar one to choose a sound and play it. However, whenever I make a choice, local chat speaks it, as though I am speaking it. In other words, if I chose LOUNGE, it appears that I said LOUNGE in local chat, if I choose EXIT, I say EXIT in local chat. I cannot find what is causing this or how to stop it. // Multi-Page Landmark Selector // Omei Qunhua April 2014 // Modified by Patrick Playfair list gListFullNames; // List of inventory landmarks list gListBriefNames; // List of abbreviated landmark names for dialog buttons list details; integer gPage; // Current dialog page number (counting from zero) integer gMaxPage; // Highest page number (counting from zero) integer gChan; // Channel used for dialog communications. key gUser; // Menu User key victim; // Avatar to Perform command on vector pos; string destination; // Destination DestinationMenu(key user) { integer TotalChoices = (gListBriefNames != [] ); // get length of landmark list // set up scrolling buttons if needed list buttons = [ "<<","EXIT", ">>" ]; integer ChoicesPerPage = 9; if (TotalChoices < 13) { buttons = ["EXIT"]; ChoicesPerPage = 12; } // Compute number of menu pages that will be available gMaxPage = (TotalChoices - 1) / ChoicesPerPage; // Build a dialog menu for current page for given user integer start = ChoicesPerPage * gPage; // starting offset into action list for current page // 'start + ChoicesPerPage -1' might point beyond the end of the list - // - but LSL stops at the list end, without throwing a wobbly buttons += llList2List(gListBriefNames, start, start + ChoicesPerPage - 1); llDialog(user, "\nPage " + (string) (gPage+1) + " of " + (string) (gMaxPage + 1) + "\n\nChoose a Destination", buttons, gChan); llSetTimerEvent(15); // If no response in time, return to 'ready' state } default { link_message(integer sender,integer num,string msg,key id) { if (num == 2) { victim = id; // Compute a negative communications channel based on prim UUID integer gChan = (integer)(llFrand(99999.0) * -1); gUser = llGetOwner(); integer count = llGetInventoryNumber(INVENTORY_LANDMARK); string name; while (count--) { name = llGetInventoryName(INVENTORY_LANDMARK, count); gListFullNames += name; gListBriefNames += llGetSubString(name, 0, 23); } } else { llResetScript(); } state busy; // Changing state sets the application to a busy condition while one user is selecting from the dialogs // In the event of multiple 'simultaneous' touches, only one user will get a dialog } } state busy { state_entry() { llListen(gChan, "", gUser, ""); // This listener will be used throughout this state gPage = 0; DestinationMenu(gUser); } listen (integer chan, string name, key id, string msg) { integer index; if (msg == "<<" || msg == ">>") // Page change ... { if (msg == "<<") --gPage; // Page back if (msg == ">>") ++gPage; // Page forward if (gPage < 0) gPage = gMaxPage; // cycle around pages if (gPage > gMaxPage) gPage = 0; DestinationMenu(id); return; } if (msg == "EXIT") { llResetScript(); } if (msg == "") { llResetScript(); } if (msg != " ") // no action on blank menu button { // User has selected a landmark from the menu llSetTimerEvent(0); index = llListFindList(gListBriefNames, [msg]); destination = llList2String(gListFullNames, index); integer channel = llRound(llFrand(-1000)); key give_to = victim; llRezObject("Alien Zapper!", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, channel); llRegionSay(channel, "ATTACH|" + (string)give_to +"|" + destination); llResetScript(); } else { llResetScript(); } } timer() { llOwnerSay("Too slow, menu cancelled"); llResetScript(); } } Edited June 15, 2017 by Patrick Playfair typos Link to comment Share on other sites More sharing options...
Rolig Loon Posted June 15, 2017 Share Posted June 15, 2017 (edited) Sorry. I started a reply, but it's too complicated to do on a cell phone. ? Edited June 15, 2017 by Rolig Loon Link to comment Share on other sites More sharing options...
Innula Zenovka Posted June 15, 2017 Share Posted June 15, 2017 (edited) The reason it's repeating your menu choice in local chat, I think, is that you declare gChan as a global variable (which is what you want) but you then re-declare it in the link message event, if (num == 2) { victim = id; // Compute a negative communications channel based on prim UUID integer gChan = (integer)(llFrand(99999.0) * -1); gUser = llGetOwner(); integer count = llGetInventoryNumber(INVENTORY_LANDMARK); string name; while (count--) { name = llGetInventoryName(INVENTORY_LANDMARK, count); gListFullNames += name; gListBriefNames += llGetSubString(name, 0, 23); } } That has the effect of turning it into a local variable, available only in that event. So by the time you get to state busy, the script has forgotten what gChan is, and defaults it to 0. So lose that second declaration, and simply assign a value there, and it should work. I'll try to think what the RLV issue might be, since it's by no means obvious what's causing it. Have you turned on Show Debug Messages on the RLV menu? Does that cast any light on the subject? What in the script actually does send "@detach=y" and could the script be getting the two prompts mixed up? Edited June 15, 2017 by Innula Zenovka Link to comment Share on other sites More sharing options...
Patrick Playfair Posted June 16, 2017 Author Share Posted June 16, 2017 On 6/15/2017 at 4:08 AM, Innula Zenovka said: The reason it's repeating your menu choice in local chat, I think, is that you declare gChan as a global variable (which is what you want) but you then re-declare it in the link message event, if (num == 2) { victim = id; // Compute a negative communications channel based on prim UUID integer gChan = (integer)(llFrand(99999.0) * -1); gUser = llGetOwner(); integer count = llGetInventoryNumber(INVENTORY_LANDMARK); string name; while (count--) { name = llGetInventoryName(INVENTORY_LANDMARK, count); gListFullNames += name; gListBriefNames += llGetSubString(name, 0, 23); } } That has the effect of turning it into a local variable, available only in that event. So by the time you get to state busy, the script has forgotten what gChan is, and defaults it to 0. So lose that second declaration, and simply assign a value there, and it should work. I'll try to think what the RLV issue might be, since it's by no means obvious what's causing it. Have you turned on Show Debug Messages on the RLV menu? Does that cast any light on the subject? What in the script actually does send "@detach=y" and could the script be getting the two prompts mixed up? Good catch on the second declaration, that was it! As for the "@detach=y", it is not sent anywhere in the script that I can see. Will look closer and see if I can find anything. Thanks Link to comment Share on other sites More sharing options...
Klytyna Posted June 16, 2017 Share Posted June 16, 2017 On 15 June 2017 at 2:27 AM, Patrick Playfair said: I am using Experience permissions to auto-attach an RLV HUD (relay) when visitors come to my sim. After it attaches I issue a "llOwnerSay("@detach=n");" command and the user cannot detach it. It auto-detaches when they leave the sim. It is working fine. However I have a HUD, and a UFO that I use to force sit them, and I use the following commands. To sit them I use the following: string restraints = "@unsit=n|@sittp=n|@tploc=n|@tplure=n|@tplm=n"; string cmdsit = cmdname + "," + (string)id + "," + restraints; llSay(relaychannel, cmdname + "," + (string)victim + "," + "@sit:" + (string)object + "=force"); llSay(relaychannel, cmdsit); It works fine, sits the user, and restricts them from standing & TP'ing. When I unsit them, I use the following: string unrestraints = "@unsit=y|@sittp=y|@tploc=y|@tplure=y|@tplm=y"; string cmdsit = cmdname + "," + (string)id + "," + unrestraints; llSay(relaychannel, cmdname + "," + (string)victim + "," + "@unsit:" + (string)object + "=force"); llSay(relaychannel, cmdsit); It unsits them and removes the restrictions, but it also removes the "@detach=n" restriction. If I add a "@detach=n" restriction to the unrestraint string, the HUD stays RED and says I still have control of it. Any thoughts on how to resolve this? This is... One of the WORST combinations of Experiences and RLV that I've heard of. Since you are running an RLV Sim, odds are your RLV using visitors will ALREADY have a relay on, and wearing two or more working relays can cause all kinds of annoying conflicts. If they don't use RLV, adding a relay hud just means they get chat spammed with rlv commands. If you are using llattachtoavatar or llattachtoavatartemp, those are 'wear' commands not 'add' commands so if they have a hud in the target attachment point already, thats locked on your 'hud attach' will probably fail utterly anyway. As far as your rlv scripting goes, first of all I wouldn't use llsay or llownersay, but llregionsayto, as it's a little faster since it doesn't have to do chat range checks. Now your forcesit hud code... You appear to assemble this string 'cmdname' and the list of restricts/unrestricts together and shove that in before the target name, without the proper pipe command characters. This is a valid rlv command sequence for an example... llSay(RELAY_CH, "detach," + (string)target + ",@detach:skull=force|@detach:mouth=force|@detach:chin=force|@detach:left ear=force|@detach:right ear=force|@detach:left eyeball=force|@detach:right eyeball=force|@detach:nose=force|@detach:neck=force"); If I had assembled that the way you have, it would look like this... llSay(RELAY_CH, "detach@detach:skull=force|@detach:mouth=force|@detach:chin=force|@detach:left ear=force|@detach:right ear=force|@detach:left eyeball=force|@detach:right eyeball=force|@detach:nose=force ," + (string)target + ", @detach:neck=force "); I've highlighted the area that may cause your problems. The relay hud you spam your visitors with, assuming it's one of the mainstream relays, may well decide that your force sit hud is spamming with defunct rlv commands when you issue the unsit, in which case the RELAY may well be issuing a @clear which would remove the @detach=n, hard to say without asking a pro rlv coder, and doing a lot of tests, but your format for assembling the rlv command string looks more than a little suspect to me. Link to comment Share on other sites More sharing options...
Patrick Playfair Posted June 16, 2017 Author Share Posted June 16, 2017 (edited) 2 hours ago, Klytyna said: This is... One of the WORST combinations of Experiences and RLV that I've heard of. Since you are running an RLV Sim, odds are your RLV using visitors will ALREADY have a relay on, and wearing two or more working relays can cause all kinds of annoying conflicts. If they don't use RLV, adding a relay hud just means they get chat spammed with rlv commands. If you are using llattachtoavatar or llattachtoavatartemp, those are 'wear' commands not 'add' commands so if they have a hud in the target attachment point already, thats locked on your 'hud attach' will probably fail utterly anyway. As far as your rlv scripting goes, first of all I wouldn't use llsay or llownersay, but llregionsayto, as it's a little faster since it doesn't have to do chat range checks. Now your forcesit hud code... You appear to assemble this string 'cmdname' and the list of restricts/unrestricts together and shove that in before the target name, without the proper pipe command characters. This is a valid rlv command sequence for an example... llSay(RELAY_CH, "detach," + (string)target + ",@detach:skull=force|@detach:mouth=force|@detach:chin=force|@detach:left ear=force|@detach:right ear=force|@detach:left eyeball=force|@detach:right eyeball=force|@detach:nose=force|@detach:neck=force"); If I had assembled that the way you have, it would look like this... llSay(RELAY_CH, "detach@detach:skull=force|@detach:mouth=force|@detach:chin=force|@detach:left ear=force|@detach:right ear=force|@detach:left eyeball=force|@detach:right eyeball=force|@detach:nose=force ," + (string)target + ", @detach:neck=force "); I've highlighted the area that may cause your problems. The relay hud you spam your visitors with, assuming it's one of the mainstream relays, may well decide that your force sit hud is spamming with defunct rlv commands when you issue the unsit, in which case the RELAY may well be issuing a @clear which would remove the @detach=n, hard to say without asking a pro rlv coder, and doing a lot of tests, but your format for assembling the rlv command string looks more than a little suspect to me. All users to our sim are checked for an active RLV relay upon landing, and are only issued one if they do not have one on. They are then checked again, and if still not detected, they are instructed on how to enable and use RLV. EXP is used only for two things. To attach the relay and for Teleports. I do not understand what is so HORRIBLE about that. Back to the original question, looking at your "valid command string" all I see is "@detach" commands. My script doesn't even have the word detach in it. I do not want to detach anything. They are not allowed to detach their relay before my script runs, but they are after, and I have NOT issued a "@detach=y" command, so I am wondering why they can detach it after my script runs. I do appreciate the response, and will review your command suggestions again and revisit them. All of the other restraints and unrestraints however work exactly as expected, so I do not suspect the command string is the problem. (I will change them to llRegionSayto, thank you) Thanks for the response... Edited June 16, 2017 by Patrick Playfair Link to comment Share on other sites More sharing options...
Innula Zenovka Posted June 16, 2017 Share Posted June 16, 2017 How does the relay know when it's supposed to issue @detach=y? If everything is happening as it's supposed to, I mean. Link to comment Share on other sites More sharing options...
Patrick Playfair Posted June 17, 2017 Author Share Posted June 17, 2017 20 minutes ago, Innula Zenovka said: How does the relay know when it's supposed to issue @detach=y? If everything is happening as it's supposed to, I mean. The @detach=n is issued when the relay is attached, by the relay itself. As for detach, because it is attach-temp, it detaches automatically when they leave the sim or logout. Link to comment Share on other sites More sharing options...
Klytyna Posted June 17, 2017 Share Posted June 17, 2017 9 hours ago, Patrick Playfair said: All users to our sim are checked for an active RLV relay upon landing, and are only issued one if they do not have one on. They are then checked again, and if still not detected, they are instructed on how to enable and use RLV. EXP is used only for two things. To attach the relay and for Teleports. I do not understand what is so HORRIBLE about that. Back to the original question, looking at your "valid command string" all I see is "@detach" commands. My script doesn't even have the word detach in it. I do not want to detach anything. They are not allowed to detach their relay before my script runs, but they are after, and I have NOT issued a "@detach=y" command, so I am wondering why they can detach it after my script runs. I do appreciate the response, and will review your command suggestions again and revisit them. All of the other restraints and unrestraints however work exactly as expected, so I do not suspect the command string is the problem. (I will change them to llRegionSayto, thank you) Thanks for the response... I didn't say it was HORRIBLE, I said it was bad... Your device checks for an active relay, well that's nice. I hope you check with a command that's actually accepted by all relays, some flavours of @notify for example, are simply ignored by many collar based relays, thats why the Infectious Rubber Skunks died out, they used an old @notify variant to check relays, and newer relays ignored the command, so the rlv infection code never triggered because it assumed people didn't HAVE relays. Another well known RLV sim, implemented an 'auto-safeword-abuse-24hr-ban' system that was supposed to detect if you had a relay, and if it thought you were constantly safewording out of the traps would ban you from the sim for 24 hours, problem again, the paranoid possessive MoFo who coded this, used a relay check command in the auto banner and their traps that was simply ignored by many modern, and commonly used relays, so even with your relay set to auto, the traps didn't work and 3 failed tries later boot, you were off the sim. It did wonder's for their traffic figures, *wink* and eventually they dropped that badly implemented nonsense. Now, your code... You are using 5 lines with string concactenation and surplus variables to do something that should take oh... 1 line. On 15 June 2017 at 2:27 AM, Patrick Playfair said: string restraints = "@unsit=n|@sittp=n|@tploc=n|@tplure=n|@tplm=n"; string cmdsit = cmdname + "," + (string)id + "," + restraints; llSay(relaychannel, cmdname + "," + (string)victim + "," + "@sit:" + (string)object + "=force"); llSay(relaychannel, cmdsit); There's 4 lines plus of course the line where you define 'cmdname'. Here's how it should look. llSay(relaychannel,"[whatever is in string 'cmdname']," + (string)victim + ",@sit" + (string)object + "=force|@unsit=n|@sittp=n|tploc=n|@tplure=n|tplm=n" ); See how much shorter and probably faster that would be. More importantly, if you get problems you can see EXACTLY what is in the command you are sending which makes it easier to figure where you made that typo that causes an rlv command to get ignored or to do the unexpected, without having to twarl through a load of variable definition statements and mentally figure how they get concactenated, and where the problem actually lies. Easier debugging, Less... is More.... 1 Link to comment Share on other sites More sharing options...
Innula Zenovka Posted June 17, 2017 Share Posted June 17, 2017 (edited) 15 hours ago, Patrick Playfair said: The @detach=n is issued when the relay is attached, by the relay itself. As for detach, because it is attach-temp, it detaches automatically when they leave the sim or logout. How strange. I was under the impression that if something calls @detach=n, then commands issued by other objects can't over-ride it (so I can't cheat and unlock one of my attachments by rezzing a prim and sending "@detach:<attach_point_name>=y"), but it looks as if I may be mistaken. How about attaching a debug prim, listening on the RLV Relay channel that repeats the messages it receives plus the name of the object sending them? That should tell you what's sending @detach=y. ETA: Am I correct in assuming that your HUD is a simply relay, listening on a channel other than the RLV Relay Channel, and, after some security checks, issuing preset commands in response to specific prompts (which is how I'd do it)? If you're temp attaching a full-blown RLV relay then, potentially at least, that changes things quite considerably. Edited June 17, 2017 by Innula Zenovka Link to comment Share on other sites More sharing options...
Patrick Playfair Posted June 18, 2017 Author Share Posted June 18, 2017 On 6/17/2017 at 5:21 AM, Innula Zenovka said: How strange. I was under the impression that if something calls @detach=n, then commands issued by other objects can't over-ride it (so I can't cheat and unlock one of my attachments by rezzing a prim and sending "@detach:<attach_point_name>=y"), but it looks as if I may be mistaken. How about attaching a debug prim, listening on the RLV Relay channel that repeats the messages it receives plus the name of the object sending them? That should tell you what's sending @detach=y. ETA: Am I correct in assuming that your HUD is a simply relay, listening on a channel other than the RLV Relay Channel, and, after some security checks, issuing preset commands in response to specific prompts (which is how I'd do it)? If you're temp attaching a full-blown RLV relay then, potentially at least, that changes things quite considerably. I will try that, and see if I can figure out where the @detach=y or @clear or whatever is coming from . You are correct, it is a simple relay (in fact, the name of it is Simple RLV HUD). Thank you Link to comment Share on other sites More sharing options...
Patrick Playfair Posted June 18, 2017 Author Share Posted June 18, 2017 On 6/17/2017 at 2:36 AM, Klytyna said: I didn't say it was HORRIBLE, I said it was bad... Your device checks for an active relay, well that's nice. I hope you check with a command that's actually accepted by all relays, some flavours of @notify for example, are simply ignored by many collar based relays, thats why the Infectious Rubber Skunks died out, they used an old @notify variant to check relays, and newer relays ignored the command, so the rlv infection code never triggered because it assumed people didn't HAVE relays. Another well known RLV sim, implemented an 'auto-safeword-abuse-24hr-ban' system that was supposed to detect if you had a relay, and if it thought you were constantly safewording out of the traps would ban you from the sim for 24 hours, problem again, the paranoid possessive MoFo who coded this, used a relay check command in the auto banner and their traps that was simply ignored by many modern, and commonly used relays, so even with your relay set to auto, the traps didn't work and 3 failed tries later boot, you were off the sim. It did wonder's for their traffic figures, *wink* and eventually they dropped that badly implemented nonsense. Now, your code... You are using 5 lines with string concactenation and surplus variables to do something that should take oh... 1 line. There's 4 lines plus of course the line where you define 'cmdname'. Here's how it should look. llSay(relaychannel,"[whatever is in string 'cmdname']," + (string)victim + ",@sit" + (string)object + "=force|@unsit=n|@sittp=n|tploc=n|@tplure=n|tplm=n" ); See how much shorter and probably faster that would be. More importantly, if you get problems you can see EXACTLY what is in the command you are sending which makes it easier to figure where you made that typo that causes an rlv command to get ignored or to do the unexpected, without having to twarl through a load of variable definition statements and mentally figure how they get concactenated, and where the problem actually lies. Easier debugging, Less... is More.... Thanks for the response. Yeah, I thought using multiple commands would help me troubleshoot, but it didn't help any. I use @versionnum to check for an active relay. I don't mind if they use safewords, and don't even strictly enforce RLV, but base upon the sims theme, not using it is kind of pointless. Regarding my auto-attach RLV HUD, I just added a script that checks versionnum again after it attaches, and if it still returns nothing, informs the user that RLV is not enabled in their viewer, and sends them a notecard explaining how to enable it. Link to comment Share on other sites More sharing options...
Klytyna Posted June 18, 2017 Share Posted June 18, 2017 (edited) 36 minutes ago, Patrick Playfair said: I will try that, and see if I can figure out where the @detach=y or @clear or whatever is coming from . You are correct, it is a simple relay (in fact, the name of it is Simple RLV HUD). As a side note to that whole 'how to detect a working relay' thing, there was a time when many rlv/rlva scripters subscribed to the idea that a relay hud should NOT be locked on all the time, and the traps and relays were coded so that the trap sent a @notify to the relay, at which point the relay locked its self with @detach=n, and replied with another @notify variant. At this point the trap had 'grabbed' the relay, and could issue its rlv command strings, then when the trap had finished messing with the victim and released them, it would use @notify again to tell the relay it was released, and the RELAY would clear the traps restrictions and its own @detach=n with a simple @clear. Technically, it's not the trap that imposes restricts, it's the relay acting under orders from the trap. More modern relays don't do this, they are 'smart' and only clear the restricts forwarded from the trap, not their own @detach=n lock commands , I'm guessing here, but... If you've taken some old opensource single channel relay script (that simple relay name implies its an old school single channel job), and modified it by putting a @detach=n line into an onAttach script block, then as soon as your traps release that relay it's doing the old school thing and issuing a @clear to remove restricts and this WILL unlock the relay hud every time a visitor gets off a trap. You'd probably be better off checking for a relay, and then if none is detected, offering them the notecard and directing them to a dispenser for mainstream relay such as satomi or turbo relay instead of trying to attach your own, that may well have significant problems. Edited June 18, 2017 by Klytyna Link to comment Share on other sites More sharing options...
Innula Zenovka Posted June 19, 2017 Share Posted June 19, 2017 3 hours ago, Patrick Playfair said: I will try that, and see if I can figure out where the @detach=y or @clear or whatever is coming from . You are correct, it is a simple relay (in fact, the name of it is Simple RLV HUD). Thank you Just to clarify (I've just read Klytyna's post), is your "Simple RLV HUD" something you've written yourself, listening on a channel other than the common RLV Relay Channel, -1812221819? Link to comment Share on other sites More sharing options...
Patrick Playfair Posted June 19, 2017 Author Share Posted June 19, 2017 19 hours ago, Innula Zenovka said: Just to clarify (I've just read Klytyna's post), is your "Simple RLV HUD" something you've written yourself, listening on a channel other than the common RLV Relay Channel, -1812221819? No, it is not mine, and listens on the standard RLV Channel Link to comment Share on other sites More sharing options...
Innula Zenovka Posted June 19, 2017 Share Posted June 19, 2017 46 minutes ago, Patrick Playfair said: No, it is not mine, and listens on the standard RLV Channel Thanks. Are you sure, then, that it's nothing in the "Simple RLV HUD" that's causing the problem? As Klytyna suggests, it may very well be something in the code there that's causing the problem. As I said above, I would suggest making your own relay that listens on a channel of your choosing, and which issues specific RLV commands in response to cues you send it on that channel. That's very simple to do and should certainly fix the problem. Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now