Re: [opensource-dev] Review Request: STORM-58 Allow objects to have 99.99% max hollow for default hollow shape.

[Lance Corrimal]

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


under certain conditions the hollow value "snaps back" to 95.0:
* stretching a hollowed prim
* entering a "wrong number" manually, e.g. 99.999

otherwise it works fine.


- Lance


On July 12, 2011, 11:47 a.m., Wolfpup Lowenhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/388/
> ---
> 
> (Updated July 12, 2011, 11:47 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> As a Builder, I want to be able to create prims that are more than 95 % 
> hollow which will allow me to create more realistic paper sheets, flags, 
> fabric bits, ribbons, etc.
> 
> 
> This addresses bug STORM-58.
> http://jira.secondlife.com/browse/STORM-58
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt d4cd5f0f33d2 
>   indra/llmath/llvolume.cpp d4cd5f0f33d2 
>   indra/newview/llpanelobject.cpp d4cd5f0f33d2 
>   indra/newview/skins/default/xui/en/floater_tools.xml d4cd5f0f33d2 
> 
> Diff: http://codereview.secondlife.com/r/388/diff
> 
> 
> Testing
> ---
> 
> Built viewer locally and testes Viewer Phase of Acceptance Criteria. 
> 
> 
> Thanks,
> 
> Wolfpup
> 
>

___
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-58 Allow objects to have 99.99% max hollow for default hollow shape.

[Jamey Fletcher]

Lance Corrimal wrote:

> under certain conditions the hollow value"snaps back"  to 95.0:
> * stretching a hollowed prim
> * entering a"wrong number"  manually, e.g. 99.999

I believe all prim size/parameter restraints are clamped on the server, 
due to the Megaprims debacle.  I think there was some testing of hollows 
greater than 95%, and some issues were run into with the physics engine. 
  As the physics engine has changed twice, at least, since then I think, 
it may be possible to increase it to 99%.
___
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-1577 Convert chat translation to third party paid translation services

[Seth ProductEngine]

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

Ship it!


Looks good to me.

- Seth


On Sept. 7, 2011, 10:05 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/464/
> ---
> 
> (Updated Sept. 7, 2011, 10:05 a.m.)
> 
> 
> Review request for Viewer and Oz Linden.
> 
> 
> Summary
> ---
> 
> Removed usage of the deprecated Google Translate v1 API.
> Implemented machine translation via Google Translate v2 and Bing Translate 
> APIs.
> 
> 
> This addresses bug STORM-1577.
> http://jira.secondlife.com/browse/STORM-1577
> 
> 
> Diffs
> -
> 
>   indra/newview/CMakeLists.txt 8da01486a36a 
>   indra/newview/app_settings/settings.xml 8da01486a36a 
>   indra/newview/llfloaterpreference.h 8da01486a36a 
>   indra/newview/llfloaterpreference.cpp 8da01486a36a 
>   indra/newview/llfloatertranslationsettings.h PRE-CREATION 
>   indra/newview/llfloatertranslationsettings.cpp PRE-CREATION 
>   indra/newview/lltranslate.h 8da01486a36a 
>   indra/newview/lltranslate.cpp 8da01486a36a 
>   indra/newview/llviewerfloaterreg.cpp 8da01486a36a 
>   indra/newview/llviewermessage.cpp 8da01486a36a 
>   indra/newview/skins/default/xui/en/floater_translation_settings.xml 
> PRE-CREATION 
>   indra/newview/skins/default/xui/en/panel_preferences_chat.xml 8da01486a36a 
>   indra/newview/skins/default/xui/en/strings.xml 8da01486a36a 
> 
> Diff: http://codereview.secondlife.com/r/464/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vadim
> 
>

___
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] Snowstorm Team Reveiw Build

[Oz Linden (Scott Lawrence)]

*Snowstorm Team Issues: Functional Review build*

STORM-918 
   Changes in Group Role Titles or Assignments Not Reflected in Title
   Dropdown 
STORM-1028 
   Speak button label not displaying at default window size 
STORM-1297 

   Clicking on Block in a dialog box from an object blocks the object
   owner, not the object, and sets the wrong block type 
STORM-1532 
   Unnecessary capability request spam 
STORM-1587 

   A lot of notifications are shown in English for other locales in
   3.0.3 Beta 

Windows 
 | 
Macintosh 
 | 
Linux 
 





Details for these builds 
 
(build logs, included changesets)


___
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-58 Allow objects to have 99.99% max hollow for default hollow shape.

[aklo]

Jamey (or anyone else that would like to answer),

can you please explain "the Megaprims debacle"?  i know it's a little
off-topic, but i've always wondered why Megaprims have such a bad rep.  i
can see how they could be abused, but i don't see how the abuse could be
anything more than a minor annoyance.

Thx!  And pls forgive my asking if ppl would really not like to have
questions like this here.

- AK

Lance Corrimal wrote:

> under certain conditions the hollow value"snaps back"  to 95.0:
> * stretching a hollowed prim
> * entering a"wrong number"  manually, e.g. 99.999
I believe all prim size/parameter restraints are clamped on the server,
due to the Megaprims debacle.  I think there was some testing of hollows
greater than 95%, and some issues were run into with the physics engine.
  As the physics engine has changed twice, at least, since then I think,
it may be possible to increase it to 99%.
___
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: STORM-58 Allow objects to have 99.99% max hollow for default hollow shape.

[Zabb65]

The clamp for primitive parameters was in place long before the
megaprim "debacle", unless you are referring to the one in early 2006,
possibly even earlier than that.

>From what I know, doing this will require that the server be updated
to relax this restriction.
___
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-58 Allow objects to have 99.99% max hollow for default hollow shape.

[Jamey Fletcher]

Zabb65 wrote:
> The clamp for primitive parameters was in place long before the
> megaprim "debacle", unless you are referring to the one in early 2006,
> possibly even earlier than that.

>> From what I know, doing this will require that the server be updated
> to relax this restriction.

That is the one I'm talking about - the one that resulted in a large 
part of the grid having objects created by Gene Replacement.

Somewhere prior to time frame, the server did not clamp the prim 
dimensions - it was done client side.  However, reverse-engineering of 
the protocol resulted in libsecondlife, which was used to create the 
most infamous of the "copybots", as well the megaprims labeled as 
created by Gene Replacement.

These prims were made full-permission and handed out quite widely - the 
20x20x0.5 cube prim is still one of the mainstays of building.  However, 
due to some of the other prims created, including a 65535x65535x0.01 
"infinite prim", which when rezzed often required Linden intervention to 
remove, Megaprims got the reputation for being laggy and bad for the 
system.  Linden Labs refused to support them, but also did not take 
action to remove them from the grid, unless they were specifically 
involved in a griefing action, such as the above prim.

For a long time, there were camps both within Linden Labs, and among the 
users, over whether or not to increase the limits.  Claims and 
counter-claims got pretty heated at times.  Finally, Andrew Linden, one 
of the anti-megaprim camp, proposed a series of checkpoints that if 
fulfilled, would lead him to supported "Megaprim Liberation Day".  The 
biggest thing was some way that users could remove megaprims from 
encroaching on their land, even if the center of the megaprim was not on 
their land.  The suggested fix at the time (and I suspect the one 
finally implemented) involved having parcels as a special object type in 
the physics engine, and checking for collision.

With the implementation of Mesh, though, we have something near full 
Megaprim liberation - we can create prims up to 64x64x64.  There will be 
times when even larger prims will be useful - and the Gene Replacement 
megaprims, as well as the second-wave ones created when the servers had 
clamping turned off by mistake a couple of years ago, are still in 
inventories and available.  But for the most part, the current maximum 
size is a very nice one, and I've already started using it to reduce my 
prim count.  Now, I just need to figure out why v3 won't run for me, so 
I can check into the "not involved in collisions" flag, which, but one 
reading of the announcement, means that prims flagged that way don't 
count against your parcel prim limit (though I suspect physics-enabled 
vehicle prim limit was what was meant).
___
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