KT Kingsley

@Rider Linden The next time someone at LL says "Hey, we've got this cool idea for a new project. Any volunteers?" keep schtum.

That is kind of what I first thought, but when I gave it a quick blast inworld it didn't work using NULL_KEY, but did using "". Mind you I was in a bit of a rush and I wasn't being systematic, so it could've been almost any of the other tinkering I was doing that caused the failure.

I'd suggest you'll want to start the notecard read in the touch_start event. That way you can drop the notecard into the prim and then click on it to get the process going. Then I'd suggest you use LLRegionSay rather than llRegionSayTo because that way you won't need to identify the receiver by its UUID. And you can put the llRegionSay in the dataserver event where you get the UUID from the notecard. And that llRegionSay can say just the UUID you're using. There's no need to send a message "Change". In the receiver script you don't want to listen out for an object that's identified by a NULL_KEY (that won't exist). The way to specify any object key is to use an empty string: "". And also in the receiver script you don't need to be listening for a specific message "Change", but rather for any message. Hopefully the only message it'll ever hear is the UUID of the texture you're using. string notecardNameOrKey = "#New Note#"; key notecardQueryId; integer notecardLine;// first notecard line is 0, so we don't have to set notecardLine = 1 here default { touch_start(integer total_num) { llSay(0, "Reading notecard..."); notecardQueryId = llGetNotecardLine(notecardNameOrKey, notecardLine); } dataserver(key query_id, string data) { if (query_id == notecardQueryId) { if (data == EOF)// we have reached the EOF (end of file) { llSay(0, "No more lines in notecard, read " + (string) notecardLine + " lines."); llRemoveInventory(llGetInventoryName(INVENTORY_NOTECARD, 0)); } else { // increment line index first, both for line number reporting, and for reading the next line ++notecardLine; llSay(0, "Line " + (string) notecardLine + ": " + data); notecardQueryId = llGetNotecardLine(notecardNameOrKey, notecardLine); llRegionSay (5589, data); } } } } default { state_entry() { llListen (5589, "", "", ""); } listen (integer channel, string name, key id, string message) { llOwnerSay ("Message received: " + message); llSetTexture (message, 0); //or change the 0 to whatever face number you're using } } Now, there's plenty of pitfalls to be found here. Perhaps the most likely is that the notecard will have a blank new line after the UUID, and this blank will be said to the receiver which will try and fail to apply it as a texture. So for now, while you're just getting the basics of this working, make sure that the notecard contains just the UUID on the first line, and that there's no blank (or even non-blank) new line after the UUID. We can get into ways of catching errors like that later if you need to.

Sorry, I can't point you at a script. But don't feel too bad about stuff not making sense to you. A lot of it doesn't make any sense to most of the rest of us either.

But the notecard reader as described makes no mention of lists. It describes reading a single texture UUID that needs to be sent to another object. There is no need for a list.

Why are we discussing lists here?

Maybe there's a confusion between "list" and "listen" happening somewhere here?

As you've already figured out, you use llGetNoteCardLine to read from a notecard. The data you get in the dataserver event will be the texture's UUID (at least it will be if the notecard you're reading from has been done properly). llRemoveInventory. The touch_start or touch_end events. To get the UUID to a seperate object you'll probably want to use llRegionSay in the HUD and set up a listener in the target object using llListen so that the message will trigger the listen event, where you can use llSetTexture to apply the texture to the object. (llSetTexture isn't particularly fussy about whether the UUID it's given is a string or a key, and there's no need to get involved with lists for this.) Note that you need a script in the target object that knows which channel the HUD will be using to broadcast the texture's UUID.

The inventory thing is related to the size of the first level of inventory: the folders directly under the inventory folder that you see when you open the inventory floater, and their contents. Sub-folders of those seem to load quietly in the background or when they're opened.

TP out of Coconut Island to Endless at approx 21:45 PDT Friday 5th May, failed. Relogged to Last Location. Message: Login failed. Agent not in region. Please try again in a minute. (Or words to that effect.). Relog returned to where I'd last logged into after a normal SL exit (which must be a few days ago by now).

That's an option in what you type into the search text box: "red AND boots NOT demo". Click the question mark next to the search text box for a brief explanation and a link to a complete explanation.

Sorry, I didn't make a note at the time, and as I'm constantly jumping from LM to LM I don't remember.

Relogging after a failed TP and freeze, I got a message I've not seen before: Avatar not in region. Closing FS and re-relogging worked ok.

I see "Account, Billing, Land & Region, Marketplace, Technical Questions and Other Second Life Properties" in that drop-down. I'm a premium member, though I don't know if or how that might affect what options I'm offered. And I'm logged in on the website.

Maybe just not add it to the list if it meets the criteria: if (llSubStringIndex (llToLower (contents_name), "freya") == -1) objectlist += contents_name;//list of object names

How about having the script read the particle parameters from a notecard that you drop into the prim?

As mentioned in other threads, if your TP is failing (for me this usually means that it hasn't happened within about five seconds, and "Requesting teleport..." hasn't appeared in the TP progress bar) click the cancel button and repeat the TP request. This brings up the "Teleports are locked" message, which you can dismiss, and also completes the teleport.

There's also the moving_start and moving_end events, which are triggered in an attachment's scripts when the avatar starts and stops moving, though the type of movement isn't limited to just walking. If you want to be walking-specific, you could use Rolig's test for that in the moving_start event and start the rotation when appropriate, and then stop it in the moving_end event.

Just to add to Wulfie's post, the commands for use with shared folders (which are what you want to use for RLV outfit folders) are here: http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI#Clothing_and_Attachments_.28Shared_Folders.29.

Just noticed that both in the OP and in the wiki, the description for the SKY_SUN parameter for llGetEnvironment refers to "moon" rather than "sun" in the last four bulleted items.

The llDetected* functions (as in user = llDetectedKey (0)) don't work in a link_message event, so the user you're targeting is the NULL_KEY. Make sure that the script that's sending the link message has the key for the target user in the key parameter of the llMessageLinked function, something like: llMessageLinked (LINK_SET, 0, "texture", llDetectedKey (0)), and then use that parameter in the call to your menu function: menu (target_key, "Select a Texture.", texture_list).

Yup, the moon is moving just fine in http://maps.secondlife.com/secondlife/Hane/203/125/58. And yup, that script in my post is comparing the two. It's an extract from a script I was using to try to get my head around how the various EEP functions work, and it compares both the parcel and region rotations for both the sun and the moon. And it gives the same results both in my home parcel (which has had absolutely no EEP tinkering performed on it: I haven't even downloaded the EEP viewer) and in the adjacent Linden Home public land, and on other LL owned public mainland.

I'm getting an odd result using llGetRegionMoonRotation, in that it's returning a result that when Rot2Eulered and RAD_TO_DEGed has a y component of zero all the time. The equivalent llGetMoonRotation returns a value, similarly treated, whose y component changes over time. default { state_entry () { llSetTimerEvent (1.0); } timer () { string text = "Moon rotation " + (string) (llRot2Euler (llGetMoonRotation ()) * RAD_TO_DEG) + " " + (string) (llRot2Euler (llGetRegionMoonRotation ()) * RAD_TO_DEG) + "\nSun rotation " + (string) (llRot2Euler (llGetSunRotation ()) * RAD_TO_DEG) + " " + (string) (llRot2Euler (llGetRegionSunRotation ()) * RAD_TO_DEG) ; llSetText (text, <1.0, 1.0, 1.0>, 1.0); //llOwnerSay (text); } }

The angle brackets around the <n> are wrong. It should be @setcam_unlock=n. In the API documentation, <y/n> means you can use either y or n, but leave out the angle brackets which are there to indicate the beginning and the end of a list of possible options.

If you want to stop your head turning while you're trying to take a photograph you can right click and edit an attachment. In Firestorm there are settings for the amount your avatar's head follows your mouse and for random eye movement in Preferences/Firestorm/Avatar. You could also try editing the attentions.xml file if the character sub-folder of your viewer's folder. I've set the focus mode to a high priority and to never timeout so when I Alt+Click on anything (Alt+Clicking on my own avatar keeps my head in its "natural" state, as defined by the animation that's playing) the mode doesn't revert to idle, which is where the mouse following happens.