Flexible linkset

Yesterday afternoon Mistress had reason to play around with flexible path values for a linkset. In doing so she mentioned that it was a bit of a pain to have to set the parameters individually for each item in the linkset. Never having really played with this before, I was a little surprised to find that it's a prim parameter that you can't set on more than one prim at once; especially given it's one you can set on more than one prim at once from a script.

So, for fun, I knocked up a little tool that would let her experiment quickly and easily. Z&A Flex Linkset was born:

The script is designed so that it listens to the object owner in local chat, and accepts commands for setting the different parameters. When a parameter is given it's applied to the whole linkset. Commands include:

flex soft <value>
flex grav <value>
flex drag <value>
flex wind <value>
flex ten <value>
flex fx <value>
flex fy <value>
flex fz <value>

As well as commands for setting the flexible path parameters, there are also commands for controlling the script itself. To see the current parameters:

flex show

To reset the parameters to their default:

flex reset

And when you're done with the script and you want it to remove itself from the object:

flex done

And that's it. It was fun to knock together, Mistress had fun playing around with it, hopefully it's of some use to someone else too.

The unnecessary script

I bought this unitard/bodysuit thing the other day:

I love it. I'm never taking it off ever again. At least not until the next thing I have to wear.

Only.... there's a thing that bugs me about it. This particular one is for the Maitreya mesh body but it doesn't auto-alpha out of the box; neither is it a perfect skin-tight fit so it does need some alpha work. That's not a problem of course, I can use the body HUD and I can then use the Maitreya auto-alpha script to make it auto-alpha for me.

Ideally I'd drop the script inside the item of clothing -- saves having to make a separate object that I have to add to any outfit -- but, as with many items of clothing, it's no-mod. And this is where it gets a bit silly and a bit unnecessary and where it bugs me.

Looking inside the item of clothing I see this:

A bloody "no rez" script. The sort of thing that, when you rez the item on the ground, it patronises you and then calls llDie.

So, for no real sensible reason I can detect, I have to carry around a script that reports that it will happily use up to 64k of script memory (why can't the author at least use llSetMemoryLimit to reduce that?) while doing nothing other than stopping me from rezzing it out. Worse, trying to stop me from rezzing it is a complete waste of time because all I have to do is find a plot with scripts turned off:

Meanwhile.... the Maitreya auto-alpha script can achieve the auto-alpha thing and it has support for the pointless no-rez thing built in as an option. Even better: it does this in a script that will use a maximum of 16k of script memory!

So.... dear clothing makers, please, please, think though your options and reasons before you drop a script into an item of clothing -- chances are all you're doing is adding scripts to avatars for no good reason whatsoever.

Have we lost the RC regions?

I make a point of keeping a good eye on the Second Life region restart and deploy schedule. I have the calendar pulled into my Google Calendar; I keep an eye on the grid status; I even have a thing set up so that changes to the grid status get IMd to me. On top of that I have a restart notification prim on most regions that I have some space on. As such, I do all I can to make sure I know what's coming, when and why.

So it came as a surprise when, earlier today, my own region restarted. My own region is a LeTigre RC region and there were no RC restarts scheduled for today or, indeed, this week. Only the main channel was scheduled for a deploy. It was even more of a surprise when it came back:

The software version stayed the same (the one we got last week) but the channel changed!

At first I thought this was just an aberration, some sort of glitch, and perhaps a word with the Lab would mean I'd find out why we'd moved to the main channel. Soon though, when I went in-world, I realised it was odder than that.

A region next to the mountain retreat is LeTigre so I went and checked it and.... main channel. Then I checked the mainland plot that Mistress has, which is also on LeTigre, and it was in the middle of a restart. When it came back it too was on the main channel.

It was starting to look like LeTigre was being removed from the grid.

Only... no. One of the Magnum sandboxes had also gone main channel and, when I just went and checked about 15 minutes ago, all 4 BlueSteel sandboxes were also now main channel.

As of now it looks like all RC regions have been removed from the grid (well, not removed, pushed onto the main channel).

This is actually kind of awkward. For one thing it means that the grid status could not be believed because, rather than just main channel regions being restarted, most or all of the grid's regions got a restart. For another this potentially affects people who rely on their being different channels and who site objects on them for good reason.

An example of using different channels would be the CasperVend drop boxes. The advice that's given, which is very good advice, is that you have one set of your boxes on a main channel region and at least one other set on an RC region. This means that there should never be a moment when a box isn't available (because main channel restarts and RC restarts are traditionally held on different days).

As of now the two locations I have, the smaller and second of which was chosen on purpose (the mountain retreat being main channel to balance out the fact that Shackles is LeTigre), no longer serve the intended purpose. Technically I can't assume that I'll always have one set of CasperVend dropboxes up and working at any given time.

Fingers crossed this is just a bit of a cock-up on someone's part. If not... this potentially has a knock-on effect for doing business in SL. It's not catastrophic by any means, but it does mean that there's one more issue to worry about and deal with.

Edit to add: Grid status got updated after today's main channel restarts finished. It says "Some regions originally on RC servers were incorrectly moved to the main Second Life server. We are working to restore these regions to their original server, and they will require an additional restart as a result. Please monitor this blog for further updates." -- so it's good to know it was a mistake (although I wonder about "some" in that -- all the known RC regions I've been to so far seem to be showing as main channel now).

Further edit to add: Woke up this morning to find this in my inbox:

All is right with the world again.

Second Life is not one world

Most of the real nonsense contained in the recent slhamlet blog post about the "skewed" perspective of Second Life has been addressed: people have pointed out that his characterisation of some of the regions in "the list" doesn't match what's seen in the region (or that the alleged popularity isn't actual popularity); people have pointed out that adult doesn't actually mean there is extreme of violent content on a region; people have also pointed out that you don't "fix" the perceived negative perception of the grid by being negative about positive perceptions (yes, that one tied my brain in knots too).

Pretty much all the content and the claimed motivation of the post has been nicely dealt with.

That's not to say that those critical of the blog post don't have their own distorted view of the grid's content either. I think that's worth keeping in mind too.

With all that aside, I've being thinking more about how people view the grid -- especially when being critical of it -- and I've come to the (not exactly novel) conclusion that the whole "if you don't show the parts of SL that I want people to view as bad" narrative is simply nonsense.

Normally click-baiting nonsense.

The sort of motivation that would have had me using the title "There is no adult Second Life" for this post, for example.

The thing is: there really is no adult Second Life.

No, really, there isn't.

I have, along with a small group of other people who like to share it with me, a region. That region is rated adult. The reasons why it's rated adult obviously encompass the fact that the public parts of the region allow for activities that can be enjoyed by and should only be enjoyed by consenting adults. I have a dress code for the public part of the region that allows for full nudity. If people want to create erotic scenarios in public I'm completely fine with that too. As long as all activities are well within the bounds of what the grid allow I'm likely fine with it.

These things are very rare to see on the region but I have the region rated Adult so that adults can make informed decisions about where they go and what they visit. There is no extreme content here. The region is very much themed with adult relationships in mind that revolve around the mutual and consenting enjoyment of dominance and submission, but when you land and walk about you're really not going to find the sorts of thing that some people think an Adult rating means.

It's that simple: it's an Adult-rated region so that adults can make adult decisions before even visiting.

But Raven Park and Z&A are not part of "Adult Second Life". They're not part of "Adult Second Life" because there is no such thing as "Adult Second Life". There are lots of adult regions on Second Life -- there are even lots of regions that have similar themes on Second Life -- but "Adult Second Life" is not a coherent whole.

Neither is "Fashion Second Life". Neither is "Aviation Second Life". Neither is "Fantasy Role Play Second Life". Neither is.... well, you get the idea.

Even more to the point, those loose groupings of similar-themed regions especially aren't a single entity called Second Life.

Second Life is a platform. It's a set of tools. It's a protocol upon which people can create things and express themselves and enjoy the creations of others.

Second Life is not one world.

This fact, for me, is the reason why I find the original slhamlet article so shallow, why it gives the perception that the author lacks even a basic understanding of the grid (yes, yes, I know... that's what makes it all the more hilarious and further gives the impression that it was disingenuous click bait, lacking only an Upworthy-style headline to really give the game away). Unless you're writing about the tools, the protocols, the underlying design of the grid; there is no need or requirement to report about every single style of region that exists.

It makes perfect sense to me that someone would write an article that documents what their curated visit showed them. It also makes perfect sense to me that a curated visit would be... well, curated. Even in my own narrow "not really a world" corner of Second Life -- what we'd loosely call "The Femdom Community" -- if I were asked to show someone around I'd obviously show the places I like, that I appreciate, that I consider to be good examples, that I can speak about with confidence, that are chosen by informed opinion.

I absolutely would not show every single place that shows in search under the term "Femdom".

The reasons I wouldn't do that are:

1. Not all of them are actually Femdom locations.
2. Not all of those that are Femdom locations are to my taste.
3. I don't even know them all and I like my opinions to be informed when I share them.

And, at no point, should I ever be expected to treat every single findable region or plot that employs that term in search as a coherent whole. Because they're not.

It's simple really: Second Life is not one world. It's a rambling collection of loosely-connected and crazily overlapping builds that, if curated correctly, will delight you.

I think, in my 9 years on the grid (starting with my original avatar), I've probably explored 1% of it. No silly "most visited" list will dictate how I view the other 99%.

The SL false dichotomy

So, once again, there's a bit of a "thing" happening in SL circles -- especially in the SL "reporting" circles (and I do use scare quotes very much on purpose) -- about how someone wrote something nice about SL and someone else wrote something not nice about the nice thing and... and of course, once again, it descends into the very common Second Life false dichotomy.

Which one?

This one:

The above is a comment made on plurk. Who made it doesn't matter, what matters is that it's representative of a common theme that bugs the hell out of me: Second Life has two sides, the pretty side and the adult side.

Utter bullshit.

That's a completely false dichotomy.

Can we please stop doing this? Seriously, can people start being adult about this and understand that these things are not mutually exclusive? Can we please drop the narrative that everything adult in Second Life is ugly and extreme and borderline illegal or even about sex at all? Meanwhile, can we also accept and acknowledge that all of the pretty static photos that use static poses and mesh clothing that looks fantastic but only really makes sense as long as you don't move, that's photographed with machine-crippling viewer settings, also isn't a realistic view of the grid?

Even better, can't we acknowledge and accept that these two things, and a thousand other facets of the grid, overlap? And, better still, some results are awesome, others are horrible, and it's all a matter of taste?

Can we?

Please?

No?

Didn't think so.

New toys for scripting

It's been a while since I noticed changes to the calls available in LSL that have interested me. The last time I can think of was when llGetAgentList turned up on our region. Today's RC release adds some handy extra items to llGetEnv. Whereas before the values that could be acquired were:

dynamic_pathfinding
estate_id
frame_number
region_idle
sim_channel
sim_version

it's now been extended with:

agent_limit
estate_name
region_cpu_ratio
region_product_name
region_product_sku
region_start_time
simulator_hostname

I can see some of these new ones being handy for information and diagnostic uses. region_start_time is especially useful in that it renders part of my region restart notifier script moot (the part that lets you know when a region last restarted). It also means you can check the update of any region you're stood in by simple use of an easily-scripted HUD.

simulator_hostname also looks handy in that it pretty much replaces any need to use llGetSimulatorHostname and, in doing so, removes the forced delay cost.

I'm also a bit intrigued to see the addition of OBJECT_LAST_OWNER_ID. That could have some interesting uses.

Get a region's map tile URLs

Earlier today I found myself in a position of needing to grab a handful of map tiles from the Second Life map API. There's an image that needs making that requires a number of map images so grabbing them from that API made sense.

To help do this job, and to help work out what the URLs are for a given region, I knocked up this script:

Just drop it into a prim and touch the prim to get all the URLs for all the map tiles, at all zoom levels, for the current region. Alternatively, say the name of a region on channel 1 to have it do the same for that region (the script is coded to only listen to the owner).

The output looks like this:

Using a variation on this script I was able to create the image I needed without too much effort (in my case I needed to get the tiles in a specific area, at a specific zoom level, so I could paste them together to make a bigger map).

I'm starting to wonder now if using something like this, in combination with media-on-a-prim, could be used to make an in-world interactive map (yes, I know, you could just browse maps.secondlife.com on a prim but where's the fun in that?).

Potential idle-time project at some point.

Calculate LOD switching distances

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.

A solved confusing mesh issue

I finally have an answer to the confusing mesh issue that was bugging me earlier today (and has been troubling and confusing me most of my evening too). After I wrote the issue up Beq Janus was kind enough to pop over to my workshop and have a look at it with me. She helped eliminate a number of possible causes (all of which I'd not thought about) and she also helped me better understand the interplay of bounding box scale and LOD levels. Sadly though we just couldn't get to the bottom of the problem.

Eventually, later on, while trying a few things, I got desperate and copied the "problem" linkset and set it all so it only had a single texture. I meshed it and uploaded the result and the resulting mesh behaved as I'd expect it should! I could place the two mesh, side by side, and watch the 4-face one collapse far too quickly while the 1-face one would collapse at the rate I expected. Both were very different rates.

At this point Beq started asking around various groups, one of which was the Sweet Meshes group (the group that supports Mesh Studio). One of the ideas we were entertaining at this point was that it was a problem with Mesh Studio itself.

Turns out this was the best place to ask as this reply came though:

[13:51] Rey (chinrey): Sorry, just noticed the discussion here. Somebody's got problems with LOD of a 4 face mesh?
[13:51] Rey (chinrey): If so, that's an old, well documented bug
...
[13:52] Rey (chinrey): What happens is that the size along the z axis is ignored when the switch points between the LOD models are calculated

That was it! That was exactly what I was seeing! Given the description of the bug it seemed like there were two workarounds available:

[13:54] Antony Fairport: So if I throw a couple more faces into it that I don't need it should fix it?
[13:54] Antony Fairport: or....
[13:54] Antony Fairport: If I turn the build on its side and mesh it?
[13:54] Rey (chinrey): Yes, those are the two solutions
[13:54] Antony Fairport laughs -- 90deg rotation happening right now.

And that was it! That fixed it. If I took the resulting mesh, turned it upright and set it alongside the the mesh made from the exact same source linksets, only with a different rotation, it behaved!

For anyone who's interested and who, like me, doesn't know of it, here's a discussion about it. It's a very odd one but, now I know, I can always work around it in the future.

Many thanks to both Beq and Rey for their help. I would never have got this solved without them.

A very confusing mesh issue

As part of a very long-term Raven Park build project, I'm currently working on creating some mesh components. As usual I'm making them with Mesh Studio. Earlier today I made a mesh version of a "prototype" object to see what the land impact would be like and to also see how well it held up to being viewed at a distance. The test went well and I was satisfied with how it turned out, both in terms of how far away it could be seen and the resulting land impact.

Fast forward to later on in the day and I now have a fully-textured source linkset (the "prototype" had a single texture applied to it and so only had a single material face -- this final version has 4). I go through the usual exercise of making the 4 LOD levels and the physics shape (as I did with the prototype), throw them all through the Mesh Studio servers and upload the result. The final land impact was slightly higher than the prototype because I needed to keep some extra faces down through all the LOD levels but it was still well within what was acceptable for the build.

Here's the textured "final" mesh next to the untextured "prototype":

Aside from the textures, and a couple of very small tweaks to the size and position of one or two of the prims that made the source linkset, they're identical. Their overall sizes are identical (< 0.6, 0.6, 7.501 > in both cases).

Only... as I start to cam away things start to differ. At around 18m away from the objects this happens:

(forgive the quality -- this is a scaled up crop, for obvious reasons). What's happened is that the "prototype" is still showing either the high or medium LOD model (it's pretty much impossible to tell which just from looking -- which is how I try and design the medium LOD) whereas the "final" object has already dropped to the low LOD. Not much further away and the "final" drops to the lowest whereas the "prototype" seems to stick with the high or medium all the way to the edge of my draw distance (which I normally have at 128).

I just can't fathom it. I've tried tweaking the source linkset and looking for any differences between the "prototype" and "final" and.... I can't see what the issue is.

I've even gone so far as going over the mesh steaming cost article on the wiki, via the mesh LODs article by Beq Janus in this magazine, to try and calculate what should be happening. That, however, has left me a little more confused. In both cases they talk about the radius of the bounding box but the concept of the radius doesn't seem to be defined anywhere (I know what a radius is, of course, but when the object in question doesn't have a bounding box whose ratios are 1:1:1 it helps to know exactly how it's defined). That issue aside though, it seems clear that two mesh objects with the same sized bounding box should collapse to the next LOD down at the same time at any given camera distance.

Shouldn't they?

Edit to add: I finally got to the bottom of this, with the help of others.

Day2K

On the one hand it's just another day on the grid. Nothing that special. Not an actual anniversary or anything like that. Not a rezday. On the other hand though there's something kind of special about those big round numbers.

Those 2,000 days have been eventful, that's for sure. While I often seem people in various groups (especially D/s groups) complain that they're "bored" in-world this is something I've never really had a problem with. In those 2,000 days I've gone from a nervous and curious observer of the SL D/s world to someone who's fully embraced it, learnt to have fun with and make things using RLV and has generally become someone comfortable with getting to know that side of myself.

There's been ups and downs, of course. When I hit 1,000 days I happened to be uncollard, something which happened again just in time for day2k. Overall though I've really enjoyed the time I spend as Antony.

And, hopefully, I will do for some time to come.

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. ;)

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:

• 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?

The only reason I can think of why people turn this feature on and then get offended by people looking at them is that they're looking for an excuse to be offended. Meanwhile, anyone with half a clue about how their viewer works will actually be looking them over without them even knowing.

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.

Saying goodbye, and a brief trip out

Today's a bit of an odd day for me. Today I said goodbye to Mistress for (almost) a week. Somehow I have to manage without her until next Monday. Something that won't be easy.

Before I had to say goodbye to her though we took a little trip out to look at another place we'd recently become aware of and wanted to drop in on called The Slave Storage Facility.

The place seems like a really neat build and, while the land details say "Materials enabled viewer required" I can't say that I noticed a lack of advanced lighting was a real problem.

While there we bumped into someone who was a stark example of why the new mesh avatars that are provided by the Lab to new residents are likely more of a hindrance than a help. The poor girl, who was only 3 days old and very obviously a genuine noob, was trying her best to get dressed. The problem was she was wearing a mesh body and had no clue what it actually was and what significance it had in regards to her (in)ability to wear various kinds of clothes,

Eventually we got her sorted as far as a "traditional" avatar and talked her through how to wear and unwear clothing and add/remove attachments -- although that was a struggle for her too and she never did seem to manage to get the whole of the dress on she was trying to wear.

It's easy to forget just how confusing the viewer can be when you've never used it before, and how difficult it can be to get to grips with the idea of your inventory and what all the things inside it are. This, to be, is made all the worse with the new mesh bodies as they're utterly useless when it comes to dealing with free clothing (which most noobs will be looking to use first).

Eventually though we had to head back to Raven Park. We wanted to have a bit of a wander around the Mansion before Mistress disappeared. We're currently toying with the idea of rebuilding it (it's just over 2 years old now) so we wanted to have a bit of a chat about what would stay, what would go and what would be where. Mostly our view is that it works as it is and what we'd really like to do is just "3D" it up a bit. While texture-only windows were fine back when we built it (the main aim was to make something low-prim that gave plenty of play spaces) it would be nice to give it proper windows and sprinkle some materials work around the place too.

With vague plans made we relaxed in the pamper room for a short while...

...but all too soon it was time for Mistress to head off. Her final act, before logging off, was to turn off my sub-allowance. This means that, for this week, I'm free to walk, talk, fly and TP as much as I like. I'm actually really not liking that at all, it feels odd, unnatural, too free.

And I'll probably have got used to it just in time for Mistress to take full control again on Monday.

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:

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.

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.

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.

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.

Zindra adventure

Earlier today Mistress and I spent a bit of time together in-world. It was another one of those occasions where she decided to make good use of her pony boy while he was still a pony boy.

In other words, we'd take a trip out on the mainland somewhere with me pulling a vehicle we we both explored and chatted on Skype. Given my mostly-naked status this time around we decided that it'd be best if we stuck to all adult regions. So, after scrabbling around to try and find a rez zone on Zindra (I thought I'd landmarked one or more but it seems I hadn't -- thankfully I found one mentioned online thanks to a Google search) we headed out and I rezzed a vehicle.

Mistress left me to select a direction so I simply headed off in the direction I was facing after rezzing the wingback. That didn't work out so well. While we did see a few sights along the way...

...we eventually hit a dead end. A proper dead end. As in, the road simply stopped as we'd run out of regions while heading south east (I, of course, couldn't see any of this on the map as maps were denied because Mistress was with me). I believe it was the same place that Mistress dropped me to start 5 hours of boot training back in July.

At this point Mistress pointed out the mistake I'd made and had me turn around and retrace my steps. On the way back to where we'd started I suggested that, perhaps, she'd like to check out the big Zindra dam. I described roughly where it was and Mistress found it on the map and navigated us there.

Once there we abandoned the wingback, Mistress attached my leash, and we explored...

Eventually we made it back up and to the other end of the dam and we had a little look around while enjoying the sunset while admiring one of the more impressive plots, in terms of location, we've ever seen for sale on the grid (although we didn't have L$150,000 spare to buy it at the time).

Finally it was time to head home again and say goodnight.

At which point I parked myself back in my stable and logged out along with Mistress so I could say goodnight to her properly.

We had loads of fun. It's always enjoyable to go exploring. As much as I love the place we've built together it's really nice to get out and see other places. This was one of those times.