Jump to content

KT Kingsley

Resident
  • Content Count

    749
  • Joined

  • Last visited

Community Reputation

663 Excellent

About KT Kingsley

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. My take on using click length, like Nova suggests, to initiate two different actions uses a timer: integer long_click; default { touch_start (integer count) { long_click = FALSE; llSetTimerEvent (0.35); } touch_end (integer count) { if (!long_click) { llSetTimerEvent (0.0); llOwnerSay ("Short click"); // do your short click stuff here } } timer () { llSetTimerEvent (0.0); long_click = TRUE; llOwnerSay ("Long click"); // do your long click stuff here } } I find h
  2. Using RLV you can set someone's active group, though for that to work they first have to have RLV active in their viewer. Not all viewers support RLV, and for many (probably most, and possibly all) of those that do it is disabled by default, and has to be deliberately enabled by the user. If you're planning to attach an object to an avatar when they enter your land that object can issue the RLV command to set the group. RLV can't determine directly whether a user is a member of a particular group, but it can attempt to set the group and the script can then test to see if it's been success
  3. 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.
  4. Use llGetObjectDetails with the UUID you got from llGetAttachedList() and the parameter OBJECT_DESC.
  5. 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.
  6. 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.
  7. 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.
  8. It might be worth taking a look in her spam folder, and setting LL as a safe sender.
  9. 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.
  10. The attach event seems logical. Test the id parameter to check if it's been triggered by an attach or a detach.
  11. 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.
  12. 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.
  13. 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.
  14. 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, usi
  15. 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.
×
×
  • Create New...