Wulfie Reanimator

You can copy scripts and have them running without recompiling if you just copy the object they're in. Objects can contain up to 10'000 items in their inventory. You'll probably want a lot less than that or you'll be waiting for the inventory to load forever. When you put an item into an object that has the same name as something else in the same inventory, they'll get a number appended to their name. eg. Script, Script 1, Script 2... You can get the name of the current script with llGetScriptName You can get the name of the current object with llGetObjectName So... Write a script that... knows the name of the object it's in. (It should be a number only.) knows what number comes after its name. (This number, combined with the object name is its starting point.) starts listening on 65 channels from its starting point when touched. Put like 100 copies of that same script into an object, name the object "1". Copy the whole object, name the new copy "2". Repeat until you have enough. Touch all of the objects to make all of the scripts in them listen on their respective channels. And now you can cover as many channels as you can be bothered to set up. If you did it correctly, you could be listening on 65'000 channels with 10 objects with 100 scripts in each. That means 1000 scripts, so you'll want to make sure you're not doing this in any sim where other people are doing things, as you'll definitely be causing some overheard for the sim.

PI is a built-in constant. It doesn't have to be declared, it just always exists: http://wiki.secondlife.com/wiki/PI n comes from the sensor event itself: sensor(integer num_detected), I just renamed it to be shorter.

PI is just the mathematical constant pi. 3.14 and so on. I use PI as the range (3.14 meters) and cone arc (3.14 radians = 180 degrees = full sphere). n is just the number of avatars detected by the sensor. When one avatar is detected, n is 1. The while-loop just goes through every detected avatar within range, and gives them a light shove away and upwards so land-friction doesn't keep them in place.

Well, not quite if you're clever (like me, hurhur, sarcasm). You can make an object that follows you. default { state_entry() { llSetTimerEvent(0.1); } timer() { vector position = llList2Vector(llGetObjectDetails(llGetOwner(), [OBJECT_POS]), 0); llSetRegionPos(position + <0,0,0.25>); } }

Attachments can't collide with anything, they have no "physical" shape. Your only options are to either rez something so that it can be physical, or use a script with llPushObject, which requires the land permissions to allow pushing. This script for example: default { state_entry() { llSensorRepeat("", "", AGENT, PI, PI, 0.1); llSetScale(llGetAgentSize(llGetOwner())); } sensor(integer n) { while (n--) { vector direction = llDetectedPos(n) - llGetPos(); direction.z = 0; direction = llVecNorm(direction); direction.z = 0.5; llPushObject(llDetectedKey(n), direction * 5, ZERO_VECTOR, FALSE); } } }

It was already explained by many people that what they're talking about is not against TOS. Your explanation didn't really add anything and your comparison was not correct or valid. I don't disagree with your conclusion but it doesn't matter if the path you took is completely wrong.

Your naive understanding of the US law is showing again, never mind that comparisons to real life law don't apply in enforcing rules in a video game. You can absolutely arrest someone with intent to commit a crime. Look up "conspiracy" as the closest example to OP. You can also be charged and found guilty of "intent" to do something. You will also be arrested if you start yelling bomb in an airport. There are lots of cases like this. Look up "inducing panic," which is at least a misdemeanor but depending on the severity it will be considered a felony. No, it's not public. It's a small closed-off room with just the GM and you. Here's an example (it's about an inappropriate name): https://www.youtube.com/watch?v=7vG3ZlTatF0

There are still a few games that do it this way, Runescape (who livestream bot banning) and FFXIV (where your character is literally summoned into a jail cell with a GM) come to mind.

I can't remember the specifics for the life of me, maybe @Whirly Fizzle knows what I'm talking about, but I recall there being a very specific animation bug where the animation would not work if some part of the avatar's key was "lower" than the animation's or vice versa. I have the impression that it's some edge-case and doesn't affect many people, but I can't find it on the JIRA.

This is normal and highly preferable. LSL (the scripting language) has safeguards that make it very hard to automatically gain permissions to animate. You MUST either sit directly on the object that wants the permissions, or you MUST attach that object to yourself. Otherwise a script can't get permissions to animate you without asking you. The Firestorm option "Stop Avatar Animations & Revoke Permissions" does not work on at least objects attached to other avatars. (I don't think it works on anything you don't own, but I haven't tested that broadly.)

It's probably hakerz.

To be fair, this was standard practice already. When an account gets stolen and lindens drained, they do get those lindens back. Those "reassessments" should always go right back to the account that was used to buy your items, not just removed from you. Same thing with unauthorized L$ purchases. Even if LL didn't refund the money, the bank could force a charge-back (or otherwise refund, depending what the insurance policy of the bank is).

You're about 11 pages late. The Lindens are working on it and actively reassessing L$. https://community.secondlife.com/forums/topic/436499-linden-dollar-assessment/

In all seriousness: Unless I missed something, nobody suggested that graphics settings should be closed off and only adjusted automatically, which would take away control. Adding a feature to enable auto-adjusting is adding convenience without taking control. Other games have features like this, the easiest of which to implement is lowering the render resolution dynamically when FPS drops below a certain threshold. Same for shadow and max texture resolution.

"Infantalizing" the end-user with convenience is absolutely a good thing. Political tribalism is absolutely not. I'm a sith btw.

Psst... Firestorm has a setting to limit its own performance when the window isn't in focus... If you turn it off, you get 100% identical performance.

Why not? What kind of error do you get?

How did you even FIND this thread?

And the part people refer to as "SL" is actually the viewer, which is open-source that anyone could modify (and do). The problem that "SL doesn't properly utilize hardware" is a fixable problem that doesn't rely on LL.

Occlusion exists in SL, you can even watch it via Developer > Render Metadata and you can read more about the specifics here. That page hasn't been updated since 2011 so it doesn't mention how mesh is handled. Do they occlude based on visible tris, bounding box, or what? It seems to be visible tris, at least partially, but I'm not 100%. It's also easy to test. Go to mainland, max out your draw distance, and put your camera inside of a solid room with no gap or transparent window outside. Your FPS will increase significantly. For example, in a "busy" area I go from ~10 FPS to ~20 if I'm in a dubious mesh hut. About ~25 if I cover my camera with a prim cube.

I might agree on account of SL not having very complex shaders that could be used in other games to get even more detail onto the screen from textures alone. Parallax mapping and cel shading especially come to mind, but any custom shader (for pixel, vertex, or geometry) would be great. I still disagree with the argument that using textures for detail would cause more lag. Only if the textures are many or unnecessarily large and the detail isn't substantial. Don't worry, that's not what I'm saying. I'm currently studying and writing my own (basic) renderers in C so I have a particularly good grasp on the concept that "nothing is free." Generally speaking you should be able to cache those calculations so that you don't have to literally go over the whole mesh all over again, especially the "relevant" faces so you wouldn't even check the shadow-side of an avatar for example, so the subsequent passes over the same mesh/object should be significantly cheaper. I don't know if viewers do this, though.

While I agree that you're more likely to get the "best" result by hand (and I've even made threads demonstrating how easy it is), it's not inherently bad to use a "magic button that does it all." From the video above, you can see that the plugin produces very clean topology for hard-surface models (the gun), but organic shapes (the skull/helmet) are handled very poorly if (and only if) the goal would be to rig it. It's very much about context and trade-offs. As you know, time spent is an important factor when working to a professional capacity. If you can just press a button to get a clean model in 5 minutes instead of spending 20-60 minutes on it, why wouldn't you do it? Same applies for all areas of the entire workflow. Not doing everything by hand doesn't reduce the value of the final product.

I strongly and respectfully disagree. Obviously the first thing is that Second Life is a game as far as any sort of tech talk is considered, there's no way around that regardless of your beliefs of the platform in general. For online games, bandwidth is the #1 priority over anything else. It doesn't matter how good the game looks if you're rubber-banding, stuck running in place, or dying in safety because you weren't safe on someone else's screen. Players will get upset over ping before anything else. In SL, interaction isn't very time-critical and that has been normalized over its entire existence. Textures are a big performance cost in real-time rendering in general. Not just loading them into memory, but drawing them from memory onto the screen as well. I don't think there's anything special about how LL has "optimized" textures, besides using a weird format that allows for "texture LODs" while bloating the total download size. I think @NiranV Dean has talked about that in the past. The way creators use textures isn't anything resembling performance-concerned development. I don't think I need to bang the drum about 1024sq textures, but generally speaking you should treat textures just like geometry. "Average pixel density" per area should be a goal just like for triangles. The problem is of course that there is no quality control or an enforceable standard. Triangles are relatively cheap. The difference between SL and other games is that SL scenes tend to be fairly static. As in, new objects/resources being created is fairly low. There are exceptions, like sandboxes or combat sims, but your average mall/club/hangout area tends to stay the same. That's why most games need to optimize more heavily -- to account for more things appearing into the world. The main exception is avatars, which are by far the worst offenders in terms of performance. They're like walking bombs, ready to destroy your framerate with all the excess everything. In games, even avatars are created with resource budgets in mind. There's some upper limit of characters that will be in a scene and all of them have to work for that limit. In SL, that limit basically doesn't exist. You can have up to (38 * 256 * 174752) triangles attached to your avatar. That's a "limit" of over a billion. Per avatar. More realistically I have seen multiple avatars in the same location with over a million visible tris, never mind all the other avatars and the world itself. TLDR: If people would develop content for SL exactly as a game developer would, we would see a significant positive change. That's neat.

Like Dessi explained, scripts cannot be copied. It's simply impossible because the "code" is never communicated to the viewer. They only exist on LL's servers, we can only observe their effect on the world. The same goes for all object contents. An otherwise "flawless" copy is as easy as it has ever been. It's easy because the viewer has all the information about the visual appearance of the object, including rigging data. If the viewer didn't have that, it couldn't display it. You can't copy an object from inside of another object because the viewer has no knowledge of what the object is, other than the fact that it's an object with a name. Similarly, it's theoretically impossible to create new objects with someone else as the creator, because object creation is handled completely by LL's servers. The only way to get around that would be if LL's servers trusted any of the data it was receiving from a viewer requesting to create a new object, which could "trick" LL's server into thinking the object was actually created by someone else. That's highly unlikely. A simple way to "hide" the fake creator is to get a transferable object from the real creator (such as a prim) and make that the root of the copied linkset. That way they can mask the name if you only select the whole object, but if you select any other link in the linkset or right-click>inspect, you'll see the actual (fake) creator. Considering the amount of people just in this thread reporting that they've lost rare gachas, I don't think there's any real reason to think there's anything being copied. If the fraud is as wide-spread as it seems from this little thread, it's not hard to imagine there being a large supply of rares just waiting to be sold later.