Bugs Larnia

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.

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.

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!

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.

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.

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.

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); }

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.

You? Mistakes? In scripts?!? Is nothing sacred???!??? 😲🙃

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

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.

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.

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.

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

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 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"); } } }

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.

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.

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?

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.

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); } } }

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.

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(); }

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.

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.