A couple of things

[Patrick Playfair]

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

[Rolig Loon]

Sorry. I started a reply, but it's too complicated to do on a cell phone. ?

Edited June 15, 2017 by Rolig Loon

[Innula Zenovka]

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

[Patrick Playfair]

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

 

[Klytyna]

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.

 

[Patrick Playfair]

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

[Innula Zenovka]

How does the relay know when it's supposed to issue @detach=y?    If everything is happening as it's supposed to, I mean.

[Patrick Playfair]

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.

[Klytyna]

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....
 

[Innula Zenovka]

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

[Patrick Playfair]

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

[Patrick Playfair]

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.

[Klytyna]

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

[Innula Zenovka]

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?  

[Patrick Playfair]

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

[Innula Zenovka]

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.