[A script that suddenly stopped working]

I agree with Nova in that there might be an issue with the trigger in the rezzed object not firing. The timing thing might be an issue. If you can't figure it out, see if you can paste the on_rez(integer param) - if present - and state_entry() events of the script, if not the entire thing.

[scrape profile image UUID]

I tested it and it seems to work for me as well.  Ultimately, it might change, as everything does, but for now, the Old Code seems to still do the trick.

[How do I turn off this script without a delay?]

Congratulations on your first script! Good milestone and ready for the next one!

Just something to take with you in the future, but with complex functions like these, I often find it easier to place something like

llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <0.000, 1.000, 0.500>, 1.0, 5.0, 1.0, PRIM_GLOW, ALL_SIDES, 0.6, PRIM_COLOR, ALL_SIDES, Green, 0.6]);

into a function where you only pass the parameters you change. That way, you don't have to go through every iteration if you need to change anything.

The below is a rough (and not altogether logical) example of how something like that might work based on the code in your timer() event.
 

integer Color;
vector Blue = <0.0, 0.0, 1.0>;
vector Green = <0.0, 1.0, 0.0>;

// A function that calls llSetPrimitiveParams, but only uses three parameters for the on/off, light color, and prim color
UpdateParameters(integer piLightSwitch, vector pvLightColor, vector pvPrimColor)
{
	llSetPrimitiveParams(
    	[
          	//I like splitting the various elements of llSetPrimitiveParams on separate lines, so it's easier for me to read
    		PRIM_POINT_LIGHT, piLightSwitch, pvLightColor, 1.0, 5.0, 1.0, 
       		PRIM_GLOW, ALL_SIDES, 0.6, 
        	PRIM_COLOR, ALL_SIDES, pvPrimColor, 0.6
    	]
    );
}

default
{
  	touch_start(integer piNum)
	{
          Color = !Color;

          if (Color == 0)
          {
            UpdateParameters(TRUE, Blue, Blue]); // Call function
          }
          else if (Color == 1)
          {
            UpdateParameters(TRUE, Green, Green]); // Call function
          }
          llSetTimerEvent(3.0);    	
	}
}

I often also find it easier to split the various parameters into separate lines to make it more readable, but that's just the way my wacky brain works.

Good job on your first script!

 

[Just curious :)]

Like @Profaitchikenz Haiku said, this is because it is a client-side effect. I have the same issue during the Twisted hunt (which has rotating cubes).  Sometimes they rotate, sometimes they don't until I right-click/edit them.  Offhand, I don't know of a different way to fix this, unless you can fix it with a texture rotation instead of a prim rotation.

[I can't even begin to understand what's going on...]

3 hours ago, DarkEmperor13 said:

the whole use first name thing

What  @Wulfie Reanimator  (likely) means is that instead of sending the whole name to the buttons, you can find the position of the first space you find and just take the bit up until that position.  You can use llSubStringIndex to return the zero-based position of the space (in my case, Bugs Larnia, that would be position 4) and copy the part of the name from index 0 to one position before the space.

That would give you the avatar's first name to put in the button, which is far less likely to exceed 24 characters.

[RIP Mr Altberg]

Thank you for all you have done to help us enjoy Second Life. You will be missed by many.

Open roads and kind fires, Traveller.

[sound slave/master]

22 hours ago, Quistessa said:

Also, not related to my original question, but I think I've found a bug:

default
{	state_entry()
    {   
        llSetSoundQueueing(TRUE);
        llLoopSound("a3325291-3b1e-f4d4-b18c-94e77e415481",1.0);
        llSleep(5.0);
        llPlaySound("03f630e3-b062-ae24-8c3d-da4cff6cdae8",0.5);
        llLoopSound("a3325291-3b1e-f4d4-b18c-94e77e415481",1.0);
    }
}

works as expected, but

default
{
    state_entry()
    {   
        llSetSoundQueueing(TRUE);
        llLoopSound("Click1",1.0);
        llSleep(5.0);
        llPlaySound("fanfare",0.5);
        llLoopSound("Click1",1.0);
    }
}

loops the fanfare sound after 5 seconds instead of click1.

Confirmed. Tried it in state_entry and touch_start with identical results. When I added an llStopSound() after the sleep, it skipped the subsequent llPlaySound() altogether.

LoopSounds()
{
    llSetSoundQueueing(TRUE);
    llLoopSound("DEEDLE",1.0);
    llSleep(5.0);
    llStopSound();
    llPlaySound("bart-didn'tdoit",0.5); //<-- this one was not played
    llLoopSound("DEEDLE",1.0);
}

[Basic Scripting Help]

Do keep in mind that the rotation axis will differ when you link or attach prims to other prims. As it says on the Wiki:

Link Sets

• If the script is attached to the root prim, the entire object rotates around the region axis.
  • If the object is attached then it rotates around the attachment axis.
• If the script is attached to a child prim, the prim rotates around the local axis.
  • A child prim can rotate around its own axis while the entire object rotates around another axis.

[Texture change on touch (I need help, thanks!)]

On 4/15/2021 at 4:22 AM, Quistessa said:

Assuming I didn't make any mistakes, you should be able to use this to cycle through as many textures as you like, specifically named uuids hard coded into the script, and all textures in the prim's inventory.

You? Mistakes? In scripts?!?

Is nothing sacred???!??? 😲🙃

[Limit the range of the ability to open an object's menu]

Instead of llVecMag, you can also use llVecDist, like below (http://wiki.secondlife.com/wiki/LlVecDist).  Do note that the distance from the prim is measured from the prim's center, so if your prim is large, then you will need to account for that.

integer IsWithinRange(float pfMaxRange, vector pvAvatarPos)
{
    return (llVecDist(llGetPos(), pvAvatarPos) <= pfMaxRange);
}

default
{
    touch_start(integer total_number)
    {
        if (IsWithinRange(2.0, llDetectedPos(0)))
        {
            //Do stuff
        }
        else
        {
            //Do other stuff
        }
    }
}

 

[How not to see my avatar while it is in the camera field of view?]

Hi Yich! If it's about vista's, you can try to force mouselook on sit (http://wiki.secondlife.com/wiki/LlForceMouselook) or use the solution Quistessa stated above.

[Texture Change HUD Button with multiple textures]

In addition to either using textures in the prim's inventory or reading from a notecard, you can also create a list with texture keys directly in the script; this is faster than reading from a notecard, which can indeed be somewhat slow, as @Quistessarightly noted.  However, this is only recommended if the textures are a fixed set, since you'd need to edit the script each time you'd want to add, remove, or otherwise change a texture.

[I need direction on direction]

18 hours ago, Quistessa said:

If you ever do, I'm fairly certain you want to use one or the other and not both.

Well, you can use both, but it's not strictly necessary. I was more referring to the status of the prim, which is influenced by the settings of llVolumeDetect, but your point is well taken.

[I need direction on direction]

1 hour ago, Quistessa said:

Funnily enough I was just working on a similar problem. I used detected velocity instead of a position differential.

    collision_start(integer n)
    {
        vector vel = llList2Vector(llGetObjectDetails(llDetectedKey(0),[OBJECT_VELOCITY]),0);
        vel = vel/llGetRot();
        if(vel.y<0)
            llSay(0,"Wrong Way!");
        else
            llSay(0,"Right Way!");
    }

My object also was llVolumeDetect(TRUE), which may or may not affect things for your application.

Thanks! I thought about using phantom and volume detection, but it wasn't really necessary for this setup.

[How to read data directly from Google Sheets.]

I use it as well. Very handy. You do need to keep in mind that when reading data from Google there can be a slight latency between the actual data update and the time it's visible in the data pull.

[I need direction on direction]

30 minutes ago, Wulfie Reanimator said:

Here's my link to my comment which has a link to my comment:

It's about doors, but it absolutely applies here too.

I don't know why it works, but it works! I do often get a double triggering of collision_start, with the second one directly contradicting the first, but I can work around that with a list of recent collision keys.

Thanks Wulfie!

 

Sample code triggering the double collision follows here

default
{
    collision_start(integer piNum)
    {         
        vector vAvatarDirection = llVecNorm(llDetectedPos(0) - llGetPos()) / llGetRot();         
        if (vAvatarDirection.y < 0)
        {
            llOwnerSay("Moving forward");
        }
        else
        {
            llOwnerSay("Moving backward");
        }
    }
}

 

[I need direction on direction]

38 minutes ago, KT Kingsley said:

Velocity has both a direction and a magnitude, so perhaps llDetectedVel might be useful here.

True, it is. I suspect it's a function of prim rotation vs. avatar rotation, combined with avatar velocity. I am just uncertain how the three factors play with each other.
 

[I need direction on direction]

Hi! I am decent at scripting, but have a blind spot the size of Jupiter when it comes to rotations.  I have a scenario where I have a flat prim on the ground (basically an invisible doormat), where a collision triggers a bit of chat to the agent. No biggie.

However, I need it to respond differently depending on whether an avatar is moving in line with or contrary to the prim's local "forward" axis (x-axis in my test prim). After some testing, I figured I could theoretically do this with the rotation difference between the prim and the avatar. Depending on the global quadrant the prim is facing (and the direction the avatar is facing when walking), this is (in vectors) either  <0.0, 0.0, 0.0> or <180,  0, 0>. This would basically cover scenarios 1 and 2 below where you move forward with W, with the camera position behind you.

Trick is that it's also possible to move "backwards", by which I mean pressing the S, to that your avatar is facing the camera. (I'm leaving aside, for the moment, that an avatar can cross left-to-right or right-to-left as well)

I also get the feeling that my lack of trigonometry skill is causing me to over-complicate things. Can someone point me in the right direction (pun totally intended) on how I can get this to work robustly?

I attached an image detailing my four scenarios.

[SLS_Help_Post_5]

I'm not entirely certain about what you need with the inventory giver either, but I have a library giver (numbered buttons, legend in bluenote) here. Maybe that's a starting point?

[How do I link one object with another and command one of the objects to control another?]

2 hours ago, IcyMiranda said:

 I would put the script into the object I would want to be the parent object and the textures into the separate controlled object, correct?

If you want a linked controller, you can use llSetLinkTexture to change the textures. Ideally, like Rollig said, you would want to create a list of texture UUIDs, so you don't have to store the actual textures in the prim inventory. You can then loop through the list on touch and use llSetLinkTexture to change the texture and face of your linked texture prim.

I have something not unlike what you want. I put it on my pastebin.  You might need to make some changes, but it's a good starting point.

[Simple countdown timer]

I think@Rolig Loon is correct and the lack of actual action is the issue.

Perhaps something like this?

integer giCount;
integer giStartCount = 120;

ResetTimer()
{
    giCount = giStartCount;
    llSetTimerEvent(1.0);
}

default
{
    state_entry()
    {
        ResetTimer();
    }

    touch_start(integer piNum)
    {
        ResetTimer();
    }

    on_rez(integer num)
    {
        llResetScript();
    }
    
    timer()
    {
        llSetText("Countdown in: "+ (string)giCount + "s\n \n \n ", <1.0, 1.0, 1.0>, 1.0);
        --giCount;
        if (giCount == 0)
        {
            //Do something
            llSetTimerEvent(0.0);
        }        
    }
}

 

[A bumper that only responds to horizontal collisions?]

The only thing I can really think of is using llDetectedVel(0) in the collision event to get the colliding agent's velocity (vector) and then checking whether the X and/or Y are unequal to zero or higher than some arbitrary minimum value you set after lots of experimentation.

[How do I detect if the owner (me) is sitting on an object?]

llGetAgentInfo would be the way to go, but you'd need it on a timer. Below is a very rough idea, but check llGetAgentInfo for more details

integer CheckAgentSitting()
{
    integer iAgentSitting = llGetAgentInfo(llGetOwner());
    return (iAgentSitting & AGENT_SITTING);
}

timer()
{
    integer iAgentSitting = CheckAgentSitting();
}

 

[Prim Resize - prim keeps reverting]

On 8/13/2020 at 1:41 AM, Rolig Loon said:

That's a very odd sort of graphics glitch, if that's what it is.  Your script isn't doing anything that involves changing textures or alpha.  It's just resizing and moving things, so I can't see how your viewer is ever being put in a position of having to "remember" what a closed or open blind looks like.  The only scripted changes are all handled by the servers.  The only thing can imagine is that somehow that odd blind is being resized and moved when it's not supposed to be.  There's nothing in your script that should do that, but did you by any chance have a test object nearby when you were developing this thing?  And if so, did you forget to pick it up?  When I am working on a script like this, I tend to rez a prim nearby and stick a simple "Hello, Avatar!" script in it so that I can send trigger messages by just clicking on the thing.  If you made something like that, with a timer in it, or if you left another test script in a child prim of the linkset somewhere, it could be triggering your odd blinds.  Of course, that's never happened to me, but hypothetically it might happen.....  🙄

It might be related (and might not), but a few months ago, I had similar issues, but without scripts.... I'd resize a prim manually and it would just revert. This could happen several times and sometimes also happened when I moved a prim using Edit; I'm guessing there might have been an issue in the server processing  the change. That might be what occurred here. The script, as Rolig said, looks ok.

[Detecting bots / Checking scripted agent status]

On 8/11/2020 at 4:12 AM, Wulfie Reanimator said:

If nothing comes up then maybe. I think llRequestAgentData would make the most sense, considering the name and what it already does, and not needing the avatar be in the area or online.

I think I recall a discussion about this a few years ago, but I don't think a solution was found. The aforementioned setting seems to be limited for viewing to LL. I checked the functions, the public profiles and the viewer URI and I haven't found a way, but I'd definitely support such a ticket if you submitted it.