Rolig Loon

Here's a simple script for the seat.... stopAnim(){ list temp = llGetAnimationList(gAv); integer i = (temp !=[]); while(~(--i)) { llStopAnimation(llList2String(temp,i)); }}key gAv;default{ state_entry() { llSitTarget(<0.0,0.0,0.5>,ZERO_ROTATION); //Change this sit target as necessary } changed (integer change) { if (change & CHANGED_LINK) { if(llAvatarOnSitTarget()) //When Av sits down.... { gAv = llAvatarOnSitTarget(); llRequestPermissions(gAv,PERMISSION_TRIGGER_ANIMATION); } else // When Av stands up .... { llRegionSayTo(gAv,-47102,"Good Bye!"); //Message to HUD script } } } run_time_permissions(integer perm) { if(perm & PERMISSION_TRIGGER_ANIMATION) { stopAnim(); llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION,0)); llRegionSayTo(gAv,-47102,"Hello!"); //Message to HUD script } }} And here's an accompanying HUD script .... default{ state_entry() { llListen(-47102,"","",""); } listen(integer channel, string name, key id, string msg) { if(msg == "Hello!") // The sit down message { llSetColor(<0.0,1.0,0.0>,ALL_SIDES); } else if (msg == "Good Bye!") // The standup message { llSetColor(<1.0,0.0,0.0>,ALL_SIDES); } }} The trick here is that the llRegionSayTo function speaks to an attachment that the av is wearing (the HUD in this case) if the message is sent on a non-zero channel. Because the message is aimed at the AvatarOnSitTarget, the only HUD that will hear it is the one being worn by that particular av.

This is a good place to point out that mastering syntax is the easiest part of learning to script. The hard part is logic, and that is almost independent of the scripting language and its syntax. Map out (on paper if necessary, but at least in your head) what the path from your starting point to the finish line has to look like. Where are the decision points along the way? What will happen at each of them if the user makes a different choice or if the script's environment changes? What pieces of information will you need in order to make decisions at each of those points? How will you know when you have reached them? If you can create a logical map that answers those questions, finding the syntax to describe the map is relatively simple. In this case, remember that LSL is an event-driven language. Actions in the environment trigger events, and all actions take place in those events. Once a timed event is triggered, the action that occurs happens in the timer event.

The table at http://wiki.secondlife.com/wiki/Rotation is about as comprehensive as you're going to get. That whole article is helpful. See also http://wiki.secondlife.com/wiki/User:Void_Singer/Rotations

Now that you have the llMessageLinked syntax figured out, get rid of it. If all you are doing is changing a texture in the other prim, use llSetLinkTexture. That lets you change the texture in the other prim directly and it gets rid of an unnecessary script in that prim too.

It's not clear to me why you want to clear cache. That shouldn't be necessary unless one or more of your cached files (inventory, appearance, preferences...) has gotten out of sync with SL's servers. Othrrwise, clearing cache has little effect, excpt that it slows down rezzing the next time you log in because your computer is having to reload all the files you wiped out. If you really want to clear your cache, though, you don't have to be in SL to do it. Clear your cache manually. See >>> http://wiki.phoenixviewer.com/doku.php?id=cache_clear

Call the billing office and ask why. LL's billing team is available 24 hours a day, seven days a week. Toll-Free (US/Canada) 800.294.1067 Long-Distance 703.286.6277 Local Toll-Free numbers * France: 0805.101.490 * Germany: 0800.664.5510 * Japan: 0066.33.132.830 * Portugal: 800.814.450 * Spain: 800.300.560 * UK: 0800.048.4646 * Support is in English Only

Yeah.. annoying. :smileysad: It should be easy to find, though. A script can't do anything unless it is in an object, and the object must be attached to you. So, open your inventory, click the Worn tab, and look for unfamiliar objects. You're looking for something named Croft Window. When you find it, detach it and delete it from your inventory. If you want to put off the search for some reason, you could always just mute the thing for now.

Yeah, it could be LL's servers doing something wierd. It could also be your own system. Textures in SL are rendered in four passes, increasing in resolution on each pass. That saves your GPU from having to render sharp images that you won't see for more than a fleeting glance. If your connection is good, the textures are already cached on your machine, your drawing distance is reasonably short, there aren't a lot of things to render in your field of view, and LL's servers aren't lagging, it usually takes only a few seconds to go from the first pass through the fourth one. The more work your GPU has to do and the crummier your connection, the longer it takes .... sometimes an hour or more. It's hard to sort out which factor is the limiting one. If you want an independent reference point, though ...... I haven't seen any change in rezzing behavior anywhere I have been in the past month or two.

Rumors are worth the paper they aren't written on.

I suspect that the reason is partly financial and partly social. The financial part, as others said, is that mesh costs more to upload than a simple image. You can run up a big bill very quickly if you are uploading test meshes to the main grid, and LL probably wants to know how you are going to pay for it. The social part is just my guess, but I think it's one way for LL to deal with people who might be tempted to upload stolen mesh. If you have payment information on file, you can't be anonymous. I know people have been able to upload ripped off image files since Day One, too, but it's too late to go back and make everyone have PIOF (although it would be a great idea). This way they can start with a clean slate and at least minimize mesh theft. BTW, I agree. We have complained for a long time about how hard it is for an OP to respond to her own thread here. You seem to have figured out our clunky system, though. Congratulations.

No. That username is like your Social Security Number in RL. It's yours for life. You can open a brand new account if you like, or you can use a Display Name, but there's absolutely nothing you can do to your username.

Nope. Your chat logs are not saved in the SL servers. They are only in the Local files on your machine. If you erase those files, they are no longer a historical record. They are history.

There are free door scripts all over SL. For a start, take a look right here in the LSL Scripting Library. If you want a nice, simple rotating door, see >>> http://community.secondlife.com/t5/LSL-Library/Simple-Hinge-Action/td-p/875331. If you want a sliding one, try >>> http://community.secondlife.com/t5/LSL-Library/Linkable-Multiprim-Sliding-Door/td-p/722649

See my response in IM. You aren't making it light by right clicking on it. You are selecting it and seeing the selection highlight. A face light is not like a flashlight. Don't expect to see a beam. A face light makes YOU light up by brightening everything within the radius you have set in it. It doesn't make ITSELF brighter.

See my response in IM. You aren't making it light by right clicking on it. You are selecting it and seeing the selection highlight. A face light is not like a flashlight. Don't expect to see a beam. A face light makes YOU light up by brightening everything within the radius you have set in it. It doesn't make ITSELF brighter.

Two potential issues and a matter of personal preference: (1) Any of the permission constants are bit masks, so when you want to test whether PERMISSION_TRIGGER_ANIMATION has been granted, for example, you need to use a binary & operation, as in .... run_time_permissions (integer value){ if(value & PERMISSION_TRIGGER_ANIMATION) { // do stuff }} The same applies in the changed event, where you would normally test for if (llGetPermissions()& PERMISSION_TRIGGER_ANIMATION) (2) PERMISSION_TRIGGER_ANIMATION is generally released when you stand up from a sit, so you don't need to test for that condition and then llStopAnimation(theAnim) . In fact, doing this will usually kick up a script error, telling you that it cannot stop the animation because it no longer has permission. (3) An agent is either sitting on the object or it isn't. Except in unusual circumstances, I can't see a good reason for the complicated test if ( agentKey == NULL_KEY && agent != NULL_KEY) instead of simply testing if (llAvatarOnSitTarget()) . One unusual circumstance might be when you have been using agentKey for something else, like a money event, and want to be sure that the next person who sits isn't mistaken for the previous one. For a simple pose ball application, though, this seems like overkill.

Two potential issues and a matter of personal preference: (1) Any of the permission constants are bit masks, so when you want to test whether PERMISSION_TRIGGER_ANIMATION has been granted, for example, you need to use a binary & operation, as in .... run_time_permissions (integer value){ if(value & PERMISSION_TRIGGER_ANIMATION) { // do stuff }} The same applies in the changed event, where you would normally test for if (llGetPermissions()& PERMISSION_TRIGGER_ANIMATION) (2) PERMISSION_TRIGGER_ANIMATION is generally released when you stand up from a sit, so you don't need to test for that condition and then llStopAnimation(theAnim) . In fact, doing this will usually kick up a script error, telling you that it cannot stop the animation because it no longer has permission. (3) An agent is either sitting on the object or it isn't. Except in unusual circumstances, I can't see a good reason for the complicated test if ( agentKey == NULL_KEY && agent != NULL_KEY) instead of simply testing if (llAvatarOnSitTarget()) . One unusual circumstance might be when you have been using agentKey for something else, like a money event, and want to be sure that the next person who sits isn't mistaken for the previous one. For a simple pose ball application, though, this seems like overkill.

Just because you can connect to e-mail and your web browser doesn't mean that your Internet connection is fine. SL requires a continuous connection and a large amount of bandwidth, unlike most applications on your machine that can tolerate gaps of several seconds or even minutes in service. If you haven't done it yet, at least reboot your router. Over time, a router's RAM is filled with random garbage and it can lose a firm grip on your IP address. Unplugging it from the power for a few minutes will restore and strengthen the connection. That may not solve your immediate problem, but it's a wise preventive measure. The other thing you can do is get off of wireless, if you haven't already. Wireless is fine for slow, static applications. It is very easily interrupted by cell phones, garage door openers, and other nearby electronic devices, however, so many SL residents have trouble on wireless.

Just because you can connect to e-mail and your web browser doesn't mean that your Internet connection is fine. SL requires a continuous connection and a large amount of bandwidth, unlike most applications on your machine that can tolerate gaps of several seconds or even minutes in service. If you haven't done it yet, at least reboot your router. Over time, a router's RAM is filled with random garbage and it can lose a firm grip on your IP address. Unplugging it from the power for a few minutes will restore and strengthen the connection. That may not solve your immediate problem, but it's a wise preventive measure. The other thing you can do is get off of wireless, if you haven't already. Wireless is fine for slow, static applications. It is very easily interrupted by cell phones, garage door openers, and other nearby electronic devices, however, so many SL residents have trouble on wireless.

You Can Place A Note In The Inworld Employment Section Of The Commerce Forum. Don't Expect Many Replies, Though. Most Content Creators I Know Want To Market Their Own Creations Instead Of Sharing The Profits With Someone Who Doesn't Have To Do Any Of The Work. By The Way, Why Are We Capitalizing The First Letter Of Every Word?

You Can Place A Note In The Inworld Employment Section Of The Commerce Forum. Don't Expect Many Replies, Though. Most Content Creators I Know Want To Market Their Own Creations Instead Of Sharing The Profits With Someone Who Doesn't Have To Do Any Of The Work. By The Way, Why Are We Capitalizing The First Letter Of Every Word?

You could put a light anywhere you want. A face light isn't anything fancy. It's just a spherical prim made transparent and set to be a light source. You can make one easily, if you are in a place where you can rez objects, like a sandbox. (1) Open your Build Edit tool (CTRL + 3) and select the rezzing tool (looks like a magic wand -- top row) (2) Select the sphere icon from the row right below it. (3) Rez a sphere by left-clicking on the ground. (4) Click the "Features" tab in the Build Edit tool, and then click the box that says "Light". That makes the sphere into a light source. You can play with the Intensity, Radius, and Falloff settings to change how bright it is and how far away it shines. (5) Click the "Texture" tab and change Transparency from zero (its normal setting) to 100. That will make your shining sphere invisible. See? Now you have a face light ... or a shoe light. Click the "General" tab and give your face light a name, then take it to your inventory. You can Wear it on your chin or your nose, and you can use your edit tool to move it around once its attached there. (If you can't see it, type CTRL + Alt + T to make it glow red temporarily.) Making it a shoe light instead of a face light is really easy. If you have mod permission on your shoes, just use your Build Edit tool to link the light to your shoe. If you don't (or if you don't feel confident about linking), then Wear your face ball on your Lower Leg. (Right click on it in your inventory and select Attach To... >> Lower Leg.) That's it. As building projects go, this is a pretty simple one, and it's kinda fun. If you don't get it right the first time, try again. Then teach someone else. :smileywink:

You could put a light anywhere you want. A face light isn't anything fancy. It's just a spherical prim made transparent and set to be a light source. You can make one easily, if you are in a place where you can rez objects, like a sandbox. (1) Open your Build Edit tool (CTRL + 3) and select the rezzing tool (looks like a magic wand -- top row) (2) Select the sphere icon from the row right below it. (3) Rez a sphere by left-clicking on the ground. (4) Click the "Features" tab in the Build Edit tool, and then click the box that says "Light". That makes the sphere into a light source. You can play with the Intensity, Radius, and Falloff settings to change how bright it is and how far away it shines. (5) Click the "Texture" tab and change Transparency from zero (its normal setting) to 100. That will make your shining sphere invisible. See? Now you have a face light ... or a shoe light. Click the "General" tab and give your face light a name, then take it to your inventory. You can Wear it on your chin or your nose, and you can use your edit tool to move it around once its attached there. (If you can't see it, type CTRL + Alt + T to make it glow red temporarily.) Making it a shoe light instead of a face light is really easy. If you have mod permission on your shoes, just use your Build Edit tool to link the light to your shoe. If you don't (or if you don't feel confident about linking), then Wear your face ball on your Lower Leg. (Right click on it in your inventory and select Attach To... >> Lower Leg.) That's it. As building projects go, this is a pretty simple one, and it's kinda fun. If you don't get it right the first time, try again. Then teach someone else. :smileywink:

You can do that, but it won't do what you expect. As written, every one of your if tests that ask if(message == "yes") will always return TRUE, so every single block of code in them will always be executed. Same with the ones that test for "no". If you want to have a sequence of actions like that, you''ll need to add a flag or a counter or some kind. if (message == "yes") { if (counter == 1) { //do this stuff the first time counter = 2; } else if (counter == 2) { // do this stuff the second time } } else if (message == "no") and so forth

The problem is not SL's servers. You have a borked file. Have you tried deleting that image file from your APPDATA file? You have its path and filename in the image you posted. If simply deleting the image doesn't solve the problem, do a clean re-install of your viewer. Do not simply re-install a new copy of the viewer on top of what's there now, or you'll just inherit the old, borked files. See >>> http://wiki.phoenixviewer.com/doku.php?id=fs_clean_reinstall . The instructions work for any viewer, although the filenames may be different.