Wulfie Reanimator

Furries tend to be shorter on average, and way less paranoid about child avatars.

Unfortunately, no. The playback of animations is handled 100% by the viewer alone, so only the viewer itself can adjust the playback of animations (for your view only).

Oh, sorry, I got confused by the myriad of functions that truncate strings (to 1024 usually) and forgot that larger strings can exist. 😋 And you're right, it would be a lot of work, I'm not ignorant to these things. But considering all of the other things LL has brought us, I don't think this exceeds any "viability thresholds."

It is true that Mono scripts only take up as much memory as they need. (5KB used out of 64KB = 5KB) Old LSO scripts would always use a static amount (16KB) of memory. One real concern is everybody defaulting to 128KB for new scripts, where less would be more than enough. The downside of Mono's dynamic memory allocation is that during transfer (teleport) between sims, the actual amount of memory being used by the script must be calculated and reallocated by the receiving sim. This process is very slow, and it is what causes that noticeable slow-motion freeze to everything when an avatar enters a sim, especially if they have a lot of scripts (even if none of them use more than 10KB memory). Doubling the default size of a Mono script could possibly almost double that lag-time. I'm sure if LL was to actually go forward with this idea and increase the overall script memory limit, they would do extensive testing on all of the functions to ensure that they didn't break. (I know, ha-ha, LL changing something without breaking anything. Memes.) Memory limits for things like strings don't really have to change either.

I know it says that, but I haven't ever seen anything saying that they wanted only 32KB.

Is this documented anywhere?

I honestly can't tell if this is a joke or not. For the benefit of those who would sincerely think like this; Income is income is income, it doesn't matter whether the thing you're selling "has no value" or not or "isn't real." (Let alone the fact that someone willing to pay for something already means it has value.) You could be selling sand from the side of the road and you'd still have to file taxes on the money you made if you got past a certain point.

Only after you've sold those game tokens because the money you receive for said game tokens is taxable income. :^)

You can register multiple accounts under the same email address. Or at least used to be able to.

This has less to do with scripting and more to do with how you should build the sign (assuming mesh). From a scripting standpoint, all you need is llSetTextureAnim to smoothly slide a texture across the UV surface. For this to work though, you must arrange the UV map for the neon sign so that a texture will cleanly move over the mesh in the way you want (think of the UV map like a "straight road" or path). Then you would just need separate textures with color gradients on them to allow for different colors. The rest of your post makes it sound a lot like you're looking for someone to write the scripts for you, though. There's a dedicated area for posts like that here.

In the words of a Linden who was tasked to write the code to remove last names: https://nwn.blogs.com/nwn/2018/03/sl-james-cook-linden-world-last-names.html

The best you can do is use RLV commands from a script that will wear/switch your physics layers from your own inventory (not the object's).

From what I understand, the Experience database is only accessible while the object is within land with your Experience enabled, so it's not very practical for a general-purpose storage system, yet...

Everything in this video is beautiful. 5 minutes of pure feels.

It's not. The parameter "permission" contains the combined value of all granted permissions, which means if it is nonzero, some permissions were granted. Since the only request in the script is PERMISSION_ATTACH, it has to be that value. You don't have to check for specific values if you're only ever requesting one of them, or only auto-granted ones (which means if you got one, you got all of them). I'm explaining this because I wrote that code in a previous thread. P.S. I will agree that that's probably not the most intuitive way to do it, since it can't be applied universally.

Edit: I just noticed my explanation was removed when I updated the code. 😂 TLDR: You need to check which link number was clicked, then request permission and detach. // Which link number closes the HUD? integer close_button = 2; default { touch_start(integer n) { if(llDetectedLinkNumber(0) == close_button) { llRequestPermissions(llGetOwner(), PERMISSION_ATTACH); } } run_time_permissions(integer permission) { if(permission) { llDetachFromAvatar(); } } // If the HUD is given to someone else, // the script must be reset, // or llGetOwner won't work. changed(integer change) { if(change & CHANGED_OWNER) { llResetScript(); } } }

http://wiki.secondlife.com/wiki/LlDetachFromAvatar

If any of you have a .blend file of a building (exterior included), I'd be glad to take the time to make 1-2 LODs (Highest/Lowest) for it as an example, depending what the numbers look like to begin with.

You're not going to get me to seriously argue that "low LODs don't matter." My point in that paragraph (and this whole thread) was "let's start with the easy stuff first, we'll benefit much much more from it."

What is the purpose of "flip" in the code? In the timer event, which starts on sit, the script just changes the object's position very slightly. (Based on the position stored on script start.) This doesn't seem like it belongs to the script as it's an outhouse and those don't tend to.. hop around. If you remove the timer event, you don't need to restart the script either.

"Normie" by Utilizator at Annie May Hall is a very good entry level head with a much lower price (500L) compared to any competitors, has Bento/built-in Omega support, expressions, and it's modifiable in case you want to manually change something.

This is actually not very true. From my experience, most mesh clothing either needs no sections to be hidden, or all of them (in cases of leggings, full-length pants, closed jackets, etc). Whenever I run into clothing that does hide sections, the clothing doesn't stop on alpha seams. Only the sections that are totally covered by the clothes are hidden, anything halfway stays visible and this makes perfect sense, since you don't want holes to show up.

You don't have to go all the way down to 30 for the lowest level of detail, budgets can vary a lot per object! A good rule of thumb is reducing the tri count by 30-50% per level, again depending on the overall shape of your object. (This would leave me with 100-385 tris at lowest.) For organic shapes with lots of round surfaces, you can reduce a lot more. It's also important to go inside of your model to remove any unseen faces for cheap reduction, like the inside of the barrel in my example. (Also, since we're only reducing geometry, it's okay to merge some quads into "messy triangles" since you don't have to be working around them anymore at this point.) For more "manufactured" shapes, like buildings or apartment insides (anything with lots of edges and flat surfaces), reduction can be much trickier. I have an example of this as well, and by far the biggest reductions are found around various framing, corners, and hidden faces. It's okay to remove/close entire openings at lower levels, or to remove one whole side of a wall. (Remember that the camera will be far outside of the building.) There's also the whole other layer of detail such as bakes (bump/normal and specular maps) that allow you to get rid of more geometry without it being noticeable, which I believe a lot more people would keep enabled if enough mesh was shaved off for FPS to increase. I don't even think that the lower LODs are that important.. well, they are, but when it's extremely common to see objects with the highest 1-2 LODs being upwards of 20k triangles, getting those creators to at least try is more important than telling them to optimize down to the wire.

I believe the "height" is affected by the height of your avatar. If you were to edit your shape to make your avatar taller, it would appear to be sitting on the ground as expected. Thy is why some AOs have different sets of animations for different heights of avatars.

This topic comes up fairly often in many areas of the forum. Could we gather some examples of the difference between the initial "high poly" mesh and its optimized highest-LOD model for SL, to showcase just how much mesh you can shave off with barely noticeable degradation in visual quality? For example, I just recently made something majorly based on BlackyJunkGallery's art, using nothing but cubes and the Subdivide Surface modifier at 3 subdivisions. Can you guess which one is the original high-poly one? Probably, if you're looking at the magazine slot. Here's the wireframe. The original model has about 17400 triangles, the optimized one has only 1600 triangles. But of course, leaning in with a magnifying glass makes the difference very obvious, but this model is still missing textures which could easily hide slight angles and in regular SL-use you'll rarely be close enough for it to bother you. I may also have been a little liberal with removing the loops as well, as the cartoony style benefits slightly from the angles. And there's not much more to it than applying the subsurf modifier and going to town. Personally, I check each loop I'm about to get rid of by double-tapping G (Grab) so I can move it along the surface. This shows me if there's going to be visible deformation to the shape and to what degree. If the loop gets to stay, I just cancel the move. If I'm getting rid of it, I move it all the way to one end and "remove doubles" which merges the loops without breaking anything. (Example workflow on a video)