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.
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!
I know I haven’t posted here recently. Unfortunately, my first life has been consuming all of my free time. Never fear, though — I’m hard at work at the next build.
As a quick teaser, the biggest new feature wil be that Parcel muting will properly mute objects in any parcel, regardless of its geometry. As a bonus, this new behavior will be retroactive, so any parcel mutes you already have will be automatically updated to take advantage of this.
And of course, there will still be bug fixes. Some troublesome bugs will hopefully be squashed for good this time around.
I get a warm and fuzzy feeling when a bug can be fixed with a minimum of fuss. Simple changes are easier to write, easier to test, and much less likely to introduce new problems into the mix.
Here’s an almost quintessential example. VWR-1460: Can not see permissions of objects in Buy Contents window when item has long name. This is a pretty annoying problem. It’s made worse by the fact that, while you can resize the “Buy Contents” window, the columns in the window don’t resize along with the window. This completely defeats the purpose of having the window be resizable in the first place.
The fix is an obvious one: Prevent the window from being resizable.
No, no, no, I’m just kidding. That’s the obvious and evil answer — it addresses the issue, but doesn’t actually fix the problem. The real answer is to make the column with the item name and permission information actually grow and shrink along with the window.
The patch to fix this problem is simplicity itself:
— floater_buy_contents.xml 2007-07-11 15:19:48.000000000 -0400
+++ floater_buy_contents.xml 2007-07-19 16:28:57.109375000 -0400
@@ -14,7 +14,7 @@
follows=”left|top|right|bottom” height=”148″ left=”15″ mouse_opaque=”true”
multi_select=”false” name=”item_list” width=”281″> <column name=”icon” width=”16″ />
- <column name=”text” width=”300″ />
+ <column name=”text” relwidth=”1.0″ />
</scroll_list>
<text bg_visible=”false” border_drop_shadow_visible=”false” border_visible=”false”
bottom_delta=”-28″ drop_shadow_visible=”true” follows=”left|right|bottom”
That’s right, it’s just a one-line change. In fact, you don’t need to recompile the viewer to fix this problem at all! Anyone can fix it. Here:
<column name="text" width="300" />
<column name="text" relwidth="1.0" />
Congratulations, you’ve patched your Second Life viewer. Well done!
While my Mute Visibility stuff is still in testing, I’ve submitted two smaller patches to JIRA:
If you have any comments or questions about either of these, let me know!
Now, it’s time for sleep…
Nicholaz talked about some handy dandy viewer startup options, and there’s one option that I find particularly useful:
-cooperative [ms]
- yield some idle time to local host
The SL viewer is a notoriously over-eager processor hog, and on my poor machine it’s nearly impossible to do anything else if SL is running. The cooperative option helps a bit, by forcing the viewer to give back some of the processor time it would normally use.
I find using “-cooperative 1″ (which means that SL will regularly give back 1 millisecond of time) helps noticeably with the responsiveness of other applications. YMMV, of course, and I don’t recommend using a value higher than about 3 or 4, or your SL experience will become significantly degraded.