Jump to content

Totally mystified and at a loss


Phil Deakins
 Share

You are about to reply to a thread that has been inactive for 276 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I create and sell security devices - often called orbs, although mine are not orb shaped. I've been doing it for many years, and I'm in the process of writing an improved version of one of them. Among other things, it can protect the whole parcel. I'm at the point of writing the actual security system, and, for simplicity, I'm starting with the parcel mode (the whole parcel). It should be extremely simple but I've run into a problem that I can't figure out. It goes like this:-

Get a list of the avatars in the parcel (uuids).
With each one:
check if it's in the white list
if not, send the uuid to the routine that does the warnings and subsequent removal.

At the moment, the warnings/removal routine simply chats the uuid, and that's it. There is nothing else there, not even any commented out code. That's all it is scripted to do at the moment. There is no code whatsoever in any of the object's scripts that does the warnings and removal.  llAddToLandBanList() doesn't exist anywhere in any scripts that are in the device. But this is what happens...

When the device is turned on, any avatar, except me (the land is in my name), instantly receives a message saying that it can no longer be there and that it has 15 seconds to go, and then it is instantly permanently banned from the parcel, and put into the parcel's land ban list. There is no waiting for the 15 seconds to run out. But there is no code in the device that can do that.

The device's channels are derived from the device's uuid, so no other device should pick any menu messages up and do its own thing. Even so, I have a few previous versions of security devices nearby, so I set all the scripts in them to not running. Not only that, but I rezzed 2 copies of this device, each having a different uuid, to ensure that the channels won't be coincidentally the same, but both devices eject avatars.

I even took it to an OpenSim grid, and it worked fine there. I logged an alt in with me, which it detected as it should. It chatted the alts uuid, as it should, and it did nothing else, as it should. Perfect.

That's the problem that totally mystifies me. I have nothing running in the parcel that uses llAddToLandBanList(), so how on earth are avatars ending up there when I turn the device on? Does anyone have any thoughts?

Incidentally, the text with the 15 seconds warning doesn't exist in the device and has never existed in any of my devices. It might be thought that the text comes from someone else's device that's in the parcel, but, if it does, why does it only appear, and the avatars get banned, when I turn my device on. Also, according to About Land > Objects, nobody other than me owns any objects in the parcel.

I'm at a total loss.
 

Edited by Phil Deakins
  • Thanks 1
Link to comment
Share on other sites

Either A) there's a serious bug with SL, or B) one of your (well founded) assumptions is wrong. You mentioned taking it to the other simulator, but did you try a different parcel that you own? It's not impossible you have some accidentally activated script in something you didn't intend to script, or just an old version of something laying around.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

You'd have to show us part of the offending scripts to give us a better clue.  But educated guesses:

1. If you truly do not have any script of your own running that gives the warning, etc. - but you are seeing the warning - then you already know the warnings are is coming from a different script (assume they are not a warning YOU wrote in some other script iteration).  This should be true whether or not you are personally running the script.

a. Possibly you are using some "shared protocol", which (unbeknownst to you) another script is using in a similar way to yours..  One way to check that is to just change your test code to send some new message prefix in addition to the UUID; if the warnings stop, then the unexpected script is ignoring the messages after you added the new prefix.

b. If the above guess is true, then it explains why the issue does not happen on OpenSim - the errant / unexpected script which picks up your message is not running there.

2. If the warning message DOES look like a message format you wrote in the past, you're probably running an old security script of your own and just don't know it.

 

  • Like 1
Link to comment
Share on other sites

1 minute ago, Quistess Alpha said:

Either A) there's a serious bug with SL, or B) one of your (well founded) assumptions is wrong. You mentioned taking it to the other simulator, but did you try a different parcel that you own? It's not impossible you have some accidentally activated script in something you didn't intend to script, or just an old version of something laying around.

My answer was similar to yours, just a lot more words! 

  • Like 1
Link to comment
Share on other sites

12 minutes ago, Quistess Alpha said:

Either A) there's a serious bug with SL, or B) one of your (well founded) assumptions is wrong. You mentioned taking it to the other simulator, but did you try a different parcel that you own? It's not impossible you have some accidentally activated script in something you didn't intend to script, or just an old version of something laying around.

I have thought about trying it on a different parcel, and I even thought about asking if someone here would let me, but I haven't asked - yet lol.

Edited by Phil Deakins
Link to comment
Share on other sites

14 minutes ago, Love Zhaoying said:

You'd have to show us part of the offending scripts to give us a better clue.  But educated guesses:

1. If you truly do not have any script of your own running that gives the warning, etc. - but you are seeing the warning - then you already know the warnings are is coming from a different script (assume they are not a warning YOU wrote in some other script iteration).  This should be true whether or not you are personally running the script.

a. Possibly you are using some "shared protocol", which (unbeknownst to you) another script is using in a similar way to yours..  One way to check that is to just change your test code to send some new message prefix in addition to the UUID; if the warnings stop, then the unexpected script is ignoring the messages after you added the new prefix.

b. If the above guess is true, then it explains why the issue does not happen on OpenSim - the errant / unexpected script which picks up your message is not running there.

2. If the warning message DOES look like a message format you wrote in the past, you're probably running an old security script of your own and just don't know it.

 

I appreciate all your thoughts on it but I have 2 copies rezzed, each using different channels, and they both eject and ban avatars that are not in the white list. I.e. if I add an avatar to the white list, it's safe. If I remove it from the white list it gets removed and banned. They both do that, using different channels.

Also, the specific text that the avatars receive was never written by me - ever lol.

Edited by Phil Deakins
Link to comment
Share on other sites

5 minutes ago, Phil Deakins said:

I appreciate all your thoughts on it but I have 2 copies rezzed, each using different channels, and they both eject and ban avatars that are not in the white list. I.e. if I add an avatar to the white list, it's safe. If I remove it from the white list it gets removed and banned. They both do that, using different channels.

Also, the specific text the the avatars receive was never written by me - ever lol.

1. Which LSL commands are you using the "say the message on a channel"? 

Since both scripts are using different channels, the commonality is that they are both using the same method to say the message.

2. a. See my suggestion of adding a "prefix" to the message for your test script - if you do that and the mystery script stops responding, then you'll know that regardless of the mystery script and channel issue, another script was intercepting your messages and using them because it was looking for a similar format (just UUID, or whatever you are sending).

b. Am I correct in assuming your "final script" was not just going to "say a UUID", but have SOME kind of prefix or message format?   If so, that is even more reason to try my suggestion, which you did not address in your response above.

 

Edited by Love Zhaoying
Link to comment
Share on other sites

2 minutes ago, Love Zhaoying said:

1. Which LSL commands are you using the "say the message on a channel"? 

Since both scripts are using different channels, the commonality is that they are both using the same method to say the message.

2. a. See my suggestion of adding a "prefix" to the message for your test script - if you do that and the mystery script stops responding, then you'll know that regardless of the mystery script and channel issue, another script was intercepting your messages and using them because it was looking for a similar format (just UUID, or whatever you are sending).

b. Am I correct in assuming your "final script" was not just going to "say a UUID", but have SOME kind of prefix or message format?   If so, that is even more reason to try my suggestion, which you did not address in your response above.

 

1. llSay()

2a. I often use prefixes so I can see which part of a script or script the message comes from.

2b. You are correct :) I've literally only just started to add the actual security code, and the first thing was to check that the right avatars are being warned etc. Like other parts of the whole thing, the parcel can be set to allow only white-listed avs, group-only avs, or private-listed avs. I'd only got as far as checking that it selects the right avs according to which of those it is set to, and according to the avs being white-listed, in the group, or private-listed.

Link to comment
Share on other sites

5 minutes ago, Quistess Alpha said:

To account for the (slim) possibility of a server side bug, also try putting your script(s) in a fresh clean cube. Weird server bugs generally persist in copies of objects.

That's the experimenting that I mentioned in the post above yours. I'm about to do it :)

  • Haha 1
Link to comment
Share on other sites

3 minutes ago, Phil Deakins said:

1. llSay()

2a. I often use prefixes so I can see which part of a script or script the message comes from.

2b. You are correct :) I've literally only just started to add the actual security code, and the first thing was to check that the right avatars are being warned etc. Like other parts of the whole thing, the parcel can be set to allow only white-listed avs, group-only avs, or private-listed avs. I'd only got as far as checking that it selects the right avs according to which of those it is set to, and according to the avs being white-listed, in the group, or private-listed.

Then, if you follow my suggestions and line of reasoning - and the mystery behavior stops - you are done; you don't really need to "solve" the mystery unless you decide to raise a JIRA or something ("Hey LL, your security system is quite astonishingly transparent..", etc.)

Link to comment
Share on other sites

22 minutes ago, Quistess Alpha said:

To account for the (slim) possibility of a server side bug, also try putting your script(s) in a fresh clean cube. Weird server bugs generally persist in copies of objects.

I've come across prims getting somehow corrupted in the past.

I've done the test and it hasn't changed anything, unfortunately. Brand new prim, copies of the scripts but not direct copies. I used new scripts and pasted the code into them from copies in my computer.

The only experiment I have left is to remove the scripts from the new object and add code chunk by chunk to see what causes it to go wrong.

@Love Zhaoying I should have mentioned that the 15 seconds warning messages were never shown as coming from an object, as lsl instant messages and local chat do. They were just a line on its own in white. I was forgetting that bit. They weren't local chat anyway.

Edited by Phil Deakins
  • Like 1
Link to comment
Share on other sites

Adding: it will be "interesting" if you find that you can trigger the LL security by using llSay() to send a valid user UUID on any channel.

It will mean:

a) LL is using code that listens on "all channels".

b) LL's parcel security message format / protocol is redonkulous.

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, Love Zhaoying said:

Adding: it will be "interesting" if you find that you can trigger the LL security by using llSay() to send a valid user UUID on any channel.

You may have been joking but, incredibly, that's the line that's causing it. It was a daft idea but there was no harm in checking it lol. I pared the script down to pretty much the bare minimum and when that line is remmed out, or when the uuid is replaced by something else such as "here", everything is fine, but when it's llSay(0, (string)uuid), the avatar gets chucked out and permanently banned.

Here is the drastically pared down code:

key owner;
integer mode;
integer scanperiod;             // seconds to removal
integer parcelAllowed;          // 0 = white, 1 = group, 2 = private
integer pclOn;                  // FALSE = off, TRUE = on

list lstWhite = [
//"Wicked Leigh","7465d9d4-995c-44bc-878d-37568b6fd51f"
];

//==================================================================================================
warn_and_ban(key agent)
{
llSay(0, (string)agent);
}

//########################################################################################
default
{
    state_entry()
    { 
        owner = llGetOwner();
        
        // Tell the Menu script that I am ready, passing the Bellisseria status.
        llMessageLinked(LINK_THIS, 0, "Main ready", NULL_KEY);
llOwnerSay("Main Ready (" + (string)llGetFreeMemory() + ")");
    }

    //==============================================================================================
    link_message(integer from, integer val, string msg, key id)
    {
        if(msg == "mode"){
            mode = val;

        }else if(msg == "scanperiod"){
            scanperiod = val;

        }else if(msg == "parcelAllowed"){
            parcelAllowed = val;

        }else if(msg == "pclOn"){
            pclOn = val;
            if(pclOn){
                llSetTimerEvent(scanperiod);        // start scanning
            }else{
                llSetTimerEvent(0);                 // stop scanning
            }
        }
    }

    //==============================================================================================
    timer(){
        // Get a list of agents that are on the parcel.
        list lstAvatars = llGetAgentList(AGENT_LIST_PARCEL, []);
        integer len = llGetListLength(lstAvatars);
        key agent;
        integer i;
        for(i; i<len; i++){

            agent = (string)llList2String(lstAvatars, i);

            // Skip it if it's the owner.
            if(agent != owner){
                // Parcel mode
                if(mode){
                    // white list
                    if(parcelAllowed == 0){
                        if(llListFindList(lstWhite, [(string)agent])==-1){  // not in the white list
                            warn_and_ban(agent);
                        }
                    }
                }
            }
        }
    }
}

When llSay(0, (string)agent); is remmed out or the message changed to something else, the avatar is safe, but it gets ejected and permanently banned when that line stays as it is.

The avatar I'm using for testing with is at the top of the script, but I've tested with another one as well, which had the same result.

If you want to test it yourself, set:
mode to 1 (that's parcel mode)
scanperiod to a few seconds
parcelAllowed to 0 (that's for the white list)
pclOn to TRUE

 

Edited by Phil Deakins
Link to comment
Share on other sites

3 minutes ago, Phil Deakins said:

You may have been joking but, incredibly, that's the line that's causing it. It was a daft idea but there was no harm in checking it lol. I

Not at all joking, I was taking your detailed explanation literally and making the only possibly conclusion!

 

  • Like 1
Link to comment
Share on other sites

1 minute ago, Phil Deakins said:

Well you hit on it. But what on earth is that, that permanently bans the avatar when the script merely llSay()s the uuid.

I am missing (either from poor reading, etc.) a couple things:

- a) Are you running this on Mainland in a Linden Homes parcel - and

- b) Can you tell if it is "obviously" triggering the "built-in" Linden Home Security?

If "a" and/or "b" are "no", then that's still a mystery to me at least.  But, I'd think only LL would be listening on "all channels", as "channel scanners" (multiple open listeners) use a lot of resources.

Link to comment
Share on other sites

5 minutes ago, Love Zhaoying said:

I am missing (either from poor reading, etc.) a couple things:

- a) Are you running this on Mainland in a Linden Homes parcel - and

- b) Can you tell if it is "obviously" triggering the "built-in" Linden Home Security?

If "a" and/or "b" are "no", then that's still a mystery to me at least.  But, I'd think only LL would be listening on "all channels", as "channel scanners" (multiple open listeners) use a lot of resources.

a. Mainland (Gwidion sim).

b. not applicable.

I've changed what that llSay says in the security device and it works fine.

Even if SL listens to everything, the llSay() doesn't tell the system to ban someone. All a listener would hear is a uuid, but no direction on what to do with it.

Link to comment
Share on other sites

3 minutes ago, Fionalein said:

stupid kitty question: you didn't accidentally drop the ejector script into something you wear?

:) There is no ejector script. It hasn't been written yet. 

All there is is an llSay() and that doesn't tell any script to do anything.

Link to comment
Share on other sites

2 hours ago, Quistess Alpha said:

Either A) there's a serious bug with SL...

It looks like there's a serious but with SL.

It's time for me to knock off now but tomorrow (maybe later this evening) I'm going to test what happens when a script simply llSay()s avatar uuids.

Link to comment
Share on other sites

10 minutes ago, Phil Deakins said:

Even if SL listens to everything, the llSay() doesn't tell the system to ban someone. All a listener would hear is a uuid, but no direction on what to do with it.

..unless it was a poorly-written security system that just listens for any valid UUID and checks if it is an Avatar, then if it is on a Whitelist vs. Banlist..

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 276 days.

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
 Share

×
×
  • Create New...