Wulfie Reanimator

The problem is essentially this loop. Until this loop has finished, the script cannot process another touch_start event. The method of using another script to reset this script is one way to do it, but you could also convert the loop into a 5-second timer (to avoid the llSleep at the same time). You don't have to stop before calling MTT either, it'll replace the current target just fine on its own.

It's not Linden Lab's fault that $10 is only enough for you to pay your rent. Linden Lab did not set the price of your rent (unless you own the land directly I guess). If LL gave you twice as many lindens for $10, your rent would surely become twice as expensive because the value of lindens would drop. Same applies for everything else you would want to buy. It doesn't really matter whether they are or not, because it is a legitimate question.

Even if the promotion was still active, don't go for it. It's not worth it.

llStopMoveToTarget (SMTT) definitely works on avatars, I've scripted movement with it. Can you show your code? Are you sure you're calling SMTT in the correct place (so it isn't immediately overwritten by another call to MTT, for example)?

Considering how many shots you're going to need for good results, if you're only working with a single camera (meaning you have to move between each shot), it might not be very feasible. For "live subjects" that might move, you'd ideally have multiple cameras set up that will all take a picture at the same time to minimize any motion. Of course, this would be expensive. The mesh generated by the program will also be very dense, it's definitely not a quick process to scan a head into bento. You'd definitely need to remesh the whole head by hand afterwards.

Yeah I know. But this is what things look like with Firestorm in focus (using 14% CPU and 30% GPU total): No cores are maxing out, CPU and GPU are practically asleep, ~35 FPS in a crowded messy sim. Don't look at my uptime.

I'm no computer expert either but if your CPU is not being used much, that does not make it a CPU bottleneck... literally the opposite. The CPU is idling, waiting for it to be told to do stuff because it already did all of the work it's meant to do. But since the GPU isn't maxing out either, the problem isn't there either. The fact is that viewers are just pretty poorly programmed to process "all the stuff" in an efficient manner that also takes advantage of everything the system can do (like splitting things into more threads (calculating multiple things at once), or using things that even make it possible). The components listed are definitely good, you could play lots of games very smoothly. Just not SL, especially when you crank up the draw distance. (That's arguably the worst thing you can do to your FPS.)

I'm pretty sure there is no distinction between "mesh shaped like a box" and "a hull." Like you said: Mesh isn't any different from prims, essentially. It is equally easy to phase through prim walls as it is mesh walls, assuming the walls are "water tight" solid shapes instead of disconnected planes. For example, if you used these as the physics model: This works as anyone should expect (you cannot phase through the surface into the box), it's a hull, the physics engine will force you out of the box if you are in it: This has 5 walls with practically no thickness, it's not a hull, and here the collisions are unpredictable and you can often walk out of it even at very slow speeds, you can even "climb" the edges of the individual triangles: This also works as you'd expect, it's a hull, just concave (the hole doesn't go all the way through, but it would still be a hull): This has the same problems as before, except you can also get stuck between the planes: All this said, I haven't been able to repro the raycasting issue myself. I've uploaded some simple shapes with loose verts but they seem to work fine. Even the last picture above.

llSubStringIndex returns a number that is the index where the matching pattern was found. If the result is 0, the pattern was found starting from the first character, meaning the string/name starts with whatever you tested with.

This is also visible in debug rendering.

Seeing the script will probably tell us why the avatar is "able to rotate when wearing for the first time."

Did someone say... fluid? You can do some tricks with llTargetOmega and llSetTextureAnim, but this only really works for flat horizontal surfaces. First you create your water surface, then you use a script to make it spin with the llTargetOmega function and make the texture spin in the opposite direction with llSetTextureAnim. In the above example, the rotation cancels out completely and the texture stays still. You could also have the speeds slightly different so the texture slowly rotates, depends what you want.

Sorry, I'm one massive brainfart.

It must have been sculpt studio. llCastRay is very accurate, I can't imagine its accuracy being any worse than regular floating point rounding errors. For example, here's a gap between two 0.1 cubes, and llCastRay is able to fit right between them. This is a simple visualizer I've scripted myself:

The inspector will use the current information at the time the object is selected. For example, but that doesn't seem to apply on textures.

It was @Fenix Eldritch with the raytracer. It displayed a completely random pattern where the mesh surface should've been. Didn't the trailer we were puzzled by use loose verts to adjust the physics shape, instead of triangles?

4MB? You might wanna check your numbers... Even a losslessly fast compressed 1024x1024 JPEG2000 doesn't each 1 MB. The inspector is at least partially affected by LOD changes, the number of triangles it reports changes depending on the LOD of the object.

I don't think those are a very good comparison. Those are entire features that would almost definitely take more work than a single function. llGetMoonRotation at least has legitimate uses (niche or not) with no harmful side-effects. But what about other things like llCastBox or llCastCircle (volume-based raycasting), llDamage without requiring a collision that instantly kills the object, llDamage with negative values (healing), objects being able to detect LL damage (even if they stay unkillable), being able to iterate children of a linkset the script isn't in (eg. you have a root key but need a specific child), etc...

What, page files for the GPU? Oh lord..

I believe the mipmaps are created during the upload process of the texture, by the uploader. The wiki page you've linked explains pretty explicitly that mipmaps exist and how they're used. Lower resolutions are used based on the texture coverage on the screen. I'm not sure what kind of "blurriness" you're experiencing. Do you use anisotropic filtering? Can you include screenshot comparisons? Definitely. Remember that 1024 is four times more pixels than 512.

" corona will pass stop hogging toilet paper you silly people "

You can't create your own skeleton when creating rigged mesh for SL. You have to use the official skeleton. http://wiki.secondlife.com/wiki/Mesh/Rigging_Fitted_Mesh

I mean you can see the verts without even zooming in. If it has a subsurf modifier on it, it's not set very high or the base model is extremely simple... It looks like a plain UV sphere with 64 loops. I can remake it with 1700 tris and no modifiers. (Or 1300 with sharp edges.) You're not wrong to mention the importance of low-poly though. 1700 or 17000, there's always room to improve things.

Sure, timer is generally better than a loop for many practical reasons. That said: An infinite loop won't "use 100% of the server's CPU," it gets scheduled its own time-slice (we're talking tiny fractions of a second) just like every other script. The script has no other events/interactions and needs to run "as far as possible" because it's a very short-lived object. (Moves very fast and won't exist more than a couple seconds.) This isn't my first rodeo either, I'm very aware of all the implications and timer-based updates perform much worse in the environment the code is expected to run in. Slowing down the timer is only going to make things worse because the velocity remains constant. I might as well have written "while (llVecDist(llGetPos(), target) > threshold" and the loop would not really change. The important thing I specifically need is that the event does not exit before that or a couple other conditions are met. "while(1)" just allows me to clearly describe the flow of the loop (when each condition should be checked) without writing comments. That's not the point of my post anyway. My case is specific, but the calculations are the generally correct answer.

Based on the Blender screenshot, the shield is Fine™. How did you determine it's too dense?