[opensource-dev] Found long-standing prim rotation bug: BUG-885

2012-11-25 Thread Ricky
Just reported BUG-885 ,
"Edge-on prim rotation snaps when snap is disabled"  Patch attached.

Looks like this bug has been in place for a very long time - dates back to
revision 0 of the code repository, committed by James Cook (James Linden).

I've been delving back into the source code after a year and a half away.
 I have to compliment LL, and all else involved, on the streamlined compile
setup - smoother even than the old develop.py system, definitely better
than the transition period when I last attempted! :D

I found this bug while I was working on learning/cleaning the code
structure in the LLManip* classes in preparation for reviving an old
project.  Imagine my surprise when I found that one of the cases didn't
have a check for whether Snapping was enabled!  So I took to opportunity to
delve deeper and work out a fix.  Enjoy!

Ricky
Cron Stardust

PS, for Firestorm I also reported it as
FIRE-8338 as
that is where I originally found the bug - however it exists in every
viewer I've looked at.  Based on my research I think it's been in existence
since snapping was first introduced - whenever that was!
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Found long-standing prim rotation bug: BUG-885

2012-11-25 Thread Ricky
For a missing hyphen... :)  I meant edge-on.

Here's how to reproduce the issue:
Rez a cube
Verify that Snap is disabled
Orient camera to directly face one of the prim faces
Select rotate mode or hold the correct modifier key(s)
Using the mouse drag on the rotate circle that is most like a line - aka it
is "edge-on"
Observe that as you drag along the line of circle the cube it rotates
smoothly (expected)
Observe that if you drag off the line - as if snapping was enabled and you
wished to snap - and then again in the direction of the line that it will
snap. (not expected)

Hope that helps clarify


Ps. Sorry for the dup email Darien, I forgot to reply all.

On Sunday, November 25, 2012, Darien Caldwell 
wrote:
> I'm a little unsure what "Edge on rotation" means. I can rotate a prim on
every axis in-world with snap off, and it never snaps. At least, not unless
I make it snap by engaging the Angle ring outside the circumfrence of the
rotation handle. Then it snaps as it should.
>
> I hope your patch isn't breaking this functionality, it's intended and
desirable.
>
> On Sun, Nov 25, 2012 at 8:23 PM, Ricky  wrote:
>>
>> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
disabled"  Patch attached.
>> Looks like this bug has been in place for a very long time - dates back
to revision 0 of the code repository, committed by James Cook (James
Linden).
>> I've been delving back into the source code after a year and a half
away.  I have to compliment LL, and all else involved, on the streamlined
compile setup - smoother even than the old develop.py system, definitely
better than the transition period when I last attempted! :D
>> I found this bug while I was working on learning/cleaning the code
structure in the LLManip* classes in preparation for reviving an old
project.  Imagine my surprise when I found that one of the cases didn't
have a check for whether Snapping was enabled!  So I took to opportunity to
delve deeper and work out a fix.  Enjoy!
>> Ricky
>> Cron Stardust
>> PS, for Firestorm I also reported it as FIRE-8338 as that is where I
originally found the bug - however it exists in every viewer I've looked
at.  Based on my research I think it's been in existence since snapping was
first introduced - whenever that was!
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
privileges
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Found long-standing prim rotation bug: BUG-885

2012-11-25 Thread Darien Caldwell
Ahh, I see what you mean. it's acting as if the hidden snap ring is still
present.  A sneaky bug. :)


On Sun, Nov 25, 2012 at 10:13 PM, Ricky  wrote:

> For a missing hyphen... :)  I meant edge-on.
>
> Here's how to reproduce the issue:
> Rez a cube
> Verify that Snap is disabled
> Orient camera to directly face one of the prim faces
> Select rotate mode or hold the correct modifier key(s)
> Using the mouse drag on the rotate circle that is most like a line - aka
> it is "edge-on"
> Observe that as you drag along the line of circle the cube it rotates
> smoothly (expected)
> Observe that if you drag off the line - as if snapping was enabled and you
> wished to snap - and then again in the direction of the line that it will
> snap. (not expected)
>
> Hope that helps clarify
>
>
> Ps. Sorry for the dup email Darien, I forgot to reply all.
>
> On Sunday, November 25, 2012, Darien Caldwell 
> wrote:
> > I'm a little unsure what "Edge on rotation" means. I can rotate a prim
> on every axis in-world with snap off, and it never snaps. At least, not
> unless I make it snap by engaging the Angle ring outside the circumfrence
> of the rotation handle. Then it snaps as it should.
> >
> > I hope your patch isn't breaking this functionality, it's intended and
> desirable.
> >
> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky  wrote:
> >>
> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
> disabled"  Patch attached.
> >> Looks like this bug has been in place for a very long time - dates back
> to revision 0 of the code repository, committed by James Cook (James
> Linden).
> >> I've been delving back into the source code after a year and a half
> away.  I have to compliment LL, and all else involved, on the streamlined
> compile setup - smoother even than the old develop.py system, definitely
> better than the transition period when I last attempted! :D
> >> I found this bug while I was working on learning/cleaning the code
> structure in the LLManip* classes in preparation for reviving an old
> project.  Imagine my surprise when I found that one of the cases didn't
> have a check for whether Snapping was enabled!  So I took to opportunity to
> delve deeper and work out a fix.  Enjoy!
> >> Ricky
> >> Cron Stardust
> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where I
> originally found the bug - however it exists in every viewer I've looked
> at.  Based on my research I think it's been in existence since snapping was
> first introduced - whenever that was!
> >> ___
> >> Policies and (un)subscribe information available here:
> >> http://wiki.secondlife.com/wiki/OpenSource-Dev
> >> Please read the policies before posting to keep unmoderated posting
> privileges
> >
> >
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Found long-standing prim rotation bug: BUG-885

2012-11-25 Thread Ricky
Yep - so sneaky it's not been noticed for years. I think it's because
no-one actually uses that part of the editors functionality!

Leaves me wondering about when the snap functionality was introduced... The
repository doesn't go back that far! :)

On Sunday, November 25, 2012, Darien Caldwell 
wrote:
> Ahh, I see what you mean. it's acting as if the hidden snap ring is still
present.  A sneaky bug. :)
>
> On Sun, Nov 25, 2012 at 10:13 PM, Ricky  wrote:
>>
>> For a missing hyphen... :)  I meant edge-on.
>>
>> Here's how to reproduce the issue:
>> Rez a cube
>> Verify that Snap is disabled
>> Orient camera to directly face one of the prim faces
>> Select rotate mode or hold the correct modifier key(s)
>> Using the mouse drag on the rotate circle that is most like a line - aka
it is "edge-on"
>> Observe that as you drag along the line of circle the cube it rotates
smoothly (expected)
>> Observe that if you drag off the line - as if snapping was enabled and
you wished to snap - and then again in the direction of the line that it
will snap. (not expected)
>>
>> Hope that helps clarify
>>
>>
>> Ps. Sorry for the dup email Darien, I forgot to reply all.
>>
>> On Sunday, November 25, 2012, Darien Caldwell 
wrote:
>> > I'm a little unsure what "Edge on rotation" means. I can rotate a prim
on every axis in-world with snap off, and it never snaps. At least, not
unless I make it snap by engaging the Angle ring outside the circumfrence
of the rotation handle. Then it snaps as it should.
>> >
>> > I hope your patch isn't breaking this functionality, it's intended and
desirable.
>> >
>> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky  wrote:
>> >>
>> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
disabled"  Patch attached.
>> >> Looks like this bug has been in place for a very long time - dates
back to revision 0 of the code repository, committed by James Cook (James
Linden).
>> >> I've been delving back into the source code after a year and a half
away.  I have to compliment LL, and all else involved, on the streamlined
compile setup - smoother even than the old develop.py system, definitely
better than the transition period when I last attempted! :D
>> >> I found this bug while I was working on learning/cleaning the code
structure in the LLManip* classes in preparation for reviving an old
project.  Imagine my surprise when I found that one of the cases didn't
have a check for whether Snapping was enabled!  So I took to opportunity to
delve deeper and work out a fix.  Enjoy!
>> >> Ricky
>> >> Cron Stardust
>> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where I
originally found the bug - however it exists in every viewer I've looked
at.  Based on my research I think it's been in existence since snapping was
first introduced - whenever that was!
>> >> ___
>> >> Policies and (un)subscribe information available here:
>> >> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> >> Please read the policies before posting to keep unmoderated posting
privileges
>> >
>> >
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Found long-standing prim rotation bug: BUG-885

2012-11-25 Thread Lance Corrimal
Verified - Now I'm sticking the patch in a test build to see if it breaks 
other stuff.

Do you have CA on file?

bye,
LC


Am Sonntag, 25. November 2012, 23:26:53 schrieb Ricky:
> Yep - so sneaky it's not been noticed for years. I think it's because
> no-one actually uses that part of the editors functionality!
> 
> Leaves me wondering about when the snap functionality was introduced... The
> repository doesn't go back that far! :)
> 
> On Sunday, November 25, 2012, Darien Caldwell 
> 
> wrote:
> > Ahh, I see what you mean. it's acting as if the hidden snap ring is still
> 
> present.  A sneaky bug. :)
> 
> > On Sun, Nov 25, 2012 at 10:13 PM, Ricky  wrote:
> >> For a missing hyphen... :)  I meant edge-on.
> >> 
> >> Here's how to reproduce the issue:
> >> Rez a cube
> >> Verify that Snap is disabled
> >> Orient camera to directly face one of the prim faces
> >> Select rotate mode or hold the correct modifier key(s)
> >> Using the mouse drag on the rotate circle that is most like a line - aka
> 
> it is "edge-on"
> 
> >> Observe that as you drag along the line of circle the cube it rotates
> 
> smoothly (expected)
> 
> >> Observe that if you drag off the line - as if snapping was enabled and
> 
> you wished to snap - and then again in the direction of the line that it
> will snap. (not expected)
> 
> >> Hope that helps clarify
> >> 
> >> 
> >> Ps. Sorry for the dup email Darien, I forgot to reply all.
> >> 
> >> On Sunday, November 25, 2012, Darien Caldwell 
> 
> wrote:
> >> > I'm a little unsure what "Edge on rotation" means. I can rotate a prim
> 
> on every axis in-world with snap off, and it never snaps. At least, not
> unless I make it snap by engaging the Angle ring outside the circumfrence
> of the rotation handle. Then it snaps as it should.
> 
> >> > I hope your patch isn't breaking this functionality, it's intended and
> 
> desirable.
> 
> >> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky  wrote:
> >> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
> 
> disabled"  Patch attached.
> 
> >> >> Looks like this bug has been in place for a very long time - dates
> 
> back to revision 0 of the code repository, committed by James Cook (James
> Linden).
> 
> >> >> I've been delving back into the source code after a year and a half
> 
> away.  I have to compliment LL, and all else involved, on the streamlined
> compile setup - smoother even than the old develop.py system, definitely
> better than the transition period when I last attempted! :D
> 
> >> >> I found this bug while I was working on learning/cleaning the code
> 
> structure in the LLManip* classes in preparation for reviving an old
> project.  Imagine my surprise when I found that one of the cases didn't
> have a check for whether Snapping was enabled!  So I took to opportunity to
> delve deeper and work out a fix.  Enjoy!
> 
> >> >> Ricky
> >> >> Cron Stardust
> >> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where I
> 
> originally found the bug - however it exists in every viewer I've looked
> at.  Based on my research I think it's been in existence since snapping was
> first introduced - whenever that was!
> 
> >> >> ___
> >> >> Policies and (un)subscribe information available here:
> >> >> http://wiki.secondlife.com/wiki/OpenSource-Dev
> >> >> Please read the policies before posting to keep unmoderated posting
> 
> privileges
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges