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.
| 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. | |  | |
Tags: Dil Spitz, JIRA, Karl Stiefvater / Qarl Linden / Qarl Fizz, Linden Lab / Linden Research Inc, Open source, Opinion, Prims, Second Life, Virtual Environments and Virtual Worlds
This entry was posted
on Friday, 13th January, 2012.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.
Possibly related posts
Qarl contributes alignment tool to Linden Lab, Fredrik Linden announces departure from Linden Lab, Why should Linden Lab listen to your feedback anyway?, Linden Lab comments officially on RedZone, In bed with Linden Lab
Wow! I’m not sure I’m surprised though. And maybe I don’t care much since I’m not likely to ever use the stock LL viewer for any length of time.
But, it is a useful tool that adds useful function and it is difficult to understand why it wouldn’t be accepted. I suspect it is more of an emotional decision than a technical one. Maybe they just don’t want to give Qarl the satisfaction?
The tone of the note doesn’t leave me with the feeling that they’d accept it even after making those changes. Note the part that says, (paraphrased) after the functionality was fixed, there’d still be some implementation style issues that would need to be addressed.
So, will they give the same reception to the parametric deformer that Qarl is working on?
Failure for Snowstorm.
And quite ironic Linden Lab is essentially labeling this half-ass when that’s essentially their forte with releasing new features. Rarely if ever do we get features that work 100% ideal. Big or small. Windlight, mesh, basic viewer, etc.
Not saying their logic is bad, but these are clearly standards they don’t hold themselves to. There’s a lot of value to the prim alignment tool as is, more than a typical new Linden Lab feature, and certainly other contributors would want to improve it via Snowstorm, no?
Oh well.
Two comments:
* This looks like a case of “not invented here syndrome”. That is where something is rejected simply because the organization didn’t think of it themselves. It requires admitting that someone else is better than you at doing your job, which is hard.
* This will tend to encourage people to keep using third party viewers. The more features in such viewers that the Linden viewer does not have, the more people will go and use them.
“Not-Invented-here syndrome”, along with a healthy dose of “GTFO, we laid you off so stop making us look bad”.
What’s so sad is, even though this is just one issue that won’t make or break the grid, there won’t be any repercussions. No second thoughts. Nothing learned. No sweat off Charlar’s brow or Rod’s. They might smile at one another Monday morning.
I’m quickly, quickly losing faith in Linden Lab. It’s just insane how willfully ignorant they choose to be sometimes.
This is ‘doh!’ moment number two in recent months for Charlar to me. The first was him going on the Metareality podcast and basically saying even though mesh beta creators were telling him mesh clothing was going to be big, Linden Lab doubted that. Really? Look at Marketplace! Browse about inworld. There’s a crapload of clothing stores and clothed people.
For judging the prim alignment tool, observe most shapes rezzed and aligned in duplicate like walls of houses and roads. They aren’t made of tori and spheres; why should the fact the prim alignment tool doesn’t line up those and rubber duck sculpties prevent it from being implemented to handle the 99% of the time use case of lining up rectangles? Thanks for being concerned I can’t line up 20 couches as easily as 20 cubes, but when the hell would I ever need to do that?
The shot callers are OBLIVIOUS to how Second Life is used at its most basic. it should be a freakin’ requirement that the ones making creation tools actually create!
God, Rod should feel ashamed of this company he’s running.
Dear LL,
“Don’t look a gift horse in the mouth.”
I know that is an old saw, but it could never be more apt than in this case.
Your argument that ZERO functionality is better than some is utterly ludicrous.
Yes, I DO think this is personal. And that makes this issue both ugly and petty.
My two cents.
All of those criticisms in the JIRA are correct. If the SL viewer had an align tool like Qarl’s when you first started using it, and it failed to align on an arbitrary diagonal, or in reference mode, you’d complain that it was incomplete, and how dare LL release such halfwayware.
But since LL QA has determined that halfwayware is not enough – which is exactly what QA is supposed to do – it’s all sour grapes and LL is evil for not being nice to Qarl.
I’d encourage Qarl to work on it some more and address some of these issues.
Everybody is on edge because LL’s reaction on Quarl’s contributions is a decisive factor to regain trust. You can’t ask LL to lower their expectations on quality. It should be be the other way around, whatever source and features. I don’t know this guy Charlar but his announcement was quite formal and that makes it even more disappointing. Doesn’t mean that everything he said is wrong. Their reaction on Quarl’s mesh deformer is crucial. If they turn THAT also down so easily, it will be unreasonable to care for SL anymore.
*Qarl
*lol*
It matters that the criticisms are correct, but it matters more that Linden Lab has long since adopted a development style of release early and release often on new features, which equates to releasing incomplete features that are later improved upon. Its their mantra, they’re proud of it, and there’s nothing wrong with it. It’s an entirely common style of releasing open source software.
What’s wrong is that Linden Lab is holding this patch from Qarl to standards they themselves don’t hold their new features to. What’s wrong is they’re denying the patch because of outlying use cases that simply won’t matter to most of us most of the time.
99% of us don’t build our houses or otherwise arrange prims diagonally. Even if we needed the end result of something like a house to be diagonal, we simply rotate the final linkset. Its silly to deny the patch over hypothetical use cases like this as if they matter more than how we actually build.
And yes as Trin put it, its more than just -this- particular nitpicking. Its precedence. Understand that the mesh deformer code is subject to the same scrutiny because, even though Oz is facilitating the mesh deformer feature a bit more than he would a normal contribution, its still subject to the normal open source contribution clauses. Which means Charlar could probably pull some more things out of thin air that he deems must be done by Qarl for the feature to be patched in at all. Things that exceed what Qarl was paid for.
Come on now. This nitpicking is juvenile. We’re talking about missing features here that don’t exist -now-. New features are being refused because they don’t include what doesn’t already exist. It’d be another thing if Qarl was introducing bug but he’s introducing 100% value. Its turned down because Charlar wants 120% value. So we’re getting 0.
I read this as LL expecting support issues if they implement it as is, it doesn’t work in certain scenarios and people would raise Jiras etc. a bit along the lines of the reasons of the developers of Blender talking of dropping COLLADA import/export from future releases.
What I’m wondering is – if the Lab thinks it needs some alterations – why not make them, as they have done in the past? The open source contribution system is supposed to be collaborative – not a buffet of ready-made products and features.
In fact, in the past, the Lab has often routinely completely rewritten contributions from the ground up. Today seems… different.
I’ve never used the Prim Alignment tool in the viewers which have it, just doing this sort of stuff by hand and eye and metal arithmetic. But the response does give me the impression that the people making the rejection know sweet fanny adams about building.
Yes, I can see why it looks a flawed solution.
But…
“There are also some coding implementation style issues that would need to be addressed.”
We’re talking about a programmer who has worked in the company. Maybe the Lindens have changed their rules on some things, but this doesn’t sound right for work by a former insider. What has he done wrong: put useful comments in the code?
And…
“It’s not usable by non-building residents who need to place and organize purchased items.”
What part of “Prim Alignment Tool” don’t you understand, Mr. Linden? It sounds as if you want a chisel to be usable as an Allen key, for when the user gets his furniture from Ikea.
Linden Lab managed to hire some people that are really damaging to the company. I believe that Charlar Linden is one of these people.
Charlar was in charge of the mesh project (at least in the later phases of it development and release). He insisted on shipping it incomplete, without support for mesh clothing adjusting with the body shape. He also refused to listen to all the feedback regarding inconsistencies with Prim Equivalence/Land Impact calculations. Both of these greatly hamper the adoption of mesh which had a potential to be a big win had it been managed properly.
It is really rich that he know rejects the prim alignment tool by calling it incomplete.
I really wish there was some sort adult supervision at the exec level of Linden Lab that was capable of identifying damage like this and doing something to address it.
I don’t think it has anything to do with code. At least it was not Oz that posted the rejection.
@Ann I agree. JIRAs that are calling for code refinement are not closed as “Won’t finish”.
They stay open.
Is LL not aware of how often their actions and words make it seem like they don’t want people to like them, much less wanna do business with them?
Most of the deficiencies of Qarl’s alignment tool are caused by the viewer’s own limits.
Anyone who has stuck a few prims together knows they can’t build seamlessly with the Local ruler…I’ve always assumed local ruler errors are caused my the doubling or tripling of errors adding up, due to using two or more global axis at once. I doubt Qarl can patch around that..
And editing No Mod objects has been broken for years( no undo/redo steps). I bet fixing this will add No Mod functionality to Qarl’s aligner.
And most of all, the only prims this really needs to work with are cubes and cylinders. No other prims need to be aligned with such scrutiny.
It will never work with mesh or scuplts, as their bounding boxes are random or very different than their visual geometry.
@LL, Just hide the tool in the advanced menu and call it “Prim cube/cylinder alignment for use while in global ruler mode”…..
I just hope this isn’t a preface for incoming mesh attachment resizing stuffs.
((pre morning coffee post, grammar, spelling, nor formatting included. ))
I just looked at the actual jira. “Closed/Won’t Finish?” Is that the standard way they run Snowstorm if they are expecting further collaboration? I’m really just asking here. That isn’t the way I’ve seen other open source projects run unless they have no interest in the feature being added.
I think the real strike against the tool is that it produces unexpected (if not technically speaking unpredictable) results when used outside the narrow use case it was intended for, no matter how common and useful that case is.
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.
But perhaps a solution would be to include some safeguards against accidents when you’re outside the defined use, rather than reworking the functionality to hypothetical situations which builders rarely find themselves in anyway.
But then, you get weird, “magical” hoops to jump through before you’re allowed to use it, which would *also* make the viewer seem random and willful.