KT Kingsley

You could maybe try invisible attachments that are scripted to move around the attachment point (perhaps Avatar Center) and leave a trail of particles. Would using a rotating (llTargetOmega) prim with with a link that emits particles work here? Further enhanced by having the root prim moving up and down relative to its attachment point, and the particle emitting prim moving in and out from the root prim?

Something I've seen, using both the viewer Avatar Health/Scripts window and llGetObjectDetails, is that the script memory apparently gets counted multiple times when you edit the script in an object. Try this routine: Change into a scriptless outfit. Rez a prim. Wear it. Check Avatar Health/Scripts. It will show 0 kb memory used. Add a new script to the object. Refresh avatar scripts. It will show 64 kb memory used. Edit the script (I add a space at the end and then delete that space so the script remains the same). Save the script. Refresh avatar scripts. It now shows 128 kb total, but only 64 kb for the object. Repeat the above. Now it's 192 kb total, but 64 for the object. TP to another region. Refresh avatar scripts. The total and the object now both show 64 kb. Edit the script again... It's a bug, I guess, but not one that's annoyed me enough to file a JIRA.

Whenever you install a viewer it takes over the SLURL protocol. If you then uninstall that viewer the protocol hasn't got anywhere to point at anymore so it won't work. And what with viewer, browser and operating system updates the protocol settings are rather susceptible to getting broken anyway. SLURL Proxy is an easy way of keeping the SLURL protocol pointing where you want it to point without having to reinstall viewers or delve into obscure and opaque operating system and browser settings, though I think this article explains how to do it that way: http://blog.nalates.net/2016/12/24/second-life-how-to-fix-slurls/.

In Firestorm, it's Show Light Radius for Selection in the Build/Options menu. May be different in other viewers, but using Search Menus should get you there.

Adding that debug setting as a quick setting might be slightly more convenient than the inventory setting. Also, favorite wearables seems to add on double click.

In Firestorm, the settings (gear wheel) icon at the bottom left of the inventory window gives you access to this option.

This feature is likely to make many of us currently perfectly happy to join experiences turn our backs on them. It certainly won't do anything to allay the fears and suspicions of users who already shun them. This absolutely must be something users can turn off completely. And, LL, if you don't provide that ability in your own viewer, don't you dare try to bully TPV developers into excluding it too.

In Firestorm there's a Range slider at the bottom of the Radar and the People/Nearby windows.

Google: "good evening for 2 days my inventory is empty and does not display the annotations while if I use other viwer everything is normal" This page from the Firestorm wiki lays out the steps to take to restore your inventory: https://wiki.firestormviewer.org/fs_missing_inventory. The steps are pretty much the same for the SL viewer. It's in English, but Google Translate should help. Google: "Questa pagina del wiki Firestorm illustra i passaggi da eseguire per ripristinare il tuo inventario: https://wiki.firestormviewer.org/fs_missing_inventory. I passaggi sono praticamente gli stessi per il visualizzatore SL. È in inglese, ma Google Translate dovrebbe aiutare."

As far as I can tell, no. RLV shared folders commands apply only to folders. Put the single item in a folder of it's own. Maybe a subfolder of whatever it's a component of, and then use the "allthis" variants of the RLV commands to attach everything including the subfolder, and refer to the subfolder specifically to detach just the one item.

Here, pehaps: http://secondlife.com/httprequest/homepage.php.

Have you set the object's Physics Shape Type to Prim? The setting is on the Features tab of the build window. And be aware that it's LI may shoot up dramatically when you do so.

In the Die() function, doesn't the preceding return statement terminate the function, so any subsequent code – in this case the call to llDie() – isn't executed?

Also, http://wiki.secondlife.com/wiki/LlSetKeyframedMotion is another option you might want to look at. This has the advantage that you get a smooth movement which might be suited to the sort of air taxi or shuttle you seem to be describing.

Do you mean, how does one make mesh objects with an LI of 1? The short answer is to make them less complex, make even less complex LoD models, and an even less complex physics model. The long answer involves thousands of web pages on ways of optimising mesh models for upload into SL. Or do you mean that when you upload a mesh object it becomes a link set of more than one object? The only reason I know of for this happening (and I'm not an expert, so there may well be others) is that you've made the model with more than eight materials. Blender materials (I don't know what they might be called in other 3D modelling programs) correspond roughly to SL faces. SL objects can only have eight faces, numbered 0 to 7. So if you try to upload a mesh model with more than eight materials the uploader will break it up into smaller components each with eight or fewer SL faces. To avoid this you need to be efficient with your use of materials, using as few different textures as possible, for example, and making sure that all the Blender faces (as opposed to SL faces) using the same texture are combined in a single material.

You can't change the shape of a mesh object using a script unless you animate it. And animesh has an LI penalty all of it's own.

All you have to do is save the text to a global variable whenever you define it, and use that variable to reinstate it whenever you bring it out of hiding.

Wear it, attaching it to a HUD attachment point, either Center or Center 2. You'll probably need to resize it to fit the screen (so use a copy rather than the original) and rotate it so it's facing towards you.

The function llRemoveInventory will do this, but only for the link the script is in. Removing inventory from other links would, I think, require a script in each link affected that'd do the removal in response to a link message.

This does sound like RLV thinks the object shouldn't be allowed to be detached and thus reattaches it when it sees it has been detached. The RLV API page mentions this behaviour. Search for "reattach" there.

It does seem to be dependant on how much time the simulator has for it. I generally get about two or three lines of code to execute pretty reliably on a detach. Any code that isn't executed at the time of the detach does execute when the object is reattached, and before the attach event is triggered for the reattachment, so if you can get anything that involves telling the rest of the world goodbye in at the start, and leave any internal tidying up until later, things should go ok. Most of the time.

When you call llListen (in the state_entry event, unless that script is particularly quirky) use the owner's key as the key parameter: llListen (my_channel, "", llGetOwner (), "");. The listen event will only be triggered by the owner chatting on the specified channel. No further checks are necessary. In the listen event test the message parameter to see if it's the on or off command, and make the call to llParticleSystem with either the full parameter list to turn particles on, or an empty list to turn them off.

The Firestorm viewer has a feature that sends stream title notifications to your local chat, and also, optionally, sends them to a chat channel of your choosing where they can be picked up quite easily by a script. This is fine for personal use, but not much good for a display set in a fixed location, where you won't be present all the time.

Two free, well-featured, open source apps are OBS Studio for recording, and OpenShot Video Editor. Recording and post-production aren't particularly simple tasks, and the software tools are correspondingly complex. Having said that, these two apps are still easier to get going with than is Blender (a 3D modelling tool for mesh with a notoriously complex user interface). Other things that are nice to have are a second monitor on a computer powerful enough to run both your actor avatar and a second camera operator avatar (or a second computer), some sort of scripted camera controller for tacking and panning shots (often something the camera operator avatar sits on that moves them around), and a 3D mouse for manual tracking, panning and tilting. Set your viewer to full screen mode, hide the interface and your HUDs, and turn off annoyances like local chat and IMs on the console that'll ruin your shot (or have OBS studio capture only a part of your screen, at the cost of lower resolution). Also, check out the Machinima Forum here: https://community.secondlife.com/forums/forum/298-machinima-forum/.

Thanks for the heads up, @Nescolet. I think I posted the question sometime after the first release of Firestorm with EEP, and the -1 thing didn't seem to work then – at least as far as EEP settings were concerned – but it seems to do what I'd expect now (using with the latest release).