Re: [opensource-dev] grid-wide banners

[Opensource Obscure]

I assume you already sent messages, notecards, emails and whatever
to the creator of that device.

I think nobody can tell you if that will work, but nonetheless I would file
at least a detailed Abuse Report.

That said:

I'm a Linux user and I can take SL videos. Let me know if you want me to
help - we may create a video that shows what happens - that is, being
banned while using a legit official SL viewer. Spreading such a video
may seriously damage the device creator's reputation, raising the chance
he will fix his product. Also, you could use the video it as a proof when
you will contact sim owners, in order to show them they're using (and
I guess paying for) a device that prevents legit users from visiting
their lands.

Please note I don't and can't access to Adult areas - so I couldn't help
if we're talking about Zindra regions.

Opensource Obscure

On Tue, Dec 21, 2010 at 02:57, Glen Canaday  wrote:
> zFire Xue's device has now identified linden build 2.4.0 (216989) for Linux as
> a copybot client. I know this is not the correct forum, but I need a hotline
> to get rid of this guy and this product. It has seriously messed with my
> enjoyment of SL by banning me from EVERY one of his customer's sims. ALL of
> them. That includes normally quiet public places, such as the Shelman Sandbox.
> Now I have no idea where I can go and cannot go - and my partner is now
> similarly affected.
>
> I simply want rid of this guy and his "product." Does anyone know the proper
> forum for this? Does anyone know if an AR will ever cut it in this situation?
>
> --GC
> ___
> 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
>



-- 
Opensource Obscure

Twitter [EN] - Twitter [IT] - Blog [IT] - YouTube - Photos - Second Life
___
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] Review Request: STORM-702 Make it possible to wear partial outfits

[Aleric Inglewood]

> On 2010-12-20 14:40:41, Nyx Linden wrote:
> > I have no technical objections to the code provided.
> > And in fact, the code provided *should* change the functionality back to 
> > what the users are reporting is their expectation of what the behavior 
> > should be.
> > 
> > The part that makes me nervous is that this enables an outfit operation for 
> > a class of folders that we have not allowed with the new outfit system 
> > previously. Based on other pieces on the code that would get called by this 
> > operation, I believe that the result will be that of the resident request 
> > to "revert" behavior (namely remove all clothing, remove body parts that 
> > are replaced by the new folder, leave old body parts that are necessary to 
> > display the avatar). 
> > 
> > That being said, we need a more comprehensive review of the role of 
> > incomplete outfits and how it fits with our technical architecture we've 
> > built up in our current outfits system. The code here should implement the 
> > correct behavior and I have no technical issues with it. But I want to make 
> > sure that we are aware of the risk of edge cases as we have not considered 
> > possibly popping up as a result of this patch.

My (mathematical) analysis of the "outfit system"
=

- The outfit system exists of sets and operators.

- Each operator works on two sets, where both sets are an input and one of the 
sets is used as output; this would be irrelevant for what the operators do 
except when those operators are not commutative (which is be Bad Thing, but 
unfortunately they are not). If one of those operators is written as '+' 
(whatever that does), then for now we can speak about a + b, which doesn't 
imply that this is the same as b + a and which intuitively extends to the 
definition a += b ==> a = a + b. Note that the '+' operator is abritrary, 
replace + with - and the same story holds.

- The elements of each set do not have the same type, and if they don't then an 
operator can't work on them. Therefore, the correct way to look at these sets 
is as vectors where an absent type will be represented by '0' (zero). That is 
an arbitrary choice, but intuitive because our operators will be a lot more 
like groups than like fields. Of course, this implies that a + 0 = 0 + a = a.

- Our vector (V) has one element per type. The types are: shape, (Linden) hair, 
(Linden) shoes, eyes, skin, alpha, tatoes, undershirts, shirts, jackets, 
gloves, undies, pants, socks, skull attachments, nose attachments, etc (one 
type for each different attachment point).

- The elements of this vector are sets: for some types it is possible to wear 
multiple of the same type at the same time. Note that these are sets, not 
vectors: the order in which these wearables are added SHOULD be irrelevant (at 
the moment it isn't; for example, old viewers only show the first attachment 
that was attached, so the order is important).

- Some types may only have a single element (in their set) at a time. As a 
result their operators are clearly not commutative, that is impossible. These 
types are: shape, hair, shoes, eyes, skin and alpha (I think; the exact list is 
irrelevant at this point). Lets call this class of types: S (of 'Single').

- The other types can be divided into two classes: wearables (tatoes, 
(under)shirts, jackets, gloves, pants, socks) and attachments (skull, nose, 
...). For an intuitive functioning of the outfit system these SHOULD behave the 
same mathematically, but at this point we can't be certain if they do. However, 
it will be clear that all wearables and all attachments respectively behave the 
same. Lets call these classes W and A. [Note that V doesn't have to be 
implemented as a linear vector, I think it would be better to implement it as a 
vector of three vectors: one vector for elements of class S, one for elements 
of class W and one for elements of class A.]

- For the S class we CAN have the following operations.

  Let x and y be two distinct elements of the same type, where the type is of 
class S.
  [Note that for the Current Outfit the empty set is not allowed.]
  Picking two arbitrary characters (+ and -) we can write for the possible 
operators: x + y = y, x - y = x.
  Other operators do not exist, but if they do out of necessity (namely, these 
are elements of a vector and we will need to define operators of the vector, 
which then in turn work on all types), then we can choose to let them be 
equivalent to either + or -. Also note that this choice defines our extended 
operators += and -= as: x += y ==> x = y, and x -= y ==> nul operator.

- For the A class we CAN have the following operations.

  Let a and b be sets. Note that any distinct element can only be once in a 
set: { e1 } + { e1 } = { e1 }, but { e1 } - { e1 } = { 0 }.
  Hence, also this class is not a group, but so far the operators are 
commutative: a + b = b + a, etc, but there is no well defined i

[opensource-dev] Need test of (32bit) linux build

[Oz Linden (Scott Lawrence)]

Aleric has got a collection of proposed build system improvements that 
are under review.

I've done a test build of them, and have already confirmed that the 
resulting viewers work fine on the Mac and on Windows (thank you, 
Wolfpup).  Would someone who's got a handy Linux system please download 
the installer from

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/217631/index.html

and let me know if you run into any issues?

___
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] Test build for a bunch of proposed patches

[Philippe (Merov) Bossut]

Hi,

Thanks Trilo for the tests.
Forwarding to the list as it is of interest to all.

Cheers,
- Merov

On Tue, Dec 21, 2010 at 10:32 PM, Trilo Byte wrote:

> I commented in the JIRA issues as well.
>
> ** STORM-785 - works well
>
> ** STORM-737 - works beautifully, thank you!
>
> ** STORM-723 - works, except there is a problem if single prim object has
> contents in it.
>
> ** STORM-669 - looks good
>
> ** STORM-387 - Works as expected
>
> ** STORM-615 - Excellent, all menus look/work as expected, no more nested
> delete button!
> ** STORM-411 - looks great!
>
> Side note... tab key's broken on this build too.  You had previously taken
> a quick look at VWR-24172 back when it had been fixed in Viewer Development
> (and couldn't repro), but it was broken again in 217184 and has been since.
> :-(
>
> Trilo
>
>
> On Dec 21, 2010, at 1:34 PM, Philippe (Merov) Bossut wrote:
>
> Hi guys,
>
> Quite a few proposed changesets required a test build to be reviewedand
> approved  by Esbee and others. I created such a build and it's available
> here:
>
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217627/index.html
>
> This merges the following patches on top of the current viewer-development:
> ** STORM-785
> ** STORM-737
> ** STORM-723
> ** STORM-669
> ** STORM-387
> ** STORM-615
> ** STORM-411
>
> Enjoy!
> - Merov
>  ___
>
> 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] Test build for a bunch of proposed patches

[Erin Mallory]

since i sent this last night and it doesnt seem to have hit the list... im 
resending it

From: angel_of_crim...@hotmail.com
To: me...@lindenlab.com; opensource-dev@lists.secondlife.com
Date: Tue, 21 Dec 2010 23:24:25 -0500
Subject: Re: [opensource-dev] Test build for a bunch of proposed patches








fix for storm 737 seems to work without breaking anything.  On the contrary it 
is a wonderful little fix. 
723 has issues please see my comments on the jira 
669 looks good
387 looks good. 
615 will take some getting used to simply because its a change, but looks very 
useful. 
411 seems good to me.
the only issue i see so far is 723...



From: me...@lindenlab.com
Date: Tue, 21 Dec 2010 13:34:14 -0800
To: opensource-dev@lists.secondlife.com
Subject: [opensource-dev] Test build for a bunch of proposed patches

Hi guys,

Quite a few proposed changesets required a test build to be reviewedand 
approved  by Esbee and others. I created such a build and it's available here:
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217627/index.html



This merges the following patches on top of the current viewer-development:
** STORM-785
** STORM-737
** STORM-723
** STORM-669
** STORM-387
** STORM-615
** STORM-411

Enjoy!
- Merov



___
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  
  ___
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

[opensource-dev] Odd issue in build 217714

[WolfPup Lowenhar]

There is an odd issue in Build 217714 of viewer-development. I noticed it
this morning while helping to test a build for Oz. Issue is occurring in all
three viewers I tested it in. I need help verifying if it is occurring in
other OS's.

 

TO repro:

1. Goto Esbees in world office.

2. Right click on the sand castle and slect object profile.(this item
generates the hight rate of this issue)

3. Look at the avatar icons next to each person's name and watch them
jump down and to the left ~10 pixiels.

 

My system information:

 

Second Life 2.5.0 (0) Dec 22 2010 01:37:19 (Second Life Developer)

Release Notes

 

You are at 238,528.0, 244,842.0, 21.7 in Hippotropolis located at
sim4038.agni.lindenlab.com (216.82.18.81:13002)

Second Life Server 10.11.30.215699

Release Notes

 

CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2800.12 MHz)

Memory: 2046 MB

OS Version: Microsoft Windows 7 32-bit  (Build 7600)

Graphics Card Vendor: NVIDIA Corporation

Graphics Card: GeForce 8500 GT/PCI/SSE2

 

Windows Graphics Driver Version: 8.17.0012.5896

OpenGL Version: 3.3.0

 

libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8j zlib/1.2.3 c-ares/1.7.1

J2C Decoder Version: OpenJPEG: 1.3.0, Runtime: 1.3.0

Audio Driver Version: FMOD version 3.75

Qt Webkit Version: 4.6 (version number hard-coded)

Voice Server Version: Vivox 3.2.0002.9361

 

Built with MSVC version 1400

Packets Lost: 0/98,428 (0.0%)

 

___
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] Odd issue in build 217714

[Oz Linden (Scott Lawrence)]

On 2010-12-22 11:20, WolfPup Lowenhar wrote:


There is an odd issue in Build 217714 of viewer-development. I noticed 
it this morning while helping to test a build for Oz. Issue is 
occurring in all three viewers I tested it in. I need help verifying 
if it is occurring in other OS's.


TO repro:

1.Goto Esbees in world office.

2.Right click on the sand castle and slect object profile.(this item 
generates the hight rate of this issue)


3.Look at the avatar icons next to each person's name and watch them 
jump down and to the left ~10 pixiels.





I'm seeing that on Second Life 2.5.0 (217108) Dec 16 on a Mac, too...   
I guess we need an issue on it.


___
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

[opensource-dev] Review Request: Update returnability of objects based on new encroachment rules

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/56/
---

Review request for Viewer and Andrew Meadows.


Summary
---

The object-vs-parcel overlap test is done by building axis-aligned bounding 
boxes (AABB) about each prim of the selected objects and then checking for 
overlap between those boxes and self- and group-owned parcels. 


This addresses bug STORM-807.
http://jira.secondlife.com/browse/STORM-807


Diffs
-

  indra/llcommon/llversionserver.h fc82190a3f0c 
  indra/llcommon/llversionviewer.h fc82190a3f0c 
  indra/llmath/llbbox.h fc82190a3f0c 
  indra/llmath/llbbox.cpp fc82190a3f0c 
  indra/llmessage/llregionflags.h fc82190a3f0c 
  indra/newview/English.lproj/InfoPlist.strings fc82190a3f0c 
  indra/newview/Info-SecondLife.plist fc82190a3f0c 
  indra/newview/llviewermenu.cpp fc82190a3f0c 
  indra/newview/llviewerobject.h fc82190a3f0c 
  indra/newview/llviewerobject.cpp fc82190a3f0c 
  indra/newview/llviewerparceloverlay.h fc82190a3f0c 
  indra/newview/llviewerparceloverlay.cpp fc82190a3f0c 
  indra/newview/llviewerregion.h fc82190a3f0c 
  indra/newview/llviewerregion.cpp fc82190a3f0c 
  indra/newview/res/viewerRes.rc fc82190a3f0c 
  indra/newview/skins/default/xui/en/menu_viewer.xml fc82190a3f0c 

Diff: http://codereview.secondlife.com/r/56/diff


Testing
---


Thanks,

Merov

___
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] Review Request: Update returnability of objects based on new encroachment rules

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/56/#review64
---


Few things I'd like to see fixed before moving to integration:
llversionserver.h : this change is irrelevant to the issue, take out.
llversionviewer.h : same
llregionflags.h : are all those changes relevant to the issue? I can see the 
interest of REGION_FLAGS_ALLOW_RETURN_ENCROACHING_OBJECT but what about all the 
other flags suppressed or commented out? Anything in there changed that 
shouldn't?
InfoPlist.strings : don't change that, let release do this when it's necessary 
to release a version
Info-SecondLife.plist : same
viewerRes.rc : same


- Merov


On 2010-12-22 09:37:08, Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/56/
> ---
> 
> (Updated 2010-12-22 09:37:08)
> 
> 
> Review request for Viewer and Andrew Meadows.
> 
> 
> Summary
> ---
> 
> The object-vs-parcel overlap test is done by building axis-aligned bounding 
> boxes (AABB) about each prim of the selected objects and then checking for 
> overlap between those boxes and self- and group-owned parcels. 
> 
> 
> This addresses bug STORM-807.
> http://jira.secondlife.com/browse/STORM-807
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llversionserver.h fc82190a3f0c 
>   indra/llcommon/llversionviewer.h fc82190a3f0c 
>   indra/llmath/llbbox.h fc82190a3f0c 
>   indra/llmath/llbbox.cpp fc82190a3f0c 
>   indra/llmessage/llregionflags.h fc82190a3f0c 
>   indra/newview/English.lproj/InfoPlist.strings fc82190a3f0c 
>   indra/newview/Info-SecondLife.plist fc82190a3f0c 
>   indra/newview/llviewermenu.cpp fc82190a3f0c 
>   indra/newview/llviewerobject.h fc82190a3f0c 
>   indra/newview/llviewerobject.cpp fc82190a3f0c 
>   indra/newview/llviewerparceloverlay.h fc82190a3f0c 
>   indra/newview/llviewerparceloverlay.cpp fc82190a3f0c 
>   indra/newview/llviewerregion.h fc82190a3f0c 
>   indra/newview/llviewerregion.cpp fc82190a3f0c 
>   indra/newview/res/viewerRes.rc fc82190a3f0c 
>   indra/newview/skins/default/xui/en/menu_viewer.xml fc82190a3f0c 
> 
> Diff: http://codereview.secondlife.com/r/56/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Merov
> 
>

___
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] Review Request: Update returnability of objects based on new encroachment rules

[Aleric Inglewood]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/56/#review65
---


I have the feeling that this notion of 'encroachesOwned' is going to cause a 
lot of trouble in the case of sculptures.
At the very least you should use use an aligned bb that is the minimal bb for 
anything *visible* of a prim. In the case
of the sculptures this requires a special function to find the min/max 
coordinates of all the points used. The same
story holds for path cut-off (mega) prims. Ie, if I resize a megaprim (the ONLY 
way to resize a mega prim is
by using one of those prim torture tricks) then it's very possible one ends up 
with a prim that is just 1/3 of it's "size".
It wouldn't be fair when a house that clearly ends on ones own parcel is 
"detected" to encroach another parcel, just
because the viewer code is too lame to take path cutting and sphere dimples etc 
into account.


- Aleric


On 2010-12-22 09:37:08, Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/56/
> ---
> 
> (Updated 2010-12-22 09:37:08)
> 
> 
> Review request for Viewer and Andrew Meadows.
> 
> 
> Summary
> ---
> 
> The object-vs-parcel overlap test is done by building axis-aligned bounding 
> boxes (AABB) about each prim of the selected objects and then checking for 
> overlap between those boxes and self- and group-owned parcels. 
> 
> 
> This addresses bug STORM-807.
> http://jira.secondlife.com/browse/STORM-807
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llversionserver.h fc82190a3f0c 
>   indra/llcommon/llversionviewer.h fc82190a3f0c 
>   indra/llmath/llbbox.h fc82190a3f0c 
>   indra/llmath/llbbox.cpp fc82190a3f0c 
>   indra/llmessage/llregionflags.h fc82190a3f0c 
>   indra/newview/English.lproj/InfoPlist.strings fc82190a3f0c 
>   indra/newview/Info-SecondLife.plist fc82190a3f0c 
>   indra/newview/llviewermenu.cpp fc82190a3f0c 
>   indra/newview/llviewerobject.h fc82190a3f0c 
>   indra/newview/llviewerobject.cpp fc82190a3f0c 
>   indra/newview/llviewerparceloverlay.h fc82190a3f0c 
>   indra/newview/llviewerparceloverlay.cpp fc82190a3f0c 
>   indra/newview/llviewerregion.h fc82190a3f0c 
>   indra/newview/llviewerregion.cpp fc82190a3f0c 
>   indra/newview/res/viewerRes.rc fc82190a3f0c 
>   indra/newview/skins/default/xui/en/menu_viewer.xml fc82190a3f0c 
> 
> Diff: http://codereview.secondlife.com/r/56/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Merov
> 
>

___
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] Review Request: Update returnability of objects based on new encroachment rules

[Liny Odell]

Another key point is "simscapes" that use megaprims that obviously covers
all parcels but is only visible along the outside of the region along the
void. Also, what about prims that are centered in a neiboring region? Are
thous detected as encroaching?

On Wed, Dec 22, 2010 at 10:45 AM, Aleric Inglewood <
aleric.inglew...@gmail.com> wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/56/
>
> I have the feeling that this notion of 'encroachesOwned' is going to cause a 
> lot of trouble in the case of sculptures.
> At the very least you should use use an aligned bb that is the minimal bb for 
> anything *visible* of a prim. In the case
> of the sculptures this requires a special function to find the min/max 
> coordinates of all the points used. The same
> story holds for path cut-off (mega) prims. Ie, if I resize a megaprim (the 
> ONLY way to resize a mega prim is
> by using one of those prim torture tricks) then it's very possible one ends 
> up with a prim that is just 1/3 of it's "size".
> It wouldn't be fair when a house that clearly ends on ones own parcel is 
> "detected" to encroach another parcel, just
> because the viewer code is too lame to take path cutting and sphere dimples 
> etc into account.
>
>
> - Aleric
>
> On December 22nd, 2010, 9:37 a.m., Merov Linden wrote:
>   Review request for Viewer and Andrew Meadows.
> By Merov Linden.
>
> *Updated 2010-12-22 09:37:08*
> Description
>
> The object-vs-parcel overlap test is done by building axis-aligned bounding 
> boxes (AABB) about each prim of the selected objects and then checking for 
> overlap between those boxes and self- and group-owned parcels.
>
>   *Bugs: * STORM-807 
> Diffs
>
>- indra/llcommon/llversionserver.h (fc82190a3f0c)
>- indra/llcommon/llversionviewer.h (fc82190a3f0c)
>- indra/llmath/llbbox.h (fc82190a3f0c)
>- indra/llmath/llbbox.cpp (fc82190a3f0c)
>- indra/llmessage/llregionflags.h (fc82190a3f0c)
>- indra/newview/English.lproj/InfoPlist.strings (fc82190a3f0c)
>- indra/newview/Info-SecondLife.plist (fc82190a3f0c)
>- indra/newview/llviewermenu.cpp (fc82190a3f0c)
>- indra/newview/llviewerobject.h (fc82190a3f0c)
>- indra/newview/llviewerobject.cpp (fc82190a3f0c)
>- indra/newview/llviewerparceloverlay.h (fc82190a3f0c)
>- indra/newview/llviewerparceloverlay.cpp (fc82190a3f0c)
>- indra/newview/llviewerregion.h (fc82190a3f0c)
>- indra/newview/llviewerregion.cpp (fc82190a3f0c)
>- indra/newview/res/viewerRes.rc (fc82190a3f0c)
>- indra/newview/skins/default/xui/en/menu_viewer.xml (fc82190a3f0c)
>
> View Diff 
>
> ___
> 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] Review Request: VWR-20962 CTRL-\ Last chatter

[Jonathan Yap]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/16/
---

(Updated 2010-12-22 11:18:28.916125)


Review request for Viewer.


Changes
---

Aleric showed me a slight optimization in the two function calls I moved to fix 
this issue. In llagentcamera.cpp:

setFocusoOnAvatar(FALSE, FALSE) (was FALSE, TRUE)


Summary
---

You have to push CTRL-\(there is a menu item for this too) twice to get the 
last chatter function to work.  My fix unlocks the camera before moving it.


This addresses bug vwr-20962.
http://jira.secondlife.com/browse/vwr-20962


Diffs (updated)
-

  indra/newview/llagentcamera.cpp 0a1d00f86446 

Diff: http://codereview.secondlife.com/r/16/diff


Testing
---


Thanks,

Jonathan

___
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] Review Request: VWR-20962 CTRL-\ Last chatter

[Jonathan Yap]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/16/
---

(Updated 2010-12-22 11:18:45.942539)


Review request for Viewer.


Summary
---

You have to push CTRL-\(there is a menu item for this too) twice to get the 
last chatter function to work.  My fix unlocks the camera before moving it.


This addresses bug STORM-785.
http://jira.secondlife.com/browse/STORM-785


Diffs
-

  indra/newview/llagentcamera.cpp 0a1d00f86446 

Diff: http://codereview.secondlife.com/r/16/diff


Testing
---


Thanks,

Jonathan

___
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] Review Request: Update returnability of objects based on new encroachment rules

[Andrew Meadows]

Merov -

Thanks for the review.  When I got your email this morning I was in
the middle of tracing back those version number changes and fixing
them.  I picked them up in the very first merge of my outstanding
changes, which was just to get my branch up to date before starting
work.  Both parents of that merge were in the log history, so it
isn't clear what happened to the version numbers I picked up.  I guess
they must have been cleared by by another merge down the line.

As to the llregionflags.h changes...

In short: yes these are the changes you want.

The longer story:
The change there reflects the change that has happened in the server
version of that file since the two projects split.  Most of the change
is the cleanup that I did for this project.  On the server side we've
split the "region flags" into "public" (that get used by both the viewer
and server) and "internal" that are only used by the server.  Most of
the lines that were changed or commented out in llregionflags.h was to
to remove unused or "internal" flags.  Otherwise I added a couple new
public flags that communicate the state of the region's "allow return
of encroaching object" feature.


I've fixed things.  Try again from this repo:

http://bitbucket.org/andrew_linden/viewer-development

revision = ba6d29a97383

- Andrew

On 12/22/2010 09:42 AM, Merov Linden wrote:
> This is an automatically generated e-mail. To reply, visit: 
> http://codereview.secondlife.com/r/56/
>
>
> Few things I'd like to see fixed before moving to integration:
> llversionserver.h : this change is irrelevant to the issue, take out.
> llversionviewer.h : same
> llregionflags.h   : are all those changes relevant to the issue? I can 
> see the interest of REGION_FLAGS_ALLOW_RETURN_ENCROACHING_OBJECT but what 
> about all the other flags suppressed or commented out? Anything in there 
> changed that shouldn't?
> InfoPlist.strings : don't change that, let release do this when it's 
> necessary to release a version
> Info-SecondLife.plist : same
> viewerRes.rc : same
>
>
> - Merov
>
>
> On December 22nd, 2010, 9:37 a.m., Merov Linden wrote:
>
> Review request for Viewer and Andrew Meadows.
> By Merov Linden.
>
> /Updated 2010-12-22 09:37:08/
>
>
>   Description
>
> The object-vs-parcel overlap test is done by building axis-aligned bounding 
> boxes (AABB) about each prim of the selected objects and then checking for 
> overlap between those boxes and self- and group-owned parcels.
>
> *Bugs: * STORM-807 
>
>
>   Diffs
>
> * indra/llcommon/llversionserver.h (fc82190a3f0c)
> * indra/llcommon/llversionviewer.h (fc82190a3f0c)
> * indra/llmath/llbbox.h (fc82190a3f0c)
> * indra/llmath/llbbox.cpp (fc82190a3f0c)
> * indra/llmessage/llregionflags.h (fc82190a3f0c)
> * indra/newview/English.lproj/InfoPlist.strings (fc82190a3f0c)
> * indra/newview/Info-SecondLife.plist (fc82190a3f0c)
> * indra/newview/llviewermenu.cpp (fc82190a3f0c)
> * indra/newview/llviewerobject.h (fc82190a3f0c)
> * indra/newview/llviewerobject.cpp (fc82190a3f0c)
> * indra/newview/llviewerparceloverlay.h (fc82190a3f0c)
> * indra/newview/llviewerparceloverlay.cpp (fc82190a3f0c)
> * indra/newview/llviewerregion.h (fc82190a3f0c)
> * indra/newview/llviewerregion.cpp (fc82190a3f0c)
> * indra/newview/res/viewerRes.rc (fc82190a3f0c)
> * indra/newview/skins/default/xui/en/menu_viewer.xml (fc82190a3f0c)
>
> View Diff 
>
___
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] Review Request: STORM-785 CTRL-\ Last chatter

[Jonathan Yap]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/16/
---

(Updated 2010-12-22 11:21:04.403780)


Review request for Viewer.


Summary (updated)
---

You have to push CTRL-\(there is a menu item for this too) twice to get the 
last chatter function to work.  My fix unlocks the camera before moving it.


This addresses bug STORM-785.
http://jira.secondlife.com/browse/STORM-785


Diffs
-

  indra/newview/llagentcamera.cpp 0a1d00f86446 

Diff: http://codereview.secondlife.com/r/16/diff


Testing
---


Thanks,

Jonathan

___
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] Review Request: Update returnability of objects based on new encroachment rules

[Andrew Meadows]

A note about the returnable encroachment feature...

It introduces a new definition I'm calling "Estate Content".
Estate content is stuff owned by the Estate Owner, or an Estate Manager.
It is treated differently by the "returnable encroachment" feature,
namely in order for Estate Content to be returned there is a special
per-region setting that mus be enabled.

That is, each region will have two independent settings:

allow_return_encroaching_object = true/false
allow_return_encroaching_estate_object = true/false

The reason for this split is that some estates already use encroachment
as a feature, where there are some encroaching content that is considered
"public content" such as roads and communal buildings.

As to encroaching objects on the mainland...

We'll eventually enable return of encroaching objects on the mainland
after some private estates have been using it for a while.  I expect we'll
enable it on a few mainland regions and see how things go, then expand.

Some mainland regions use encroachment as a feature and I think we should
move a little slowly there until we have a good understanding of how things
should be configured for the least damage.  After that I suspect we'll
enable encroachment return across all of mainland.

As to cross-region encroachment, where an object is on one region but sticks
into the parcel of another region...

Return of cross-region encroaching objects is not supported yet, but we plan
to implement it before mesh ships (early 2011).  This means "simscape"
megaprims will be at risk for encroachment return via neighboring regions.

Estate owners can always disable encroachment return if they prefer to protect
their simscapes, or they can just make sure their simscapes fall into the
Estate Content category.  Meanwhile on the mainland I think the returnable
encroachment outweighs the simscape megaprim hack so I will push to make the
demise of this hack a non-blocker.

Eventually I'm sure we can come up with a solution and I hope it is a "real"
simscape feature that doesn't rely on really really big megaprims.

- Andrew


On 12/22/2010 10:57 AM, Liny Odell wrote:
> Another key point is "simscapes" that use megaprims that obviously covers all 
> parcels but is only visible along the outside of the region along the void. 
> Also, what about prims that are centered in a neiboring region? Are thous 
> detected as encroaching?
>
> On Wed, Dec 22, 2010 at 10:45 AM, Aleric Inglewood 
> mailto:aleric.inglew...@gmail.com>> wrote:
>
> This is an automatically generated e-mail. To reply, visit: 
> http://codereview.secondlife.com/r/56/
>
>
> I have the feeling that this notion of'encroachesOwned'  is going to 
> cause a lot of trouble in the case of sculptures.
> At the very least you should use use an aligned bb that is the minimal bb 
> for anything *visible* of a prim. In the case
> of the sculptures this requires a special function to find the min/max 
> coordinates of all the points used. The same
> story holds for path cut-off (mega) prims. Ie, if I resize a megaprim 
> (the ONLY way to resize a mega prim is
> by using one of those prim torture tricks) then it's very possible one 
> ends up with a prim that is just 1/3 of it's"size".
> It wouldn't be fair when a house that clearly ends on ones own parcel 
> is"detected"  to encroach another parcel, just
> because the viewer code is too lame to take path cutting and sphere 
> dimples etc into account.
>
>
> - Aleric
>
>
> On December 22nd, 2010, 9:37 a.m., Merov Linden wrote:
>
> Review request for Viewer and Andrew Meadows.
> By Merov Linden.
>
> /Updated 2010-12-22 09:37:08/
>
>
>   Description
>
> The object-vs-parcel overlap test is done by building axis-aligned 
> bounding boxes (AABB) about each prim of the selected objects and then 
> checking for overlap between those boxes and self- and group-owned parcels.
>
> *Bugs: * STORM-807 
>
>
>   Diffs
>
> * indra/llcommon/llversionserver.h (fc82190a3f0c)
> * indra/llcommon/llversionviewer.h (fc82190a3f0c)
> * indra/llmath/llbbox.h (fc82190a3f0c)
> * indra/llmath/llbbox.cpp (fc82190a3f0c)
> * indra/llmessage/llregionflags.h (fc82190a3f0c)
> * indra/newview/English.lproj/InfoPlist.strings (fc82190a3f0c)
> * indra/newview/Info-SecondLife.plist (fc82190a3f0c)
> * indra/newview/llviewermenu.cpp (fc82190a3f0c)
> * indra/newview/llviewerobject.h (fc82190a3f0c)
> * indra/newview/llviewerobject.cpp (fc82190a3f0c)
> * indra/newview/llviewerparceloverlay.h (fc82190a3f0c)
> * indra/newview/llviewerparceloverlay.cpp (fc82190a3f0c)
> * indra/newview/llviewerregion.h (fc82190a3f0c)
> * indra/newview/llviewerregion.cpp (fc82190a3f0c)
> * indra/newview/res/viewerRes.rc (fc82190a3f0c)
> * indra/newview/skins/default/xui/en/menu_viewer.xml (fc82190a3f0c)

Re: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules

[Stickman]

Glad to hear the encroachment issue will be resolved in the near
future. I know a lot of people, LL included, have been waiting for
this.

> Eventually I'm sure we can come up with a solution and I hope it is a "real"
> simscape feature that doesn't rely on really really big megaprims.

3D skybox support, perhaps?

https://jira.secondlife.com/browse/SVC-4118

Stickman
___
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] Review Request: Update returnability of objects based on new encroachment rules

[Daniel]

Linden Homes intentionally use off-parcel placement of the homes 
themselves, so that the tenants can use the full 117 prims for their 
furniture.  Have you checked that this encroachment check will not break 
that setup?

On 12/22/2010 12:57 PM, "Merov Linden"  wrote:
> The object-vs-parcel overlap test is done by building axis-aligned bounding 
> boxes (AABB) about each prim of the selected objects and then checking for 
> overlap between those boxes and self- and group-owned parcels.
Daniel
___
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] Review Request: Update returnability of objects based on new encroachment rules

[Andrew Meadows]

I don't know the Linden Home stuff well, but it sounds like you're
saying that the homes aren't actually owned by the parcel owners
themselves.  Or else they are self owned but are "placed" in public
parcels that are owned by Governor Linden or whoever is the manager
of the region/estate.

If either of those are true then I think we'll be able to enable the
returnable encroachment feature... as long as no homesteader's
home encroaches upon a second homesteader's parcel.

In short...

If a mainland region's content is not compatible with returnable
encroachment then I think we'll leave the feature disabled there
until the content is made compatible.

The simple way to make it compatible is to make sure the stuff that
we want to save is owned by Estate Managers, and then only enable
return of regular content (not "Estate Content").

- Andrew


On 12/22/2010 02:08 PM, Daniel wrote:
> Linden Homes intentionally use off-parcel placement of the homes
> themselves, so that the tenants can use the full 117 prims for their
> furniture.  Have you checked that this encroachment check will not break
> that setup?
>
___
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

[opensource-dev] cmake issues with latest pull 12/22 - r14261:5d69e36a53ee

[Twisted Laws]

after pulling these changes, cmake . seems to go into a loop or something and 
never does anything and never exits on windows 7 (64), vc 2005.  is it just me?
this is after the social fixes and a lot of checkins from callum
if you break it...
 
$ Traceback (most recent call last):
  File "install.py", line 1150, in 
sys.exit(main())
  File "install.py", line 1142, in main
options.scp)
  File "install.py", line 636, in do_install
cache_dir)
  File "install.py", line 595, in install
ifile.fetch_local()
  File "install.py", line 135, in fetch_local
file(self.filename, 'wb').write(urllib2.urlopen(self.url).read())
  File "C:\Python26\Lib\socket.py", line 327, in read
data = self._sock.recv(rbufsize)
  File "C:\Python26\lib\httplib.py", line 537, in read
s = self.fp.read(amt)
  File "C:\Python26\Lib\socket.py", line 351, in read
data = self._sock.recv(left)
KeyboardInterrupt
close failed in file object destructor:
Error in sys.excepthook:
Original exception was:
 
Note there is nothing further printed... so i don't know what the original 
exception 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] Review Request: STORM-785 CTRL-\ Last chatter

[Aleric Inglewood]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/16/#review68
---

Ship it!


I am all happy with it now.

- Aleric


On 2010-12-22 11:21:04, Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/16/
> ---
> 
> (Updated 2010-12-22 11:21:04)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> You have to push CTRL-\(there is a menu item for this too) twice to get the 
> last chatter function to work.  My fix unlocks the camera before moving it.
> 
> 
> This addresses bug STORM-785.
> http://jira.secondlife.com/browse/STORM-785
> 
> 
> Diffs
> -
> 
>   indra/newview/llagentcamera.cpp 0a1d00f86446 
> 
> Diff: http://codereview.secondlife.com/r/16/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jonathan
> 
>

___
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] Review Request: Update returnability of objects based on new encroachment rules

[Aleric Inglewood]

I have no problems with the intent of returning encroaching objects,
but I do with the way encroaching is detected: You should not add
this feature when it is in a broken state, and I think it is broken when
it will think that objects are encroaching when not even the minimal
aligned bounding box of the object is encroaching.

I'm not speaking about a mostly transparent tree even, or
a L-shaped object at the corner of a parcel. But even, just
the simplest and most OBVIOUS ways to drastically decrease
the size of mega prims - or just the using cut path on a box.
That should be detected - as should the minimal bb for sculpties
be more accurately determined imho.

On Wed, Dec 22, 2010 at 8:51 PM, Andrew Meadows  wrote:
> A note about the returnable encroachment feature...
>
> It introduces a new definition I'm calling "Estate Content".
> Estate content is stuff owned by the Estate Owner, or an Estate Manager.
> It is treated differently by the "returnable encroachment" feature,
> namely in order for Estate Content to be returned there is a special
> per-region setting that mus be enabled.
>
> That is, each region will have two independent settings:
>
> allow_return_encroaching_object = true/false
> allow_return_encroaching_estate_object = true/false
>
> The reason for this split is that some estates already use encroachment
> as a feature, where there are some encroaching content that is considered
> "public content" such as roads and communal buildings.
>
> As to encroaching objects on the mainland...
>
> We'll eventually enable return of encroaching objects on the mainland
> after some private estates have been using it for a while.  I expect we'll
> enable it on a few mainland regions and see how things go, then expand.
>
> Some mainland regions use encroachment as a feature and I think we should
> move a little slowly there until we have a good understanding of how things
> should be configured for the least damage.  After that I suspect we'll
> enable encroachment return across all of mainland.
>
> As to cross-region encroachment, where an object is on one region but sticks
> into the parcel of another region...
>
> Return of cross-region encroaching objects is not supported yet, but we plan
> to implement it before mesh ships (early 2011).  This means "simscape"
> megaprims will be at risk for encroachment return via neighboring regions.
>
> Estate owners can always disable encroachment return if they prefer to
> protect
> their simscapes, or they can just make sure their simscapes fall into the
> Estate Content category.  Meanwhile on the mainland I think the returnable
> encroachment outweighs the simscape megaprim hack so I will push to make the
> demise of this hack a non-blocker.
>
> Eventually I'm sure we can come up with a solution and I hope it is a "real"
> simscape feature that doesn't rely on really really big megaprims.
>
> - Andrew
>
>
> On 12/22/2010 10:57 AM, Liny Odell wrote:
>>
>> Another key point is "simscapes" that use megaprims that obviously covers
>> all parcels but is only visible along the outside of the region along the
>> void. Also, what about prims that are centered in a neiboring region? Are
>> thous detected as encroaching?
>>
>> On Wed, Dec 22, 2010 at 10:45 AM, Aleric Inglewood
>> mailto:aleric.inglew...@gmail.com>> wrote:
>>
>>    This is an automatically generated e-mail. To reply, visit:
>> http://codereview.secondlife.com/r/56/
>>
>>
>>    I have the feeling that this notion of'encroachesOwned'  is going to
>> cause a lot of trouble in the case of sculptures.
>>    At the very least you should use use an aligned bb that is the minimal
>> bb for anything *visible* of a prim. In the case
>>    of the sculptures this requires a special function to find the min/max
>> coordinates of all the points used. The same
>>    story holds for path cut-off (mega) prims. Ie, if I resize a megaprim
>> (the ONLY way to resize a mega prim is
>>    by using one of those prim torture tricks) then it's very possible one
>> ends up with a prim that is just 1/3 of it's"size".
>>    It wouldn't be fair when a house that clearly ends on ones own parcel
>> is"detected"  to encroach another parcel, just
>>    because the viewer code is too lame to take path cutting and sphere
>> dimples etc into account.
>>
>>
>>    - Aleric
>>
>>
>>    On December 22nd, 2010, 9:37 a.m., Merov Linden wrote:
>>
>>    Review request for Viewer and Andrew Meadows.
>>    By Merov Linden.
>>
>>    /Updated 2010-12-22 09:37:08/
>>
>>
>>      Description
>>
>>    The object-vs-parcel overlap test is done by building axis-aligned
>> bounding boxes (AABB) about each prim of the selected objects and then
>> checking for overlap between those boxes and self- and group-owned parcels.
>>
>>    *Bugs: * STORM-807 
>>
>>
>>      Diffs
>>
>>        * indra/llcommon/llversionserver.h (fc82190a3f0c)
>>        * indra/llcommon/llversionviewer.h (fc82190a3f0c)
>>        * indra/llmath/

[opensource-dev] What is with the cycling port connections on SLv2.4?

[Ann Otoole]

connect disconnect connect 4 times at once disconnect 4 bang bang hammer hammer

Dear Oz and Esbee: Run a port monitor and look at what your client is doing.

Please. No don't just do it from the office LAN. Hire someone to travel around 
to different areas of the country to monitor what your client really does. 
Seriously. Crashiest client ever.



  ___
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

[opensource-dev] Review Request: The world map can point to the wrong URL

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/61/
---

Review request for Viewer.


Summary
---

Implements the processing of map-server-url correctly so not to overwrite the 
default value (which can still be useful if a grid does not implement 
map-server-url).


This addresses bug STORM-805.
http://jira.secondlife.com/browse/STORM-805


Diffs
-

  indra/newview/app_settings/settings.xml 5d69e36a53ee 
  indra/newview/llstartup.cpp 5d69e36a53ee 
  indra/newview/llworldmipmap.cpp 5d69e36a53ee 

Diff: http://codereview.secondlife.com/r/61/diff


Testing
---


Thanks,

Merov

___
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

[opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/62/
---

Review request for Viewer.


Summary
---

Unit tests addition:
- add tests for llkdu
- turned back on and fix unit tests for llimage
- turned back on and fix unit tests for llworldmap and llworldmipmap


This addresses bug STORM-744.
http://jira.secondlife.com/browse/STORM-744


Diffs
-

  indra/llimage/CMakeLists.txt 5d69e36a53ee 
  indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee 
  indra/llkdu/CMakeLists.txt 5d69e36a53ee 
  indra/llkdu/llimagej2ckdu.h 5d69e36a53ee 
  indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION 
  indra/newview/CMakeLists.txt 5d69e36a53ee 
  indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee 
  indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee 

Diff: http://codereview.secondlife.com/r/62/diff


Testing
---


Thanks,

Merov

___
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] Review Request: KDU Improvements: add unit tests for llkdu

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/62/
---

(Updated 2010-12-22 23:45:57.202290)


Review request for Viewer.


Changes
---

Update from Andrew taking Merov's comments into account


Summary
---

Unit tests addition:
- add tests for llkdu
- turned back on and fix unit tests for llimage
- turned back on and fix unit tests for llworldmap and llworldmipmap


This addresses bug STORM-744.
http://jira.secondlife.com/browse/STORM-744


Diffs (updated)
-

  indra/llcommon/llversionviewer.h d8fef72af99e 
  indra/llmath/llbbox.h d8fef72af99e 
  indra/llmath/llbbox.cpp d8fef72af99e 
  indra/llmessage/llregionflags.h d8fef72af99e 
  indra/newview/llviewermenu.cpp d8fef72af99e 
  indra/newview/llviewerobject.h d8fef72af99e 
  indra/newview/llviewerobject.cpp d8fef72af99e 
  indra/newview/llviewerparceloverlay.h d8fef72af99e 
  indra/newview/llviewerparceloverlay.cpp d8fef72af99e 
  indra/newview/llviewerregion.h d8fef72af99e 
  indra/newview/llviewerregion.cpp d8fef72af99e 
  indra/newview/llvoavatar.cpp d8fef72af99e 

Diff: http://codereview.secondlife.com/r/62/diff


Testing
---


Thanks,

Merov

___
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] Review Request: KDU Improvements: add unit tests for llkdu

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/62/#review70
---


I don't think there should be any change in indra/llcommon/llversionviewer.h, 
especially none to reference snowglobe...

- Merov


On 2010-12-22 23:45:57, Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/62/
> ---
> 
> (Updated 2010-12-22 23:45:57)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Unit tests addition:
> - add tests for llkdu
> - turned back on and fix unit tests for llimage
> - turned back on and fix unit tests for llworldmap and llworldmipmap
> 
> 
> This addresses bug STORM-744.
> http://jira.secondlife.com/browse/STORM-744
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llversionviewer.h d8fef72af99e 
>   indra/llmath/llbbox.h d8fef72af99e 
>   indra/llmath/llbbox.cpp d8fef72af99e 
>   indra/llmessage/llregionflags.h d8fef72af99e 
>   indra/newview/llviewermenu.cpp d8fef72af99e 
>   indra/newview/llviewerobject.h d8fef72af99e 
>   indra/newview/llviewerobject.cpp d8fef72af99e 
>   indra/newview/llviewerparceloverlay.h d8fef72af99e 
>   indra/newview/llviewerparceloverlay.cpp d8fef72af99e 
>   indra/newview/llviewerregion.h d8fef72af99e 
>   indra/newview/llviewerregion.cpp d8fef72af99e 
>   indra/newview/llvoavatar.cpp d8fef72af99e 
> 
> Diff: http://codereview.secondlife.com/r/62/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Merov
> 
>

___
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

[opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/63/
---

Review request for Viewer.


Summary
---

Unit tests addition:
- add tests for llkdu
- turned back on and fix unit tests for llimage
- turned back on and fix unit tests for llworldmap and llworldmipmap


This addresses bug STORM-744.
http://jira.secondlife.com/browse/STORM-744


Diffs
-

  indra/llimage/CMakeLists.txt 5d69e36a53ee 
  indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee 
  indra/llkdu/CMakeLists.txt 5d69e36a53ee 
  indra/llkdu/llimagej2ckdu.h 5d69e36a53ee 
  indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION 
  indra/newview/CMakeLists.txt 5d69e36a53ee 
  indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee 
  indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee 

Diff: http://codereview.secondlife.com/r/63/diff


Testing
---


Thanks,

Merov

___
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] Review Request: Update returnability of objects based on new encroachment rules

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/56/
---

(Updated 2010-12-22 23:54:00.934665)


Review request for Viewer and Andrew Meadows.


Changes
---

Andrew's update with comments from Merov's taken into account


Summary
---

The object-vs-parcel overlap test is done by building axis-aligned bounding 
boxes (AABB) about each prim of the selected objects and then checking for 
overlap between those boxes and self- and group-owned parcels. 


This addresses bug STORM-807.
http://jira.secondlife.com/browse/STORM-807


Diffs (updated)
-

  indra/llcommon/llversionviewer.h d8fef72af99e 
  indra/llmath/llbbox.h d8fef72af99e 
  indra/llmath/llbbox.cpp d8fef72af99e 
  indra/llmessage/llregionflags.h d8fef72af99e 
  indra/newview/llviewermenu.cpp d8fef72af99e 
  indra/newview/llviewerobject.h d8fef72af99e 
  indra/newview/llviewerobject.cpp d8fef72af99e 
  indra/newview/llviewerparceloverlay.h d8fef72af99e 
  indra/newview/llviewerparceloverlay.cpp d8fef72af99e 
  indra/newview/llviewerregion.h d8fef72af99e 
  indra/newview/llviewerregion.cpp d8fef72af99e 
  indra/newview/llvoavatar.cpp d8fef72af99e 

Diff: http://codereview.secondlife.com/r/56/diff


Testing
---


Thanks,

Merov

___
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] Review Request: Update returnability of objects based on new encroachment rules

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/56/#review71
---


indra/llcommon/llversionviewer.h shouldn't be modified

- Merov


On 2010-12-22 23:54:00, Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/56/
> ---
> 
> (Updated 2010-12-22 23:54:00)
> 
> 
> Review request for Viewer and Andrew Meadows.
> 
> 
> Summary
> ---
> 
> The object-vs-parcel overlap test is done by building axis-aligned bounding 
> boxes (AABB) about each prim of the selected objects and then checking for 
> overlap between those boxes and self- and group-owned parcels. 
> 
> 
> This addresses bug STORM-807.
> http://jira.secondlife.com/browse/STORM-807
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llversionviewer.h d8fef72af99e 
>   indra/llmath/llbbox.h d8fef72af99e 
>   indra/llmath/llbbox.cpp d8fef72af99e 
>   indra/llmessage/llregionflags.h d8fef72af99e 
>   indra/newview/llviewermenu.cpp d8fef72af99e 
>   indra/newview/llviewerobject.h d8fef72af99e 
>   indra/newview/llviewerobject.cpp d8fef72af99e 
>   indra/newview/llviewerparceloverlay.h d8fef72af99e 
>   indra/newview/llviewerparceloverlay.cpp d8fef72af99e 
>   indra/newview/llviewerregion.h d8fef72af99e 
>   indra/newview/llviewerregion.cpp d8fef72af99e 
>   indra/newview/llvoavatar.cpp d8fef72af99e 
> 
> Diff: http://codereview.secondlife.com/r/56/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Merov
> 
>

___
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