Tentacolor » Guides, How-Tos & Tips

Bypass an Anti-Inspect Shield in 3 Easy Steps

Jacek Antonelli — Thu, 17 Sep 2009 21:25:34 +0000

The SL fashion world has spawned a bizarre and mysterious type of device known as the anti-inspect shield. The primary purpose of these devices is to deter other people from checking the names and creators of attachments you are wearing, so that they can’t go and buy the same things you did and copy your “style”. The shields accomplish this by surrounding your avatar in many layers of transparent prims, so that other people can’t right click and Inspect your other attachments — their click will hit the shield instead.

Anti-inspect shields are a contentious issue for many reasons. Not the least of these is that it deprives designers of the new customers they could have gained from people seeing and admiring your outfit, and finding out who made it. But just as bad is that they severely reduce your framerate and the framerate of everyone around you, as Gabby Panacek has demonstrated.

Hurting the creators of the items you love, and slashing everyone’s framerates in the process? Well, that’s pretty vain and selfish, but maybe it’s worth it to stop “copycats” from stealing your style? Perhaps it would be, if the shields actually stopped people from inspecting your attachments — but they don’t.

In fact, there’s an extremely quick and easy way to completely bypass the shields, and you don’t even have to fiddle around trying to get the right camera angle. All it takes is 3 easy steps, which I’ll demonstrate with Caer Balogh’s lovely ~~brown paper bag~~ “Advanced Fashion Shield 1.0″, which Gabby kindly passed on to me. It’s just as useless as the real shields at stopping people from inspecting, but doesn’t hurt your framerate, and is way more stylish.

Enable Advanced > Rendering > Hide Selected. (Use Ctrl-Alt-Shift-D to turn on the Advanced menu if you need to.)
Open Edit mode (Ctrl-3) and click on the shield to select it. It will disappear from your view (except for its outline). If the person is wearing multiple shields, you can hold Shift and continue to click them until you have selected (and thus hidden) them all.
Click on the attachment you want to inspect.

Even the biggest, primmiest, laggiest shield, whether scripted or unscripted, sculpty or nonsculpty, can be bypassed in just a few clicks using this method.

So if you have a shield, please, take it off. All you’re doing is making SL less enjoyable for yourself and everyone around you.

Random UI Tip: Send an item through the IM window.

Jacek Antonelli — Sun, 25 Jan 2009 19:00:54 +0000

Here’s another random UI tip for you, this one discovered by McCabe Maxsted:

Drag and drop an inventory item into the IM window to send it to the person you’re IMing with. You don’t need to open their profile window! (This doesn’t work for group IMs, though.)

The next version of Imprudence will have a little reminder note in the IM window, but you can do this with any SL viewer right now!

The more you know!

Random UI Tip: Reset a slider to its default value

Jacek Antonelli — Sat, 24 Jan 2009 19:00:32 +0000

You find out the darnedest things, looking through the viewer source code.

For example, if you Ctrl-click on a slider bar in the SL viewer (or Imprudence), it will reset that slider to its default value.

The more you know!

P.S. This is what a slider bar looks like:

Serving simple HTML by LSL script

Jacek Antonelli — Mon, 24 Nov 2008 20:22:19 +0000

I’ve written an LSL script which “serves” custom-generated HTML via a neat trick I discovered. But don’t bust out the champagne just yet — this method is extremely limited, so I don’t expect this to revolutionize HUDs or anything like that. Still, it’s a fun curiosity.

The trick is this: If you use text of the form “data:text/html,[html code here]” as the web URL, Firefox (and maybe other browsers?) will render the HTML code as a web page. For example, visit data:text/html,

Oh hai!

, and Firefox will render the words “Oh hai!”. It’s not accessing a web page, and it’s not loading a local HTML file, it’s loading the HTML code from the pseudo-URL.

The same trick works in SL as well, by setting the parcel media URL to the “data:text/html” string. You can use an LSL script to generate the HTML code and set the parcel URL, or even set the URL for an individual avatar. The result is that your LSL script acts as a very simple web server!

However, as I mentioned, there are some serious limitations: SL won’t let you set the web URL to a string longer than 254 letters! That means you have to cram all the HTML code into that tiny string, which severely limits the complexity of the HTML you can display.

Another problem is that the method may not work for other web engines besides Firefox / Mozilla. Linden Lab is (or was recently) working on switching to WebKit, the engine used by Safari, for rendering HTML. That’s good news, since WebKit is some great software, but this little trick might stop working when they switch. So, I wouldn’t rely on it.

So, I don’t expect this method to be more than a silly toy for programmers to play around with. But it is that! And on the plus side, there are signs that we might get proper HTTP server functionality in LSL sometime in the future, which would be a great boon to many scripting industries in SL.

You can get a full-perm copy of the object and script in SL at my sandbox or copy the following code (below the fold, if you’re viewing this on my blog front page) into an LSL script in your own object (in which case you should apply the “*Default Media Texture” to your prim from the Library, or you won’t see anything).

// VERY SIMPLE HTML SERVER // by Jacek Antonelli, 2008-11-24. // // Description: When an avatar touches the object, it sets the // avatar's media URL to a custom-generated HTML string, // effectively serving HTML from an LSL script. // // However, this method is limited by the maximum allowed // URL length of 254 characters. Thus it's only possible to // serve very simple HTML with this method. // // This script has been released to the PUBLIC DOMAIN // by its author. default { touch_start( integer n ) { string html = ""+ "

"+ "Your name is "+ llDetectedName(0)+".
"+ "Your position is "+ (string)llDetectedPos(0)+ ".
"+ "This HTML is generated by the LSL script.
"+ "Have a nice day. :)"+ "

"; llParcelMediaCommandList( [PARCEL_MEDIA_COMMAND_TEXTURE, "8b5fec65-8d8d-9dc5-cda8-8fdf2716e361", PARCEL_MEDIA_COMMAND_URL, "data:text/html,"+html, PARCEL_MEDIA_COMMAND_TYPE, "text/html", PARCEL_MEDIA_COMMAND_SIZE, 600, 300, PARCEL_MEDIA_COMMAND_AGENT, llDetectedKey(0), PARCEL_MEDIA_COMMAND_PLAY ]); } }

Happy Days, Old Viewers

Jacek Antonelli — Mon, 03 Nov 2008 04:49:01 +0000

Tired of those beautiful, photo-realistic sunsets? That new-fangled Windlight rendering engine slow your compy to a crawl? Want to relive the good old days, back when voice chat was new and strange, and Linden Lab even bothered to pretend to communicate with its customers?

Well now you can!

… Actually, you’ve been able to do so for a long, long time — ever since the D�a de Liberaci�n back in summer 2007. One of the benefits of “message liberation” was that you wouldn’t need to download a new SL viewer just because they made some server changes; old viewers would continue to work with new sims.

And in fact, that has held true, even to today. The only thing stopping you from using a 1.18-series (pre-Windlight) viewer is that annoying “You must download the latest version to continue” message, which is easily bypassed with a trick I’ll describe below.

But what of that mandatory security update in early October? Or the security update and protocol switch from UDP to HTTPS less than two weeks before that? Wouldn’t those issues prevent old viewers from connecting?

Apparently not. As of this writing, even 1.19 and 1.18 viewers (but not 1.17 or other older, “unliberated” viewers) can connect to SL with nary a hitch, though they’re probably still susceptible to the security issues mentioned above. As usual, the purportedly required updates are, in fact, not.

So, what is this trick, this secret knowledge needed to bypass the download prompt and log in with older viewers? Change the channel. It’s an old trick, though there was some concern that it wouldn’t work anymore since the change to HTTPS. Fortunately, those concerns have not come to pass, and the SL servers seem perfectly happy to use UDP with older viewers.

Changing the channel is easy. The viewer application takes a parameter, “–channel CHANNEL”, which sets the channel to use. The process for giving that parameter varies between operating systems. The processes are described on the SL wiki, but I’ve included a brief overview below.

Windows: Create a shortcut to the older SecondLife.exe. Open up the shortcut’s properties (right click > Properties) and edit the shortcut path. ~~After SecondLife.exe but before the closing quotation mark~~ After the closing quotation mark, add: --channel Happydays
Mac: Open up the terminal and run these two commands (adjust the first path if your Second Life app isn’t in Applications):
```
cd "/Applications/Second Life.app/"
echo "--channel Happydays" >> Contents/Resources/arguments.txt
```
(Mac users, leave a comment if the above solution didn’t work for you. I don’t have a Mac handy to test it!)
Linux: Run the viewer as: secondlife --channel Happydays

You should now be able to log in to SL with your retro viewer version. Enjoy, good night, and good luck!

P.S. Don’t have the installer for the old viewer laying around? No worries, they’re still available for download. Mad props to McCabe Maxsted for putting that wiki page together!

Tip: Replace the SL typing sound with crickets

Jacek Antonelli — Fri, 26 Sep 2008 17:00:07 +0000

Here’s an updated version of an oldie but a goodie. Back in January 2007, I found out how to disable (on your computer only) the SL typing sound — the loud, annoying click-clack-clack sound that plays whenever you or anyone around you starts typing something into chat.

It has been nice and peaceful since then. But tonight, while testing the latest build of Imprudence, I heard it for the first time in 21 months (since my regular SL settings weren’t loaded). Blech! What a racket. I went to disable it, but then I thought of something better: I could replace it with a nicer sound. That way I’d still have an audible indicator of when someone was typing (something I realize I had been missing).

After rummaging around in my inventory a bit to find an appropriate sound, I settled on a freebie cricket chirp sound. It was full perm, so I grabbed the asset UUID: b3831ff2-a197-62df-34f7-a83be592c1da

So, I enabled the Advanced menu (Ctrl+Alt+D, or Cmd+Alt+D for you Mac-types), opened up Advanced > Debug Settings, typed in UISndTyping, then pasted in b3831ff2-a197-62df-34f7-a83be592c1da in the box at the bottom, replacing the UUID that was there. Close up Debug Settings and… voila! Now instead of clacking on a keyboard, everybody chirps like a cricket when they start typing!

Of course, if crickets aren’t your thing, you can use any sound at all, as long as you have the UUID for it. You can get that by right clicking on it and selecting Copy Asset UUID — but only if you have full permissions on the item.

So, enjoy your crickets etc.! If you find a free sound that you like even better than crickets, leave a comment with the UUID or link to where it can be downloaded so I can try it out. (No illegal rips, please!)

Tip: Stop the Tools menu from hiding in 1.20

Jacek Antonelli — Thu, 31 Jul 2008 21:10:12 +0000

Wonder where the “Tools” menu went in Second Life viewer 1.20? Linden Lab decided, in the interest of reducing the number of menus presented to the user, to make it only visible when the “Build” window is open (Ctrl-3).

This change was rather unpopular, and Linden Lab has, thankfully, decided to revert it in a future version. But in the meantime, we’re stuck with it — or we would be, except there’s a quick and easy work-around to disable it! All it takes is a text editor (Notepad, etc.); you don’t even have to compile anything. (If you’re really lazy, you can just download my file and put it in the right spot, as described below.)

This trick is a simple one. Since SL looks for the Tools menu by name to find which menu to hide, all you have to do is change its name, and SL won’t find it, and it’ll stay visible all the time!

The really easy way (download the replacement file):

Download my pre-chewed XML file to “Second Life/skins/default/xui/en-us/”, replacing the existing one. On OS X, go to Applications, ctrl-click on “Second Life”, choose “Show Package Contents”, then put the file in “Contents/Resources/skins/default/xui/en-us/”.
Restart SL, enjoy.

The slightly less easy way (edit the file yourself):

Open up “Second Life/skins/default/xui/en-us/menu_viewer.xml” in your text editor. On OS X, go to Applications, ctrl-click on “Second Life”, choose “Show Package Contents”, then open up “Contents/Resources/skins/default/xui/en-us/viewer-menu.xml” with TextEdit (or your favorite text editor).
Search for: name="Tools" (it’s on line 590)
Change name="Tools" to name="Toolz" or some other non-Tools word.
Save the file, restart SL, enjoy.

Voila, your Tools menu will now be visible all the time. Piece of cake.

Tutorial: SL Animation for Blender Newbs!

Jacek Antonelli — Fri, 06 Jun 2008 21:02:16 +0000

It’s done! I am pleased to present to you, SL Animation for Blender Newbs. It’s 6 pages long, with pictures. It might take you maybe 30 minutes or so to follow along, I’m guessing. If you have any feedback (e.g. suggestions or praise), leave a comment on any of the pages.

Enjoy.

JIRA Issue States (Part 2 of 2)

Jacek Antonelli — Thu, 20 Dec 2007 02:47:32 +0000

In Part 1, I talked about the different states a JIRA issue can have, as well as the different resolutions and what they mean. Today, I’ll walk you through the life of an issue, from the time it’s opened to the time it’s fixed and released. I’ll also talk about some of the challenges the JIRA process faces as it turns from an inward-facing tool to be used by trained software developers, to an outward-facing tool to be used by the general public.

In theory, here’s how things are supposed to go:

Someone opens a new issue. We’ll call that person the issue reporter. The issue is now Open.
People vote and comment and add more info.
A programmer (either a Linden or an open source volunteer) sees the issue and decides to tackle the job. The issue is now In Progress.
When the programmer is done working their voodoo, they upload a patch to the JIRA. The issue is now Resolved. Or maybe it’s still Open. Who knows?
A Linden with access to LL’s source code repository applies the patch and marks the issue as Resolved, with a resolution of “Fixed Internally”.
It’s compiled and examined and made sure it works and there don’t seem to be any bugs. This is called QA (Quality Assurance), and it can take a long time, because there are lots of issues to check. The issue has to wait in a queue until it can be looked at.
If it all checks out, eventually it will be released in a new version along with other fixes. Yay!
The issue reporter downloads the new version and makes sure the issue has really been addressed. If it has, they mark the issue as Fixed, and Close it. If not, they change it back to Open, and we go back to step 1.
Done!

That’s how it’s supposed to go, anyway; or rather, as I said last time, my interpretation of it based on experience.

In practice, though, issues often don’t end up Closed. Instead, they linger as Resolved until a dutiful volunteer sifts through the hundreds (thousands?) of Resolved issues, marking off the ones that have been fixed. Often, issue reporters simply don’t realize they’re supposed to check back later to Close the issue.

As it happens, the Closed state isn’t used much. Maybe it’s the ambiguous difference between Resolved and Closed. Maybe it’s confusion about when it’s appropriate to Close an issue, and who is allowed to do it. Maybe it’s fear that Closing an issue is forever, as implied by the description of Closed as “the final resting place” (it’s not forever; you can re-open Closed issues just like you can for Resolved issues). Maybe they don’t want to make the reporter angry by closing their issue.

Another contentious issue is the fact that voting is closed for Resolved issues, which (in my opinion) should not be the case. There are cases of high-profile bugs that are still ruining a lot of people’s SL experiences, but the fix seems to be stuck in QA limbo. Since issues are marked Resolved / Fixed Internally while going through the QA process, people can’t vote for it anymore. That means there could be hundreds of Residents who would have registered the fact that it affects them, but couldn’t. This prevents the number of voters reflecting the relative severity of the problem, a metric that could (and possibly should) be used to prioritize issues in the QA queue.

Fortunately, there are JIRA issues about the issues with JIRA (how delightfully recursive)! A lot of progress has already been made on improving JIRA, but there’s still more to do. To get you started, check out:

WEB-194 (“Streamline and clarify JIRA reporting process for non-technical users”)
WEB-274 (“Change status labels for PJIRA”)
WEB-315 (“Meta Issue: LL JIRA Guidelines”)

JIRA Issue States (Part 1 of 2)

Jacek Antonelli — Sat, 15 Dec 2007 21:03:35 +0000

If you used the SL Public JIRA (highly recommended for all Resis, it’s neat!) then you might be familiar with the various states an issue can have. But you might not really know what those states mean.

What’s the difference between “Resolved” and “Closed”? When is something “Fixed”, and why do some issues seem to get stuck in “Fixed Internally” for a long time?

Read on to find out!

Due to some confusing technical jargon that doesn’t make a lot of sense if you’re not used to them, the meanings of the various states aren’t immediately obviou. Here’s a list of the possible states that an issue can have right now:

Open: the normal state, people can vote and comment and post patches and such.
In Progress: someone’s working on it, so never ye worry.
Resolved: some sort of action has been taken to address the issue, but someone needs to confirm that it’s addressed, or it still needs to be released. Voting is closed, but you can comment or even re-open it.
Closed: the issue has been solved and released, everything’s groovy, nothing more to be done. Voting is closed, but you can comment or re-open it.

At least, that’s my interpretation of them, based in large part on this well-hidden blurb on the SL wiki. There’s a lot of confusion about issue states, especially among users who aren’t used to issue tracking software and its weird jargon.

When someone says a problem has been “resolved”, that usually means the thing has been fixed. But wait, that’s what the “Closed” state means on JIRA! So what does “Resolved” mean, then? Is it the same as “Closed”? Why do they have both of them?! Arrrgh, so confusin’!

To make it even more confusifying, the “Resolved” state can mean lots of very different and unrelated things, depending on what the “resolution” is:

Fixed Internally: LL has fixed the issue (or applied a patch) in their internal source code repository, but it still needs to be reviewed to make sure everything’s good and it can be released.
Fixed: the issue has been fixed and released. Yay!
Won’t Finish: LL won’t fix the issue, for any number of reasons. Maybe it would break content, or make things really slow, or it just doesn’t fit within their grand vision.
Duplicate: someone has already reported this same (or a very similar) issue earlier or with better info/repro, and you should comment/vote on the other issue instead.
Needs More Info: the issue doesn’t have enough info, or it isn’t specific enough, for anyone to address the issue. E.g. “inventory is borked plz fix kthxbai” <– needs moar infos!!
Cannot Reproduce: the Linden who looked at this issue can’t make babies. Just kidding! It means they tried to make the bug happen so they could study it (and later try again to make sure it doesn’t happen up anymore), but they couldn’t. Repros are an important part of the process!
Misfiled: this issue doesn’t belong on JIRA. Examples include “Halp I furgetted my password”, “I liek ponies”, and “LL sucks cuz there poopy heads”. These types of reports don’t help make SL better!

But those labels can be confusing, too, hence me needing to explain what they mean. And some of them don’t really fit with the Resolved state: the “Fixed” resolution, for example, should really only go with the Closed issue state. But, the same list of resolutions is used for both Resolved and Closed, and there’s some overlap, so it’s fuzzy and ambiguous.

Tune in next time for an overview of the JIRA process flow, more JIRA quirks and weirdness, and some tips on making JIRA a better place!