Wulfie Reanimator

As a scripter, I know the answer: Barely any. As a lazy person, I know the issue: Laziness.

Obi-Wan = us Anakin = ARCTan Palpatine = Most mesh creators The Force = render cost / jellydolls Padme = Philip Linden

"Lag" is a very vague term. The size of your inventory (if significantly large) can make logging in slower or even harder if your internet connection is poor. Having a large inventory can also cause the viewer to freeze for a moment when you open the inventory window (or a second one). Having a large inventory shouldn't have any effect on your FPS or the speed at which objects or avatars rez on your screen.

As cool as that might be, it's actually impossible. Your feet/shoes (or any visible part of your avatar, in fact) can't collide with anything. Your avatar has a single invisible "hitbox" that represents where the avatar, roughly, exists in the world.

Make a default cube, don't make it invisible or anything. Make the prim the root. (Doesn't really matter, but let's make this simple.) From your inventory, add it to an attachment point that makes sense. (Default point is always right hand.) Once you have it attached, right-click the attachment from your inventory and select "Edit." From the edit window, make sure that the position is set to 0, 0, 0. If after this you still cannot see the prim AKA root, there's something wrong with your mesh that offsets the attachment point so much that you can't even find it. But at this point you should see the prim where you'd expect it, and be able to left-click on it after you put a script in it.

Explicitly preloading the sound is most likely unnecessary in this case. Walking is an action people tend to trigger quite often (or not at all), so after the first attempt to walk when the sound would load and be out of sync, it would become synced soon as the avatar stops and starts walking again (since the sound has now had time to load). There's a lot here but I don't know if it's going anywhere. The "server framerate" is up to 45/s. That part is correct. Animation playback is "constant," as in, in dependent of viewer framerate. Animations in SL can have 1-45 keyframes per second, depending on how many frames the creator... created. If the viewer's framerate is higher than the animation's, the viewer will create fake "in-between" frames. (interpolation) Time dilation has no effect on animation speed, though. Network lag has no effect on animation speed, either. The most ideal situation is to have the animation file, so you can create a looping sound that matches the pace. Then you simply start both at the same time. Realistically, you probably don't have the animation or can't predict what animation will play, and in that case you might create multiple looping sounds with different paces to choose from. And this is how you would detect "if owner is walking" every 0.1 seconds: default { state_entry() { llSetTimerEvent(0.1); } timer() { if(llGetAgentInfo(llGetOwner()) & AGENT_WALKING) { llLoopSound("walking", 1); } else { llStopSound(); } } }

One alternative to llRemoteLoadScriptPin, after having distributed the scripts to all required objects, is to select all of them (at the same time) and going to Build > Scripts > Set Scripts to Running. It's a slightly manual process, but it could be faster and definitely easier.

The new Sonic movie is actually about Jim Carrey saving the world.

I just literally translated the actual Wikipedia article into LSL. (For fun, of course. Sadly this wasn't a very educational exercise even for me.) vector rgb2hsl(vector color) { float H; float S; float L; float min = llListStatistics(LIST_STAT_MIN, [color.x, color.y, color.z]); float max = llListStatistics(LIST_STAT_MAX, [color.x, color.y, color.z]); if(max == min) H = 0; else if(max == color.x) H = 60 * (0 + ((color.y - color.z) / (max - min))); else if(max == color.y) H = 60 * (2 + ((color.z - color.x) / (max - min))); else if(max == color.z) H = 60 * (4 + ((color.x - color.y) / (max - min))); if(H < 0) H += 360; if(max == 0) S = 0; else S = (max - min) / (1 - llFabs(max + min - 1)); L = (max + min) / 2; return <llRound(H), llRound(S*100), llRound(L*100)>; } default { state_entry() { llOwnerSay( (string)rgb2hsl(llGetColor(0) ); } } I have deliberately left out some very obvious optimizations.

To set an environment for your parcel: Create an environment setting. Apply it (to region or parcel). You're done! To view the environment setting enabled for the current parcel: Select World > Environment > Use Shared Environment You're done! This is the process described by the wiki. I don't think the old "windlight presets" can be used with EEP. I also don't think that the method of sharing the old windlight presets is supported by the official LL viewer, or work at all if you have a custom windlight.

I went over the logs and calculated the intervals, and these were the absolute highest amount of requests within 20 seconds: | 1556346472 | SLOW | Slowing for double region cross to | 4.6399 | Dunlevie | | 1556346473 | SLOW | Slowing for double region cross to | 3.83697 | Dunlevie | | 1556346473 | SLOW | Slowing for double region cross to | 3.15458 | Dunlevie | | 1556346473 | SLOW | Slowing for double region cross to | 3.36189 | Dunlevie | | 1556346474 | SLOW | Slowing for double region cross to | 1.97424 | Dunlevie | | 1556346479 | CROSSSPEED | | 4.27327 | Eldridge | | 1556346479 | CROSSEND | Region crossing complete in | 0.200195 | Eldridge | | 1556346480 | SLOW | Slowing for double region cross to | 2.93807 | Eldridge | | 1556346486 | CROSSSPEED | | 0.334506 | Clyde | | 1556346486 | CROSSEND | Region crossing complete in | 0.266113 | Clyde | | 1556346488 | SLOW | Slowing for double region cross to | 14.1767 | Clyde | | 1556346490 | CROSSSPEED | | 13.7874 | Welsh | | 1556346490 | CROSSEND | Region crossing complete in | 0.26709 | Welsh | The above shows 13 requests within 20 seconds, not nearly enough to trigger the supposed limit of 25. | 1556347158 | SLOW | Slowing for double region cross to | 0.487929 | Eagan | | 1556347158 | SLOW | Slowing for double region cross to | 0.493334 | Eagan | | 1556347158 | SLOW | Slowing for double region cross to | 0.493756 | Eagan | | 1556347159 | SLOW | Slowing for double region cross to | 0.494134 | Eagan | | 1556347164 | CROSSSPEED | | 0.486514 | Jaffee | | 1556347164 | CROSSEND | Region crossing complete in | 0.241455 | Jaffee | | 1556347165 | CROSSSPEED | | 4.68891 | Heaton | | 1556347168 | CROSSSLOW | Waiting for avatar(s) to cross regions. | 0 | Heaton | | 1556347171 | CROSSSLOW | Waiting for avatar(s) to cross regions. | 0 | Heaton | | 1556347174 | CROSSSLOW | Waiting for avatar(s) to cross regions. | 0 | Heaton | | 1556347177 | CROSSSLOW | Waiting for avatar(s) to cross regions. | 0 | Heaton | And the above is only 11 requests within 20 seconds. Other areas of the log are showing 2-8 requests within 20 seconds. But this assumes that All of the requests are pointed at this server All of the requests arrive successfully No other scripts are making requests (that would total 1000 requests per 20 seconds) Edit 1: I don't know if I understand what is classified as a "burst" though. (This is from the bottom of the caveats..) Is anything above one-per-second a "burst" that would lower the throttle limit for any follow-up requests? The wiki is unclear. Either way, there were lots of times where two requests were logged within the second, sometimes 3 and rarely 4, but never more than that. Edit 2, I'm leaving the first edit in to bridge the gap: It says "25 per 40" because of this from earlier: So as long as you never reach 25 total requests within a 20 second period (even if you send 12 requests in a second, wait 5, and send 12 more and stop), you will not be throttled.

This is the kind of hack I was talking about in its truest form, lol. Had to test it myself just to witness it. Apparently changing state from within a conditional is possible. (It doesn't have to be TRUE specifically. Any IF-check that evaluates to true allows this.) For example, this would work if the UUID was valid: function(key uuid) { if(uuid) { state test; } } However, "else if" or "else" does NOT allow changing state. You will get the expected "Global functions can't change state" error. On another note, here's a fun fact about variables and scopes. integer test = 3; default { state_entry() { test = 2; llOwnerSay( (string)test ); { integer test = 3; llOwnerSay( (string)test ); } llOwnerSay( (string)test ); } } What do you think the the output is? Does this even compile? Spoiler: It compiles just fine. You can nest new scopes without an IF or a function. (That's the point I'm making.) The output is "2 3 2" because the second variable has a more local scope and it is discarded when execution leaves that scope. The global "test" variable (as well as any other non-global variable) is unaffected by more local scopes.

You do not need to announce the great deed of blocking someone. You will probably soon find out some big flaws with the blocking system. So technically there were two instances of her avatar online at once? That's pretty incredible, lol. Next time it happens, see if you can get the person to come visit their own doppelganger. Now that'd be even more interesting to see!

I have hair from Stealthic that uses alpha blending. (Pictured below is "Passion") It has the same issue as all other hair. What may be a big difference between this and other brands like, say, Magika, is that the strands of hair are built out of thin planes rather than those "round globs" of mesh. This minimizes the surface area that might be covering other alpha blending textures, but isn't any kind of "workaround" that prevents any of it from happening. It's a treatment, not a cure. Fun fact I noticed after taking that picture: My older sculpt hair that I actually use on that avatar also uses alpha blending, but it does not cause that "cut out" effect. The worst you get is sorting issues, where nearby alpha textures behind may appear in front of surfaces they shouldn't be.

A script cannot delete any items (even itself) from the owner's inventory.

Switch to the Black Dragon viewer. It can disable full-brightness on objects. 😎

I think your image needs a couple asterisks. While you might want to avoid "long and thin" shapes (a regular wall is not thin enough to be a problem), you should also avoid small gaps (two normals facing each other), because small gaps seem to cause huge LI penalties when you scale down the object. (Gap gets smaller = more physics accuracy needed = LI goes up.) And when you don't close the end of your wall, the avatar can walk into it, like the pieces of wall on both sides of the slope. Leaving the top of the wall might be okay, but definitely not the side that's facing the walkable area.

"Clear your cache."

It doesn't have to be super complicated math! vector avatar_direction = llVecNorm(avatar_position - llGetPos()) / llGetRot(); And then you just check if avatar_direction.x is positive or negative.

Can you share examples of these brands with alpha sorting workarounds? Deconstructing how they're built shouldn't be too difficult.

Thread was posted 29 minutes ago, edited 17 minutes ago to this? You aren't very patient, are you?

But resorting to cloud storage would potentially make this even more complicated / slow. First (I'm) uploading to the cloud for at least 12 days. Then, assuming you can install SL into that cloud as well (or somehow "directly connect it"), you're at the mercy of that cloud service's bandwidth limits which may be limited/restricted.Though the currently fastest cloud service I could find is able to upload files at 40Mbps or 5MB/s, it is still 55 hours on top of my 12 days of uploading to the cloud and doesn't include any bandwidth usage limits imposed by the service itself. Besides, ChinRey stated in her OP that the upload fees alone would put the whole planet in poverty many times over, so the final cost can already be ignored as untenable.

The more immediate question is, are you gonna be able to fit all of those on your HDD? 32-bit color depth means 256 colors (0-255) per Red, Green, and Blue. 256 * 256 * 256 = 16'777'216 shades of color. 1024 * 1024 = 1'048'576 pixels. 1048576 * 16777216 = 17'592'186'044'416 unique 1024px textures. A PNG file with 32 bits of color information at 1024x1024 resolution is going to take up exactly 4096KB (4MB) of space to store. 4 * 17592186044416 = 70'368'744'177'664 MB or 70 Terabytes of storage space required. (Not including all of the lower resolutions.) My personal internet connection is a 60/10, meaning my upload speed is 10Mb/s or 1.25MB/s. This means that, in lab-perfect conditions, with no interference or interruptions (and no throttling from Linden Lab), it would take me almost 278 hours or 11.5 days to upload those highest resolution textures. And honestly, you wouldn't want to generate all of those lowest resolutions first. If you generated only the highest resolution textures, you could crop them to get yourself lower resolution textures that would still be equally unique (since all of those unique lower resolution textures would be contained in the 1024x1024 ones).

Understandable but kind of silly of a question. It's an acceptable risk that requires you to sell 8 copies before you're making profit, the idea being that you may get more potential customers faster. (Or end up losing your whole account, as Dakota Linden said.) There are plenty of backwards-sounding marketing strategies (especially if paying a flat fee for a visibility boost is your bar for silly), such as intentionally selling a product for a loss. (Look up "loss leader") Popular example: Sony is losing money for every console they sell. Their profit comes long-term from game sales and their subscription services. Or even giving away your product for free, but selling accessories and services for the initially free product. As a kind of similar and within-SL-rules example, you could also sell your product for dirt cheap to attract more people and spread your product/brand. This happens especially when you're a newcomer to a large market.

Gonna need a big source on that. Alpha sorting is certainly not an unsolvable problem, especially not to the degree that it is in SL. Our rendering code is just a bit ancient, duct tape and all. (Doesn't help OP, but that's way too big of a claim to brush over.)