KT Kingsley

Generally a HUD user expects, and is expected, to position their HUDs wherever they find convenient themselves, using the standard build tools. It rarely goes well when a creator forces a HUD to position itself where they think it should go in contravention of the user's wishes. Having said that, you can move a HUD around the screen using llSetPos or llSetLinkPrimitiveParamsFast with the PRIM_POS_LOCAL parameter.

Use llGetObjectDetails with the UUID you got from llGetAttachedList() and the parameter OBJECT_DESC.

There's this utility that might help you: https://wiki.firestormviewer.org/slurl. I've no idea what might have broken in your setup, but SLURL Proxy should set itself up to take SL map references from your browser and direct them to the viewer of your choice. SL viewers usually grab control of the SLURL protocol when they're installed. If you have multiple viewers installed, you may want to keep it linked to a specific one, and this helps with that. In your case it may be that you installed a viewer, and then uninstalled it, leaving the browser with nowhere to send those references.

This is a know bug, uplift-related, and discussed in this forum thread: .The work-arounds are to either use your dashboard to set the abilities (though some people have been reporting issues with their friends list in their dashboard), or to go to one of the two regions that have been kept off the cloud and do it there: http://maps.secondlife.com/secondlife/Debug1/128/128/0.

It's group profiles that show your last login. According to the Xcite! group, it was 2015/02/09. Your in-world profile says you joined SL on 08/23/2006: 14 years 3 months; 5206 days ago.

It might be worth taking a look in her spam folder, and setting LL as a safe sender.

Someone somewhere (here or the Library forum maybe) mentioned a website that hosted a free online database that could be accessed by LSL scripts. A quick Google for "free database online" put Zoho (which sounds vaguely familiar) at the top of my search results, though there's others there too. I haven't looked into any of these myself, but I'd be willing to bet there's something useful out there.

The attach event seems logical. Test the id parameter to check if it's been triggered by an attach or a detach.

One thing I'd suggest is to have a second script that only deals with the stored data and communicates with the main script using link messages, perhaps serving up just one list at a time. How useful that'd be probably depends on how much of the main script's memory is used by the code, and how difficult it'd be to implement on how you're using the data in the main script.

RLV will work directly on the owner of an object issuing RLV commands using, as you say, llOwnerSay. In order for that object to use RLV on someone who isn't its owner they must be wearing an RLV relay: this listens to chat commands from the object and relays them, in turn, to its owner using llOwnerSay. The RLV relay protocol is decribed here: http://wiki.secondlife.com/wiki/LSL_Protocol/Restrained_Love_Relay/Specification.

I can confirm that using both positive and negative channels, and using both llSay and llRegionSayTo a listen event will receive a full 1024 byte message. Perhaps someone with wiki editing rights will see this and correct the wiki entry for llListen at https://wiki.secondlife.com/wiki/LlListen.

The wiki entry for the listen event at http://wiki.secondlife.com/wiki/Listen makes no mention of the length of messages: neither "1023", "256" or "254" appear on the page. The wiki entry for llRegionSayTo at http://wiki.secondlife.com/wiki/LlRegionSayTo does specify a maximum message length of 1024 bytes; how many characters this can accommodate will depend on whether unicode is involved. Edit: I did just check in-world, and I can confirm it's possible to send a 1024 byte message using llRegionSayTo to a script in another object which does receive it in full in its listen event, using a positive-numbered channel.

One thing that puzzles me is your use of the term (string)records[i] which I'm unfamiliar with, and which should throw a syntax error. LSL lists are not arrays and you need to use an llList2* function to access list items: llList2String (records, i). Edit: doh! Firestorm's pre-processor lazy lists thing hit me just as I hit the submit button.

The first thing that comes to mind is that the response has been truncated. According to the wiki entry for llHTTPRequest at http://wiki.secondlife.com/wiki/LlHTTPRequest#Caveats

Maybe sort of a cross between Rolig and Wulfie's methods is to make a mesh object that uses a separate face for each button. You can then have a single script use a combination of llDetectedLinkNumber (if you need to use more than one mesh object to accommodate more than eight button faces) and llDetectedTouchFace to decide what to say to the receiving object. I think llRegionSayTo is the most efficient and secure method of sending chat to an object, but it does require the sending script to know the receiving object's UUID.

If you haven't already done so, work through this page https://wiki.firestormviewer.org/fs_camera. In addition to that, which mentions the debug setting FocusOffsetRearView, you could try resetting CameraOffsetRearView to its default: this setting controls the position of the camera – from what you describe that may be what's at fault.

The code in the attach event is only executed when you put the object on or take it off. When you reset the script it executes the code in the state_entry event (none, in this case) and then waits for some other event to get triggered (again, there's no event going to be triggered unless you take the object off and put it back on again, which will trigger the attach event). Generally the best way to do something repeatedly is to use a timer event. So, the sequence I'd suggest here is attach: llResetScript state_entry: llRequestPermissions run_time_permissions: llSetTimerEvent (15.0) timer: llPlaySound, llStartAnimation, and no llSleep One difference with this scheme is that you will wait 15 seconds after calling llSetTimerEvent until the timer event itself is triggered. To have the sound and animation triggered immediately, you'd have to repeat the llPlaySound and llStartAnimation calls in the run_time_permissions event.

A roaring fire or a sunkissed tropical beach in SL do seem to ward off the RL chills a bit for me, and a winter setting in SL does seem to make an already chilly RL feel a little colder, but nothing seems to help me when RL is getting too warm.

Firstly, Windlight has been replaced by EEP (Environment Enhancement Project), and the next release of Firestorm should incorporate this. I don't know if Firestorm will continue to support parcel Windlight after this. I'm going to assume that by "latest Firestorm viewer" you mean the current public release and not the beta EEP Firestorm viewer (in which case you'd probably be better off applying an EEP setting to your parcel). EEP does allow individual settings for parcels, and for up to four different settings at different altitudes. Firestorm parcel Windlight does not support Windlight day cycles, so whatever Windlight setting you specify should remain fixed. To do this you need to insert something like this into the parcel description in the About Land window: /*Sky@1000-2000:"My windlight setting"RegionOverride*/ where 1000 and 2000 are the lower and upper limits for the altitude at which the setting will be applied. You should adjust these to somewhere a bit below and a bit above the altitude of your skybox, and you should replace "My Windlight setting" with the name of the Windlight setting you want to use. Note that only Firsestorm users who've enabled parcel Windlight (via Preferences/Firestorm/Windlight) will see this setting. Note also that you need to be able the change your parcel settings, which might not be possible if you're renting one of a stack of skyboxes on a landlord's parcel. If you can't change the parcel settings, you'll have to apply the setting manually when you're in your skybox: top menu bar/World/Environment Editor/Environment Settings... (or using the WL Sky dropdown box in Firestorm's Quick Preferences window). More about parcel Windlight on the Firestorm Wiki: https://wiki.firestormviewer.org/fs_windlight.

It goes something like this: key notecard_key; default { state_entry () { notecard_key = llGetInventoryKey ("My notecard"); // read notecard data } changed (integer changes) { if (changes & CHANGED_INVENTORY) { key new_notecard_key = llGetInventoryKey ("My notecard"); if (new_notecard_key != notecard_key) { notecard_key = new_notecard_key; // read new notecard data } } } }

The message "CUSTOM" goes out on menu_channel – it's one of the menu buttons sent by the menu – so you should check for it in the if (channel == menu_channel) section of the listen event and open the text box from there. The if (channel == textbox_channel) section of the listen event should only be processing the message sent by the text box.

Thanks - I hadn't realised that. I guess I was fooled because I'd seen the AVsitter experience explicitly enabled in places that use it, and I'd somehow incorrectly assumed it was grid-scope.

To really excite me, grid-scope KVPs would have be separate from experiences. Currently land owners have to deliberately enable specific experiences on their land. To be useful to me, KVPs would have to be available anywhere, anytime, and without intervention from individual land owners.

A pedantic detail regarding alpha values: in the edit window it's measured as percentage transparency, while script functions use your actual alpha, which is a measure of opacity, and measured 0.0 to 1.0. Different scales, and the other way around. Where you use the value 100, you should be looking at 1.0. Fortunately the script engine can cope.

Maybe too basic, but basically you want to take the code that changes the texture (which will likely be found in the touch_start event) from one script and use that to replace the code that plays the sound (which will likely be found in the collision_start event) in the other script. When you change the texture you will want to start a timer, and in the timer event you'll stop the timer and change the texture back again. Something like this (I'm guessing that the texture change script uses llSetLinkPrimitiveParamsFast): default { collision_start (integer count) { // llPlaySound ("My sound", 1.0); //not needed here, so commented out llSetLinkPrimitiveParamsFast (...stuff to do the glow and transparency); llSetTimerEvent (1.0); } timer () { llSetTimerEvent (0.0); llSetLinkPrimitiveParamsFast (...stuff to undo the glow and transparency); } } Feel free to ask more questions if you need to.