Update 16th January: Charlar has added a comment to the JIRA that clarifies LL’s position on the alignment tool and puts concerns into perspective. The comment further makes it clear that from LL’s position, the opportunity to see the tool included in the official Viewer is far from closed, and Oz indicated in his comment from yesterday.
Update 15th January: The JIRA mentioned below has been re-opened, and Oz has requested any developers willing to take the alignment tool further to contact him directly. This clearly shows that the Lab is aware of feelings on the matter and are trying to meet people half-way, and full kudos to them on this. Qarl (Karl) has declined to update the code, but has stated it’s in the public domain, and others are welcome to do so.
Earlier in the month, Karl Stiefvater (do I still need to introduce him as the creator of the parametric deformer?) submitted an earlier piece of code he’d created – the prim alignment tool – to Linden Lab under a code contribution agreement.
I didn’t cover the contribution at the time, as Tateru had it very well covered. However to recap: Karl, formerly Qarl Linden, now Qarl Fizz, submitted the code to LL by way of a “Thank you” for a generous donation someone made towards the deformer project, as you can read on his website as well as Tateru’s blog (Tateru having steered the donation in the right direction).
The alignment tool does precisely what it says on the box: it aligns prims, as Karl’s own video demonstrates:
No fuss, no bother. It’s not a one-size-fits-all solution that is designed to fit every possible situation where prims (or linksets or objects) may need to be aligned, and it is not intended to be. However, it does provides a major benefit for builders in dealing with a specific set of issues that can otherwise be time-consuming to overcome. As such, it has been adopted by a number of TPVs, where it has proven to be highly popular.
But it has been rejected by Linden Lab under the original JIRA raised on it some 2 years ago by Nalates Urriah. As Lance Corrimal (himself the developer of the Dolphin TPV which uses the tool) and Tateru on her blog point out, the reason for the rejection appears to be primarily because the tool doesn’t perform tasks it was not designed to do and is thus “incomplete”.
The rejection notice as posted on the JIRA reads:
Thanks for making this effort. Alignment and snapping are an area where there are useful enhancements to be made.
However, we are not able to accept this contribution as it is.
These are the primary issues we found which resulted in that decision:
- The feature should support the same modes as the other manipulation modes.
- It does not work for non-mod permission objects. This functionality should work for all objects that the user can manipulate in-world.
- It only supports World snap mode, not Reference and Local modes, unlike all our other manipulation modes
- It packs and aligns to the face of the object bounding box. If objects are not cubes and do not share the same alignment, or aren’t aligned with the world coordinates (see above), the result of the operation is unexpected. Ideally the operations would use the actual shape of the object for aligning and packing.
- There are also some coding implementation style issues that would need to be addressed. These can be covered in more depth after the functionality is dealt with.
In it’s current form, this is usable for purely prim-based builders under specific circumstances. It’s less useful for building with non-cube prims, mesh, sculpties. It’s minimally useful for building when the structure is not facing a global direction (ex: North, South, East, West). It’s not usable by non-building residents who need to place and organize purchased items.
LL obviously have the right to reject code that they feel is not in their best interests, or in the interests of the Viewer or their users. That’s a given and is fair enough. As such, and being of a generous nature, I have to say that there might be some mileage in some of the reasons given for the rejection (Jonathan Yap actually raises a couple of points within the JIRA). But, and again being fair to all, the rejection equally comes across as little more than nit-picking.
Take, for example, the remark that, “It’s minimally useful for building when the structure is not facing a global direction (ex: North, South, East, West).” On the surface, this might appear reasonable – until one remembers that the same is pretty much true for building as a whole in the Viewer at present – as anyone who has encountered prim drift can ably testify.
Then there is the comment, “There are also some coding implementation style issues that would need to be addressed. These can be covered in more depth after the functionality is dealt with.” This reads as not only nit-picking, but also to be putting the cart before the horse.
If Karl is in fact committing some basic errors in his approach to coding for the official Viewer, surely these should be addressed before embarking on any major functionality changes (were they to be agreed upon), in order to circumvent the risk that such “style issues” don’t lead to yet another rejection down the road?
Some have commented that the entire rejection smacks of a “not invented here” mentality. That may be the case, equally, there may be issues within the code as submitted we’re not privy to and which the note in the JIRA isn’t really helping to make clear. Even so, seeing this rejection I have to confess to being left with an uneasy feeling as to how the deformer tool is to be judged by the wider audience within LL. Time will tell on that, however.
As far as the alignment tool is concerned, I’m with Tateru on the matter and calling “time” on any hope of seeing it incorporated into the official Viewer, for precisely the reasons she states.
With thanks to Tateru Nino
Inara Pey: Living in a Modemworld 
Once again LL fails the civility test! I would be so much nicer if they had said “Thank you for the submission. Unfortunately we will not be implementing it in it’s current form for the following reasons: [ xxxxxxxxxxxxxxxxxx ], we may however use it as part of a future more inclusive tool.”
LikeLike
Exactly. Now why couldn’t I have posted things that succinctly :).
I don’t really have a problem with LL turning things down; it’s more than manner of how the rejection is expressed – and some of the reasons given neither seem insurmountable or entirely black-and-white (hence why I’ve highlighted them).
LikeLike
It is really a scandal and soon I think LL just wont improve SL or the Viewer. I really cant understand it.
LikeLike
I’ll have to beg to differ on that somehwat.
In fariness to LL, one of the points in having TPVs is to allow specific functionality to be developed and included in them that LL may not have the time or man power to develop themselves, and which fulfil specific niches within people’s SL needs. As such, it’s really beholden to LL to include absolutely everything that comes along, particualrly as they regard themselves as having a slightly different audience to address than TPVs (although we might debate with them as to whether this is strictly the case). And at the end of the day, it’s not as if the community is without the tool because they’ve rejected it.
However, that said, it *is* hard to agree with (or understand) several of the reasons for the rejection as stated, as they don’t appear to bear-up to scruntiny when compared to common limitations found within the Viewer as it currently stands, or in the order in which the recommendations are given (i.e. such as advising functionality is added, *then* addressing what appear to be coding style issues, which to me seem in the reverse order). In this respect, Shug has hit the nail squarely on the head in her comment above.
We’re obviously not privy on what may have been said between LL and Karl directly on the matter; but one has to say that – with the greatest of respect all involved – the rejection notice as posted doesn’t read at all positively in terms of encouraging a further submission of code, were the coder so minded to do so.
On the wider issue – we do continue to see overall improvements both within the Viewer and the grid as a whole. So while this decision may be something of a disappointment to many of us (myself included), *and* appear to be somewhat confused in it’s thinking; I don’t think it’s fair to tar LL’s efforts as a whole with it.
LikeLike
You right. Its maybe a bit harsh to say “they wont improve SL” because there were some improvement in the past I noticed too (generally). But basicly this message of LL means to me again “If you are content creator, use a TPV”. As this is a pretty essential tool in my opinion. But after all the viewerwar´s I stay on the point and learned there is defenetly a reason to suggest a TPV to someone who would like to create things in SL, as TPV´s simply have some features which make your life easier as builder. I remember having trouble rotating on linked prim axis while I can do it with a TPV and so on. And Qarl´s gift up´s the ante now. So what I meant to say was that I see improvements from content creator standpoint only on TPV´s. That those Viewer´s have a slightly different audience might be true. Yes I want to say from this standpoint my second life has rather been improved by TPV Dev´s and not by LL.While LL improved my second life with very great features like “Mesh Import”… sure I have to differ. But Viewer-technically I see these improvements anywhere but not in the official viewer. It looks like LL gives the basic code and SL-Users and Devs improve it. That is my opinion. 🙂
LikeLike
To some extent you have to make allowances, the Linden geeks are not always diplomatically adept. Feedback like this needs to be corrected (and it has been) but we have been through the silent treatment and only the PR department being able to say anything at all. I will take a few awkward stumbles just to have the communication.
LikeLike
Absolutely on the last part.
LikeLike
It will matter? If Sopa and Pipa passes, it will really matter?
LikeLike
The Jira is back open and now set to a status of Open Development Candidates with Oz asking for volunteers to contact him if they think they can help with this. To be fair to Charlar, he did say in the comments he was hoping that the people submitting the code would look at Linden Lab’s response and then re-submit the code.
The communication got there in the end to a response that is better, I’m happy that Charlar and Oz at least try to communicate in these sort of threads, even if it takes a few posts to make clear what they mean.
LikeLike