KT Kingsley

The Firestorm AO has a thing where it kicks into swimming when you're flying underwater. I've only ever used it to see what it does, but it didn't really seem to suit my needs, and I prefer to use my own AO based on llSetAnimationOverride. Adding swimming to that has long been an intended project, though one I haven't gotten around to yet. Someone once suggested that turning your HUD into a vehicle while you're swimming would be the way to go. Anyone have any experience of that? Meanwhile I continue to use Siggy Romulus's ancient The Swimmer 2.06, which I don't mean to either recommend or deprecate.

I think that'd make it too easy to acquire free copies of paid-for EEP setups.

Many thanks, Oz, for everything you've done, and especially for they way that you did it. Have fun!

Once you've found Blake Sea there's the Nautilus island continent to the west which you can circumnavigate, and numerous connected private sailing regions to the northeast and southeast. Heading north from the northwest corner are passages to even more water areas. It's been a while since I've taken my boat out, but I think all, or most, of the major sailing areas are now connected, though sometimes via narrow and not very obvious passages. Unfortunately the world map is hors de combat right now, but once it's back you'll be able to zoom in on the less obvious connections, and zoom out to see the wealth of large sailing areas available in SL. Here's an SLURL for you: http://maps.secondlife.com/secondlife/Foligno/205/12/22. From here you can head off towards the northern continents and seas, or south towards the Blake sea (hang a left at the top of the "heart" region where there's a channel across to the other side and then continue south).

Hmm, I tired that myself (copied from your post and pasted into a new script in a newly created cube) and it compiled (saved) without errors. I can only guess, but perhaps there's an extra character somewhere in the script you copied the post from that slipped through?

Ah, is the object rigged mesh clothing? As far as I know you can't instatouch worn rigged objects, and have to go through the menu. I think you're going to have to use a transparent unrigged prim or mesh, shaped to match (roughly) the rigged clothing, and linked to it. The unrigged prim should react to instatouches. You'll wear the link set on an attachment point where you can get the linked unrigged prim into a position that matches the rigged item. An item can detach itself automatically using the function llDetachFromAvatar. For that to work the script needs to get permission using the function llRequestPermissions with the parameter PERMISSION_ATTACH beforehand. default { state_entry () { llRequestPermissions (llGetOwner (), PERMISSION_ATTACH); //dialog if not worn, automatic if worn } touch_end (integer count) { //Rezzing stuff here llDetachFromAvatar (); } } (I've used the touch_end event here because touch_start was being a bit unreliable.) When you link the rigged item with the unrigged prim you should make the rigged item the root, and the script should go in the root. (At least, that's what worked for me when I tried it out just now.)

I tried it, too, and it did work. So, obvious questions first: are you on land where you're allowed to rez things, and does the land allow scripts to run? Is there something invisible getting in the way? Try right-clicking it and selecting "touch" from the menu. Put an extra line inside the touch_start event: llOwnerSay ("Touched"); (between the "{" and the "float"). Does that respond when you click? Oh, and is the script set to "running"?

It works as it is if you're wearing the object it's in. You may want to adjust the vector <0, 0, 1> a bit so that the rezzed objects don't push down on your avatar when they rezz.

The bake service is the process that generates the BoM and system avatar textures by combining the skin, tattoo, clothing and alpha layers into a single texture. It's the first time I've seen that mentioned in a status update, too. I didn't know that premium services had their own processes distinct from everything else. Presumably the software for these is being updated so that it runs better in the cloud.

0 is fine. It's up to the receiving script to decide what, if anything, to do with the parameters it gets in the link_message event. The integer, string and key values you put into the llMessageLinked function are the values the script(s) in the specified link will get in their link_message event parameters. If there's only one other script listening out for link messages and it has only one job to do, then none of the parameters really matter: just receiving a link message can be enough to let it know it should do its thing. The integer parameter is often used to do things like identify a particular script that needs to respond to this link message, but not others, or to specify a particular request to do something specific with the data in the string or key parameters. The 0x5000 value you mention could be something like that.

It's one of the three pieces of information you can send using llMessageLinked, and you can use it (or not) for whatever you want, the same as the string and the key parameters. It doesn't affect what the function does. Incidentally, you can also use the key parameter to send another arbitrary string to the receiving script.

Yup, the debug setting "EnvironmentPersistAcrossLogin" is there in the LL viewer.

I'd never looked at the caveats for the attach event before this! That's useful to know. Also, I found an explanation for something that's been bugging me for ages in there too. Thanks for pointing this out. Maybe the issue you're having is something to do with something like the Slink script checking keys or owner keys or the attachment status of the source of the command that get messed up during a detach? In my amateurish hacky way, I guess I'd try using a second attached object (maybe a permanently worn HUD) that gets a message from the first object when it's detached, and then issues the toenail command itself, perhaps detaching itself after that. Or something like that.

I have a few things that work in the same way, and they do work pretty well. I've found you can get a couple of lines of code to execute pretty reliably in the attach even when the object is being detached. I suspect the occasional failure is due to to a very busy simulator. Any code not executed when the object is detached does pick up where it left off when the object is reattached. My code looks like this: attach (key id) { if (id) //object has been attached { //do stuff when attached } else //object is being detached { //do stuff when detached } }

If you use Firestorm you can set the home page of the built-in browser to Google Translate (Preferences/Network & Files/Connection), and you can open it using Ctrl+Shift+Z or a toolbar button. Also, I guess you could make a gesture that chats the link. Not very elegant, though.

I think you're looking for "Personal Lighting". In the LL viewer it's in the top bar menu World/Environment/Personal Lighting... In Firestorm I generally use the button in Quick Preferences.

To respond to clicks, you need a touch_start event. In that event you can test the result of llDetectedKey(0) to see if it's the owner. touch_start (integer count) { if (llDetectedKey (0) == llGetOwner ()) { //Clicked by the owner llPlaySound ("My sound clip", 1.0); } else { //Clicked by someone else } } If all your script is intended to do is to make a noise when the owner clicks it you only need the touch_start event. I'm guessing, though, that the script is actually doing other things that do require listening to chat and reading notecards, beyond what you've posted.

You've left out some braces (curly brackets): integer Listen_Detect; default { state_entry() { Listen_Detect = llListen(0, "", llGetOwner(), ""); } listen(integer channel, string name, key id, string message) { key Owner = llGetOwner(); key OwnerID = llGetOwnerKey(id); if(OwnerID != Owner) return; else { llGetOwner(); llListenRemove(Listen_Detect); } }//missing dataserver(key ListA, string lsData) { //No more lines to read if(lsData == EOF) { llSetText("End of notecard reached", <1,1,1>, 1); llSleep(1.0); llSetText("", <1,1,1>, 1); } }//missing }//missing Keeping your braces aligned really helps sort out that kind of issue. Incidentally, all that testing for the owner in the listen event is redundant: you've specified the owner in the call to llListen, so only chat from the owner will ever trigger the listen event. Also, for this to compile you need to define Listen_Detect as a global integer, before the default state, as in the code I've shown above.

https://status.secondlifegrid.net/ Marketplace Down For Unscheduled MaintenanceSubscribe Investigating - The Marketplace is currently down for unscheduled maintenance. Residents may receive a "502 Bad Gateway" error when attempting to access the Marketplace. Please follow this blog for updates. Feb 2, 11:24 PST Unscheduled Marketplace MaintenanceSubscribe Investigating - We are aware of problems when purchasing L$0 objects on the Marketplace, and for now we recommend using the Buy Now (instead of Add to Cart) option for those objects until we have it resolved. Please follow this blog for updates. Feb 1, 13:45 PST

Sadly, the changed event isn't triggered by animation state changes. You'll have to poll llGetAnimation in a timer event every couple of seconds.

If you're going to do any sorting a strided list is needed: [score, avatar, score, avatar, ...]. If you're keeping track of avatars you should perhaps consider using avatar keys, which are immutable, rather than names which can change, and which can be spoofed.

I tend to use explicit floats and explicit typecasts, though this is mainly to help keep my own head straight. Where I do have some exceptionally busy code (which is hardly anywhere) I will look for any optimisations I can make.

You need a index that you increment (making sure it doesn't go out of bounds, and resetting to 0 when it does) whenever you rez an object. It should be declared as a global integer variable so that it persists across each timer event. Use the index variable in llGetInventoryName, replacing the constant 0. Incidentally, llSetTimerEvent ("60") won't work: you need a float value there and not a string literal.

A bit of specularity makes normals more obvious.

Not done much with vehicles for a long time, but the functions llGround and llWater, and the land_collision events might be useful to you.