Wulfie Reanimator

Deleting your account isn't necessary. That would just be another dramatic overreaction. Just forget about it and move on and everything will be fine.

Me too. Me too...

Literally who cares? If they want to start charging for an item they created and initially gave out for free, let them. Whether or not they're trying to deny that's what they're doing doesn't make it a scam. That is their right. Stop harassing them with a witch hunt.

The description does say they're made for "Second Life, Unity" etc.. a lot of the effects seen would be pretty simple to do with shaders, but since we don't have those in SL, you'd need duplicate layers of mesh to overlay different texture animations, which might then be vulnerable to alpha glitches. How different the signs would look in SL, I don't know. Maybe @Lindsey Warwick wants to come talk about it if they use the forum.

You should post on the Wanted or Inworld Employment forums instead. This forum is for advice about scripting. But if you do -- make sure to clarify whether you need rigging, animating, scripting, or all three. What you're asking is a pretty big workload, or at least one that requires a wide range of skills. Also, not really related but the avatar you linked is very old, it was released before mesh even existed.

Regarding this part -- merchants can sell multiple individual no-copy items through a single listing. Only when the items run out, the listing will disappear. Commonly it will be just one item, but it doesn't have to be. In cases where multiple no-copy items are being sold, the one to be delivered will be chosen randomly from the "listing folder."

The social aspects of apartments are far outweighed by the complete lack of privacy and having to deal with rendering what ever tosh people like to litter their apartments with. If I wanted a "skyrise" apartment, the floors would have to be 64m tall 'sections' at least. Re: Prices.. If I recall correctly, I get 100 (or 150?) prims for 180L per month on mainland from Prokofy. Been there for a couple years now I think.

An avatar that sits on an object can be moved up to 1000 meters away from the root.

If we discount comments, empty lines, and curly braces... 157 lines. Including some code I duplicated because I hadn't compartmentalized it into a function yet. LSL floats are single-precision (32-bit), so they literally cannot have more than 7 decimals of precision. It's a limitation of the floating-point format itself. Likewise, reading many more digits than that and trying to add them to the float will cause problem exactly for the same reason. Another common format is double-precision (64-bit) floats, which can have up to 17 decimals of precision.

Watch your words... 300 lines of code and some light recursion. It's not perfect, but I only spent a little over an hour or two on it and LSL is not built for string parsing at all. You have to do a function call (and create a new string) every time you want to check a single character of an existing string. Not just that, but LSL (for some baffling reason) doesn't have break or continue, so you have to use jumps to control (exit/restart) your loops. Why does that even exist?? You can literally just typecast a string to a float, even if there's text behind the number... value = (float)"40.23578"; llOwnerSay((string)value); // 40.235780 value = (float)"-683.3"; llOwnerSay((string)value); // -683.300000 value = (float)"9924"; llOwnerSay((string)value); // 9924.000000 value = (float)"-123abc"; llOwnerSay((string)value); // -123.000000

The iOS client will also be text-only, no 3D view planned when they last confirmed it.

Well, there's your problem. Missing type. Also, the three other functions aren't used anywhere by these functions, so they get removed.

Sure. When you're writing a new post, there's a little <> button above the text field, which allows you to insert a code-block.

The preprocessor isn't limited by memory the same way scripts are. It's extremely unlikely that'd be your issue. Though, it will remove any unused functions/variables from the source. If that "one short function" calls other functions, but those other functions aren't used anywhere else, they'll all be removed. Are you getting actual syntax (or other) errors? Share those.

From what I know, object instances cannot have modifiers (or at least differing modifiers from the original object). As a sort of workaround, couldn't you disable the modifiers in edit mode? That way you could preview with a quick switch to Object Mode. I know it's not the same, but maybe it's better than nothing.

This post is 9 years old. We now have a single function that resizes any non-rigged object. http://wiki.secondlife.com/wiki/LlScaleByFactor

Okay, but... We've already established that the PNG formats are not pre-multiplied, according to your original wiki page. So, besides the implementation details of specific programs like Photoshop or SAI, the PNG format is effectively the same as TGA, the biggest difference being that TGA is an uncompressed format (faster to process in higher resolutions), while PNG is a losslessly compressed format (which makes sense for networking). Here's an official specification page. "Alpha channels can be included with images that have either 8 or 16 bits per sample, but not with images that have fewer than 8 bits per sample." "The alpha sample for each pixel is stored immediately following the grayscale or RGB samples of the pixel." "The color values stored for a pixel are not affected by the alpha value assigned to the pixel. This rule is sometimes called "unassociated" or "non-premultiplied" alpha. (Another common technique is to store sample values premultiplied by the alpha fraction; in effect, such an image is already composited against a black background. PNG does not use premultiplied alpha.)" From the above, we can conclude that I was right about the representation layout, though it's RGBA, not ARGB. What you're saying couldn't even make sense. You can't premultiply alpha into the color data, as that would just make everything opaque and lose the alpha information. Never mind that even if the alpha is still stored somewhere else, now you'd have transparent pixels that are all the wrong color. Nobody would design an image format like this. You have to choose one (associated or unassociated), not both. Here's a StackOverflow question asking how to preserve color data about fully transparent pixels in Photoshop. "Yes, the PNG format itself does contain RGB data even for fully-transparent pixels. This is a problem with Photoshop, not PNG." The accepted answer is a link to a Photoshop plugin called SuperPNG by Fnord, which adds support for not cleaning the color data from 100% transparent pixels. So again, provably not a PNG limitation. Same as to why you can't use a mask for PNG in Photoshop. It's badly coded and doesn't take the mask into account while creating the PNG.

This is just a simple marketing problem. Asking on a such general forum as this, about whether or not they'd pay to feel pain, is probably not gonna get you a lot of "yes please!" If instead you made something more broad, a little system that allowed you to easily connect SL scripts to RL devices, you could pitch that in so many different ways that also includes your original idea. People are already selling this in the form of an LSL-controllable vibrator (physical product), I'd link it but I literally can't remember the name of it. That said, there is this (NSFW Github), but it's not quite "plug and play" by itself, not useful unless you know 100% what you're doing. Is this even a serious question, or just spitballing? Were you planning to ship shockers to people?

That's absolutely adorable. Sounds like she was excited and totally okay with that being the case, too.

As it turns out, you can publish your code in all of them with a single console command if you wish.

My school has a 5-page mandatory coding style definition. If you don't follow it exactly, your assignments won't be graded. (We have an automatic program that will check that the coding style is followed.) This is because all assignments are graded by multiple other students, so everybody must be able to easily make sense of your coding style and naming-schemes. It's honestly a relief, based on my experience on the internet (and seeing some of their non-schoolwork code), but it still has its issues.

Yes, the JSDoc format (and ones similar to it) is used in a lot of places, but only in conjunction of another program that benefits from it. External documentation, code hinting in the editor, etc. LSL doesn't benefit from that, unless you use an external editor with a plugin installed. If you only wanted to make an in-source-code comment, you wouldn't format it that meticulously. That's way too much effort unless, again, you're already using a plugin that does it for you on the fly. Does it really matter that it's a multi-line comment (/**/) instead of multiple single-line comments (//)? Do you really need the first line to have two stars (/**)? Does the '@' in front of a parameter mean anything to a human or make it "more clear?" Do the value-types have to be in curly-braces ({ })? All of these exist only because the computer requires it. Not because humans need them to understand the comment. Similarly how for every scripter in SL, keeping global variables before any state, and all events inside of a state, is a standard. It's a standard imposed by external necessity (the compiler) that your opinion/taste can't change.

Yes, this I'm aware of, and those are two objective reasons why TGA is better. That's not what I'm wondering about though. I understand the 8-bit per channel limit, but why does Windows claim the PNGs as 32-bit? The wiki page you linked also says (under Pixel Format) that "TrueColor and alpha" uses 32 bits (4 channels, 8 each) per pixel. This would actually be the ARGB format I'm familiar with and what my understanding keeps falling back to. Color Depth / True Color wiki: "24 bits almost always use 8 bits each of R, G, and B. As of 2018, 24-bit color depth is used by virtually every computer and phone display[citation needed] and the vast majority of image storage formats. Almost all cases of 32 bits per pixel assigns 24 bits to the color, and the remaining 8 are the alpha channel or unused." PNG wiki: "Pixels in PNG images are numbers that may be either indices of sample data in the palette or the sample data itself." For example, the bits would be set as: aaaaaaaa-rrrrrrrr-gggggggg-bbbbbbbb or 255-255-255-255 This would all fit all 16777216 colors with 256 levels of alpha into a single int and it's the format I use for graphical rendering. Very easy, very efficient, and although "the way I do it (because it's how most systems do it)" isn't necessarily how PNG works, the wiki page doesn't seem to explicitly disagree with what I know and have demonstrated.. and that simplicity is almost certainly the main reason the convention is so wide-spread. It would not make sense to store the alpha somewhere else when you have exactly the needed amount of unused bits. The more I read and think about all of this, the more it seems like it's you who's misunderstanding the PNG formats. Yes, the color-depth is 24-bit. But that still fits 8 bits for the alpha, giving us a bit-depth of 32. TGA is no different. From the wiki about it: "For a pixel depth of 24 bits, each pixel is stored with 8 bits per color. A 32-bit pixel depth defines an additional 8-bit alpha channel." Why Photoshop isn't able to save a PNG while an alpha-layer is being used without transparency in the pixels, I might never know. The solution on the user-side is to use the alpha layer as a selection and remove it from the color channels, but that's obviously just a dumb workaround. Photoshop should be able to take the layer into account and do it properly, as it does with TGA. It's just a simple matter of processing the data that exists into the proper format.

That's a specific format for a specific parser, with actual functionality. It's not "the" standard, or even "a" standard. It's syntax just like the language it surrounds. It's literally used to auto-generate documentation files externally from the code itself. OP is asking about decorations, which while I don't care for, is its own thing.

This is where I get lost. As far as I understand, I'm not using 32 bits per channel in any of my examples.. I'm not even sure how that would work. All I know is RGB/RGBA (8 bits per channel, or lower), not what would happen with 4x the amount of color data (or after reading that wiki page, maybe it's not explicitly color data, but indices to color data?). I guess I'm vaguely aware of 16-bit channels (true color?) but even that I couldn't talk about. Both images -- the sky and the wall -- are marked as having "bit depth: 32" according to the file details in Windows. I assume this means 4x8 bits, not 4x32. One of them works as expected in SL, one doesn't. "PNG standardized on "unassociated" ("non-premultiplied") alpha, which means that imagery is not alpha encoded; the emissions represented in RGB are not the emissions at the pixel level. This means that the over operation will multiply the RGB emissions by the alpha, and cannot represent emission and occlusion properly." There are a few new terms/contexts for me here, but one thing I can't get over is "over operation." What does that even mean? In layman's terms I'd reword this as: "The color data and alpha is separate. The color data does not represent the final color, because the alpha will be added before output." How far off is that? As it does for all images I've created over the course of this thread, even during the process of creating the original image. I've never touched the alpha channel. Sky: (works) Wall: (doesn't) The landscape image I used for the sky example was way more saturated than this simple brick wall. Wall #2: (made in Photoshop this time) I get it, TGA can be a solution, but clearly this is easily doable with PNG as well, so I would consider switching file types a clutch -- a solution to a problem you (general you, including me) don't understand. But from what I can gleam from "TGA vs PNG" discussions elsewhere, TGA's separate alpha channel is what allows you to have fully transparent pixels that still hold color value, unlike PNG which requires this 0.1% or 1% opacity. (TGA below, the alpha channel doesn't work if I save as PNG) What I'm trying to wrap my head around is why would SAI mess up? In fact, the problem disappears if the background texture is at 4% opacity. At 3% the colors start degrading. This could literally just be a bug in the way SAI encodes color data with high alpha. And of course, 4% background is too much, as the whole wall becomes noticeably brighter with emissive mode. Here's progressive steps from 1% to 4%: