The virtual adventures of one man and his pink lawn flamingo.
It’s almost certain that the next SL server rolling restart will once again remove the ability to create large prims.
I’ll continue to address bugs in my viewer that are related to use on other grids that already support large prims, but this won’t work in SL once the rolling restart is complete by Thurdsay.
Okay, once more, with feeling.
This release introduces two new features:
And a couple of bug fixes:
Once you’ve read the instructions and disclaimers, go ahead and download Release 4.
If you like having megaprim support in the viewer, feel free to vote on JIRA issue VWR-7192.
(And a hat tip to the constantly-helpful Nicholaz Beresford for helping me fix the major memory leak.)
One more update to the patch (and probably the last, unless I find another bug).
Changes:
Download Able Edition, release 3 once you’ve read the notes and disclaimers.
I found and fixed a minor bug with Release 1, so here is Release 2. It’s the same deal as before, so see the disclaimers and instructions on the previous entry before downloading.
One important note I accidentally neglected to mention before is that, for a variety of reasons, my viewer is compiled without Apple Quicktime support, so streaming movies will not work.
Once you’re all caught up, you can download Able Edition, release 2 and enjoy.
The wonderfully mad patcher, Nicholaz Beresford, was kind enough to include most of my megaprim creation patch with his Release: Eye Candy EC-f. I say “most” only because Nick didn’t want to modify the official UI xml files (understandably so).
However, I’ve gotten some requests for a compiled copy of my viewer with the megaprim patch (VWR-7192) and the bling and facelamp patch (VWR-6540) included, along with my UI changes, so here you go: Release 1 of the Able Edition viewer. (Currently available for Windows only.)
This is a no-frills release, with no installer, and is entirely unrelated to my previous viewers with visibility muting features. Please only download it if you’re comfortable mucking about with changing some of the files that are installed with the official viewer.
Before you download Release 1, please note that it will require version 1.19.1.4 of the official viewer (not a Release Candidate viewer). You can download the official viewer from the official download page.
Once you’ve installed the official 1.19.1.4 release, you can download the Able Edition Release 1.
[Updated: Release 2 contains a small bug fix. Once you’ve installed the official 1.19.1.4 release, you can download the Able Edition Release 2.]
Please read the “README.txt” file included in the archive, as it has some important notes and caveats for installing and using this viewer.
And, as Nick always says:
Disclaimer: This viewer is unofficial and although I am doing my best to make it better than the release viewer, it may contain extra bugs and you will have to trust me that there is no malicious code in it. Please also understand that it runs on the main grid with your real SecondLife account and inventory.
Of course, continuing my theme of fixing things that annoy me: megaprims.
Now, megaprims don’t annoy me. Megaprims are great–they’re incredibly useful for building all manner of things. What annoys me about megaprims is that if I make something with them, I’m not listed as the creator, because megaprims always have to be made by someone else. It’s great that there are lots of collections of freely-available megaprims, but well, they’re just not mine.
To address this problem, I produced the patch that can be found in JIRA issue VWR-7192: Hack to allow creating arbitrarily-sized prims in the viewer.
My patch allows people using the 1.19.1.4 version of the viewer (the latest officially-released version) to create their own prims of arbitrary size. And release candidate users aren’t left out either, thanks to the enthusiastic assistance of Jacek Antonell, who provided a patch for the 1.20 RC5 viewer.
The details and gotchas are in the JIRA issue already, so I won’t rehash them here, but at least there’s one more thing that doesn’t annoy me any more.
I’ve noticed a pattern in my work on the viewer, and that is most of the features I work on are so that I can control the ways in which people inworld can annoy me. My primary motivation for working on visibility muting was simply that 16 sqm ad farms are, well, damned annoying.
Sometimes I feel like this makes me sound as if I am a virtual old codger yelling at the damn kids to keep off his lawn. But really what it boils down to is my belief that if you are able to annoy me, I should be able to ignore you. So it is with yet another way to ignore something that motivated one of my recent viewer contributions.
Introducing JIRA issue VWR-6540: “Add options to selectively render attached lights and attached particle sources”. (An alternate title might be “Let people turn off bling attachments and facelamps”.)
This patch adds Advanced menu options to disable particle sources and light sources that emanate from attachments.
Attached particle sources can not only be annoying, but they also contribute a lot to the Avatar Rendering Cost (ARC), so if bling annoys you or you’re in a busy area, turning it off can help reduce visual lag.
Attached lamps (usually facelamps) can also be annoying, in that they can interfere with ambient or environmental lights that happen to be part of neaby builds. Mostly this is due to the fact that most people aren’t aware that there is a 6-light limit. I see a lot of people with 2 or 3 attached lights (although I’ve seen some people with 6 lights, and one time as many as 30! attached lights), and as they move around a sim, local stationary lights can flicker on and off depending on your location.
The patch is pretty simple; particles aren’t drawn if their source object is an attachment, and light sources whose source is an attachment are simply omitted from distance sorting when the viewer selects which ones to render.
It’s been ages since I’ve written anything here… Alas, work and real life concerns have prevented me from spending much time at all in SL, let alone working on the viewer.
The unfortunate consequence of my neglect of the viewer is that, at least for now, my work on visibility muting is on hold indefinitely. This is primarily due to the fact that the last version of my viewer to support those features was a pre-voice viewer (not to mention pre-Windlight, pre-Havok4, etc., etc.) and the underlying implementation details of the viewer have changed so dramatically that providing an updated viewer would be an enormous amount of work. I simply don’t foresee having enough time to dedicate to doing that work for now.
I am trying to make some time for smaller, incremental improvements to the viewer. I’ve got a couple of them in the works right now, and when I have a moment I’ll write about them a bit here.
Cheers!
Hello! I am still busily working away at the next release of the Able Edition viewer with improvements to the Mute Visibility functionality. I’ve discovered a couple of problems with how my new viewer handles sim crossings; namely, that it handles them rather poorly.
I have a good idea of the root cause of the troubles, but I don’t want to release a new viewer until I’ve gotten these last couple of bugs fixed. I should also note that this upcoming release will still be based on version 1.18.0.6 of the official viewer, and will not incorporate voice support (which is present in 1.18.1.2).
Migrating the Mute Visibility changes to the latest voice-enabled viewer will take some time, and I want to make at least one more release before updating to the latest official viewer source. I had originally intended to make build 41573 of my viewer available this past weekend, but, alas, the sim crossing problems squashed that notion. Time permitting, I will have a new release this coming weekend.
Nothing makes testing and debugging a more frustrating experience than not being able to reliably reproduce a bug. It’s this exact reason that Torley asks quite rightly that people put as much specific detail into their JIRA bug reports as possible. The more details, the better the chance that someone at LL will be able to consistently cause the bug in question to occur.
This is an essential part of debugging: it’s impossible to investigate the cause of a bug without being able to observe it occur “in the wild”, and the more observations of the bug that can be made, the better the chances of determining the root cause, and ultimately producing a fix for the problem.
So it is to you, my brave and helpful testers, that I come looking for your assistance in tracking down a few nefariously difficult bugs in the Able Edition. I am asking for help because I have been unable to reproduce these bugs myself, and so I have very little chance at being able to fix them.
Here are the Frustrating Four:
If you have seen any of these bugs occur while using the Able Edition viewer, please let me know! The more information you can provide, the better. For example:
Even if these problems don’t happen to you, that would still be helpful to know, along with some information about the kind of system you’re using. Feel free to post here, or IM me inworld, or email me with any information you have that might be helpful.
Thank you all very much for your help!