Wulfie Reanimator

Guy second from the right is Father Grigori from Half Life 2. (I like him!) Black guy, second from the right (front row) is the main character from GTA: San Andreas. Girl next to the black guy looks like a rip directly from SL. Girl behind her looks familiar, but I can't place it. Same with the guy in green, way in the back, and the one with the guitar. Edit: Bah, foiled by @cheesecurd

Just shooting from the hip, but could it be that the uploader is looking at the individual/average file sizes? 1 file = 1 MB, weight = 1 2 files = 0.5 MB each, weight = 0.5 (Numbers are obviously made up.)

I live in a country where land ownership (especially forest) is considered fairly important. That said, I also live in a ~30sqm box IRL with no desire to own land or even a bigger apartment. I like what I have, there's no wasted space but I don't feel like I'm running out of room either. The apartment is in a great location with public transportation (bus/train) constantly going everywhere, there's even a 24/7 mall within walking distance in case I feel like getting something at 3 AM. I have no idea what I would do if I lived elsewhere with yard all around. Same thing on SL, I rent a tiny 320 sqm parcel and all I use it for is a private sandbox for scripting. I could easily afford a parcel 10 times bigger, but why?

Good point. For the sake of completeness, I did read the LSL bridge code and there isn't anything AO related there (not even llSetAnimationOverride) besides an interface for OpenCollar and LockMeister, so you're correct there. The bridge also does use llOwnerSay. (Full script here) The only arguments given to this are "on", "off", "standon", "standoff" aoState(string newstate) { llOwnerSay("<clientAO state="+newstate+">"); }

You can't get accurate script memory usage as an observer, it's about as useless of a metric as script count. (Unless you're an estate manager, but I think LL changed even that method.) You can only find out the maximum memory limit; 64KB for Mono (lower if it uses llSetMemoryLimit) or 16KB for LSO. Mono scripts use memory dynamically. That means that a small script might use 5KB out of 64KB. LSO scripts are fixed-size. They always use 16KB no matter how big of small the script is.

~--i I can't tell if I'm ready to vomit or propose. Edit: I think you meant "cuwewe."

Here's a fun one; what about i++? Since post-increment requires the current value of i to be copied, incremented, and assigned to the previous address, it does require the stack unlike ++i. Unless the compiler does the smart thing when both would work, anyway.

You don't need the script after the AO has been initialized because it uses llSetAnimationOverride, an LSL function to allow server-side changes to the avatar's animations. It has a caveat though: "Animation overrides survive script reset, script removal, attachment removal, crossing into another region and teleporting, but not relog."

I don't know why since i'm not a Firestorm dev but i'd assume because people asked for it. I also assume though that the question wasn't about why they added it but why they have one despite me saying that i won't have one unless LL gives us proper capabilities to do so which would imply either that i'm full of ***** or FS found a hacky way to do it and that's exactly what they did: They force attach a bridge (i think everyone knows about the FS bridge by now) and this bridge contains a script (or maybe multiple) that communicate with the Viewer (most likely through a secret channel in local chat or possibly via direct IMs or llOwnerSay()) in some way to give it additional capabilities that can only be achieved by scripts because the Viewer lacks the ability to ask for these kind of information from the servers. The AO was just a normal AO scripts until they introduced server side AO capabilities, FS later changed (as far as i know) the AO stuff to use said server side capabilities. The point however remains that this requires attaching a script which requires attaching an attachment to you to do and by doing so you could as well just attach an AO. The script in the bridge is full-perm at least, so the chances of nefariousness is pretty low. (I would copypaste it here but I'm not at home to do it.) The bridge also does more than just act as an AO, it also provides other things like a move-lock (not ground-sit) and flight-boosting. Like you said, if anybody wanted to get malicious, they'd do it directly in the viewer where even fewer people are likely to find, read or understand it.

And this is exactly why the job of a moderator isn't as simple as regular posters may think. 😉 There also exist communities within communities, not just one group of "regulars" and "new users." Even well-intentioned reports can be incorrect. It gets even more messy when the user keeps reporting posts and "nothing ever happens" because the moderator(s) disagree. Sometimes it results in that user with good intentions to start breaking rules themselves which may be worse than the original perceived rule-breaking, causing action to be taken against them, which can frustrate them even more. Sometimes you can alleviate this by sending a PM to the user, but that alone can be taken as an offensive action by the user which throws them into a fit. People are different and unpredictable... but that often makes them kind of predictable. When you spend years moderating hundreds of thousands of people (as I have), you start to see pretty obvious patterns and they're 100% correct more often than not.

This. I've been a moderator on a couple forums alongside other daily/hourly moderators who would spend most of the day looking at the new posts/comments with me. The rules are rarely followed literally, it's more about "the spirit of the law, not the letter of the law." There's also some implicit bias when it comes to regular users who post a lot or for a long time (and so is familiar to the moderator), they tend to get more leniency because they have social trust.

This is entirely correct. The blocked person can ALWAYS see what you're doing. Inworld you automatically decline items and TP/friend requests, and you can enable yourself to see muted chat. In the forum, you see a collapsed comment titled "xxx replied" and you don't get notifications about them quoting or mentioning you, but you DO get "new comment" notifications if you are following the thread. (I know this because I've blocked one person in the past.)

"Stack" is used for run-time memory. When you call a function like llList2String, the function itself takes a bit of memory on the stack and the final list returned by that function also goes onto the stack. If you have too much memory on the stack, the script will crash. The "event queue" is just a waiting list for events like touch_start, listen, control, sensor, etc. When the script is processing some event and a new event is triggered, the new event goes onto the queue. This queue is handled by the region and does not take up any memory from the script itself. Up to to 64 events are kept by the region, any more than that are discarded. So when you have an event/function with a loop, the script will just be busy processing that loop and any new events will go into the queue. The iterations don't take up any memory on the stack by themselves, so the stack doesn't change either unless you use other functions that use memory. list j; // The variable itself is stored on the heap. // All of the compiled bytecode is also stored on the heap. default { state_entry() { llListen(0, "", "", ""); // The function call uses stack. // The memory used by llListen is freed from the stack after it returns. } // When a chat message is heard, "listen" goes into the queue. // If the script isn't busy, it will start processing the next event. // The event will use stack memory while being processed. listen(integer channel, string name, key id, string message) { integer i; // Stack while (i < 1000) // Uses no memory, but the script stays "busy." { // (1000 uses heap because it's a literal.) j += message; // Stack memory grows. ++i; // Technically uses stack, but doesn't really use memory. } if (message == "clean") // "clean" is a literal. { j = []; // Stack memory shrinks. } } // All of the stack-memory used by listen (everything besides j) // gets freed when the event ends and the script is no longer "busy." } You can crash the above script with a stack-heap collision if you never say "clean" near it. Edit: I guess if we go super nitpicky, "i < 1000" uses memory because the expression returns a value (1 or 0), but I don't exactly know when it gets freed but that's extremely insignificant to any script.

I believe this is because "proper mesh" is way more accessible than sculpt maps. The art of prims was pretty elusive as well...

The eyes-rolling-into-your-skull has been a problem for many many years. I remember having this issue back when the Phoenix viewer still existed.

All variables are always initialized to zero-values in LSL. You're right that in some languages, for example C, this isn't case. LSL is a safe language though.

Not quite as extreme of an effect, but yeah, animated capes exist. (Both animesh and traditionally rigged.)

Yup, it plays two animations per "stand" or whatever state the avi is in. When you're sitting, the hair plays a sit animation for the avatar, and a totally separate animation (using bones like tail, spine, leg, etc) for the hair. This way the hair's animations don't conflict with bones the actual avatar might be using. (So for example, if the hair used the tail bones but you have a tail, the hair would cause your tail to wave around as well if it wasn't a separate animesh object.) What might be an interesting thing to do is to into the hair's contents and play one of the hair-animations on your own avatar.

Animesh uses a separate skeleton from the avatar itself, so even priority 1 animations would be enough to not get affected by things like furniture or dances.

It's worth noting that whenever a game moves to a new version of an engine, it doesn't necessarily mean the game is going to look any different (or is going to have that pretty physics destruction). The tech demo is also definitely impressive, but similar destruction was already possible with Unreal Engine 3. (Also the debris created from the mayhem does disappear, fall into the ground, etc. You can see it pretty clearly if you look closely, for example at 2:55 on the left-side wall as things are falling down, and on the street below when the camera focuses on the little robot.)

That's just a limitation of the in-world profiles. They're always scaled down as far as I know. My profile picture on the web profile (same as in-world) is 600x600, not sure if it can go higher than that.

Have you tried changing the physics type?

Oh, no, I don't care what you actually do. Copybot all you want, whatever you want. It's no skin off my back whatever you do. I'm just baffled by the mental gymnastics you're (not?) doing to justify it. There is. The permission system. I've shown you the part of LL's terms and conditions that specifically says "the permission system is a license," meaning that when a merchant sells you a HUD with a script (and just those) and sets them no-modify, that means that: You haven't bought textures, only an applier. You have no rights to the textures being applied to your avatar. What you have bought is no-modify, meaning you cannot make modifications to them without breaking the license. Even if the applier was modifiable, you would only have the license to edit the HUD/script itself, not the textures. Only when the textures are provided and modifiable could you make the argument that bypassing the permission system (going into your cache, if they aren't full-perm) to make personal modifications to the textures is fine. But you don't seem to agree, because apparently you're not understanding what the terms and conditions actually say.

Thanks, my forum title is very deliberate. It was given to me years ago on another forum and I quite like it. I know the textbook definition of stealing. The one you've given me doesn't even cover piracy because you can't "steal" a game, you're just creating a new copy of it without deriving someone else of anything. Obviously piracy is considered stealing, but you need to use better definitions if you're going to start copy-pasting literary to me. I also understand the first-sale thing and it makes perfect sense. However, it's not absolute and it can be overridden. Video games -- besides the physical disk (or technically even the disk I think?) -- aren't covered by it because of End-User License Agreements. They specifically say you aren't paying for the code required to run the game, and you aren't paying for the assets required to represent the game on your screen. Linden Lab has this stipulation too (terms and conditions): As @OptimoMaximo pointed out, Second Life's agreement specifically states that the permission system is used to define the license to use the content you buy. You aren't buying the content itself. P.S. Answer the other example in my previous post above yours.

Because you're too daft to understand what you've purchased. Hint: It's not the texture. Can you explain the difference between you buying an applier and extracting the actual texture, and me buying a video game and extracting the textures from that? Let me guess, is it something along the lines of "games cost more or are bigger than just appliers?" Or a more relevant example again, when you buy yourself a mesh body, why do you think it's not okay to extract the model and make adjustments to it? I guess you already explained that "you have to do it locally," but you have to do that with textures as well so that doesn't count. What gives? Could it be because people can easily tell when you've re-uploaded an edited model?