Fenix Eldritch

Drama is a plentiful resource, why would anyone need to mine for it?

The Second Life viewer should have a built in clock that shows SLT by default. Beyond that, if you're on Windows, you can have multiple clocks in your taskbar that show when you mouse over it. I have one for my local time, and another for SLT.

Scripts cannot write to notecards: they may only read from them. Additionally, the act of saving a notecard actually creates a whole new asset, with a new UUID. Edit: Depending on the needs of your project, it might be possible to store the UUIDs in a list within the script's memory. But you still have the issues of discovering the UUID of the texture, which is only possible if the texture is full perm as per llGetInventoryKey.

Perhaps it would be prudent to take a few steps back and try to shore up your foundational knowledge. Being familiar with the basic concepts of LSL (and programming in general) will be essential as your progress in your scripting projects. Topics and concepts very quickly build upon each other and if you don't have a good grasp on the basics, it will make anything even remotely more advanced difficult. That includes reading documentation like the various LSL function pages on the wiki. If you haven't already, I would wholeheartedly recommend you take some time and read through the tutorials on the wiki. Read through them in order, and they will introduce you to all the basics and you can build up from there. http://wiki.secondlife.com/wiki/Category:LSL_101 And you can always ask questions that arise along the way and we'll try to answer as best we can. Good luck!

I had a similar problem a while back. One solution that was offered was to perform a series of short-range ray casts to "look ahead" and predict any incoming impacts. Reference: Edit: additionally, I played around with some of the prim's properties to reduce it's elasticity. That may also help to dampen the bounce on contact.

You can make your mouse cursor visible while in mouselook by holding down the ALT button. However, this feature is of limited usefulness and has a bunch of quirks. When you hold ALT while in mouselook, your camera/view is locked in place. You'll be able to move the mouse around the screen and can click on HUDs or interact with whatever GUI elements that don't get hidden in mouselook (like the minimap). All other control inputs are blocked. You cannot move your avatar with the keyboard, nor will any scripted object that is acting upon your control inputs be able to detect them. Any object scripted to respond to regular touch events will work if you click on them while in ALT+Mouselook, but the cursor will always snap to the screen's center again after each left click. This could be useful for initial calibration of your steering wheel, but I don't think it will be practical to have the cursor visible and pilot a vehicle at the same time.

I did a quick search of the JIRA and found only two (very old) instances of the error message. Both of these bugs say the problem hits when a script tries to set a parameter on an object which the current owner does not have modify permissions to. (Though in your case that seems unlikely, since as you say, you built the demo rezzer and should have full modify rights to it and your bikes within). https://jira.secondlife.com/browse/SCR-225 https://jira.secondlife.com/browse/SCR-230 Interestingly, the second bug notes that although it's the same root cause, it was manifesting in a different area of the code and needed a slightly modified internal fix. Perhaps you've stumbled upon another edge case that makes that old bug resurface again. If this is reliably reproducible, definitely file a new JIRA on it.

Agreed, I have an RC vehicle project on the back burner for the same reason. My attempt at a workaround is to have the pilot sit on it like normal vehicle and ask that they remove all attachments and wear an alpha mask layer. It's far from ideal and raises a lot of other problems in the process (like the avatar's physics shape getting added to the linkset and is in this case larger than the RC vehicle). There is a bit of a silver lining though. Several feature requests for expanding the scripted camera have been accepted on the JIRA. BUG-40473 specifically requested the ability for the camera to follow an object. That was marked as a duplicate to I believe BUG-6325 which suggests several additional enhancements to llSetCameraParams - and that has been marked as accepted. So hopefully one day this will get priority.

That's extremely vague and doesn't answer my question. Have there been documented instances of this? JIRAs? Anything that concretely identifies the source of the supposed "glitch" being traced back to the use of NULL_KEY in place of "" ? If not, then I think I'll take my chances, thank you.

Then in the interest of gaining a better understanding, can you elaborate on the scenario where this would cause a problem? And to be clear, I'm not talking about the best practice of making one's listener filters as specific as possible to eliminate unnecessary chat. Specifically, under what circumstance would using llListen(737, "", NULL_KEY, "" ); fail where llListen(737, "", "", "" ); would not?

Glad you got your issue sorted out Minstral. And Steph, I have no idea what you're talking about. I stand by my original statement. All other things being equal, using "" or NULL_KEY for the speaker's id parameter in llListen the end result will be the same.

That is not true. The key parameter for llListen can be either an empty string ("") or the NULL_KEY constant and the result will be the same: i.e. it won't be used for filtering. This is explicitely stated on the wiki page for llListen, and can also be seen in the hover tip when moving the cursor over the function in the viewer's script editor. Just now, I set up two scripts to talk and listen and can confirm that the following variants are functionally identical: llListen(737, "", "00000000-0000-0000-0000-000000000000", "" ); llListen(737, "", NULL_KEY, "" ); llListen(737, "", "", "" );

Slight nitpick for an otherwise excellent post, but the wiki page for llListen does say that the id can be either "" or NULL_KEY and it will be treated the same - i.e not used for the filter.

The "data" variable is local to the dataserver event, and can only be accessed from inside that event. In addition, it will be overwritten with each successive call. In order to preserve it, you must save the string to a global variable. Then you can do other things to it after the dataserver event passes. Alternatively, you could instead opt to initiate the llRegionSayTo relay right then and there once you have confirmed the data string isn't an EOF. You could move your llRegionSayTo command out of the touch_start event and instead into the else clause of the dataserver event (where your llSay is outputting the notecard line and text to local chat). Note that you need to update your llRegionSayTo command to actually contain the data string you intend to transmit. Something as basic as this could work - assuming you have formatted the notecard line to only have a single uuid and nothing else. Otherwise you'll need to do some parsing either before or after the string is transmitted. llRegionSayTo(llDetectedKey(0), 5589, data); //transmit the contents of the data variable to llDetectedKey(0) over channel 5589 Then, in your listen event, you would find the transmitted text inside the "message" variable. It should be noted that your script as currently written will immediately start reading the notecard lines once the script is compiled or reset. And it will read the entire notecard automatically and then delete it. This may cause you some trouble if you run the script before the notecard is ready. I would advise you move your initial llGetNotecardLine call out of the state_entry event and instead into the touch_start event. That way, you can control when it starts reading, and it will give you time to actually place the notecard inside the object.

llGetNotecardLine by itself doesn't give you the actual data from the notecard. Instead, it gives you a query id and then queues up a datasrerver event. It is in the dataserver event that you will be given the actual text from whatever notecard/line you specified. You can use the query id to match up any dataserver event to the specific llGetNotecardLine function call. See the wiki page for an example, note how the dataserver event handler shown there has two variables, a key named "query_id" and a string named "data". You would compare the key returned by llGetNotecardLine with the query_id in the dataserver event. If they match, then you know that this specific instance of the dataserver event is answering that specific llGetNotecardLine call. The data variable would contain the contents of the notecard at that line - whatever it may be. If it's just a uuid for a texture and nothing else, then you can get away with dropping that string straight into a texture function where appropriate. llSetLinkTexture for example, takes a string variable which can be the uuid of the target texture. Edit: Ah if it's transmitting the uuid from a hud to another object, that's a little different. See KT's post below. But it would be a good idea to do some error checking before hand, to make sure the value read in matches the expected format of a texture uuid with nothing else on that line.

Related question: do similar thoughts apply to object inventory? Will an object with a large inventory affect sim performance when said object moves between sims? I vaguely understood inventory in general to be a list of wrappers that eventually will resolve to the asset when appropriately referenced (rezzed, applied as a texture, sound, animation, etc). My assumption was that the inventory list was just that: a lightweight list.

Dunno about checking the number of unique textures without being able to edit the object and inspect each face in the build tool, but there is a way to check the size of the texture on the currently selected face. In the official viewer I think it's under Develop > Rendering > Selected Texture Info. There's also a keyboard shortcut of Ctrl+Alt+Shift ⇧+T . A quick glance at the Firestorm wiki shows that it maintains similar shortcuts. There's also a similar function for materials, I don't know off the top of my head what that displays - it may present the size of any additional normal/specular texture data, but I'm not at a viewer to confirm at the moment. Regarding scripts, I'd echo what Qie said: less is generally better, though there are some functions that still need support scripts in child prims like sound effects. Checking for excessive object updates with Ctrl+Alt+Shift ⇧+U is also a good idea. As for physics shapes, it's highly dependent on the object's use. If the object is modify-enabled, you can always switch to convex hull which is usually less heavy (but the object's physics shape becomes shrink-wrapped for lack of a better word - this may or may not be tolerable depending on what you object is used for). You can also set the physics shape to none to negate it entirely - but that's only doable for child links, not the root. Again, not a big deal if you already have modify rights. Animesh allows a rigged mesh object to have its own copy of the avatar skeleton. if worn, it will animate independently of your own skeleton. The only thing to look out for is if two animesh objects use conflicting bones - but since you're only allowed to wear on animesh object/linkset at a time, the odds of that are low. I suppose it could be an issue if you link multiple animesh objects into one attachment.

http://wiki.secondlife.com/wiki/Glossary

I got curious and after some experimentation, I did manage to accomplish the task using llDetectedTouchST. Since the function returns a vector with the x and y components in the range of 0 to 1, that means they are in essence a percentage of how far the touched point was from the corner of the face. Knowing that, we can perform some operations to make them correspond to the center of the game board prim and offset accordingly. The demo below assumes you have a gameboard prim as the root and a linked child (link number 2) as the game piece. It also assumes the game board's top face (0) is what will be clicked on. default { touch_start(integer total_number) { //Only allow touching the top face of the root prim for this demo if (llDetectedLinkNumber(0) != 1 || llDetectedTouchFace(0) != 0) {return;} vector boardDimensions = llGetScale(); vector localPos = llDetectedTouchST(0); localPos.x = boardDimensions.x*localPos.x - boardDimensions.x*0.5; localPos.y = boardDimensions.y*localPos.y - boardDimensions.y*0.5; llSetLinkPrimitiveParamsFast( 2, [PRIM_POS_LOCAL, localPos] ); } } When I tested this, the object was attached to my Avatar center, but since these are local coordinates, that shouldn't matter. I even saw that this works ok when not attached as well. A solution using llDetectedTouchPos may yet be possible, but this was the first approach I tried. Edit: Whoops, that if/else condition for each axis seems to be unnecessary since both branches are doing the same thing. I think that's a remnant from an earlier attempt when I was using a different through process. I've removed it to further simplify the demo.

Regarding the question at hand, the script is basically doing three things: Detecting whether it's just been attached to an avatar, and then Issuing a message to the owner Initiating a detach - which itself involves requesting the PERMISSION_ATTACH to be granted first. If your goal is to trigger #2 and #3 from a touch, then the first step would be to add in a touch_start event. Within the touch_start event you can check if the object is currently attached by checking the return value of llGetAttached. If it is determined that the object is attached at this time, then you can move the llOwnerSay and llRequestPermissions commands into the touch_start event, and get rid of the attach event. The run_time_permissions can be reused as is. How exactly to set this up, I leave as an exercise to the OP. But it will follow a very similar structure to what you see in the attach event.

Sorry, but that's not entirely true. In my testing, I've seen that there are some instances where llStopSound will be able to stop attached audio started by llSound. There are also other instances where it won't stop the sound, so I can understand the different results you might see if you tested it yourself. Below is a simple test harness which you can use to try the all different parameter combinations (the queue and loop parameters seem to change the nature of the sound with regards to whether it can be stopped by llStopSound). Uncomment one, save the script and then click the host prim before the audio completes. The comments indicate the results I saw when testing. key audio = ""; //fill in your audio uuid (use as long a sound as possible) default { state_entry() { llStopSound(); //llPlaySound(audio,1.0); //can be stopped //llSound(audio,1.0,TRUE,TRUE); //can be stopped //llSound(audio,1.0,FALSE,TRUE); //can be stopped //llSound(audio,1.0,TRUE,FALSE); //can't be stopped //llSound(audio,1.0,FALSE,FALSE); //can't be stopped } touch_start(integer total_number) { llStopSound(); } } I believe this is a case where the wiki's documentation is in need of an update and/or more clarification. Because the page for llStopSound also doesn't mention that it works for audio started by llPlaySound - in practice it does, which I included in my test script. Since it only explicitly mentions llLoopSound, it may be causing some confusion. But this is getting a bit off topic To circle back, if you want to adjust the volume of a currently playing attached sound, as others have said earlier llAdjustSoundVolume is one method - though it does incur a 0.1 second pause in script execution. Interestingly, llAdjustSoundVolume will work on the same instances of llSound for which llStopSound has an effect and it won't work for the instances that llStopSound doesn't effect. You can replace llStopSound in my example above with llAdjustSoundVolume and see similar results. In either case, this is largely moot since llSound is deprecated and ostensibly we shouldn't be using it. The behavior we see today could very well change or break entirely at any point. Still, I find it pretty interesting.

The strange part is that llStopSound is indeed capable of halting looping audio created by llSound at any point (just tested in-world), but apparently it won't work for a non-looped one. I'm still puzzled why LL would choose to replace it instead of fixing what could legitimately be considered a bug back then. There could very well be more going on under the hood with these functions that we don't get to see which could have contributed to the switch. I did some more poking around found the version 0.2.0 release notes on another wiki which were for one of the closed betas in 2002. There is a reference to llPlaySound there which implies it was already implemented before the public release of SL. That makes the choice to deprecate llSound in favor of llPlaySound even more intriguing. If it was done during closed beta, why keep llSound around at all? Very interesting!

Qie, I spent some time messing with the old llSound on the beta grid and here are my findings: llSound seems to only loop if both the queue and loop parameters are TRUE. Calling llSound with the loop parameter set to FALSE will not interrupt an already playing attached sound (looping or not) set by llLoopSound llPlaySound, or a previous llSound call. The queue parameter doesn't seem to have any effect (that I could see) when loop is FALSE. Calling llSound with queue=FALSE and loop=TRUE will interrupt any currently playing/looping attached sound similar to llPlaySound's behavior. Calling llSound from a HUD will result in the sound emanating from the avatar's in-world position instead of the worn HUD. As a side note, I did a little digging and discovered that llSound has been deprecated since early 2004 - and possibly earlier. That's astoundingly early... I'm really curious what happened back then to make them switch.

Why are you so confrontational? I was responding to OP's most recent reply - in which they were asking where to place the llStopSound command in their sample script.

For a quick fix of stopping the currently playing sound and restarting it with a new volume, Placing llStopSound(); on the line before the llLoopSound command in your state_entry event should work. Make sure you don't forget to add a semicolon ( ; ) after the command - otherwise you'll get a syntax error.