Wulfie Reanimator

Hopefully this time black/grey text will be readable. That's the main reason I kept the old light theme on and used my own extension to control everything. Edit: This is exactly what I mean... @Linden Lab

The Jira (or "bug tracker") is also used for feature requests. Once you log in (using your regular Second Life account), there's a blue "Create" button at the top of the page. By default, it should suggest the "BUG" project with the "Issue type" set to "feature request." If not, just choose those from the first two dropdown menus.

What does "updated to BOM" mean?

There's a lot more code in llpreviewscript.cpp, getTmpFileName seems to be most relevant, but I'm not sure: https://vcs.firestormviewer.org/phoenix-firestorm-release/files/tip/indra/newview/llpreviewscript.cpp?at=tip#L2045 Anyway, there's no option to choose the file-name format for external files. (Besides editing the source code, obviously.) If the script was named after the inventory name, you couldn't edit two scripts with the same name at the same time.

It also, somehow, manages to avoid being forced into dark-mode by my own extension. 80% of the site goes dark (vs 100% with the old theme), and the other 20% is random blindingly white elements, such as new (unread) notifications. Updating is nice but change is painful.

The problem is that lists cannot contain lists in LSL, unlike Python, so you can't "iterate over multiple lists" unless you write a function that takes a specific amount of lists that never changes.

When you pull a script from your inventory into an object, editing the script in your inventory does not change the script in the object.

If the scripts you're editing already exist in-world and the script in them have just been recompiled... Why do you then replace the scripts with itself? The process of editing an object rezzed by another object is unavoidably laborious. Rez MB Wear HUD Open their scripts externally Save your edits Detach HUD Replace the HUD in MB Test.

What you want is, specifically, this: (At least, based on how you worded your question and code.) if ( (Xvector != Yvector) || (Xvector != Zvector) ) "if Xvector not equal to Yvector, or Xvector not equal to Zvector" (Extra inner-parentheses for clarity.) Vectors, integers, lists, etc. are values. Operators are the symbols next to values, that do some kind of operation on one or two values. A full list of them can be found here, and this page on an older wiki goes into more detail on how "bitwise operators" work. There's also this wikipedia page on it.

When you select a linkset and get the texture info on it, you'll get a breakdown of the individual links. It does not tell you how many textures are on any linkset. If you use a single texture on a linkset of 10 objects, it'll list the same info 10 times. 1 linkset, 3 objects with the same texture: 1 object with multiple same-size textures: Combination of the above:

[insert rant about how not-useful Complexity is as a metric] These are all possible, especially on Firestorm. Firestorm's inspector shows exact triangle/texture counts and memory usage, and all viewers (even the official one) is able to list what resolution each texture on each face has. I believe all viewers are also able to list at least the "Estimated Tris."

"Gestures" is very accurate. Gestures are, quite literally, actions that can be triggered by keywords or shortcut keys. They can play sounds and animations, even make you speak in chat.

Yes, but don't let that stop you. The web API is documented here: https://developer.valvesoftware.com/wiki/Steam_Web_API Specifically, under "GetPlayerSummaries": Private Data gameid If the user is currently in-game, this value will be returned and set to the gameid of that game. So once you have your API key, you can do: http://api.steampowered.com/ISteamUser/GetPlayerSummaries/v0002/?key=XXXXXXXXXXXXXXXXXXXXXXX&steamids=76561197960435530&format=csv Note: Some data associated with a Steam account may be hidden if the user has their profile visibility set to "Friends Only" or "Private". In that case, only public data will be returned.

Sad thing is you have no idea how many people are sneering and laughing at your salty narrow-mindedness.

Simply saving the .lsl file with Ctrl-S will make the script compile in-world as well.

The "original batch" was the first set of new last names. Old last names won't become available.

LL doesn't want everybody changing their name all the time. It's an option for those who really want it (and a way to get some people to try Premium for a month), but they don't want name changes to be "popularized." They've said this either in the blog posts and/or the in-world meetups.

But the logical NOT is correct, that's not the problem. That value ("on") can only be 1 or 0. If you try to use bitwise NOT (~), you get totally wrong values. ~(1) = -2 ~(0) = -1 The script is written correctly, but the real problem is exactly what Rolig pointed out. Light goes off, color information gets removed. (I don't really understand what the benefit of this could be.) The solution would be to store the color data into a global variable. If there can be any number of lights (of different colors) in the linkset, maybe use a list of colors.

Name three? I'll make a mental note of them.

I'll say it again in case you missed it: I'm not defending Apple. But I fully stand by my point. New > Old. You're right that evolution for the product is important, but if you look around, you'll notice that nothing stands the test of time. You can only improve software so much until it becomes more beneficial to replace it with something different. Otherwise, why would we even bother making separate open-source/cross-platform APIs? Just pile it all into OmegaGL and everybody wins, right? I'm not even saying that OpenGL is "bad." When I say "I hope OpenGL dies," I'm saying that eventually, inevitably, something will naturally replace OpenGL because it's seen as a better alternative. I want that leap to happen as soon as it can, as many times as it can.

To echo what Animats said: Base64 is not encryption, it's encoding. That means it's a 1:1 translation from one format to another, with absolutely zero security. If anyone catches your base64-string, they can immediately get the real content. You cannot do anything to "make base64 more secure." The "nonce" used by the MD5 function in LSL can be alternatively read as "n, once." (Probably not intentional.) It's a number, used at a single point in the encryption process. llMD5String("password", 0); The above code actually results in: MD5("password" + ":0") // Output: "5980d6f828464365b63eac19a6984b3f" You can verify this with any online MD5 generator. The difference between Base64 and MD5/SHA1 is that if I give you an encrypted string, there's (ideally) no way for you to figure out how that encrypted string was created. MD5 and SHA1 are specifically designed as one-way encryption. It's not possible to create a decrypter for them. (For example, what is this? "d612308c602ba6467964a2d20a91d7d0") The process of figuring out the input would involve creating plain-text, encrypting it, and checking if the outputs match. The same applies to user accounts. When you sign up, the password you enter is encrypted, either one-way or two-way, and the encrypted string is stored into a database. When you try logging in, the password you enter is encrypted again and the system checks if the two results match.

OpenGL is like 30 years old. No tech should be supported (or developed/maintained) forever. Eventually, new things come along with more benefits and less baggage. Metal might be "Apple specific" but I make the same argument for Vulkan, for example. OpenGL will die hopefully sooner rather than later.

With Rolig's script, your drawer will have to be made up of multiple, separate linksets. Each usable drawer (and its contents) will be its own linkset, where Rolig's script will be in the root prim and no scripts are needed in any other part. Here's a short video: https://gfycat.com/illfixedafricanhornbill The "main body" of the drawer is unscripted.

Because as I know you know, that's not what alpha masking does.

Alpha blending/masking only determines how transparency is treated. Alpha blending allows partially transparent pixels. Alpha masking allows only fully transparent pixels, or solid pixels. I assume your green screen is a completely solid surface, so it wouldn't have transparent parts to begin with. Changing its alpha-mode in that case should cause no changes to its behavior -- especially not the shadows it casts (or are cast onto it).