Extrude Ragu

You see that as a bad thing, but in the end of the day as the end user Black Dragon is completely hostile towards me and Firestorm manages to do everything I need it to do, despite not necessarily being great at any one thing.

It is a lack of focus. When you split the efforts of people into too many products, what you end up with is many mediocre products, that all take longer to develop. If you go into a supermarket and there are 20 different flavors of Jam, chances are they all cost more and taste worse than a store that just sells 3 good ones. Likewise you as the consumer are more likely to buy a jam from the store that sells 3 because too much choice is overwhelming and you just want a good jam, not a quirky jam. Most of the viewers struggle to maintain a good release cycle, some going years at a time without a stable release. I think the developers have stretched themselves too thin for the sake of independence and the end result is nobody can deliver a viewer that does everything well. And when there's no viewer that does everything well there is a lot of viewers that do a lot of things bad. My opinion is that if of those 8 different 3D viewers we have now, the developers should really be joining forces and focusing on delivering about three good viewers, they can contribute code from each others viewers and take the best from several and put it into one good one.

The trouble with open source development seems to be that everyone goes their own way and puts the things they personally care about into the viewer. The end result is that we have like 6 different viewers, that are all good at one particular thing, but none that are good at everything. Some viewers are really speedy, but ruin it by being too opinionated about UI, taking away choices. Some viewers have all the choices in the world, but run like crap And then there's the LL viewer In the end all the performance improvements in the world meant nothing to me if the things I want to work don't. And thus firestorm won despite it's framerate issues lol

Use llGetTime to get the time since the script started or the last call to llResetTime().. Here's some psuedo code. I use next_stop_to_think to define how long it will take before I get going again. I always think for 5 seconds. .... float next_stop_to_think; default { .... timer() { float elapsed = llGetTime(); if (elapsed > next_stop_to_think) { // Wait llSay(0, "Thinking..."); next_stop_to_think = 5 + llFrand(10); // We'll stop to think again in 5 to 15s llSetTimerEvent(5.0); // Think for 5s llResetTime(); // So that elapsed will always be time since last stopped to think. } else { llSetTimerEvent(1.0); // Ensure timer resumes normal pace } } }

This is not the solution to the problem. I am a bit passionate about this. Allow me to explain. There is a standard way of overcoming this issue that most game engines use, called Animation Constraints. But first you have to understand a little bit about the problem: Why don't our hands line up when we play our hand holding animation? The vast majority of animations in SecondLife are FK (Forward Kinematics) animations. SecondLife has a bone heirachy starting from the Pelvis. In an FK animation, there is no target that the bone is pointing to. To get your hand in position, the Torso bones, shoulder, upper arm, lower arm and finally wrist are rotated by specific degrees on each axis. Where the hand ends up is unpredictable because these are fixed rotations and the length of your bones varies based on your shape. How do we overcome this? Game Engines would use IK (Inverse Kinematics) animations. In an IK animation, we do not specify the rotation of each joint in the chain, but rather we declare a point in space where we would like our hand to end up. The computer automatically calculates the rotations necessary to achieve the desired pose, responding to your shape automatically. We use a system of constraints to define where these targets in space are. Sometimes constraints are relative to other bones on our own body, sometimes they are relative to the ground. Sometimes they are relative to moving points in space (Such as grabbing a door handle) The Original Lindens Knew Things are about to get very nerdy (as if they weren't already). The Lindens who created the animation system knew about inverse kinematics and bone constraints. The .anim file format the Lindens created, supports bone constraints (to an extent). In fact, the default noob animations that play when you have no AO use them! So why aren't we using them? So far the main animation tools that people use to create animations for SecondLife do not support the constraints feature that SecondLife has. Whilst Blender itself supports IK and constraints, The Avastar plugin that people export them with does not. Tools such as Qavimator do not support them either. So all the main third party animation tools can't take advantage of this feature built into SecondLife. Frustrated with this, I made a tool once to read and write animation file data, just to see how they work. A Linden who perhaps doesn't know much about the animation format has at some point broken ground constrained animations. There are also some limitations [1] [2] of the format currently, that I have made suggestions to the Lindens in the past to fix.

Thanks for the information This would not work - The creators body modification would need to use BOM too to match the bodies skin. If the user wore an alpha layer, it would hide the skin on both the body and the mod. There is no way that I am aware to have an alpha layer affect only one BOM attachment. That is why I am saying, even with BOM there is still currently a need for a body to have lots of texture faces because it's the only way to have control of visibility without affecting other attachments using BOM too.

@Beq Janus You talk about the issue of 'Alpha sliced' avatars creating more 'draw calls' for the viewer. You seem to have a good understanding of what is going on under the hood. What creates more draw calls in a body specifically? More texturable faces? Or the mesh being split into multiple links? Related: In a recent JIRA, a Linden mentioned there is a Magic Texture UUID which is built into the viewer but not built into LSL. This is IMG_INVISIBLE. Which I gather the UUID is "3a367d1c-bef1-6d43-7595-e88c1e3aadb3". The Linden mentioned that if a face uses this UUID, it is skipped from rendering 'very efficiently'. They said the effect is only known to be used in Alpha Wearables when 'Fully invisible' is checked but could not comment on if this efficient skipping is used elsewhere within the viewer. I would be very interested to know if the 'efficient skipping' applies to other worn attachments or rezzed objects as I imagine this could be an FPS booster. Beq also seems to advocate that bodies should not be using alpha slices any more, but instead use BOM Solely. I would like to draw attention to the fact that this would make products such as breast mods, or in my case Squeezy Stockings which change the shape of thighs by hiding a part of the original body impossible. I think that SecondLife should have some way to make such mods possible without incurring a 'draw call' performance penality, as that remains once of the big reasons why a creator is likely to supply their body split into many parts and faces, even with BOM.

I wonder if it would be possible to create a sort of 'Street view' of a region using these? It would be cool to be able to essentially give a 3d tour of a sim. Perhaps it could be used to aid navigation, or to entice someone into SecondLife who does not play.

Sim crashed today. Everyone got disconnected. When we try to teleport in, we get This was on first teleport attempt after logging back in. None of us have attempted to teleport in 6 times. Some new bug introduced at some point?

Firestorm managed about 4 lol. Except, whenever I moved the camera too much, it would freeze up for a few seconds. Presumably pulling stuff from the cache on the UI thread

I know I posted this elsewhere but seems like it ought to be in here~

It was yearbook photo today. I've amassed an army over the years. Many of the people in this photo are just starting to learn about each other and were introduced to one another today. We had fun. Hopefully many new friendships will blossom as a result~

Although I do use Caspervend mass deliveries feature in the past, I found the effectiveness limited. In particular I sold a product that had some systems built into it and found customers still using the old version many years later. The bulk of updates that seem to be done by customers are done using the CasperUpdate system, which is a script in the item that phones home and checks for new versions when the product is rezzed or attached.

Makes sense to me. The threads are getting made anyway. People want to talk about the things that matter to them. We're not Reddit users, we're SecondLife users.

Think this is a mistake personally. I know people in my community who log in with their phone from time to time, and their physical presence is still appreciated even if we know they can't see us unless they enter the 3D view. For partners it can be a comfort thing too

I used to use a tool called Land Sensor in my sim to keep a rolling log of people who had recently visited the sim. Mostly for admin purposes and nice to know how busy the sim was or wasn't whilst I was asleep. It had an app and would let you do remote administration and stuff. I've been using it for years but noticed it stopped working recently. Now I can't get it to work again, the creators store seems to no longer exist. Wondered what happened? It's a shame because there does not seem to be a good alternative right now and it was a really useful tool.

With some of my students~

Although I can see the spirit of this development, I don't think bulk re-delivery is an effective way to handle product updates. A user just has to be signed off for a while for the message to be lost to history and the update never noticed. The user receives the update to the product whilst they are not using the product and might not even care about receiving further updates on an item. It would be better if the rezzed item itself detects when an update is available and prompts the user. That way the user is only prompted from items they are actually using. I did make JIRA's for this but I got the canned we won't do it response iirc.

In case anyone is having this problem in the newer version of Firefox, the menu is different:- 1 - Go to Settings Click the Hamburger Menu in the Top Right and find Settings: 2 - Manage Cookie Data Select Privacy and Security from the left hand menu, Scroll down to Cookies and Site Data, Click Manage Data... 3 - Delete Secondlife Cookies/Site Data In the dialog window, search for SecondLife, Select the Sites Click Remove Selected and then press Save Changes. Hope it helps

'Internal limitations' reads to me like someone has red-taped something from being touched that really ought not to be red-taped Perhaps someone at LL could find someone with some scissors Come on LL you can do it

I could see it being fun for roleplay. Just expect that not everyone is fun and some won't play along. Setting the mood

You can't interpolate into the first frame of an animation You need some time in your animation during which the interpolation would occur. Move all of your keyframes along so that the first keyframe is when you want the interpolation to end. Copy that frame also to the first frame. Then you set the ease in time to match, I've not used Qavimator btw I use Blender so idk how those tasks translate to that particular piece of software.

Mixed feelings about this. On the one hand I've seen Gacha's be predatory and people gamble away all their money on them. On the other hand I've received Gacha plushies from friends and it's special because it's the one they received and they've given it to me. Chance can be the spice of life but it can also ruin people when they don't know how to quit.

To be fair it still took me two attempts to get in. It's an improvement from six, but still one too many more than I should need to