During the process of getting to the bottom of yesterday's bizarre mesh problem I got to see a really handy script in action. It dumped massive amounts of information about the mesh object it was dropped into (most of it went right over my head -- there's still a lot I need to learn about how mesh works and reacts in-world and in the viewer). One handy bit of information it gave was the distances at which the different LOD switches would happen.
I like to think I have a fairly good feel for how the different LODs for a mesh should look, and indeed when I can even leave them out. In some situations I will leave out the lowest and low LODs if I feel that they'll never be seen (although I've noticed that the lowest can often be seen very close when an object first comes into view, or first comes back into view after being hidden by another object, or looked away from; but that's a different story). This can, of course, save a ton of land impact. So normally I just mesh away, upload, make sure my viewer's RenderVolumeLODFactor is set to no more than 2 and then cam around and away like crazy and see how the object reacts and looks. This has generally served me well.
Fact is though, as is detailed in Beq's article in this issue of Prim Perfect, there's an actual calculation that can be done to know exactly what the distances are. That's just too handy and some hard numbers will always trump a vague feel. So, given that, I took what's given on the Wiki and wrote the following script to give the bare minimum information.
Hopefully that's useful to someone else too.
Showing posts with label Viewers. Show all posts
Showing posts with label Viewers. Show all posts
2015-04-03
2015-02-18
DoF glitch
These days I'm running with a setup that can handle ALM and related things rather well. As such I'm still enjoying the novelty of playing with things like materials (not that I'd not experienced that before -- it's just that ALM would impact my FPS so bad that I could only really play with it in a static environment) and, at the moment, depth-of-field.
Earlier on I was messing about in the workshop, taking some photos with the Z&A logo behind me, while toying with the DoF settings (and trying to get the hang of how to set the point of focus and have it stay there, etc, especially in flycam mode).
While camming around, I noticed this:
Curious "halo" of non-blurred background hovering over my head. Very strange. Well, not so strange when you view transparent...
(yes, my hair does generally need 1/2 region to itself). Turns out that it's some fun clash with the background and an invisible mane on the head harness.
And I thought this sort of glitch had been left behind when we dropped the invisiprim hack. ;)
Earlier on I was messing about in the workshop, taking some photos with the Z&A logo behind me, while toying with the DoF settings (and trying to get the hang of how to set the point of focus and have it stay there, etc, especially in flycam mode).
While camming around, I noticed this:
Curious "halo" of non-blurred background hovering over my head. Very strange. Well, not so strange when you view transparent...
(yes, my hair does generally need 1/2 region to itself). Turns out that it's some fun clash with the background and an invisible mane on the head harness.
And I thought this sort of glitch had been left behind when we dropped the invisiprim hack. ;)
2015-01-13
The crosshair obsession
There's many things about how people behave in-world that confuse and fascinate me and one of them is their reactions to crosshairs. As I'm sure most people know, some viewers (Firestorm anyway, and Pheonix and Emerald before it -- I don't actually know if any other viewers support the feature as I seldom use them) have a facility where you can have "crosshairs" on screen that show you where people's cameras are focused. It's a feature I've used as long as I've used viewers that support it and my main use is idle curiosity (although sometimes it's useful to know when someone's observing me working in the workshop, that can be a handy heads-up to a possible incoming IM or, rarely, a workshop invasion by someone who doesn't quite understand that privacy is a request that involves both parties).
A little earlier today I saw someone's profile (actually, there's another blog post to be had: people who get upset that people might be looking at their profile) that listed "crosshairs" as a big dislike of theirs. Not that crosshairs exist, that wasn't the complaint. The complaint was about other people having their crosshairs on them.
I find this utterly bizarre. Here's why:
What's even worse is people who think they fully understand how the crosshairs work and then get annoyed at people for all the wrong reasons. I was once at a dance and one avatar there had very obviously gone afk -- there was no response from them when anyone tried to speak to them and they never moved. Someone else, however, started loudly and publicly berating them for lying and really being at their keyboard and just watching people without taking part.
Their evidence that this was the case? The afk avatar's crosshairs kept jumping from person to person. It's true too. The afk avatar's crosshairs were jumping all around the room. But it wasn't their doing and it wasn't under their control. Crosshairs have a colour scheme that tells you what the camera is doing and why it's doing it. In this case the crosshairs were a light grey and were always jumping to the last avatar or object that had spoken. This is the "autolisten" focus that happens to every avatar.
It's hard not to view all of this as people whose approach to enjoying Second Life involves a portion of "I'm going to manufacture offence at people enjoying the visuals of a very visual medium". Really, if knowing what people are doing bothers you so much turn the bloody feature off, and understand that even when you've got it turned on people will be doing it anyway without your knowledge.
A little earlier today I saw someone's profile (actually, there's another blog post to be had: people who get upset that people might be looking at their profile) that listed "crosshairs" as a big dislike of theirs. Not that crosshairs exist, that wasn't the complaint. The complaint was about other people having their crosshairs on them.
I find this utterly bizarre. Here's why:
- If it worries and bothers you that someone might actually have their camera focused on you why turn on crosshairs in the first place? Just turn them off and live in blissful ignorance.
- Following on from that: you do realise that people can be following you and watching you and their crosshairs won't be showing, right? There's at least 3 methods I can think of:
- People can turn off the transmission of the data that lets your viewer know where their camera is focused.
- People can have the data transmission turned on and anchor their camera on something else but position it so that they're actually watching you.
- Flycam! Anyone using a 3D mouse or other controller that works well with flycam mode can have their crosshairs in front of themselves but can be watching you -- possibly from many thousands of meters away.
- What's so terrible about being seen anyway? If you've spent a good amount of money on your avatar and made it good to look at why wouldn't you want people looking at you in a public space? Isn't it actually a compliment to see those crosshairs wandering all over your avatar?
What's even worse is people who think they fully understand how the crosshairs work and then get annoyed at people for all the wrong reasons. I was once at a dance and one avatar there had very obviously gone afk -- there was no response from them when anyone tried to speak to them and they never moved. Someone else, however, started loudly and publicly berating them for lying and really being at their keyboard and just watching people without taking part.
Their evidence that this was the case? The afk avatar's crosshairs kept jumping from person to person. It's true too. The afk avatar's crosshairs were jumping all around the room. But it wasn't their doing and it wasn't under their control. Crosshairs have a colour scheme that tells you what the camera is doing and why it's doing it. In this case the crosshairs were a light grey and were always jumping to the last avatar or object that had spoken. This is the "autolisten" focus that happens to every avatar.
It's hard not to view all of this as people whose approach to enjoying Second Life involves a portion of "I'm going to manufacture offence at people enjoying the visuals of a very visual medium". Really, if knowing what people are doing bothers you so much turn the bloody feature off, and understand that even when you've got it turned on people will be doing it anyway without your knowledge.
2015-01-06
More prim/FS/PI oddness
A little earlier I was setting up this week's releases in the shop. As usual we normally set the boards up in the workshop (or, in this case, out on the build platform in front of the workshop seeing as how there was rather a lot of them this time) and then, when I'm ready to move them to the shop, I pick a point in the shop and paste the coordinates into each of the boards to send them down.
Keep in mind the workshop is a couple of km above the shop.
So I send all 8 boards down and then take the TP pad down to the shop. They're not there! I go back up to the workshop and they're still up there! So I send them down again, go down after them and... they're not there! This time I head back up to the workshop and also log the shop alt in on the last version of Firestorm that doesn't have Project Interesting as part of it.
Here's what I see in Firestorm 4.6.9:
Keep in mind that it's the bottom row I'd sent down, yet they appeared to be still up on the build platform. Now, the same scene as seen at the same time by the shop alt you can see in the picture above:
And, sure enough, when I sent him down to the shop the boards I'd sent down were down there, for him.
I relogged to find the boards in the shop too.
I give in...
Keep in mind the workshop is a couple of km above the shop.
So I send all 8 boards down and then take the TP pad down to the shop. They're not there! I go back up to the workshop and they're still up there! So I send them down again, go down after them and... they're not there! This time I head back up to the workshop and also log the shop alt in on the last version of Firestorm that doesn't have Project Interesting as part of it.
Here's what I see in Firestorm 4.6.9:
Keep in mind that it's the bottom row I'd sent down, yet they appeared to be still up on the build platform. Now, the same scene as seen at the same time by the shop alt you can see in the picture above:
And, sure enough, when I sent him down to the shop the boards I'd sent down were down there, for him.
I relogged to find the boards in the shop too.
I give in...
2015-01-02
Firestorm, Interesting and a RLV(a) issue?
I'll start out by making it very clear that this is nothing more than me jotting down something I found and noting my internal speculation about the causes. What I'm thinking (and this post is just me thinking out loud) could be (likely is) completely wrong; but I think it's worth noting down anyway.
At the moment I'm working away on building the new range of Z&A RLV cells while retiring the old ones. Given that they all contain the same script engine there's not a lot of scripting to be doing with that. Sure, there's the odd cell-specific plugin to write here and there but generally nothing I'd call "fun". The bulk of the work is prim-flinging and meshing, something I really enjoy, but it's not scripting, which I really enjoy.
A few days back, when I suddenly couldn't fling prims around so well, I did what I often do in that situation: I rezzed out a cube, got cosy with it and started scripting. This time the idea was to finally do a complete re-write of another early Z&A product to make it better and different. One of the RLV API features it makes use of is the @sit command. While working on that bit of code I decided to have a play and see just how far away (on a region) an object can be before the force sit fails.
[Caution, vague non-technical terms follow]
Keep in mind, at this point, that objects exist in two places in SL. They exist on the server and so exist as things that can be seen by scripts (because scripts live and run server-side). They also exist client-side in the sense that there's a list of "stuff" your viewer knows exists at any given time. Hence the reason why it's always suggested that people have sensible draw distances otherwise you end up potentially wasting a lot of memory and bandwidth loading up lots of objects and textures and the like that you can't really "see".
In the script I was toying with I check that any given object that is a potential sit target actually exists. Of course, the object my script is in and the object I'm verifying might be a few thousand meters apart but the script can still get information about it. RLV, on the other hand, being a body of code that exists only in the viewer, can presumably only ever deal with objects known to the viewer at any given time. Given these facts I sort of assumed that @sit might fail for objects not in draw distance.
Turns out it's a little more complex than that.
Having satisfied my curiosity that things near (the avatar/camera) can be @sit targets and things a long way away can't be (in my case a handful of things in the workshop, where I was stood, vs a chair in Mistress' house, which is about 2km away from the workshop) I got on with writing the code.
Yesterday, while doing some testing, I noticed a very curious thing. One of the target objects, which was near me (and well within my draw distance, about 33m away from where I'd have been stood when the @sit request was sent), just wasn't working. Or, more to the point, the @sit request was coming back as "ok" from my relay but I wasn't being sat.
After double-checking the code I then turned on RLVa debug messages in Firestorm and saw messages like this:
This is the point at which I started to suspect that it might be related to Project Interesting. I won't claim to know anything about how PI works other than what has been mentioned at a high level, but one thing I seem to recall reading is that it tries to do a good job of only loading/holding details of objects you can actually see. So an unobscured object in a scene, that's on the very edge of your draw distance, will be known to the viewer. On the other hand an object close by but obscured by other things won't be.
I guess you can see where my thinking was going at this point: like I said, the problem object, although only 33m away, was obscured by a floor and a wall from my location.
So, to test this idea (that it was about things being obscured, not that it's PI directly to blame), I made a little test rig on the platform outside the workshop. First I made a 3-prim object like this:
The blue bar is the root and is called "Force Sit". The two arrows are named with the UUID of two objects 23m either side of the object. Inside the root is the following code:
The idea is simple: stand at the arrows and click an arrow to be force sat on the object that's in that direction. The difference between the two objects is that one of them is in the clear while the other is obscured:
by two hollowed out cubes, one inside the other:
Initial testing never had a failure. But, I'm guessing, my viewer would "know" about the target object even when obscured and wouldn't bother dumping the data when it was fairly close by. Even heading down to the ground, walking about, and coming back up didn't make a difference. It all still just worked.
So I decided to leave it alone, all sat outside the workshop, and test it again the next time I logged in. Which I did this morning.
I got into the workshop, walked out onto the platform, detached my camera from my avatar using flycam so that my camera would stay about 38m from the arrows and about 45m from each of the target objects, and did the test.
First I touched the green arrow, which would attempt to force sit me on the object that I could see. That worked just fine.
Next I touched the red arrow, which would attempt to force sit me on the object that I couldn't see as it was inside the boxes. Nothing. I didn't move. One again I turned on RLVa debug messages and, sure enough...
It still failed. I then raised and tilted a little more until just one corner of the object was visible:
...and this time the test worked. I was force sat on the object inside the box.
That seemed to pretty clearly demonstrate it: object distance from your avatar, or your camera position, isn't the only thing that will affect how a @sit works -- it's also about if the object in question is obscured.
Keep in mind too, as mentioned above, that a relay will still reply that the operation worked "ok", but the avatar won't be sat and internally the sit will be seen as a failure (something that can of course be overcome by use of @getsitid).
The point of all of this? Well, like I said at the start, there's no actual conclusion to this; I just felt the need to document a curious problem that I'd run into and how I looked into it and what I found. It feels like it's something related to what Project Interesting has done although, of course, I'm not sure. I've also not tested this (so far) with any viewer other than Firestorm 4.6.9.
What I do know is that, if and when this code becomes a released product, this effect is something I might need to note in the documentation. People might see the product work fine on some victims but not on others and there'll be no obvious reason why this is the case.
At the moment I'm working away on building the new range of Z&A RLV cells while retiring the old ones. Given that they all contain the same script engine there's not a lot of scripting to be doing with that. Sure, there's the odd cell-specific plugin to write here and there but generally nothing I'd call "fun". The bulk of the work is prim-flinging and meshing, something I really enjoy, but it's not scripting, which I really enjoy.
A few days back, when I suddenly couldn't fling prims around so well, I did what I often do in that situation: I rezzed out a cube, got cosy with it and started scripting. This time the idea was to finally do a complete re-write of another early Z&A product to make it better and different. One of the RLV API features it makes use of is the @sit command. While working on that bit of code I decided to have a play and see just how far away (on a region) an object can be before the force sit fails.
[Caution, vague non-technical terms follow]
Keep in mind, at this point, that objects exist in two places in SL. They exist on the server and so exist as things that can be seen by scripts (because scripts live and run server-side). They also exist client-side in the sense that there's a list of "stuff" your viewer knows exists at any given time. Hence the reason why it's always suggested that people have sensible draw distances otherwise you end up potentially wasting a lot of memory and bandwidth loading up lots of objects and textures and the like that you can't really "see".
In the script I was toying with I check that any given object that is a potential sit target actually exists. Of course, the object my script is in and the object I'm verifying might be a few thousand meters apart but the script can still get information about it. RLV, on the other hand, being a body of code that exists only in the viewer, can presumably only ever deal with objects known to the viewer at any given time. Given these facts I sort of assumed that @sit might fail for objects not in draw distance.
Turns out it's a little more complex than that.
Having satisfied my curiosity that things near (the avatar/camera) can be @sit targets and things a long way away can't be (in my case a handful of things in the workshop, where I was stood, vs a chair in Mistress' house, which is about 2km away from the workshop) I got on with writing the code.
Yesterday, while doing some testing, I noticed a very curious thing. One of the target objects, which was near me (and well within my draw distance, about 33m away from where I'd have been stood when the @sit request was sent), just wasn't working. Or, more to the point, the @sit request was coming back as "ok" from my relay but I wasn't being sat.
After double-checking the code I then turned on RLVa debug messages in Firestorm and saw messages like this:
Antony's Collar: failed: @sit:{uuid}=force (invalid option)(where {uuid} was the UUID of the object, of course). Now, the object in question wasn't in my direct line of sight; it was obscured by a floor and a wall. But, like I say, it was just 33m away from me. Unsure what was going on I cammed out to it, grabbed the UUID of it again and double-checked and, sure enough, it was the right UUID. I tested again and it worked without me having changed anything in the code!
This is the point at which I started to suspect that it might be related to Project Interesting. I won't claim to know anything about how PI works other than what has been mentioned at a high level, but one thing I seem to recall reading is that it tries to do a good job of only loading/holding details of objects you can actually see. So an unobscured object in a scene, that's on the very edge of your draw distance, will be known to the viewer. On the other hand an object close by but obscured by other things won't be.
I guess you can see where my thinking was going at this point: like I said, the problem object, although only 33m away, was obscured by a floor and a wall from my location.
So, to test this idea (that it was about things being obscured, not that it's PI directly to blame), I made a little test rig on the platform outside the workshop. First I made a 3-prim object like this:
The blue bar is the root and is called "Force Sit". The two arrows are named with the UUID of two objects 23m either side of the object. Inside the root is the following code:
The idea is simple: stand at the arrows and click an arrow to be force sat on the object that's in that direction. The difference between the two objects is that one of them is in the clear while the other is obscured:
by two hollowed out cubes, one inside the other:
Initial testing never had a failure. But, I'm guessing, my viewer would "know" about the target object even when obscured and wouldn't bother dumping the data when it was fairly close by. Even heading down to the ground, walking about, and coming back up didn't make a difference. It all still just worked.
So I decided to leave it alone, all sat outside the workshop, and test it again the next time I logged in. Which I did this morning.
I got into the workshop, walked out onto the platform, detached my camera from my avatar using flycam so that my camera would stay about 38m from the arrows and about 45m from each of the target objects, and did the test.
First I touched the green arrow, which would attempt to force sit me on the object that I could see. That worked just fine.
Next I touched the red arrow, which would attempt to force sit me on the object that I couldn't see as it was inside the boxes. Nothing. I didn't move. One again I turned on RLVa debug messages and, sure enough...
Antony's Collar: failed: @sit:{uuid}=force (invalid option)I then raised my camera and tilted it down a little until I could almost, but not quite, see the target object:
It still failed. I then raised and tilted a little more until just one corner of the object was visible:
...and this time the test worked. I was force sat on the object inside the box.
That seemed to pretty clearly demonstrate it: object distance from your avatar, or your camera position, isn't the only thing that will affect how a @sit works -- it's also about if the object in question is obscured.
Keep in mind too, as mentioned above, that a relay will still reply that the operation worked "ok", but the avatar won't be sat and internally the sit will be seen as a failure (something that can of course be overcome by use of @getsitid).
The point of all of this? Well, like I said at the start, there's no actual conclusion to this; I just felt the need to document a curious problem that I'd run into and how I looked into it and what I found. It feels like it's something related to what Project Interesting has done although, of course, I'm not sure. I've also not tested this (so far) with any viewer other than Firestorm 4.6.9.
What I do know is that, if and when this code becomes a released product, this effect is something I might need to note in the documentation. People might see the product work fine on some victims but not on others and there'll be no obvious reason why this is the case.
2014-12-24
Two root prims
Ever seen an object with two root prims? No? Here's one...
I'd linked together two smaller linksets to create the one object. I'd "dropped" the edit of them and then went to edit again. Both appeared not to have linked together. Only, they had. Both had the same (higher) LI count in the edit floater but both appeared to be different linksets with different roots.
And how did I fix it? I changed groups, moved my camera a bit, selected something else and then selected one of the problem objects again and...
Frustratingly when it was a "two root" object both of the original linksets could be moved on their own without apparently affecting the other. Further attempts to link them (again) made no difference. I've had this happen so many times before that I'm very careful about this now (although I still get caught out now and again -- last week this sort of mixup partially resulted in me deleting a build I'd been working on for a few hours; thankfully I had backups and could also restore from trash to last position).
This is a great example of why I wouldn't recommend the latest versions of Firestorm (or any other viewer that still contains this sort of interest list bug -- which I assume it is). Many of the other improvements make the later versions worth having but you have to be very vigilant while building as you're going to be fighting the viewer at times.
The viewer (and the region, depending on what's happening) will lie to you.
I'd linked together two smaller linksets to create the one object. I'd "dropped" the edit of them and then went to edit again. Both appeared not to have linked together. Only, they had. Both had the same (higher) LI count in the edit floater but both appeared to be different linksets with different roots.
And how did I fix it? I changed groups, moved my camera a bit, selected something else and then selected one of the problem objects again and...
Frustratingly when it was a "two root" object both of the original linksets could be moved on their own without apparently affecting the other. Further attempts to link them (again) made no difference. I've had this happen so many times before that I'm very careful about this now (although I still get caught out now and again -- last week this sort of mixup partially resulted in me deleting a build I'd been working on for a few hours; thankfully I had backups and could also restore from trash to last position).
This is a great example of why I wouldn't recommend the latest versions of Firestorm (or any other viewer that still contains this sort of interest list bug -- which I assume it is). Many of the other improvements make the later versions worth having but you have to be very vigilant while building as you're going to be fighting the viewer at times.
The viewer (and the region, depending on what's happening) will lie to you.
2014-12-22
Firestorm 4.6.9
For quite some time after updating to Firestorm 4.6.7 I've being meaning to downgrade back to 4.6.1. The main reason was two rather annoying bugs (only one of which could be called Firestorm's fault, as far as I can tell) that did degrade the in-world experience. The worst, of course, is the Interest List related bug that actually messes with in-world objects and so affects people on otherwise unaffected viewers.
So, last night, I did the sensible thing and.... updated to 4.6.9. Yeah, I know, what was I thinking?
The main reason for this was that 4.6.9 has some features I thought sounded really useful, especially some that would be really useful when helping other people out with things Firestorm-related.
Often I'll be reading a non-viewer related group and someone will be having some sort of problem or wondering about some sort of in-world thing and I'll be sat here thinking "there's a Firestorm setting for that!", followed by some frantic searching for the setting (thanks to Firestorm's setting backup/restore system I seldom need to venture into settings so easily forget what's where). Or there'll be something that can be done down in the Advanced or Develop menus.
Firestorm 4.6.9 has this nicely solved for menus...
which means you can do this:
and the menus narrow down to just the options that match:
The choice of colours to signify hits is questionable, at least in the theme/skin I'm using, but it works and works well (why the hits need to be highlighted when the menus are filtered anyway is something I can't quite work out).
The preferences dialog is just as handy now too (and here the highlighting makes more sense):
As well as the above, this was also of great interest to me:
While I've only once, as far as I can recall, felt the need to ban an avatar from a group I own, finally having access to this "just in case" is a good thing. Hopefully I'll never need to use it.
Another thing I'm really liking is the new columns in the radar:
The notes column (see the column with an N in it for Zanda?) is especially worth having. I'm an avid user of avatar notes; I generally use it to keep track of important stuff about friends, make notes about interactions with customers and, sometimes, record details of a concerning incident with avatars who might be causing trouble. Given that it's really handy to be able to see at a glance, when you land at some location, who you might have made notes for. Really nice touch.
There's one final little change (that I've noticed and that I find useful -- I'm only a few hours into using this relase so this is all I've disocvered that's useful to me so far) that's worth a note:
The two little arrows highlighted with the red arrow can be used to navigate through prims in a linkset when you have "Edit linked" ticked. For a long time I've been used to using Ctrl-. and Ctrl-, to do this but, sometimes, reaching for the keyboard to press a key combination like that can be a pain -- especially if you've got one hand on your trackball and the other on a SpaceNavigator (as I sometimes find when I'm copying/pasting data throughout a linkset).
Another not-obviously-visible change in this release is the fix of the really annoying "textures get all funky when loading after you've done a texture refresh during a login session" bug. That one was getting seriously annoying to the point that I'd do everything I could to avoid doing a texture refresh. I can now finally refresh all the things without worrying.
So, all in all, not a bad update. There's a good number of useful things to be had.
One downside is that there's been no update to RLVa to bring it in line with the latest version of the RLV API so, for now, the new vision control APIs can't be used by a lot of people (if this ever rolls out in Firestorm there's a few Z&A products I want to update to make use of this; until then though it doesn't seem worth the trouble).
Another downside is that the Interest List bug still hasn't been fixed (it's marked in the JIRA as fixed for 5.0 from what I can see). This alone means that, if anyone were to ask me if it's worth updating, and if they're on 4.6.1, I'd answer with an emphatic no. I consider this to be a near-showstopper when it comes to bugs and it's caused me no end of problems as a builder. As it is I've managed to find workarounds for most of the issues it's introduced and I've learnt to be very careful about how I approach certain aspects of building, but the fact remains that 4.6.7 and 4.6.9 (along with other project Interesting viewers, this has been demonstrated as an issue that affects other viewers) actually break content. Unless you must upgrade I'd hang on for now.
Given Firestorm's "only three active versions and then we block" policy I really hope the next release is the one that fixes this.
2014-12-12
Viewer freezing when detecting hardware
This week's round of Windows updates appears to have brought me an interesting problem, and a bit of searching on Google suggests it's "just me" rather than a widespread issue.
Wednesday night into Thursday morning my desktop machine did an automated Windows update (yes, I do let it do that -- I find I'm really lazy about letting them apply manually if I don't). No big deal, it's happened many times in the past. I get to the machine the following morning, log myself in, go make my coffee (I know to do this first as I indirectly get alerts on my Android devices that let me know this has happened) and then come back and set things up as I like them and do my usual quick viewer login check.
This time though it didn't go so well. It just sat here:
Not good. I then tried a different viewer, and then a different one. Same result with them all. The next thing I did, in the best IT Crowd tradition, was turn it off and on again (or, to be more precise, did a proper restart via the OS). That seemed to fix it. I could start Firestorm and all the other viewers and everything was fine.
So I went about my normal work day and then, in the late afternoon, went in-world to do a few things. Everything worked fine. I probably ran up the viewer and logged in 3 or 4 times in total. I headed off to make dinner and deal with some general RL things and came back a couple or so hours later. Ran up Firestorm and... it froze detecting hardware again!
This time I did a bit of searching to see if anyone else was reporting a similar issue and nothing turned up. I found sporadic reports of similar issues over the years, but every single case was isolated and they all appeared to be down to video driver issues (that I could see). I did notice however that a workaround in each case was to use the "-noprobe" command line option on the viewer to get going.
So, I tried that, and it worked like a charm. Suddenly Firestorm was working just fine. One wrinkle however is that opening "Help >> About" causes the viewer to freeze and I have to kill the process -- presumably this is because the about dialog again probes the machine to find the video card and driver details.
At this point I decided to update my video drivers. This is something I'm normally pretty lax about so it was a good enough problem to prompt me to do this. This in itself didn't go well to start with in that the install kept hanging at various points. In the end though, after a few attempts, the install went through.
At this point viewers were starting up just fine again (without "-noprobe" on the command line) and everything was looking okay with the new driver. In fact, while I wouldn't say general performance was any different, I did notice that turning on advanced lighting didn't seem to have much of an impact on performance.
Normally, if I try and use ALM, I find that my FPS drops by half or even more (even with shadows turned off). With this change I'm finding that the FPS drops by just a small amount rather than by 50% or more. I even found that if I turned on full shadows it had little extra impact! I need to test it some more but I think I might just have given my ageing graphics card a little extra lease of life.
Anyway, at this point, everything was looking good. Viewers were starting and I had a shiny new driver installed that seemed to be improving the performance of the more stressful aspects of a SL viewer. All was good.
I get to my machine this morning and run up Firestorm again to check if everything was still okay and... same problem. The viewer was frozen detecting hardware. So, whatever the issue was, it wasn't down to a mix of a Windows update and the graphics driver. It seems that whatever it is it's related to the uptime of the machine. After a reboot hardware can be detected just fine. After a significant number of hours this ceases to be the case.
So, for now at least, until I can find the actual cause of the problem, it looks like I'll have to run my viewer with "-noprobe" and be sure I never go anywhere near "Help >> About".
As a side note, as I was typing this, I noticed that Windows was telling me that there was yet another update available. Which is sort of odd. There's an update marked as important called KB3024777. Reading its details it seems its job is nothing more than to undo KB3004394 because it causes (unspecified) problems on Windows 7 SP1 -- which is what I'm running on my desktop. Perhaps these issues are related?
I'll install the update and see what happens.
Edit to add: Seems I'm not alone in this. I've just seen two other people mention the issue in the Firestorm support group. Not seeing any solutions offered at the moment (I don't think there's any support people around right now) but it's kind of heartening to know it's not just me.
Wednesday night into Thursday morning my desktop machine did an automated Windows update (yes, I do let it do that -- I find I'm really lazy about letting them apply manually if I don't). No big deal, it's happened many times in the past. I get to the machine the following morning, log myself in, go make my coffee (I know to do this first as I indirectly get alerts on my Android devices that let me know this has happened) and then come back and set things up as I like them and do my usual quick viewer login check.
This time though it didn't go so well. It just sat here:
So I went about my normal work day and then, in the late afternoon, went in-world to do a few things. Everything worked fine. I probably ran up the viewer and logged in 3 or 4 times in total. I headed off to make dinner and deal with some general RL things and came back a couple or so hours later. Ran up Firestorm and... it froze detecting hardware again!
This time I did a bit of searching to see if anyone else was reporting a similar issue and nothing turned up. I found sporadic reports of similar issues over the years, but every single case was isolated and they all appeared to be down to video driver issues (that I could see). I did notice however that a workaround in each case was to use the "-noprobe" command line option on the viewer to get going.
So, I tried that, and it worked like a charm. Suddenly Firestorm was working just fine. One wrinkle however is that opening "Help >> About" causes the viewer to freeze and I have to kill the process -- presumably this is because the about dialog again probes the machine to find the video card and driver details.
At this point I decided to update my video drivers. This is something I'm normally pretty lax about so it was a good enough problem to prompt me to do this. This in itself didn't go well to start with in that the install kept hanging at various points. In the end though, after a few attempts, the install went through.
At this point viewers were starting up just fine again (without "-noprobe" on the command line) and everything was looking okay with the new driver. In fact, while I wouldn't say general performance was any different, I did notice that turning on advanced lighting didn't seem to have much of an impact on performance.
Normally, if I try and use ALM, I find that my FPS drops by half or even more (even with shadows turned off). With this change I'm finding that the FPS drops by just a small amount rather than by 50% or more. I even found that if I turned on full shadows it had little extra impact! I need to test it some more but I think I might just have given my ageing graphics card a little extra lease of life.
Anyway, at this point, everything was looking good. Viewers were starting and I had a shiny new driver installed that seemed to be improving the performance of the more stressful aspects of a SL viewer. All was good.
I get to my machine this morning and run up Firestorm again to check if everything was still okay and... same problem. The viewer was frozen detecting hardware. So, whatever the issue was, it wasn't down to a mix of a Windows update and the graphics driver. It seems that whatever it is it's related to the uptime of the machine. After a reboot hardware can be detected just fine. After a significant number of hours this ceases to be the case.
So, for now at least, until I can find the actual cause of the problem, it looks like I'll have to run my viewer with "-noprobe" and be sure I never go anywhere near "Help >> About".
As a side note, as I was typing this, I noticed that Windows was telling me that there was yet another update available. Which is sort of odd. There's an update marked as important called KB3024777. Reading its details it seems its job is nothing more than to undo KB3004394 because it causes (unspecified) problems on Windows 7 SP1 -- which is what I'm running on my desktop. Perhaps these issues are related?
I'll install the update and see what happens.
Edit to add: Seems I'm not alone in this. I've just seen two other people mention the issue in the Firestorm support group. Not seeing any solutions offered at the moment (I don't think there's any support people around right now) but it's kind of heartening to know it's not just me.
2014-10-05
Interesting for the wrong reasons
At the moment I'm deep in the middle of doing organising things for The Femdom Hunt V (which is why I might not be blogging quite so much over the next couple of weeks). The job I'm working on right now is making up the final update pack for all the locations, which means making up the hunt objects (a shoe) that will be hidden at locations on the hunt. Each shoe needs to be individually named so, to make the job more manageable, I make a workarea that splits the shoes and packs up into groups of 10. Each one has a platform that starts out red and I change the colour to green as I do each batch. This means I can wander off and get a drink, or go browse the web for 5mins, or something, without losing my place.
After finishing the first round of edits to the objects all the platforms were green, as you'd expect. I then had cause to cam away for a moment and cam back. This is what I found:
That was me on Firestorm 4.6.7. Now compare the same view, seen at the same time, in Firestorm 4.6.5:
This is how it looked in 4.6.7 too before I cammed away and cammed back.
What you're seeing here is, I guess, an instance of FIRE-14394 (AKA BUG-7084) kicking in. It's easily the most blatant and obvious example I've experienced of it yet.
If I wasn't so busy with things right now I'd be finally downgrading Firestorm to 4.6.5. This bug (which isn't directly a Firestorm bug -- the same thing has been reproduced in the Lab's viewer) is too intrusive to be ignored. Heck, in a way, it also means that even the Lab's own viewer "violates" the shared-experience rule for viewers.
If you are thinking of updating your viewer to one that has the Project Interesting code in it I'd strongly suggest thinking twice about it.
After finishing the first round of edits to the objects all the platforms were green, as you'd expect. I then had cause to cam away for a moment and cam back. This is what I found:
That was me on Firestorm 4.6.7. Now compare the same view, seen at the same time, in Firestorm 4.6.5:
This is how it looked in 4.6.7 too before I cammed away and cammed back.
What you're seeing here is, I guess, an instance of FIRE-14394 (AKA BUG-7084) kicking in. It's easily the most blatant and obvious example I've experienced of it yet.
If I wasn't so busy with things right now I'd be finally downgrading Firestorm to 4.6.5. This bug (which isn't directly a Firestorm bug -- the same thing has been reproduced in the Lab's viewer) is too intrusive to be ignored. Heck, in a way, it also means that even the Lab's own viewer "violates" the shared-experience rule for viewers.
If you are thinking of updating your viewer to one that has the Project Interesting code in it I'd strongly suggest thinking twice about it.
2014-08-24
Firestorm 4.6.7 Update
Following on from my previous post about Firestorm 4.6.7 things with the odd lighting issue that I wrote about have moved on. Thanks to the JIRA I filed I had it confirmed by one of the Firestorm support people that it was, indeed, a real issue and that I wasn't alone in seeing it. Since then it's been filed on the Lab's JIRA and, from what I've been told, has been internally acknowledged as an issue.
At this point I would have been tempted to give up and roll back to 4.6.5 -- especially given that I've stumbled on an issue with textures and I think I might have found an irritation relating to RLV (although I still need to test that out and write it up). But one thing has stopped me.
On Saturday Mistress and I dropped in on Collarbor88. Normally this can be a difficult time. It's not unusual for us to go there and for me to not have loaded all of the vendor boards or displays after 1/2 hour (an issue that isn't just a C88 thing). This time, however.... the difference was really stark. Within 5 minutes I had pretty much the whole of the event loaded!
That alone, for now at least, is enough to keep me on 4.6.7. Of course, avatars took a little longer to load, and there was the usual hilarious assortment of not-yet-rigged clothing and body parts...
...but I see that as a good thing. It provides entertainment while everything else loads up. I kind of hope that issue never gets fixed. ;)
(although I do have to wonder why some people who make body parts and clothing do have to make them so damn large)
C88 itself was a real success with Mistress brining back an awful lot of demos. A good few of those demos, earlier today, turned into actual purchases. And one of those demos turned into a.... interesting turn of events for me. I won't say more now because I'll doubtless be blogging the full impact of this in the next day or so. ;)
At this point I would have been tempted to give up and roll back to 4.6.5 -- especially given that I've stumbled on an issue with textures and I think I might have found an irritation relating to RLV (although I still need to test that out and write it up). But one thing has stopped me.
On Saturday Mistress and I dropped in on Collarbor88. Normally this can be a difficult time. It's not unusual for us to go there and for me to not have loaded all of the vendor boards or displays after 1/2 hour (an issue that isn't just a C88 thing). This time, however.... the difference was really stark. Within 5 minutes I had pretty much the whole of the event loaded!
That alone, for now at least, is enough to keep me on 4.6.7. Of course, avatars took a little longer to load, and there was the usual hilarious assortment of not-yet-rigged clothing and body parts...
...but I see that as a good thing. It provides entertainment while everything else loads up. I kind of hope that issue never gets fixed. ;)
(although I do have to wonder why some people who make body parts and clothing do have to make them so damn large)
C88 itself was a real success with Mistress brining back an awful lot of demos. A good few of those demos, earlier today, turned into actual purchases. And one of those demos turned into a.... interesting turn of events for me. I won't say more now because I'll doubtless be blogging the full impact of this in the next day or so. ;)
2014-08-20
Firestorm 4.6.7
For me, SL viewers are like text editors: I hardly ever switch and once I've made a choice I'm comfortable with it takes a lot to entice me away (which reminds me, I really must write about how I fell in love with Sumblime Text and how I almost never use the in-world editor any more). On top of that, I almost never early adopt. When a new version comes out I tend to hold back and see how things go in general and then I update my backup machine first.
Only when I'm happy with everything and there's no annoying or showstopper bugs do I finally make the move.
And yet, for reasons I still can't figure out, I dived right in and installed Firestorm 4.6.7 within 24 hours of it being announced. On my main machine!
So far though it's mostly okay. I'd say rezzing is a bit faster and things do appear to show up in-world in a more logical order, but I have run into a couple of annoyances.
The first and most obvious one is that it appears to be causing lighting to misbehave. In our home, shop and workshop we use automatic lighting. You know the sort of thing, it detects if the SL Sun is up or not (as dictated by the region's daylight cycle) and turns the lights on and off.
Nothing clever, but it works and has been working for a good couple of years in different incarnations. But, suddenly, with the move to 4.6.7, the lights appear to be misbehaving (emphasis on "appear"). Both Mistress and I have noticed that the lights are sometimes on when they should be off, or off when they should be on. At first I thought something had gone wrong with the scripts or someone had somehow gained access to the menus (they're coded so only we can interact with them) but a quick bit of testing suggested otherwise.
The lights are coded so that the menu offers three options: On (as in always on), Off (as in always off) or Auto (on when night, off when day). They're normally always in Auto mode. If the light looks wrong and I use the menu to set them to Auto again they show in the right state.
Except.... sometimes they show in the right state, I'll look away, look back and they're wrong again.
As best as I can tell, at the moment, what appears to be happening is that some (all?) of the object's prim properties appear to bounce back to whatever state they were in when I first "saw" the object in that login session. The only properties I've noticed this with so far are PRIM_GLOW, PRIM_FULLBRIGHT and PRIM_POINT_LIGHT.
Further evidence that this appears to be viewer-related is the fact that if I'm looking at lights that are wrong I can relog and they appear right. Or if I'm looking at them and they're wrong I can log one of my test avatars in on a different machine and come look at the same light and it'll appear right to them (while still appearing wrong to me).
I've tried, and so far failed, to create a setup that recreates the problem in a controlled way. I've also asked in the support group but nobody else has knowingly experienced the same issue. Given the nature of this release (which is, in part, about caching object details and the like) it was suggested that it'd be a good idea to JIRA it.
So I did.
Another niggle I've noticed is that, on my mini-map, avatars seem to turn up at 0,0 (or, in some cases, waaaaaay of the region) a lot. And they appear to stay there until I can actually see them in world.
In the above image I'm way up in the sky in my workshop and Zanda and Black (the two shop bots) appear to be at 0,0,0 on the region. If I pop down to the shop they both snap into place. While this issue isn't exactly new in that I've had this happen before if my connection has been rather dodgy this is happening all the time now and only started post-upgrade.
I've not bothered to ask about this or document it just yet as I don't see it as being such a big deal, although I probably should some point soon. Again, it has the feel of being related to the "Project Interesting" changes that have taken place.
Those niggles aside though 4.6.7 seems to perform fine. No better than 4.6.5 but no worse either.
Only when I'm happy with everything and there's no annoying or showstopper bugs do I finally make the move.
And yet, for reasons I still can't figure out, I dived right in and installed Firestorm 4.6.7 within 24 hours of it being announced. On my main machine!
So far though it's mostly okay. I'd say rezzing is a bit faster and things do appear to show up in-world in a more logical order, but I have run into a couple of annoyances.
The first and most obvious one is that it appears to be causing lighting to misbehave. In our home, shop and workshop we use automatic lighting. You know the sort of thing, it detects if the SL Sun is up or not (as dictated by the region's daylight cycle) and turns the lights on and off.
Nothing clever, but it works and has been working for a good couple of years in different incarnations. But, suddenly, with the move to 4.6.7, the lights appear to be misbehaving (emphasis on "appear"). Both Mistress and I have noticed that the lights are sometimes on when they should be off, or off when they should be on. At first I thought something had gone wrong with the scripts or someone had somehow gained access to the menus (they're coded so only we can interact with them) but a quick bit of testing suggested otherwise.
The lights are coded so that the menu offers three options: On (as in always on), Off (as in always off) or Auto (on when night, off when day). They're normally always in Auto mode. If the light looks wrong and I use the menu to set them to Auto again they show in the right state.
Except.... sometimes they show in the right state, I'll look away, look back and they're wrong again.
As best as I can tell, at the moment, what appears to be happening is that some (all?) of the object's prim properties appear to bounce back to whatever state they were in when I first "saw" the object in that login session. The only properties I've noticed this with so far are PRIM_GLOW, PRIM_FULLBRIGHT and PRIM_POINT_LIGHT.
Further evidence that this appears to be viewer-related is the fact that if I'm looking at lights that are wrong I can relog and they appear right. Or if I'm looking at them and they're wrong I can log one of my test avatars in on a different machine and come look at the same light and it'll appear right to them (while still appearing wrong to me).
I've tried, and so far failed, to create a setup that recreates the problem in a controlled way. I've also asked in the support group but nobody else has knowingly experienced the same issue. Given the nature of this release (which is, in part, about caching object details and the like) it was suggested that it'd be a good idea to JIRA it.
So I did.
Another niggle I've noticed is that, on my mini-map, avatars seem to turn up at 0,0 (or, in some cases, waaaaaay of the region) a lot. And they appear to stay there until I can actually see them in world.
In the above image I'm way up in the sky in my workshop and Zanda and Black (the two shop bots) appear to be at 0,0,0 on the region. If I pop down to the shop they both snap into place. While this issue isn't exactly new in that I've had this happen before if my connection has been rather dodgy this is happening all the time now and only started post-upgrade.
I've not bothered to ask about this or document it just yet as I don't see it as being such a big deal, although I probably should some point soon. Again, it has the feel of being related to the "Project Interesting" changes that have taken place.
Those niggles aside though 4.6.7 seems to perform fine. No better than 4.6.5 but no worse either.
2014-04-14
If there's one thing I like about Firestorm 4.6.1...
...it's this:
While it was in the previous beta I never really got to enjoy it because that FS version broke a fairly important (to me) part of RLV. Having it in my "use every day, lots" version really makes a difference.
While it was in the previous beta I never really got to enjoy it because that FS version broke a fairly important (to me) part of RLV. Having it in my "use every day, lots" version really makes a difference.
2014-03-14
Editor font size in Firestorm 4.6.1
Yesterday, after I'd got all the business of a new product release out of the way, I decided to upgrade my copy of Firestorm. I'd being sticking with 4.4.2 because of a rather nasty bug in 4.5.1 that broke quite a few RLV toys and gadgets, including a couple I use a lot. Having tested 4.6.1 on a different machine to be sure that this issue had been fixed I knew it was mostly safe to make the switch (I could always go back if I hit a show-stopper).
The upgrade went pretty smoothly (all the better for Firestorm's rather awesome settings backup and restore system) and, for the most part, there were no horrible surprises. One obvious difference I did see is that water seems more blue and more milky now, at least on the default windlight -- that's something I want to look into more as it looks a little odd. Other obvious differences pretty much came down to things being done differently in the new version (the texture tab in the build floater being very different, for obvious reasons).
However, one thing really stood out because it was such a stark difference and because it's something I use a lot: the font in the script editor seemed so much smaller and so less readable. The editor's dialog has no setting for this, and neither does the general preferences. Kind of annoying.
A quick visit to Google later turned up this FS JIRA with a comment posted yesterday with a possible solution. Sure enough, a quick dabble in the fonts.xml file and an edit of the value for this:
later and I had a bigger script editor font. I still haven't found a size I'm delighted with, and the need to relog every time I want to try a new one is a bit of a pain, but I'm thankful that there is a way to change this. I'm sure I'll settle on a good size at some point soon.
It'd be great if this could be made a setting in the editor preferences.
The upgrade went pretty smoothly (all the better for Firestorm's rather awesome settings backup and restore system) and, for the most part, there were no horrible surprises. One obvious difference I did see is that water seems more blue and more milky now, at least on the default windlight -- that's something I want to look into more as it looks a little odd. Other obvious differences pretty much came down to things being done differently in the new version (the texture tab in the build floater being very different, for obvious reasons).
However, one thing really stood out because it was such a stark difference and because it's something I use a lot: the font in the script editor seemed so much smaller and so less readable. The editor's dialog has no setting for this, and neither does the general preferences. Kind of annoying.
A quick visit to Google later turned up this FS JIRA with a comment posted yesterday with a possible solution. Sure enough, a quick dabble in the fonts.xml file and an edit of the value for this:
later and I had a bigger script editor font. I still haven't found a size I'm delighted with, and the need to relog every time I want to try a new one is a bit of a pain, but I'm thankful that there is a way to change this. I'm sure I'll settle on a good size at some point soon.
It'd be great if this could be made a setting in the editor preferences.
2014-03-12
Stalled logins
For the past week or so I seem to be having an occasional problem with logging into Second Life. What happens is I'll hit the login button and I'm left staring at something like this (in Firestorm, in this case):
And that's it. It just sits there, never failing, never progressing. At least, it never has for as long as I've left it. If I then hit the "Quit" button and log in again almost every single time it'll log me right in without a hitch. A couple of times I've had it do this twice in a row, and it doesn't seem to be just a Firestorm problem as I've had it happen with METAbolt once too.
And that's it. It just sits there, never failing, never progressing. At least, it never has for as long as I've left it. If I then hit the "Quit" button and log in again almost every single time it'll log me right in without a hitch. A couple of times I've had it do this twice in a row, and it doesn't seem to be just a Firestorm problem as I've had it happen with METAbolt once too.
2014-01-21
Tools and stuff
Although I've often been amused by reading them I've never really been motivated to contribute to Strawberry Singh's Monday Memes thing. The reason is, mostly, time and the simple fact that they're normally on subjects that I don't have much to contribute to (or if I do I'd want to spend way too much time on it).
However, via Inara Pey's entry, I realised that this was one that's close to my heart and that I'd have some fun with it. So, here goes... (warning, there's a lot of self-made stuff here -- this isn't an attempt at self-promotion, it's just that I'm a programmer by trade and we have a horrible habit of reinventing wheels when faced with a problem because.... well, it's fun)
First off, here's my usual viewer view of the world:
As you can see, I run Firestorm. On my main machine I use the last stable version and on my laptop I have the beta (I've not upgraded the main machine due to a rather annoying bug that impacts on one aspect of RLV). While I have a good number of other viewers installed for testing purposes Firestorm is my work environment of choice.
I try and keep it as uncluttered as I possibly can. When I'm busy it's normally covered with an inventory window or two, a build floater, the conversation window and more often than not one or more script editor windows. But when I'm wandering around I try and keep the view nice and clean.
I only have the following HUDs on all the time. First there's my Sub-Allowance HUD:
I guess this should be considered less a tool for me and more a tool for Miss Vila. The same can be said of the Submission HUD:
Both of those are locked in place and can't be removed. So, leaving RLV HUDs aside (well, there's one more to come, sort of), the only other two HUDs I use a lot are as follows: first there's the OpenCollar Submissive AO...
Although Firestorm has a builtin AO, which actually works really well (I use it with great effect on a different avatar), I like that the OC AO has tight integration with the OC collar (my collar is scripted with OC).
Finally, to help stop the non-locked HUDs being knocked off during outfit changes, I have my HUD Locker:
And that's pretty much it when it comes to tools that are HUDs. Given that a lot of my in-world time is either time spent with Miss Vila or time spent working in the workshop I don't have much need for anything else. My other useful tools are all about knowing what's going on in-world and knowing the state of our region.
So, this is where I wander away from the viewer-oriented stuff and talk more about how I try and stay informed about what's going on. One really important tool, for me, is the Linden Lab grid status blog. There's two really important and useful things on there. The first is the calendar of scheduled server releases:
I use Google Calendar (on the desktop, on my phone, on my tablet) so I subscribe to the above. That way there's absolutely no reason why I should ever need to guess about when any restart is scheduled. All too often I see people in various build groups making guesses about it when this information is really easy to get at and, with almost no effort, can be with you all the time.
The other important information on that blog is, of course, the status information itself. While we all know that it can, on occasion, be a little misleading, or a little late, it's still important to know what's going on and to stay informed. To this end I've got a couple of things in place. The first is I've got this script I (re)wrote a while back sat in a prim in the workshop. The moment something changes on the blog's RSS feed I get an IM to let me know.
But I've also gone one step further. I'm a fairly avid user of ifttt so I've got this set up:
This is an ifttt recipe that, when something new shows up on the grid status RSS feed, it sends a push notification to all my mobile devices (they're all Android in my case) using Pushover. This in turn has my phone or tablet make a nice loud "bong" sound to let me know that something happening (and, of course, it also sends the text of the status entry so I can read it too).
Another vital tool is the region restart notifier that I wrote some time ago. I have this in a prim in the workshop so that I can know when our region has come back from any restart. In fact I normally have a copy of this, in some form, in mall locations I have too. That way I can know that a mall has had a restart in case I want to double-check that the vendor boards have come back online (something that's never been a problem since I switched to CasperVend -- but that's another blog entry for the future, I guess). It's not uncommon for me to know (and announce in their group) that a region has come back from restart before the person who kicked off the restart knows. ;)
There's also one more vital thing I rely on heavily. It's actually a viewer thing. It's also a thing that confuses me about many other people. It's to do with this:
Given the gadgets and stuff I have in-world to keep me informed about what's going on this is a common occurrence. It's a common occurrence for anyone with a non-trivial involvement in-world, I imagine. But rather than announce this fact in my profile and use the usual "so send a notecard" line I do this: I have IMs go to email. It's that simple. No messing with notecards and instructions on how to get them to me (the one that never ceases to amaze me is when people say "send me a notecard if I'm offline" and then they hide their online status from people who aren't on their contact list). Just.... send an IM, as you normally would.
The best part about it is that I can reply. Email -> IM replies are so damn handy. I can reply to people and help them out without even being near a computer, I just reply via email on my phone.
And that's pretty much it. Aside from all the usual build tools (Photoshop, Qavimator, etc...) and the backup regime I have (that's another long blog post if that was to happen) they're my most-used and most-useful tools that relate to SL.
However, via Inara Pey's entry, I realised that this was one that's close to my heart and that I'd have some fun with it. So, here goes... (warning, there's a lot of self-made stuff here -- this isn't an attempt at self-promotion, it's just that I'm a programmer by trade and we have a horrible habit of reinventing wheels when faced with a problem because.... well, it's fun)
First off, here's my usual viewer view of the world:
As you can see, I run Firestorm. On my main machine I use the last stable version and on my laptop I have the beta (I've not upgraded the main machine due to a rather annoying bug that impacts on one aspect of RLV). While I have a good number of other viewers installed for testing purposes Firestorm is my work environment of choice.
I try and keep it as uncluttered as I possibly can. When I'm busy it's normally covered with an inventory window or two, a build floater, the conversation window and more often than not one or more script editor windows. But when I'm wandering around I try and keep the view nice and clean.
I only have the following HUDs on all the time. First there's my Sub-Allowance HUD:
I guess this should be considered less a tool for me and more a tool for Miss Vila. The same can be said of the Submission HUD:
Both of those are locked in place and can't be removed. So, leaving RLV HUDs aside (well, there's one more to come, sort of), the only other two HUDs I use a lot are as follows: first there's the OpenCollar Submissive AO...
Although Firestorm has a builtin AO, which actually works really well (I use it with great effect on a different avatar), I like that the OC AO has tight integration with the OC collar (my collar is scripted with OC).
Finally, to help stop the non-locked HUDs being knocked off during outfit changes, I have my HUD Locker:
And that's pretty much it when it comes to tools that are HUDs. Given that a lot of my in-world time is either time spent with Miss Vila or time spent working in the workshop I don't have much need for anything else. My other useful tools are all about knowing what's going on in-world and knowing the state of our region.
So, this is where I wander away from the viewer-oriented stuff and talk more about how I try and stay informed about what's going on. One really important tool, for me, is the Linden Lab grid status blog. There's two really important and useful things on there. The first is the calendar of scheduled server releases:
I use Google Calendar (on the desktop, on my phone, on my tablet) so I subscribe to the above. That way there's absolutely no reason why I should ever need to guess about when any restart is scheduled. All too often I see people in various build groups making guesses about it when this information is really easy to get at and, with almost no effort, can be with you all the time.
The other important information on that blog is, of course, the status information itself. While we all know that it can, on occasion, be a little misleading, or a little late, it's still important to know what's going on and to stay informed. To this end I've got a couple of things in place. The first is I've got this script I (re)wrote a while back sat in a prim in the workshop. The moment something changes on the blog's RSS feed I get an IM to let me know.
But I've also gone one step further. I'm a fairly avid user of ifttt so I've got this set up:
This is an ifttt recipe that, when something new shows up on the grid status RSS feed, it sends a push notification to all my mobile devices (they're all Android in my case) using Pushover. This in turn has my phone or tablet make a nice loud "bong" sound to let me know that something happening (and, of course, it also sends the text of the status entry so I can read it too).
Another vital tool is the region restart notifier that I wrote some time ago. I have this in a prim in the workshop so that I can know when our region has come back from any restart. In fact I normally have a copy of this, in some form, in mall locations I have too. That way I can know that a mall has had a restart in case I want to double-check that the vendor boards have come back online (something that's never been a problem since I switched to CasperVend -- but that's another blog entry for the future, I guess). It's not uncommon for me to know (and announce in their group) that a region has come back from restart before the person who kicked off the restart knows. ;)
There's also one more vital thing I rely on heavily. It's actually a viewer thing. It's also a thing that confuses me about many other people. It's to do with this:
Given the gadgets and stuff I have in-world to keep me informed about what's going on this is a common occurrence. It's a common occurrence for anyone with a non-trivial involvement in-world, I imagine. But rather than announce this fact in my profile and use the usual "so send a notecard" line I do this: I have IMs go to email. It's that simple. No messing with notecards and instructions on how to get them to me (the one that never ceases to amaze me is when people say "send me a notecard if I'm offline" and then they hide their online status from people who aren't on their contact list). Just.... send an IM, as you normally would.
The best part about it is that I can reply. Email -> IM replies are so damn handy. I can reply to people and help them out without even being near a computer, I just reply via email on my phone.
And that's pretty much it. Aside from all the usual build tools (Photoshop, Qavimator, etc...) and the backup regime I have (that's another long blog post if that was to happen) they're my most-used and most-useful tools that relate to SL.
2013-07-10
I survived the great SSA rollout of 2013
Today's run to my restart retreat was a little more special than usual because, of course, today was a pretty significant day in Second Life (well, for those of us who live on or hang out on LeTigre regions). For the first time since the rollout of mesh and bigger prims I was sat waiting for a big and important new thing to show up, along with most of the rest of the grid.
So, I sat there watching the kettle, waiting for it to boil...
...wondering how well it was going to go. When the region came back I TPd home. When I landed home I turned grey all over for a couple of seconds and then.... there I was, textured as I should be. No drama at all.
So far, other than the fact that an outfit change is very fast, there's no real obvious difference. Which is a good thing. I did notice one small niggle though: when I logged in this evening my face was a little fuzzy but, of course, rebaking my avatar no longer does anything. I had to change outfits to fix that. Perhaps there's a better way that I'm not aware of yet.
There's one very curious thing about the move to SSA though. Zanda, the Z&A shop bot, is running on a rather old bot client. I'd fully expected it to run into problems, with Zanda not showing correctly. Thing is, so far, he's fine. He's textured all nice, as he should be. I've had others look at him and he looks fine to them too. I've even cleared my texture cache just in case his texture was cached locally, or something -- no difference. There's no way the bot application is SSA-compatible, the code hasn't been touched since late 2010, so I'm unsure how or why he's working (could it be there's some sort of hand-over period and the doom and gloom about older viewers wasn't totally correct?).
My plan was to move him over to METAbolt. I've already got the script working so he can carry out doing his duties (handling group invites) but I think I'll hold off until I actually see him fail.
So, I sat there watching the kettle, waiting for it to boil...
...wondering how well it was going to go. When the region came back I TPd home. When I landed home I turned grey all over for a couple of seconds and then.... there I was, textured as I should be. No drama at all.
So far, other than the fact that an outfit change is very fast, there's no real obvious difference. Which is a good thing. I did notice one small niggle though: when I logged in this evening my face was a little fuzzy but, of course, rebaking my avatar no longer does anything. I had to change outfits to fix that. Perhaps there's a better way that I'm not aware of yet.
There's one very curious thing about the move to SSA though. Zanda, the Z&A shop bot, is running on a rather old bot client. I'd fully expected it to run into problems, with Zanda not showing correctly. Thing is, so far, he's fine. He's textured all nice, as he should be. I've had others look at him and he looks fine to them too. I've even cleared my texture cache just in case his texture was cached locally, or something -- no difference. There's no way the bot application is SSA-compatible, the code hasn't been touched since late 2010, so I'm unsure how or why he's working (could it be there's some sort of hand-over period and the doom and gloom about older viewers wasn't totally correct?).
My plan was to move him over to METAbolt. I've already got the script working so he can carry out doing his duties (handling group invites) but I think I'll hold off until I actually see him fail.
2013-04-05
So that's where my shop went...
It was sort of heartening to read this blog post a little earlier today. While I've noticed the missing prim thing a lot over the past few months, and while they always appear when I do an edit, it's got a lot worse since this week's rolling restart. And it's always a little worrying to see my shop looking like this:
A fix somewhere down the line would be really nice.
A fix somewhere down the line would be really nice.
2013-02-19
Extending a Linden robot
I have three "non-me" accounts for dealing with Z&A business. The first one I ever created was "Zanda Slacker". Unless there's been a glitch in his connection you'll always find him hanging out in our main store somewhere, doing something vaguely useful (right now he's available for trolley rides). As a registered scripted agent (AKA "bot") he also handles group invites and he lets me keep an eye on the shop while I'm working at my desk but not in-world.
The second is "CrashTestMistress Resident". When building Z&A items we've always taken myself and Miss Vila as the size guides. However, due to our different timezones, Miss Vila isn't always available to help size things up when I'm building. To get around this problem I created Crash as an avi with similar size and shape as Miss Vila and kitted her out with fairly high heeled boots. As a template to work around she works well. With the help of METAbolt I can have her in while I'm in on my viewer of choice and get things done.
More recently I had a need for a third avatar. Late on last year I was getting more and more into working with mesh. At that point Firestorm (my viewer of choice) wasn't quite up to the job of uploading models so I was always switching over to the official Lab viewer to get that job done. A slight hassle, but no big deal. Until, that is, things happened that meant I was using RLV all the time again. At that point I didn't want to be logging into a viewer that lacked RLV. I also wasn't sure that, even if I could use a viewer that contained RLV and handled mesh uploads well, I'd have access to things like inventory all the time. While I could have used one of the other avis for uploads I also wanted the object's creator to show as something sensible -- either me or....
Meet ZandAProductions Resident.
He quickly became my goto avi for doing things (with Miss Vila's permission, obviously) that I couldn't do due to some RLV fun. As time went on the need to use him for his original purpose diminished. Firestorm now has much improved mesh upload so the need for me to switch viewers has pretty much gone away.
But he does still have a purpose. For the past couple or so months I've been working on a lot of new stuff (which will be getting launched early next week) and, again, because of the restraints I was sometimes in while doing this work, I needed another avi to be the "victim". "The Robot" (has he's generally known to us) was the perfect candidate. Log him in on METAbolt with the RLV module enabled and I was all sorted.
Because we use LockGuard for particle chains and the like I started out by putting some freebie cuffs and collar I'd made on him. However, it seems that METAbolt doesn't support multiple attachments on a single attachment point (or, if it does, I missed how to do it) so he'd end up losing cuffs or body parts. The solution was pretty obvious.
One round of copying his body parts, adding some extra prims, and dropping LockGuard scripts in those prims later and I had a LockGuard compatible version of one of the Lab's robot avis:
This solved the problem nicely and it works a treat.
In this form he's not a good body double for me in terms of checking sizes, but for checking general workings and that I've got the chains/ropes/etc working right he's perfect.
So, thank you for making him mod, Linden Lab. Much appreciated. :)
The second is "CrashTestMistress Resident". When building Z&A items we've always taken myself and Miss Vila as the size guides. However, due to our different timezones, Miss Vila isn't always available to help size things up when I'm building. To get around this problem I created Crash as an avi with similar size and shape as Miss Vila and kitted her out with fairly high heeled boots. As a template to work around she works well. With the help of METAbolt I can have her in while I'm in on my viewer of choice and get things done.
More recently I had a need for a third avatar. Late on last year I was getting more and more into working with mesh. At that point Firestorm (my viewer of choice) wasn't quite up to the job of uploading models so I was always switching over to the official Lab viewer to get that job done. A slight hassle, but no big deal. Until, that is, things happened that meant I was using RLV all the time again. At that point I didn't want to be logging into a viewer that lacked RLV. I also wasn't sure that, even if I could use a viewer that contained RLV and handled mesh uploads well, I'd have access to things like inventory all the time. While I could have used one of the other avis for uploads I also wanted the object's creator to show as something sensible -- either me or....
Meet ZandAProductions Resident.
He quickly became my goto avi for doing things (with Miss Vila's permission, obviously) that I couldn't do due to some RLV fun. As time went on the need to use him for his original purpose diminished. Firestorm now has much improved mesh upload so the need for me to switch viewers has pretty much gone away.
But he does still have a purpose. For the past couple or so months I've been working on a lot of new stuff (which will be getting launched early next week) and, again, because of the restraints I was sometimes in while doing this work, I needed another avi to be the "victim". "The Robot" (has he's generally known to us) was the perfect candidate. Log him in on METAbolt with the RLV module enabled and I was all sorted.
Because we use LockGuard for particle chains and the like I started out by putting some freebie cuffs and collar I'd made on him. However, it seems that METAbolt doesn't support multiple attachments on a single attachment point (or, if it does, I missed how to do it) so he'd end up losing cuffs or body parts. The solution was pretty obvious.
One round of copying his body parts, adding some extra prims, and dropping LockGuard scripts in those prims later and I had a LockGuard compatible version of one of the Lab's robot avis:
This solved the problem nicely and it works a treat.
In this form he's not a good body double for me in terms of checking sizes, but for checking general workings and that I've got the chains/ropes/etc working right he's perfect.
So, thank you for making him mod, Linden Lab. Much appreciated. :)
2013-02-04
Embrace the pain
Earlier today, in the group chat of a certain popular in-world builders group, the subject turned to how terrible Second Life is and how Linden Lab are just out to take all our money, make life as painful as possible, and how we all just bend over and take it. Etc... You know the sort of thing. The sort of thing where all the other grids are greener and anyone who points out any flaws in that argument is an apologist for the Lab.
One thing that came up was the cost of uploading content.
Which got me thinking... the latest Firestorm lets you change the UI sounds. So doesn't it make sense that we make those upload costs as painful as possible?
Here's my suggestion to those who want to embrace the pain. First, in Avatar >> Preferences, go to the "Sound & Media" tab, then go to the "General" sub-tab. At the bottom, change the "L$ change threshold" to a nice low figure -- one below L$10, obviously.
Now, having done that, head to the "UI Sounds 1" tab and find the "Money balance decrease" item:
In here, place the UUID of a slapping or spanking sound. For bonus points add a recording to the end of that sound of you going "Thank you Lindens, please may I have another?"
Hit "OK" and you're all done. Now, every time you upload content to the Second Life servers and are forced to pay for it you can feel really good about the pain.
One thing that came up was the cost of uploading content.
Which got me thinking... the latest Firestorm lets you change the UI sounds. So doesn't it make sense that we make those upload costs as painful as possible?
Here's my suggestion to those who want to embrace the pain. First, in Avatar >> Preferences, go to the "Sound & Media" tab, then go to the "General" sub-tab. At the bottom, change the "L$ change threshold" to a nice low figure -- one below L$10, obviously.
Now, having done that, head to the "UI Sounds 1" tab and find the "Money balance decrease" item:
In here, place the UUID of a slapping or spanking sound. For bonus points add a recording to the end of that sound of you going "Thank you Lindens, please may I have another?"
Hit "OK" and you're all done. Now, every time you upload content to the Second Life servers and are forced to pay for it you can feel really good about the pain.
2012-03-30
Random Search
Second Life search is fun. By "fun" I mean interesting values of "fun", of course.
Earlier this morning I needed to search for Whiz Wonder (the CEO of The Whizical Hunts) because I had a couple of questions about The Naughty Bunny Hunt (I was doing the final work on being ready for it starting). Problem was, she wasn't showing in search. That seemed odd given the position and purpose of that avatar. So I find them by other means and point this out.
Quickly we realise that quite a few avatars, and locations, that should be in search aren't. I quickly noticed I wasn't!
That's annoying. I'm very open about being in search. I make and sell things so I need people to be able to find me. One thing I pride myself on is being available for questions and help and not being listed in search sort of messes that up.
Fast forward an hour or so and...
Okay.... Oh well, I guess this random nature is all part of the new search system's charm, right?
PS: I'm going to have to check out Twink's Art Gallery (look at the classifieds in the above images). No idea who they are but if they show up for a search for me I'm sure that's an omen. ;-)
Earlier this morning I needed to search for Whiz Wonder (the CEO of The Whizical Hunts) because I had a couple of questions about The Naughty Bunny Hunt (I was doing the final work on being ready for it starting). Problem was, she wasn't showing in search. That seemed odd given the position and purpose of that avatar. So I find them by other means and point this out.
Quickly we realise that quite a few avatars, and locations, that should be in search aren't. I quickly noticed I wasn't!
That's annoying. I'm very open about being in search. I make and sell things so I need people to be able to find me. One thing I pride myself on is being available for questions and help and not being listed in search sort of messes that up.
Fast forward an hour or so and...
Okay.... Oh well, I guess this random nature is all part of the new search system's charm, right?
PS: I'm going to have to check out Twink's Art Gallery (look at the classifieds in the above images). No idea who they are but if they show up for a search for me I'm sure that's an omen. ;-)
Subscribe to:
Posts (Atom)