Rolig Loon

I use LSLEditor almost exclusively. It is up to date and offers good diagnostic messages. I used to use the in-world editor when I'm in SL, but now that Phoenix lets me link directly to LSLEditor from in world, I'm finding that I use it almost all the time.

Wearing the object as an attachment means that it will mimic your own large body movements, which will actually make it look less natural than if you let it follow you. As you twist and bend, any attached object stays in a constant place relative to the attachment point. That's fine for something like a shoulder pet that is meant to look physically attached to your body, but not so good for something that is supposed to follow at a distance. Your object will tend to whip around every time you change position. The only big advantage to wearing it is that the object will stay with you as you TP or fly, instead of being abandoned.

We seem to get a lot of requests for a script that will give access to some residents but not others. Here is a generic script that lets the owner give access to (1) Owner only, (2) Group and owner, (3) whitelisted avatars, (4) group and whitelisted avatars, or (5) everyone. All you need to do is drop the script and a notecard with whitelisted names into an object. (Be sure to add your own event in state OK to define the action that people with access are allowed to do -- open a door, receive an object, play a sound .... whatever.) // Generic Whitelist Script -- Rolig Loon -- March 2011 // Put login names (NOT Display names) of avatars to be whitelisted in a notecard, one per line // Spelling and capitalization count list gWhiteList = []; string gCard; integer gLine; key gQuery; list gWho = ["Me Only","Group","List","Group+List","Everyone"]; integer gAccess; integer gDChnl; default // Read Whitelist from notecard, one name per line { state_entry() { if(llGetInventoryNumber(INVENTORY_NOTECARD) == 1) { gCard = llGetInventoryName(INVENTORY_NOTECARD,0); gQuery = llGetNotecardLine(gCard, 0); } else { llOwnerSay("The whitelist notecard is missing."); } } changed(integer change) { if (change & CHANGED_INVENTORY) { llResetScript(); } } dataserver(key QID, string data) { if(gQuery == QID) { if (data != EOF) { gWhiteList += [llStringTrim(data,STRING_TRIM)]; gQuery = llGetNotecardLine(gCard, ++gLine); } else { llOwnerSay("Initialized"); state running; } } } } state running { state_entry() { gDChnl = (integer) ("0xF" + llGetSubString(llGetOwner(),0,6)); } changed(integer change) { if (change & CHANGED_INVENTORY) { llResetScript(); } } touch_start(integer total_number) { llResetTime(); integer idx = llListFindList(gWhiteList,[llDetectedName(0)]); if (llDetectedKey(0) != llGetOwner()) { if ((gAccess == 4) || ((gAccess == 3) && (~idx || llSameGroup(llDetectedKey(0)))) || ((gAccess == 2) && (~idx)) || ((gAccess == 1) && (llSameGroup(llDetectedKey(0))))) { llSay(0,"Access granted."); state OK; } else { llSay(0,"Access denied."); } } } touch_end(integer num) //Mouse button released { if(llDetectedKey(0) == llGetOwner()) { if (llGetTime() < 3.0 ) //Less than 3 seconds after mouse button down { llSay(0,"Access granted."); state OK; } else if (llGetTime() >= 3.0 ) // Owner set access permissions { llListen(gDChnl,"","",""); llDialog(llGetOwner(),"Who should have access?",gWho,gDChnl); } } } listen(integer channel, string name, key id, string msg) { gAccess = llListFindList(gWho,[msg]); string temp; if (gAccess == 0) { temp = "you only."; } else if (gAccess == 1) { temp = "group members only."; } else if (gAccess == 2) { temp = " \n" + llDumpList2String(gWhiteList," \n"); } else if (gAccess == 3) { temp = "this group and " + " \n" +llDumpList2String(gWhiteList, " \n"); } else { temp = "everyone."; } llOwnerSay("Access has been granted to " + temp); } } state OK { state_entry() { llSetTimerEvent(10.0); llSay(0,"You're in!"); } changed(integer change) { if (change & CHANGED_INVENTORY) { llResetScript(); } } // Insert whatever events you want available for people with access // Be sure that there is a path back to state running timer() // Return to previous state if nothing else happens before timer triggers { llSetTimerEvent(0.0); state running; } }

You can certainly try all of the suggestions posted so far. Unfortunately, none of them will really make your belt fit all the time. I have been making clothing for a long time, and have learned that it's not enough to make a prim attachment that looks good when you are on a pose stand. As soon as you move (twist, stretch, bend, sit down, dance ....) the orientation of the attachment will shift. Your belt will dig into your body on one side and hang off the other with a big gap. Just do the best you can, using the suggestions posted here, and don't expect perfection. BTW, if you are building your own belt and the design allows it, consider making your belt with a torus that deliberately has a hole smaller than your waist. That way, unless you move a lot, there is never a huge gap between the belt and your body. Also, wear your belt as close to the actual attachment point as possible, so that there is very little relative movement as you twist.

Your resize script can be very simple. Use vector Size = llGetScale to get the current size of the vendor and then define preset sizes for which you change Size.x and Size.z . Let the user select among the presets with a dialog that s/he can activate with a chat command, if you need to avoid a touch option.

Yes, scripting it as a for loop is your slowest option. In this case, though, the time savings is negligble, so it's simply a matter of doing what you find easiest. It should work fine as posted ( as a while loop ), or you could write it as a do .. while loop. Whatever you like.

Unless you want other people to unlock the chastity belt. :smileyvery-happy: It will work either way.

You have a semicolon at the end of the line that says while(a++ < b); at the top of your listen event. That makes it a null statement, and everything after it is being ignored. Just remove the semicolon. Otherwise, your logic is fine. (You also don't need that same line, repeated at the bottom of the listen event. It's doing nothing there.)

And don't forget to remove the } bracket after the line that says llSetStatus(STATUS_PHANTOM, TRUE); // Become un-solid

Yes, those are the same options that I'd have in RL, so it makes sense that they would apply in SL too. Calculating moment of inertia would be a nasty job, especially since you also have to consider the mass and placement of the avatar pilot. I have just been experimenting with decreasing the VEHICLE_ANGULAR_MOTOR_TIMESCALE and increasing the magnitude of the X component of the angular motor direction vector. That seems to help a bit, although it's essentially just using a bigger hammer. Thanks. Your suggestions are reassuring, and this is a nice (if silly) learning exercise.

Darn! I should have thought of that, Dora. :smileytongue: Thank you.

Yes, that certainly makes sense in the context of RL physics. I'm a little surprised to see that SL physics is so sensitive to moment of inertia, though. The whole aircraft is no more than 3m from wingtip to wingtip, or prow to stern, and the center is necessarily hollow, because you have to have somewhere to sit. Its moment of inertia, therefore, is fairly high. This is really a design question, then. Other than trying to cram more of an aircraft's mass around its center of gravity, is there a scripted approach to compensate for the loss of angular motor repsonse?

This falls into the category of annoying mysteries. I have had very little to do with scripting vehicles, but decided to create a simple one-person helicopter just to get a feel for the parameters. It works, and it's kinda cute, but I discovered that as soon as I add a single small prim (an unscripted light bulb) to its rear fin, the vehicle's angular motor becomes very sluggish. It's like trying to turn in stiff molasses. However, if I move the same prim toward the vehicle's center of mass, without making any change in the script, the vehicle's angular motor responds quite quickly. So, what am I overlooking?

1. No, your rezzed objects remain rezzed, so they keep their UUIDs. The only time you get a new UUID is when you rez a new instance of an object. 2. Yes, you can script the changed event to detect a region restart. Your script will not normally reset when there is a region restart, for example, but you could force them to by writing change (integer change){ if (change & CHANGED_REGION_START) { llResetScript(); } }}

Thank goodness. I was afraid that we would lose the archived library resources as LL moved to the new forums. Now, where are all the archived threads from the old Scripting forum? That's where a lot of the creative thinking is buried. ETA: Ah! Never mind. Found it. This is going to take some getting used to. :smileytongue:

Latif Khalifa wrote: The sim freezes that you call "lag events" are still there and there was no visible improvements in server 1.42. I agree. I have been monitoring the server lag as avatars have TP'd in and out of two private sims since mid-summer and have not noticed any statistically significant decrease in the duration of "lag events".