At least partly because it only really works with standard prims, you know, being a prim-alignment tool.
Actually, the Lab’s argument here seems to be that the alignment tool is incomplete (though I’d say it is more complete than a number of features I’ve seen the Lab ship over the last few years), and that since it provides assistance to only one set of fiddly, annoying tasks that it should not be included.
At least, that’s the way I read it. Here’s the rejection notice in its own words from the relevant JIRA:
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.
Basically, the argument looks to me as if it is largely being rejected because it does not perform tasks that it was not designed or intended to do. Quite ironically, as this is the same logic that many journalists use to call Second Life a failure.
As it is, though, I’m ready to call this one dead. While the rejection is only for the contribution in its current form, I don’t think Qarl is necessarily going to take the time to rework it – he has other things on his plate – and I don’t think the Lab will be pressured into changing its mind on this.
Thanks to Dil Spitz for the heads-up.
UPDATE: Qarl responds.
I didn’t look closely. There are actually two jiras.
https://jira.secondlife.com/browse/STORM-468
https://jira.secondlife.com/browse/VWR-360
The first, where most of the comments are being made, including Charlar’s notes, was closed last August in favor of the second. The second one is still open.
No, we cannot allow you to put that hammer in the toolbox.
Because it cannot be used as a screwdriver.
Solution: Find another toolbox.
@Tali
“It is a power tool for users who know what it is and what to use it for, but fairly dangerous for those who don’t, so I can see why LL is reluctant to include it.”
How long was ‘transparency’ a half-ass feature missing its main use case of 100% transparency and we all relied on alpha textures? How dangerous is it now for users to be able to scale transparency to 100% instead of just 90%? What if a user has no idea they need to hit Alt-T to find their transparent objects?
I think the point most people are making is that we’re absolutely used to getting half-baked features. We’re absolutely used to the Build Tool being ‘dangerous’ to new users who can enter a value that sends their prim halfway across the sim, make it invisible, make it too miniscule to see, make it physical and rolls into the abyss of sim water, screw up its texture repeats, etc.
Exactly what ‘danger’ precedent is being set by the alignment tool compared to what exists now to the inexperienced?
And as far as half-baked goes, a lot of us would place the prim-alignment tool above that, because its actually -nailing- the main use case. Physical or virtual, the world is mostly made up of right angles and straight edges that we finically align together with decimal place measurements. The prim alignment tool nails that. That should matter more than the fact its not as good at arranging a basket of apple sculpts.
The issue with the patch rejection are three:
1. The value from Charlar’s list of needed improvements are trivial to the value already present in the tool.
2. Even if the above wasn’t true, Snowstorm is a freakin’ open source project where features are supposed to be developed collaboratively and incrementally.
3. The feature is being held to standards -none- of Linden Lab features released Rod’s first year have been held to in terms of demanding it to be feature complete and requiring no further work.
I am totally fine with this, because it is already included in the firestorm viewer, and so it just continues to show Firestorms superiority over the vanilla client.
Actually code style requests are pretty standard stuff and not to be taken as something personal. That would be why the lab doesn’t have the catznip spellchecker yet .. It’s really not a big deal.
Trinity, I have seen a few things about code style, over the years, and I have done enough programming over the years to have an inkling of how much it can matter. Though the optimisations employed by modern compilers make some aspects less critical that they were. (Some things I’ve read on LSL suggest that some of the old BASIC-interpreter tricks are still worthwhile in that case).
I once used GOTO 3000+(N*100) and I put in a check on the value of N
Different styles, different purposes: where do I find what Linden Lab require?
“However, we are not able…”
Precisely.
Most of you are taking the sensationalism bait a bit too far. Don’t forget that the company has a new CEO and with that new management principles. You can’t fairly hold the Lab 100% to previous track records and standards. Given, you can argue that current term releases have shown little that we might call improvement on that, but most of us don’t have the evidence – and don’t forget that the current term releases are on the back of previous terms and in change.
Not only that but we don’t manage the company’s HR or its expectations. There is a difference between working in project code from outside the company and managing the company’s own milestones and project timeline resources. Outside code will always have a higher standard to be introduced; it must have the minimal required support.
The way this is going you’re all telling them one day to fix their shit – then the next you’re telling them, wait don’t fix your shit – fix his instead!
Get your message unified and stick to it.
I don’t have as much sympathy on this one even with regards to the style comments because Qarl was employed there and should have known better than to submit an old and possibly unmaintained project.
Sounds like the person that hasn’t learned was Qarl, at this point – no real offence meant, but still.
It’s important to keep the whole thing in perspective.
Charlar’s criticisms are, for the most part, correct and those issues should be addressed. By Linden Lab developers.
That’s just the thing, this alignment tool should have been developed in-house by LL and implemented no later than 2002, before the first non-Linden avatars logged in. That LL lacks such basic functionality (and this is hardly the only case of it) is a big part of why people outside of SL cannot take SL seriously.
LL did not do that and has shown no sign of correcting their mistake.qarl offered, as an un-paid community submission, a patch to partially address this gaping functionality hole, and LL is turning it down because it doesn’t also make curly fries and brew a fine pot of coffee?
That’s just ridiculous, especially when they released mesh incomplete and qarl, paid by members of the community, has been working to address the broken mesh functionality LL left out.
Adromaw, a big problem is that Charlar is rejecting the code because it cannot do things which are, in a world of sculpts and meshes, close to impossible to automate.
And at least some of the difficulties he conjures up can be partly blamed on the piss-poor standard of user documentation provided by Linden Lab.
Its just a shame. Sometimes I believe LL is not interested in improving Second Life.
This is the reason why I rather stick with a TPV.
Wolf, it also suggests a potential future intention of the lab to address those issues. The only problem there, if that is their intended goal, is if they don’t arrive at that eventually on their own if need be.
The Lab actually spent something like a year designing its own alignment tool – but it must have been too hard for them, or too low a priority, because after all that work, it never went anywhere.
Where in the time line was that though? And in what state was the project as a whole in terms of the viewer when that happened? If it wasn’t recent enough it might be a complete re-do again… if it was during different staffing circumstances it might have been for completely different reasons than “too hard”. You’re better than just dropping such open statements than that Tat.
That’s basically all I know about it. I couldn’t even tell you which year it was. It’s information, anyway, however scanty.
Yeah unfortunately, there are plenty of things I’d like to know that I don’t know either. And for sure, I’d love the official viewer branch to have a lot more useful features than it does. But I’m also aware that in practice it’s going to be far from as simple as we expect and sometimes for reasons other than raw code, but reasons still. There is always a bigger picture.
The unfortunate part of code is that it doesn’t evolve until parts of it are rewritten and it doesn’t grow at the same rate as our ideas. Or even at the same rate as other ideas and their rewrites. And most of us users that don’t code are used as drama fodder for coder ego wars. As a graphics student working with programming teams, I’ve had my share of witness to coder differences of opinion between themselves and the broader coding community.
It can get to be a less than efficient pool at times, but that’s just how it is, for now.
Damn, what I could give for an edit button -
*As a former graphics student that worked with
Past tense!
It drives me nuts that they recently made it necessary to dig to change alignment, which I do many times every build session. It’s obvious that A) those employees altering the build ui never actually build anything, and B) they don’t consider building important.
Building, custom animation, machinima/photography are the peerless SL strengths with which no other program can compare.
Odd, no?
And now it has been brought back to life by Oz in https://jira.secondlife.com/browse/STORM-468
And Qarl declines to make the changes Charlar wanted.
http://www.qarl.com/qLab/?p=79
Squandered opportunity for Linden Lab to demonstrate how successful Snowstorm could be. Oh well. Nice job, Charlar.