Wulfie Reanimator

I use the Dark Reader extension for my browser. It's more consistent than built-in dark themes, and works for any site without affecting other programs. For example, if someone colors their text black on the forum, it's invisible to those using the built-in dark theme.

Even if it could be done to the degree that real computers can... Why would you want to get on your computer to log into SL to play other video games? Serious question.

Where does this happen? My curiosity is piqued.

I can kind of see some uses for a feature like this, but regarding the "gift card copybotting" thing -- there are already much better methods. First of all, why couldn't the gift card modify itself the first time the new owner wears it? It would be a simple instruction to them. "You must wear the gift card near the vendor after purchase." Secondly, if your gift card can be simply copybotted, your design has bigger problems. It means anybody could just make their own gift card even without such a tool. Scripts are the only thing that can't be duplicated, so you should exploit that. The script itself should generate a secret key of some kind and store it internally (and register that in the database if you have one, but databases aren't necessary for gift cards). This way, all gift cards would appear the same but still be able to differentiate.

I would recommend steering away from jumps, because they can lead to bad habits. Instead, you could use a real loop: vector gScaleSmall = <0.5, 0.5, 0.5>; default { touch_start(integer total_number) { while (TRUE) { llSetScale(gScaleSmall + <0.5,0.5,0.5>); llSetScale(gScaleSmall - <0.5,0.5,0.5>); } } } You'll notice I also took out the duplicated lines. I assume you added them to try to "slow down" the changes, with little luck. Instead, you could use llSleep, which pauses the script for some amount of time. while (TRUE) { llSetScale(gScaleSmall + <0.5,0.5,0.5>); llSleep(0.2); llSetScale(gScaleSmall - <0.5,0.5,0.5>); llSleep(0.2); } Changing the delay gives you finer control of the effect. There's also the potential problem that this is an infinite loop -- it will never stop, and the script will never do anything else. Ideally, you wouldn't do this. Instead you'd have something like a timer event where you do one of those two things. (increasing or decreasing size) vector gScaleSmall = <0.5, 0.5, 0.5>; integer gExpand = TRUE; default { touch_start(integer total_number) { llSetTimerEvent(0.2); // Sets a time interval } timer() // Happens at regular intervals { if (gExpand == TRUE) { llSetScale(gScaleSmall + <0.5,0.5,0.5>); gExpand = FALSE; } else { llSetScale(gScaleSmall - <0.5,0.5,0.5>); gExpand = TRUE; } } } Slightly more complicated, but this way the script can handle other events as well, such as being touched again, hearing messages from other objects, etc. It works by having a gExpand variable that has one of two values -- TRUE or FALSE -- 1 or 0 -- and it either sets the scale bigger or smaller depending on what the value is. Then it changes that value so that the other thing will happen next time.

There's llGetTimeOfDay and llGetSunDirection.

A parcel is divided into two sections -- "ground level" and above. I think the split is about 80 meters above ground level. It has been like this for as long as I can remember. If you have parcel privacy enabled and your skybox is at 3000 meters, anybody around 150 meters and above can see you if they're on the same parcel. Conversely, if your home is on the ground level, anybody above a certain height won't be able to see you even on the same parcel. I think the "ban lines" cover this area, so enabling them will prevent anybody from entering the ground-level privacy area and seeing you even if they are on the same parcel. Lastly... The viewer is open-source, anyone can change the code. Even if LL forced the camera limits (which I think are enabled by default in the LL viewer), anybody could make a third-party viewer that disabled that feature. You can't make a viewer that bypasses parcel privacy because it's the LL server that simply doesn't share the avatar data of privacy-enabled parcels unless they are in the same area. (They do share position, which is why radars still work.) They could do the same for all objects on the parcel, but I don't think they want that considering what it would do to mainland.

...Oh. Did you not realize people rip and reupload literally-watermarked textures, or that most creators do watermark their textures today? The watermark can exist in parts of the texture that's never seen on the actual product. That doesn't prevent copybotting. If the watermark is visible on the product, customers complain. If the watermark is in an area that's never seen, the copybotter can just remove it. Here's a texture I made that's watermarked with "STEALING IS BAD" (I did this in 2 mins, sorry if it's ugly.) Here's a screenshot of it in-world: You never see it unless you steal it. What does this achieve? Very little. Likewise if you're the original creator and someone is trying to go out of their way to edit the textures, they likely know to look for watermarks, paint over them or otherwise destroy them, etc. Or they just don't care.

Let's just give this the benefit of the doubt and assume it could work... How would it work, exactly? LL gets the texture, does some "magic" to create a second key or something and checks whether this has already been uploaded by someone else. Sounds simple enough. Now -- the texture was from a freebie site, and someone else uploads the exact same texture. LL gets the texture, does some "magic" and checks whether this has already been uploaded by someone else... oh no. Okay. Maybe LL should hide the second key in the texture file? Now -- the texture is ripped from SL with its secret key included. Uploading it back won't work because LL will check for its existence. But since the file (and secret key) is on the copybotter's computer... They can just edit the file to slightly change or remove the key. Maybe the copybot viewer will just remove it automatically. It wouldn't even necessarily be difficult to figure out. You upload a small, simple texture file as a test, rip it, and see what changed. LL would have to re-implement their own image/cache file, requiring lots of time and a rewrite of lots of code. And then you can still rip the texture straight from the GPU, without having to decode LL's custom files. It wouldn't even include the secret key unless it's embedded in the color data... Which could potentially reduce quality. Even in that case, all you would need to do is change a couple pixels to change the secret key. Never mind that if the key is in the color data, all textures from the same creator would have the same colors in the same pixels, otherwise adding the secret key to the texture would make it a different texture that would generate its own secret key on the next upload...

BOM is a "complete set" of all the layers you're wearing. If you're wearing an underwear layer, you'll never appear completely nude. Allow me to demonstrate.

But that's no longer a valid URL.

I guess you could do... llSay(0, "[http://maps.secondlife.com/secondlife/Help%20Island%20Public/181/197/23 http://maps.secondlife.com/secondlife/Help%20Island%20Public/181/197/23]"); It would be clickable, but it would also display the full link. Essentially it uses the fact that you can create "named links," for example: [google.com Google!] would become Google!

I didn't dispute anything you said, don't be so combative.

Noooo. There's a way easier way! Import the texture into SL as a local texture. Open the texture file with Gimp. Edit the file, and save to override the original file. You will see the texture update in SL within seconds.

You can set up a business page without any kind of verification process. https://www.facebook.com/business/pages/set-up But a "business page" isn't a profile. That page is connected to someone's account.

You would have to break up the data into multiple lines. You can't read the first 255 characters and then the next 255 characters. You can only read the first 255 characters, because anything beyond 255 in a notecard doesn't exist for scripts.

Detecting a copybot viewer is also basically impossible. The official viewer is open-source. That means anybody can take that code, modify any (or no) part of it, and use it as their own little viewer. It's how Firestorm, Catznip, Black Dragon, etc. exist. Officially speaking, third-party viewers must self-identify themselves and cannot pretend to be any other viewer. Every viewer has a little "title" that they announce to LL's servers when they connect. It's a simple bit of plain text and there's nothing preventing a malicious viewer from claiming to be the latest release of Firestorm. LL can't truly verify it, especially if the homebrew is based on the latest version of Firestorm. There's just no practical solution, considering that even if you were to do a thorough verification of each viewer when they try to log in (like comparing the executable to some list of trusted viewers), you would basically lock out new viewers (and viewer updates) until they contact LL and get manually "whitelisted" to the "maybe legitimate" viewer list. Then there's the fact that a "summary" of a file can be faked, low upload speeds would hurt many SL users, and there are tools external to the viewer that can be used to steal content from SL (or any other game). Speaking of that TPV policy, I have no idea how much of it is actually enforcable, or how. I guess LL can ban the developers' SL accounts, or delist the viewer from the official TPV directory (if it even gets there or wants to be there)? Maybe a cease-and-desist letter, if they're in the US? Even if there was a way they could block a specific viewer from connecting, there's nothing stopping that viewer's developer from making a "new" viewer that's exactly the same, with only enough changes to make it "different enough" to bypass LL's viewer ban methods.

Are you putting all of this on a single line on a notecard? Scripts can't read more than the first 255 bytes of a line. The "cut off" you're seeing isn't exactly at 255 characters, but it's very conveniently close, the discrepancy could be explained by the formatting...

Think about Youtube, or Twitch (a streaming service). They don't go around hunting for IP violations, they sit on their hands until someone fires a DMCA. This is very much on purpose for a very good legal reason that enables them to exist at all. Youtube, Twitch, and Second Life rely on hosting user-created content, not something they curate or post themselves. This obviously opens them up to a lot of potential IP violations since anybody could upload anything. You can upload a full movie onto Youtube right now. You can upload 3D models from big games onto SL right now. Technically, the host is responsible for the IP violations, not the uploader, since it's being hosted on their servers. To make this business model feasible (since you can't possibly approve every upload individually or even automate the process), these companies are protected under Safe Harbor laws, which require that they in good faith try to remove violating content when they find out about it. This is where DMCAs come in. By filing a DMCA, you're claiming (under a penalty of perjury) that you are the actual owner of something, and it's being infringed upon. This is where Youtube/Twitch/LL are considered aware of the problem, and must remove the content. If they don't, they're literally taking personal responsibility for that content, and open themselves up for a lawsuit if they're mistaken. Anybody can make a false claim that something belongs to them and should be taken down because they say so. DMCA requires you to give out your legal info so the other person and you can have a chance of sorting it out, and for LL to have a paper trail in case you're filing false DMCAs. It's not perfect but it's a big deterrent to malicious behavior. If LL goes around removing and banning suspected copybotters / IP violators, what do you think happens when they make a mistake and ban a legitimate user? What if that seller uses SL for actual income, or even relies on it? That's another outrage and possible lawsuit. It's not about "their bottom line," it's about making sure SL can continue to exist as it does.

llCSV2List will correctly parse a string like "value, <1,1,1>" in a way that keeps the vector intact. llParseString2List won't. I agree with Rolig that we need to see more code.

More specifically to what Mollymews said, in your code: else if (~level & edge & CONTROL_ML_LBUTTON) This triggers every time ML_LBUTTON is released. Doesn't matter how long you (don't) hold it down. You basically need a little float to keep track of how long the button was held, and check that value on release. Or, you can use llResetTime on press and llGetTime on release.

Because one person can have multiple accounts, the source files can be shared by the original creator outside of SL, etc. LL can't guarantee that something is/isn't an illegal copy. It's literally not LL's job to spend the time making those decisions, since they operate under Safe Harbor. They will only take action when a DMCA is filed.

Some people love derendering clothes on people and taking pictures / jerking in the distance. Meanwhile I like using alphas to leave out all the fun bits.

There are two easy explanations for why you might appear naked to this individual, assuming your clothes are mesh (3D, not clothing layers). 1. You've attached your clothing to your HUD. Your HUD is only visible to you, even if your clothes appear to be worn around your body. 2. That person went out of their way to derender your clothes, and is messing with you by telling you that you have no clothes on. They might even show screenshots, which are a lie.

default { touch_start(integer total_number) { integer count = llGetInventoryNumber(INVENTORY_OBJECT); integer item; while (item < count) { string name = llGetInventoryName(INVENTORY_OBJECT, item); integer length = llStringLength(name); if (length > 12) { llOwnerSay("\"" + name + "\" is too long."); } ++item; } } } [06:21:06] Inventory: "This name is probably too long and shouldn't exist" is too long. Thankfully it doesn't seem possible to put multi-byte characters into object names, so you don't have to handle weird characters (which could be done with llEscapeURL).