Jenna Huntsman

These 2 aren't friends. Nvidia will get better FPS on Windows for SL - it's a known thing that AMD's OpenGL implementation on Windows sucks, and this isn't likely to change given the amount of games which rely intensely on OpenGL (which isn't that many, as Vulkan is now a thing) If you feel inclined, you can try out Linux which has a vastly superior OpenGL implementation and thus SL performance is much improved (On my system, which is similar to yours, I went from around ~24fps average to between 80-100 on Linux). Other than that, turn down your draw distance, and turn down particle effects to around 1024. Turn down your LOD settings to around 1.5.

Does having a texture in Mask mode with the cutoff of 255 also trigger this?

Just read through this.. I hope Maitreya provides a cut-free version of the body in their next update!

You can't. The reason why BD is better for photography is because the viewer is designed as such - and uses different shaders and a modified rendering pipeline to achieve the looks that it does. FS on the other hand is fairly stock* renderer (I'm sure the FS team have modified it, feel free to jump in and mention the exact differences) designed for day-to-day use on any supported platform. Different tools for different jobs.

You can't do this with LSL. That being said, the 'default' attachment point is the last used attachment point, so if you distribute a HUD that you've already equipped on the desired attachment point, the users will equip to that point by default.

Careful using a llSleep if the user can interact with the HUD at any time, as the script is unresponsive when slept and (I think) loses touch events that occur when slept. Smooth transitions are possible but depend on the animations themselves having similar start and end positions, and the ease in / ease out would be better if set to around 1 second ish. If you use a timer, and offset that with the ease in duration of the following animation you can achieve near seamless transitions (note that there is always some variation as you cannot guarantee an animation is present in cache) Sidenote: I notice you're swapping texture UUIDs to represent the status of the HUD (on or off) - is this needed? You can use a texture atlas to swap the colour of a button, or alternatively make the button texture greyscale and use llSetPrimitiveParams to apply a tint (e.g. red or green) to represent the state instead

A user could disable hovertext rendering clientside. It wouldn't remove the demo message, but they would no longer see it on their end (everyone else would however) If your script is modify, it may be best to re-engineer it to find the correct link numbers based on their names, and thus it doesn't matter what order they are linked in as the script will find and cache the correct link numbers in it's memory.

You can't. Unless the script prints the chat with a different method (i.e. the script also sends the list over a link message) then that data will always be inaccessible (Only LL would be able to manually retrieve the variables stored within a running script, and even then I don't think I've ever heard of them doing so)

It depends. You can send the list to chat in blocks (i.e. send entries 1 through 10 in one chat message, 11 - 20 in another, etc.), or, if the message is just variants of a sentence (e.g. (avatar) hits the deck at high speed, (avatar) faceplants at high speed) then you can get away with only storing the variable portion of the sentence (e.g. hits the deck or faceplants) and then adding the remainder of the sentence afterwards, and if you need to print that all at once, use a for loop in connection with llGetListLength

The 255 character limit is a limit on the public chat channel (in fact, all positive chat channels, negative have a limit of 1024) - so your script is reading the entire list, but the message is being clipped when printing to chat. (You can get around this by sending the list to chat in blocks)

Not a viewer dev, but here's my 2 cents: Texture transfer cost is a tricky one, but off the top of my head: 1. Count the amount of textures used above the standard 'system' textures. 2. Find the size of the textures (fewer but larger being preferred, as this promotes the use of a texture atlas and reduces overall draw calls (?)) 3. Account for if the texture has an alpha channel (if so, is it used as a mask (preferred) or a blend) There's probably some nuances I missed out on, and I'm sure someone else with a bit more knowledge could suggest how to improve this, but may be a good start point (P.s. Just realised that I had a brainfart and texture transfer cost could mean something entirely different from what I assumed when reading - if so, I'm sorry!)

TLDR; LL need to remove penalties for having correctly made LODs so creators don't have an "excuse" not to provide them. (I'd much rather have a higher complexity and not have my avatar break at distances of 8m +, but so many creators are laser focused on advertising a low complexity value at whatever cost, meaning their content breaks the second it isn't 'in focus' )

I'll give it a download on Fri this week and report back (currently working away from home, with my crappy laptop!)

With AMD cards (especially modern ones) you're severely hampered by the Windows OpenGL driver - if you have the chance, try out SL on Linux - find a distro that works for you (I personally use Fedora) - I've (no joke) doubled my performance making that move. Again: Only if you have the chance. If you need to stay with Windows, stay with Windows. If you know what you're doing, you can maybe try dual-booting.

With a bit of LSL you can take control of the camera and have it interpolate between locations. There's tools available on the MP which allow you to do this if you don't want to get your hands dirty. Alternately, some TPVs have Machinima controls which can be used to do this. But yeah. What @Wulfie Reanimator said - you need to match your virtual camera to that of your real one. Essentially, you need to match the focal length of your real camera (e.g. 35mm). Some viewers have this pre-programmed (I think Black Dragon has lens presets built in, but I may be wrong). Lighting! This is important, and something that many get wrong in SL as it's a little hard to wrap your head around. Lighting in SL revolves around 8-bit RGB, and thus you'll see many lights which are just pure white (255,255,255) - but lights in real life are pretty much never pure white, instead they lie somewhere on the Kelvin scale. For example, the traditional filament lamp is in lighting terms, a 'tungsten' source, thus has the colour temperature of 3200k. LEDs can vary wildly, some can be 3200k (often called 'Warm White'), or 6500k ('Cool white'). The colour temperature of daylight is also variable, but generally on a clear day it's around 5300 - 5600k. To translate all of that into SL terms, you need to convert from Kelvin to RGB. Fortunately, that work has already been done: https://andi-siess.de/rgb-to-color-temperature/ Another thing - think about the types of lights in the room. A regular table lamp will have a lamp shade, and gaps above and below. In SL, that means you have to use projector lights in order to get the same kind of beam pattern on surrounding surfaces as would be the case IRL. Final thing - remember that also your environment preset also adds it's own light, again, often assuming that sunlight is 'pure white', 'orange' or 'blue'. (The Linden presets fall foul of this, which is why much of the Mainland and Bellisseria looks so washed out). All things to think about. Match your camera settings, your movement and your lighting and you'll have most of the work done.

Check that your script isn't passing any bad characters to llHTTPRequest. That error is generated before the HTTP-out happens, and indicates that the URL contains a bad character (usually, because the URL wasn't escaped beforehand). See here: http://wiki.secondlife.com/wiki/LlHTTPRequest#Caveats

Just read through that wiki article, to paraphrase: You must have a minimum of 10 private islands to join the CLPP (with a maximum of 30, at least with a single CLPP application) The regions MUST be open to the public (except banned residents) Your account cannot have been indebted to LL within the last 18 months. Your community must have existed for at least 1 year prior to the CLPP application The regions must match their maturity ratings to the connecting mainland region, or lower. (e.g. a moderate Linden region can connect to a moderate private region, a moderate Linden region can connect to a general private region, but a general Linden region cannot connect to a moderate private region. Adult regions are excluded from the program.) An application fee is payable to LL upon applying to the CLPP program. A high bar, for sure, but not insurmountable.

dreams

I've just looked over the script now - that's a bug. I've now patched the script, and will roll it out later today. (Redelivery will come to you automatically via Caspervend). I've also implemented a scripthook which tells any other interested script that my script has finished it's work. (see instructions in package) Correct - the script actually generates 2 lists, one of parts to keep, the other of parts to delete. The parts to keep list is never used, but is there in the event that a future scripthook could request that list to assist in whatever that script wants to do.

You're welcome to do so. The main reason I stopped where I did was to preserve features that I know for a fact people do make use of, and to make sure the body HUD continued to work as expected. I did play around with removing more components, but the HUD would often break after doing so (YMMV). The components (layers*) left are as follows: Breast shapes - normal, perky and push up (You must leave one, otherwise you'll have no chest!) Foot shapes - all heights. Left to preserve compatibility with heeled shoes, as a lot of people live in heels on SL. (Why has no one actually made use of the Bento bones for feet yet! 😢) Foot adapters - BellezaFit & SlinkFit - Left to preserve compatibility with Slink feet, as the Belleza feet UVs do not align well at all. Arm adapters - BellezaFit & SlinkFit - Left to preserve compatibility with Slink hands. May be a solution to those experiencing the 'splayed hands' issue. Neck sizes - all sizes. Preserves compatibility with non-SLNeck compatible heads. *I realized that using layers to describe core body parts was a poor move on my part. Now referring to them as 'components'

There will be some layers left over, as these are parts which change your foot shape, breast shape, HD nipple, etc. There are some parts which cannot be optimized (e.g. the hands) as the onion layers are incorporated into the mesh itself. You'll know if the script worked, as after it completes it's work, it will tell you that 'Your body is now optimized'. The name of the body will also have changed to (Opt)[bodyname] to indicate that the mesh has been optimized.

The stupid part is that they sell you something, then force you to buy something else because the initial item won't work as advertised without it.

I already know that 'active' usage won't change - but Mono's memory reporting always reports the max usable, hence why limiting the memory to only what's needed can be beneficial if a script performs a fixed function, as someone using one of those dreaded 'performance monitors' might see a simple item eating 64k of script memory and accuse that of the source of lag for the region. Stupid as it sounds, I've seen it happen many times.

You may also want to use another function: llPreloadSound This will eliminate the delay in playing sounds as this will make nearby viewers download and cache the sound before it is needed. You can also make use of llSetSoundQueueing This will mean you can queue sounds to play sequentially, thus meaning you can have a slower timer loop. Note that you can only queue 2 sounds at a time, so the timer would have to trigger at approx 15 seconds (assuming the 2 previous sounds were 10 seconds each) to use llPreloadSound and add the next item to the queue. For efficiency's sake, you may want to add this line under your state_entry llSetMemoryLimit(llGetFreeMemory() + 512); This will limit your script's memory usage to only use what it actually needs, with a little headroom.

In my defense, I didn't actually use that part of the command, only the first sudo command, which is all that was needed. No idea what the Growl stuff was about.