Jenna Huntsman

If the device is actively cooled, then you're likely okay. If it's passively cooled, then.. I wouldn't buy it if SL factors in your decision.

In terms of getting an animation to reliably run, you're better off using a looped animation and have the script check the avatar's animation list every now and then to confirm that the animation is still running. You can optimize that script a lot more, but in terms of the issue at fault, the approach is the issue (From reading the script, you're using a non-looped animation and retriggering it every time the animation ends, which is wildly unreliable).

The absolute best thing you can do (right now) would be to update your viewer to the latest version. If you're a Firestorm user, they released an update today which incorporates the Linden Performance Viewer code. Beyond that, there *may* be some mileage in a faster CPU, but not much.

In my particular use, a follower wouldn't be practical as the idea for the item is that it can be used anywhere on the grid, including no-rez zones (or, zones without object entry for that matter)

Yeah, I'm working with an object that's attached to AVATAR_CENTER, which is then meant to be tracking an object in global space (hence, requiring conversion between coordinate spaces), but with the average error the tracking has a tendency to go wild if the region starts returning a result with too much error.

Unfortunately, even when moving the rotation returned is subject to quite a large amount of error, which makes it pretty unsuitable for my application (I'm converting between coordinate frames, avatar-local and global, and I need the most accurate data as poss!) - also, the particular item I'd expect most people to be using while standing.

Hey all, Kinda stumped on this one, wondering if one of the brilliant minds on this forum might think of something that I haven't. I'm looking to accurately determine an avatar's global rotation. Normally, when wanting an object's rotation, I'd use llGetRot() or llGetObjectDetails(), however the wiki clearly states that neither can accurately determine an avatar's rotation (instead, returning a rough rotation) - but the particular application I'm using the data for needs to be as precise as possible. Has anyone got a more elegant solution for finding the avatar's rotation? Many thanks!

You may find the instructions on this page more help than the one's you're reading. https://wiki.secondlife.com/wiki/Puppetry_Setup

.. Have you considered the Steam Deck? It's capable of running SL at full detail (excl. shadows, but they kill pretty much all machines). I can't speak for the other use-cases you mentioned unfortunately, but it's got a full-fat quad-core Zen 2 AMD CPU in there. It's not modular with traditional PC components unfortunately, but it does fit within your price range.

I'm aware - unfortunately pretty much all of the public images of the body either don't show that much, or as you say, are photoshopped. I managed to obtain a prerelease copy of the body (Not sure if I'm allowed to take photos) - I'd say it's a nice body, but not without a couple faults: The stomach area is a bit of a pain point, as it's been designed with thin avatars in mind, and even though the rigging allows it to be made larger without deforming too badly it looks unnatural because of this. The nipples are somewhat cartoonishly oversided (If I'd have to guess, the nipples are ~3 cm long by default). Hands are modelled in such a way that they are designed too small for the size of the body. (Could be just how I tend to measure my hand shape, as I tend to say it's correct when my index finger is aligned with one side of the arm, and my ring finger with the other side). And just some other details: The body also includes a couple different options for labia type, so if you don't want to be stuck with an innie by default, you can change it. Nice feature, although obvs. most go 3rd-party for their sexy items. It's purely a cosmetic change, there's no functionality down there. (Deliberately designed that way). For body mod creators, there's an API for you, so you can hide the appropriate section of the body that is used as part of your mod. No alpha HUD. (This is a good thing, as alpha HUDs mean the body is made in such a manner that it creates a lot of render lag). Uses SLNeck. (This should be a given for new bodies, but FYI). Uses mesh-swapping for foot shape. (This is what most bodies do, but just means the Bento skeleton isn't being used to it's full potential. See the Cinnamon & Chai body for bento feet!) Applier layers present. (I'm told there is a LITE version of the body without these included with the body). Feet are resizeable via shape sliders. Body has all 3 physics zones functional (Breasts, belly and butt). Rigging seems to be, on average, better than Lara. Shoulders and groin are immaculate as far as I can tell. Body is very flexible with it's shape, although again, due to the pain points listed above not all shapes will look natural. Again, though, this body is no-mod. This seems like a poor choice, the reasons given for this decision were... not very good. I wasn't going to spend my time arguing that it should be mod, but given that 2 of the successful recent body releases (that I know of) are mod (Namely, eBody Reborn and Kalhene Erika), you'd have thought that other body creators would take note of this trend.

I've posted the settings that I use to my Wiki page: https://wiki.secondlife.com/wiki/User:Jenna_Huntsman#Jenna.27s_Camera_Settings They attempt to create a more modern over-the-shoulder camera, rather than the mile-high camera (as seen in the default).

To change normal map direction, remove the blue channel from the normal map (this will create a yellowish normal map, which is an inverted normal)

In terms of new bodies, Prima would be one to watch. They have a curvy variant, but that's not the interesting one - the interesting one is the Petite variant, which would seem to be a Maitreya competitor. See here (NSFW): https://www.flickr.com/photos/37690108@N05/52328430267/in/dateposted/ Unfortunately it's intended to be no-mod, so I'd be unlikely to buy it. Sigh.

Which would be indicative of a bottleneck elsewhere - as you mentioned in that thread, my CPU is fairly evenly matched to yours, and we were getting roughly about the same framerate. I'll give it a go the next time I'm on a similarly spec'd Nvidia machine, but that isn't often.

If we go back to this thread the consensus for the (admittedly, small) test was the bottleneck was no longer the GPU, whereas it was with previous driver versions: I'd agree more testing is required, but I'd also say that it's an unfair judgement to completely write off modern AMD cards.

This is no longer true as of AMD's 22.7.1 drivers - OpenGL performance issues have been fixed. (There are some other issues, but nothing that affects SL right now).

Using llDetectedKey would only work if: The script detecting for the event is in the root (assuming it's detecting for any children firing off an event) For events like touched, the prim must be set up to pass touches (default behaviour) - some scripted objects may change this. (See llPassTouches)

As Henri says, this card is probably a little too gutless at this point. You'd be better off going higher-end. Check prices for AMD GPUs as well. Geopricing is definitely a thing, so you may find an AMD GPU will give a lot more bang-for-buck than a Nvidia card where you live. Neither, really. RTX is more of Nvidia's flagship lineup, but they charge a premium for it. The headline feature of RTX vs GTX is Ray Tracing, something which SL (or any of the other games listed) don't make use of. This is okay, but I'd say get an SSD over a hard drive.

You say that, but these are people whose inventories are so flat, they probably can't login. As far as I'm aware, LL have been contacting affected residents beforehand to give them a chance to fix things.

In my experience, llSetSoundQueueing isn't instantaneous, so you may need to add an llSleep in there too. I usually use a value of 0.1 for the sleep, it doesn't take long for the queue value to be set, but it does improve reliability in my testing. Knowing nothing about the samples you want to play, I'd probably do something like this: float vol = 1; //Float value for the playback volume. 0 would be muted, 1 is full volume, and 0.5 is half volume, etc. float sampleLength = 3; //Average length of a sound sample. Mainly used for testing purposes as I don't know how long the samples are. default { touch_start(integer total_number) { llSetSoundQueueing(TRUE); //Enable the sound queue, so we can play back all sounds back-to-back. llSleep(0.1); //Allow the queue property to be set. list lSounds = ["77a018af-098e-c037-51a6-178f05877c6f", "104974e3-dfda-428b-99ee-b0d4e748d3a3", "85cda060-b393-48e6-81c8-2cfdfb275351"]; integer i; for(; i < llGetListLength(lSounds); ++i) { llOwnerSay("Now playing index: " + (string)i); llPlaySound(llList2String(lSounds,i), vol); llSleep(sampleLength); //Allow some time for the sample to play before queueing next, to avoid queue conflicts. } } }

In this case, you'd want to insert llSetSoundQueueing before your loop - you can then add sounds to be played to a queue. Be warned though that the playback queue will only queue 1 sound in addition to the one playing, so don't try queueing them all at once!

Assuming that you're testing against similar settings, you should file a JIRA on the Firestorm portal. https://wiki.firestormviewer.org/file_a_jira

The viewer's bandwidth cap is extremely misleading - It's only used for some communications between the viewer and the region. Anything else is unthrottled. (Including, but not limited to, streaming media). So, use whatever bitrate is appropriate for the resolution of the video. This calculator gives a pretty good recommendation, given some other information.

That only controls if, when a link is touched, if that touch event will be passed to the root of the linkset (the default behaviour), or to not pass the touch event. It won't fire a touch event for any other link than the link root.

To my knowledge, there isn't a way to pass touch events between links. They will only fire on the link that is touched, or the root of the linkset.