KT Kingsley

One useful tool is the Windows Character Map utility. Also, have a look at this Wikipedia page https://en.wikipedia.org/wiki/List_of_Unicode_characters. Note that not all Unicode characters are supported by everyone's systems. But really, only use the Unicode characters that may be specific to your native language's alphabet that you need to show your chosen display name.

Is this a situation where you could use running totals and rolling stats instead of storing every item in the script? Also, somewhere in this forum, Innula (I think) has posted a tutorial on using Google Sheets to store data externally from a script... Here:

In these situations I tend to go for something like this: float min_delay = 10.0; float max_delay = 100.0; float delay = min_delay + llFrand (max_delay - min_delay); llSetTimerEvent (delay); I'm not sure if this is what you're looking for here, though. I use this for cycling through stands (and freestyle sits) in my AO.

If you're using Firestorm, it has a particle editor that's a lot easier to use than editing a script, if only because you can see the effect of the various parameters almost immediately. Rez a prim and attach it to Avatar Center. Edit it. From the Build menu on the top bar select Object/Edit Particles. Using the editor window I approximated the Firestorm effect by changing these settings from the default values: Burst Rate: 0.2 Burst Count: 2.0 Burst Radius: 0.5 Burst Speed Min: 0.0 Burst Speed Max: 0.0 Scale Start: 1.0, 1.0; End: 0.1, 0.1 (the End setting is activated when the Interpolate Scale setting is set turned on) Emissive: on Interpolate Scale: on Target Position: on When you turn Target Position on the Target Key setting is activated. Click on the prim icon next to it and then on your avatar to put your avatar key into the target setting. There's an orange colour in the predefined colour settings you can select for Start Color. It's close, but not that close. Then it's up to you to tweak things until you've got the exact effect you want. When you're happy with it click the Inject button in the editor window. A particle script is created in the prim you've been editing, and which you can edit to fine tune the effect.

I don't know if this is one of the usual suggestions, but from the menu bar: Advanced/Highlighting and Visibility/Hide Selection would be my first port of call.

I really don't know enough about this to be answering, but here's a couple of pennies worth anyway. Won't selecting "Close Holes" close any holes, like doors and windows? Won't using your high LOD model make an excessively complex physics model with subsequent high LI cost? Maybe you could try making a separate physics model using a few planes for the walls and floors? And when you've uploaded and rezzed the model, remember to set its physics type to "Prim".

I too am less than comfortable when it comes to probability, but I think the trend is this case is that the difference between the number of reds or blacks relative to the number of spins tends to level out, rather than the difference between the numbers themselves. 10 spins: 4 red, 6 black; difference 2, red 40% 100 spins: 45 red, 55 black; difference 10, red 45% 1000 spins: 475 red, 525 black; difference 50, red 47.5% Even though the difference between the number of reds and blacks is increasing in this example, the percentage is trending towards 50%.

It could be that your viewer is hitting its particle limit. Maybe someone has installed a particle-heavy object somewhere nearby. Check your viewer's setting for Max. particle count and bump that up a bit if its not already maxed out (that's the setting label in Firestorm, on the Graphics/General tab in Preferences, it should be something similar in other viewers). Also you could hunt around for anything particle-heavy nearby and block it - which also blocks the object's owner - if it's that limit that's causing the problem.

Ha! I hadn't noticed that it'd been made available in the Library, but now you've pointed that out I do seem to have resurfaced some vague memory that only about 100 or so of the more popular FS windlights were going into the Library. If that's the case then Tommy Terrible's collection will likely include some of the more obscure settings that didn't make the cut.

CalWL is indeed a Windlight. Windlight has been replaced by EEP (Environment Enhancement Project). If you go here on Marketplace: https://marketplace.secondlife.com/p/Firestorm-Default-Sky-Windlights/20088838, you can get Tommy Terrible's EEP conversions of the FS Windlights for free. The EEP version of CalWL is in the A-D box. Extract that to your Settings folder. It'll then be available in the menu systems for selecting EEP settings.

Although it doesn't inherently increase lag once set up, option b) takes longer to perform. The script function that reads lines from notecards has a built-in delay of 0.1 seconds, so reading 15 lines will take 1.5 seconds longer than if it wasn't restricted, on top of the manual fiddling about to get the process started. If you use outfit folders, perhaps the easiest option would be to include the sports HUD in your sports outfit folders and the standard HUD with the others.

The only thing I can think of that may be affected by the order in which viewers are installed or updated is the SLURL protocol. This is the system where clicking on an SL location link on a website will open the viewer for you to log in directly to that location. Generally it'll be the most recently installed viewer that'll respond, though Firestorm now has an option for that in its installation routine. Firestorm also provide a utility, SLURL Proxy, that lets you manually control which viewer responds to SLURLs.

Note the LINK_SET constant you can use as the link specifier parameter with both llSetLinkColor and llSetLinkAlpha.

"Scheme" Although it appears that in US culture the word "scheme" is commonly taken to mean "a plot or secret, devious plan", in the UK (and presumably in other English-speaking cultures) it generally means "a systematic plan of future action". The online dictionaries I've glanced, briefly, at seem to put the more benign interpretation first.

Here's a free one, with all the quality and sophistication of a 2005 freebie: https://marketplace.secondlife.com/p/Sunhat/22400703

default { state_entry () { llSetText ("Can't decide?\nClick for a suggestion", <1.0, 1.0, 1.0>, 1.0); } touch_start (integer total_number) { llRegionSayTo (llDetectedKey (0), PUBLIC_CHANNEL, "Get the one on the " + llList2String (["left", "right"], (integer) llFrand (2.0)) + "."); } }

For future reference, you can edit someone else's object and take a look at its contents.

Maybe something like a pachinko machine?

With any luck, clicking this SLURL: http://maps.secondlife.com/secondlife/Pooley/71/170/30 should open the last viewer you installed and log you in to Pooley. Hopefully you installed the LL viewer after Firestorm, and haven't installed any other since then. But if you have, you might want to look at Firestorm's SLURL Proxy utility, here, which lets you control which viewer responds to SLURLs.

You can, though, do this in a global declaration: key key_1 = "blah-blah-blah"; key key_2 = "blah-blah-blah"; key key_3 = "blah-blah-blah"; list keys = [key_1, key_2, key_3];

You can use the function llDetectedTouchUV in one of the touch events to get the texture coordinates for where the prim was touched, and then scale the X or Y value (depending on which way the prim is orientated) by 255 (and convert to integer) to get the values you want. (Or use the function llDetectedTouchST to get the prim surface coordinates.)

Is this the Caribbean Breezes club and theatre on the sky platform at Riviera Island? If so, I've just had a look and the textures seem OK to me, which suggests your texture cache is corrupt. This can be fixed by clearing the cache and letting it repopulate itself with uncorrupted textures.

Are the click and dialog features in separate scripts? If so, has the click script been disabled somehow? Is the clickability restored when you remove the dialog stuff? If not, did the touch events get removed from the original script when the dialog code was added? Does the attachment respond to the "Touch" option in its right-click menu? If you use a fresh copy of the object with just the default "New Script" added, is it clickable?

This page in the Firestorm wiki has advice on how to fix a broken camera: https://wiki.firestormviewer.org/fs_camera. Further down that page is a link to another page explaining how to clear your Firestorm settings. And if you're really set on the idea that you need to uninstall and reinstall Firestorm to fix your problem, this page explains how to do a clean install: https://wiki.firestormviewer.org/fs_clean_install. You almost certainly don't need to do this.

Incidentally, if you use llSetMemoryLimit in a script, the reported increment in the total memory used is the same as the limit you set.