From secret.argent at gmail.com Wed Feb 1 04:30:41 2012 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 1 Feb 2012 06:30:41 -0600 Subject: [opensource-dev] View on Lion In-Reply-To: References: Message-ID: > For that matter, what is the status of Lion, period. OS Xista? Or is it ok? OS X Vista. Definitely. From jhwelch at gmail.com Fri Feb 3 06:05:16 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 03 Feb 2012 14:05:16 -0000 Subject: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy In-Reply-To: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120203140516.13700.53682@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/ ----------------------------------------------------------- (Updated Feb. 3, 2012, 6:05 a.m.) Review request for Viewer. Changes ------- Fix bad assumption in getAvatars Description ------- The SL simulator has recently been fixed so that the CoarseLocationUpdate message properly returns 255 for all altitudes above 1020 meters. The code for the mini-map, in drawing the agent locations for equal, above or below needs to take this into account. It currently does not. The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs (updated) ----- doc/contributions.txt 0010858de5a1 indra/newview/llnetmap.cpp 0010858de5a1 indra/newview/llworld.cpp 0010858de5a1 indra/newview/llworldmapview.h 0010858de5a1 indra/newview/llworldmapview.cpp 0010858de5a1 Diff: http://codereview.secondlife.com/r/545/diff/diff Testing ------- See test plan in jira Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120203/85086aad/attachment.htm From jhwelch at gmail.com Fri Feb 3 08:51:57 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 03 Feb 2012 16:51:57 -0000 Subject: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy In-Reply-To: <20120203140516.13700.53682@domU-12-31-38-00-90-68.compute-1.internal> References: <20120203140516.13700.53682@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120203165157.10598.58624@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/ ----------------------------------------------------------- (Updated Feb. 3, 2012, 8:51 a.m.) Review request for Viewer. Changes ------- Fixed another logic error in getAvatars. This code could be improved by changing one call into this method, so avatar_ids always has a matching positions parameter (which, erroneously, I thought it did). Description ------- The SL simulator has recently been fixed so that the CoarseLocationUpdate message properly returns 255 for all altitudes above 1020 meters. The code for the mini-map, in drawing the agent locations for equal, above or below needs to take this into account. It currently does not. The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs (updated) ----- doc/contributions.txt 0010858de5a1 indra/newview/llnetmap.cpp 0010858de5a1 indra/newview/llworld.cpp 0010858de5a1 indra/newview/llworldmapview.h 0010858de5a1 indra/newview/llworldmapview.cpp 0010858de5a1 Diff: http://codereview.secondlife.com/r/545/diff/diff Testing ------- See test plan in jira Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120203/9bf7594c/attachment.htm From oz at lindenlab.com Fri Feb 3 11:59:24 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 03 Feb 2012 14:59:24 -0500 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120128201334.f74c3cfd.sldev@free.fr> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> Message-ID: <4F2C3C9C.9020005@lindenlab.com> On 2012-01-28 14:13 , Henri Beauchamp wrote: > On Fri, 27 Jan 2012 16:57:20 -0500, Oz Linden (Scott Lawrence) wrote: > >> Sorry for the delay letting you know - the inventory service on Aditi is >> running the version this is needed for, so if you want to test a port, >> do it there. > The feature also depends on a sim capability, and as far as I could see > (and in the sim I tested the feature in), that capability is not yet > implemented/advertized... Could you please tell us which sims advertize > the new "CreateInventoryCategory" capability on Aditi ? > I didn't realize that it wasn't everywhere.... it should be enabled on the Inventory Test regions on aditi. Info available here: https://wiki.secondlife.com/wiki/InventoryBetaTest From jaeger_Reg at hotmail.com Sun Feb 5 10:43:05 2012 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Sun, 05 Feb 2012 18:43:05 -0000 Subject: [opensource-dev] Review Request: VWR-28264 - Display Z coordinate in Script Error window Message-ID: <20120205184305.30479.78738@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/550/ ----------------------------------------------------------- Review request for Viewer. Description ------- This adds the Z coordinate to the displayed location of an erroring script. This addresses bug VWR-28264. http://jira.secondlife.com/browse/VWR-28264 Diffs ----- indra/newview/llfloaterscriptdebug.cpp 37dd400ad721 Diff: http://codereview.secondlife.com/r/550/diff/diff Testing ------- rezzed a prim with a script error in it, observed Z location is displayed as well as x and y in the script warning/error floater Thanks, Tankmaster Finesmith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120205/1ac210f2/attachment.htm From oz at lindenlab.com Mon Feb 6 10:16:59 2012 From: oz at lindenlab.com (Oz Linden) Date: Mon, 06 Feb 2012 18:16:59 -0000 Subject: [opensource-dev] Review Request: STORM-1803 Adding raw anim file upload support In-Reply-To: <20120131220719.10598.61740@domU-12-31-38-00-90-68.compute-1.internal> References: <20120131220719.10598.61740@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120206181659.30480.62360@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/546/#review1161 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Jan. 31, 2012, 2:07 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/546/ > ----------------------------------------------------------- > > (Updated Jan. 31, 2012, 2:07 p.m.) > > > Review request for Viewer. > > > Description > ------- > > Adds support for uploading .anim files as part of Upload->Animation or as a Bulk Upload. > > For naming consistency and clearness some bvh-related files were renamed to reflect their function. > > > This addresses bug STORM-1803. > http://jira.secondlife.com/browse/STORM-1803 > > > Diffs > ----- > > doc/contributions.txt b91d07f8fad9 > indra/newview/CMakeLists.txt b91d07f8fad9 > indra/newview/llfilepicker.cpp b91d07f8fad9 > indra/newview/llfloateranimpreview.h b91d07f8fad9 > indra/newview/llfloateranimpreview.cpp b91d07f8fad9 > indra/newview/llfloaterbvhpreview.h PRE-CREATION > indra/newview/llfloaterbvhpreview.cpp PRE-CREATION > indra/newview/llfloaternamedesc.h b91d07f8fad9 > indra/newview/llfloaternamedesc.cpp b91d07f8fad9 > indra/newview/llviewerfloaterreg.cpp b91d07f8fad9 > indra/newview/llviewermenufile.cpp b91d07f8fad9 > indra/newview/skins/default/xui/en/floater_animation_anim_preview.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_animation_bvh_preview.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_animation_preview.xml b91d07f8fad9 > indra/newview/skins/default/xui/en/notifications.xml b91d07f8fad9 > > Diff: http://codereview.secondlife.com/r/546/diff/diff > > > Testing > ------- > > See Test Plan in jira > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120206/986ff5c4/attachment.htm From oz at lindenlab.com Mon Feb 6 10:19:49 2012 From: oz at lindenlab.com (Oz Linden) Date: Mon, 06 Feb 2012 18:19:49 -0000 Subject: [opensource-dev] Review Request: STORM-1804 Details... button on PERMISSION_DEBIT dialog triggers run_time_permissions() with a deny action In-Reply-To: <20120125124706.21301.52022@domU-12-31-38-00-90-68.compute-1.internal> References: <20120125124706.21301.52022@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120206181949.30474.25856@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/544/#review1162 ----------------------------------------------------------- Ship it! indra/newview/llviewermessage.cpp No ... leave it - Oz Linden On Jan. 25, 2012, 4:47 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/544/ > ----------------------------------------------------------- > > (Updated Jan. 25, 2012, 4:47 a.m.) > > > Review request for Viewer. > > > Description > ------- > > When an object requests DEBIT permissions a large, yellow dialog appears. This dialog has three buttons: "Grant", "Deny", and "Details..." When you select "Details..." Additional information about DEBIT permission is displayed. > > The bug is that when "Details..." is selected PERMISSION_DEBIT is denied and the run_time_permissions() event handler is triggered. There is also a system message in the Local Chat pane of the communicate window that informs the user that permission has been denied. Further, if "Grant" or "Deny" are pressed AFTER details the run_time_permissions() event handler is NOT triggered, yet there is a system message saying that permissions have been granted or denied. > > What should happen when "Details..." is pressed is no run_time_permissions event should be triggered and the "Grant" and "Deny" buttons should operate normally and trigger the run_time_permissions event afterwards. > > > This addresses bug STORM-1804. > http://jira.secondlife.com/browse/STORM-1804 > > > Diffs > ----- > > doc/contributions.txt 3f2162768b29 > indra/newview/llviewermessage.cpp 3f2162768b29 > > Diff: http://codereview.secondlife.com/r/544/diff/diff > > > Testing > ------- > > See test script in jira. > > Click on Details: additional information is shown, click on Ok to dismiss that, then you can go back and click on Grant or Deny. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120206/aca028fb/attachment.htm From oz at lindenlab.com Mon Feb 6 10:33:18 2012 From: oz at lindenlab.com (Oz Linden) Date: Mon, 06 Feb 2012 18:33:18 -0000 Subject: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy In-Reply-To: <20120203165157.10598.58624@domU-12-31-38-00-90-68.compute-1.internal> References: <20120203165157.10598.58624@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120206183318.32265.93751@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/#review1163 ----------------------------------------------------------- Ship it! indra/newview/llworld.cpp When wrapping conditions across lines, I find it more clear to put the operators on the left: if ( condition1 && condition2 ... - Oz Linden On Feb. 3, 2012, 8:51 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/545/ > ----------------------------------------------------------- > > (Updated Feb. 3, 2012, 8:51 a.m.) > > > Review request for Viewer. > > > Description > ------- > > The SL simulator has recently been fixed so that the CoarseLocationUpdate message properly returns 255 for all altitudes above 1020 meters. > > The code for the mini-map, in drawing the agent locations for equal, above or below needs to take this into account. It currently does not. > > The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. > > In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. > > > This addresses bug STORM-1793. > http://jira.secondlife.com/browse/STORM-1793 > > > Diffs > ----- > > doc/contributions.txt 0010858de5a1 > indra/newview/llnetmap.cpp 0010858de5a1 > indra/newview/llworld.cpp 0010858de5a1 > indra/newview/llworldmapview.h 0010858de5a1 > indra/newview/llworldmapview.cpp 0010858de5a1 > > Diff: http://codereview.secondlife.com/r/545/diff/diff > > > Testing > ------- > > See test plan in jira > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120206/306ee543/attachment-0001.htm From jenn at lindenlab.com Mon Feb 6 11:13:31 2012 From: jenn at lindenlab.com (Jenn Leech) Date: Mon, 6 Feb 2012 11:13:31 -0800 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <4F2C3C9C.9020005@lindenlab.com> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> Message-ID: I should add that we are also testing inventory routing changes on those sims on aditi as well. Items which are *newly* sent to your inventory should show up in the Received Items folder (e.g. someone gives you an item, you purchase an item etc. - these will show up in this new system folder). We plan to announce a public beta for testing these behavior changes in the next couple of weeks and have been performing primarily internal testing so far. We will be debugging and re-deploying throughout this week as we continue with internal testing, but these simulators should be essentially functional for testing Viewer changes. Thx! - Jenn On Fri, Feb 3, 2012 at 11:59 AM, Oz Linden (Scott Lawrence) < oz at lindenlab.com> wrote: > On 2012-01-28 14:13 , Henri Beauchamp wrote: > > On Fri, 27 Jan 2012 16:57:20 -0500, Oz Linden (Scott Lawrence) wrote: > > > >> Sorry for the delay letting you know - the inventory service on Aditi is > >> running the version this is needed for, so if you want to test a port, > >> do it there. > > The feature also depends on a sim capability, and as far as I could see > > (and in the sim I tested the feature in), that capability is not yet > > implemented/advertized... Could you please tell us which sims advertize > > the new "CreateInventoryCategory" capability on Aditi ? > > > > I didn't realize that it wasn't everywhere.... it should be enabled on > the Inventory Test regions on aditi. Info available here: > https://wiki.secondlife.com/wiki/InventoryBetaTest > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120206/d50866de/attachment.htm From jhwelch at gmail.com Tue Feb 7 06:28:10 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 07 Feb 2012 14:28:10 -0000 Subject: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy In-Reply-To: <20120203165157.10598.58624@domU-12-31-38-00-90-68.compute-1.internal> References: <20120203165157.10598.58624@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120207142810.30474.65567@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/ ----------------------------------------------------------- (Updated Feb. 7, 2012, 6:28 a.m.) Review request for Viewer. Changes ------- Fix syntax error. Forgot to compile after making the last change. Dumb mistake. Description ------- The SL simulator has recently been fixed so that the CoarseLocationUpdate message properly returns 255 for all altitudes above 1020 meters. The code for the mini-map, in drawing the agent locations for equal, above or below needs to take this into account. It currently does not. The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs (updated) ----- doc/contributions.txt 0010858de5a1 indra/newview/llnetmap.cpp 0010858de5a1 indra/newview/llworld.cpp 0010858de5a1 indra/newview/llworldmapview.h 0010858de5a1 indra/newview/llworldmapview.cpp 0010858de5a1 Diff: http://codereview.secondlife.com/r/545/diff/diff Testing ------- See test plan in jira Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120207/956ae28b/attachment.htm From jhwelch at gmail.com Tue Feb 7 07:47:31 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 07 Feb 2012 15:47:31 -0000 Subject: [opensource-dev] Review Request: STORM-1803 Adding raw anim file upload support In-Reply-To: <20120131220719.10598.61740@domU-12-31-38-00-90-68.compute-1.internal> References: <20120131220719.10598.61740@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120207154731.30475.65463@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/546/ ----------------------------------------------------------- (Updated Feb. 7, 2012, 7:47 a.m.) Review request for Viewer. Changes ------- Removed superfluous ) which the Windows compiler did not complain about but the Linux one did. Description ------- Adds support for uploading .anim files as part of Upload->Animation or as a Bulk Upload. For naming consistency and clearness some bvh-related files were renamed to reflect their function. This addresses bug STORM-1803. http://jira.secondlife.com/browse/STORM-1803 Diffs (updated) ----- doc/contributions.txt b91d07f8fad9 indra/newview/CMakeLists.txt b91d07f8fad9 indra/newview/llfilepicker.cpp b91d07f8fad9 indra/newview/llfloateranimpreview.h b91d07f8fad9 indra/newview/llfloateranimpreview.cpp b91d07f8fad9 indra/newview/llfloaterbvhpreview.h PRE-CREATION indra/newview/llfloaterbvhpreview.cpp PRE-CREATION indra/newview/llfloaternamedesc.h b91d07f8fad9 indra/newview/llfloaternamedesc.cpp b91d07f8fad9 indra/newview/llviewerfloaterreg.cpp b91d07f8fad9 indra/newview/llviewermenufile.cpp b91d07f8fad9 indra/newview/skins/default/xui/en/floater_animation_anim_preview.xml PRE-CREATION indra/newview/skins/default/xui/en/floater_animation_bvh_preview.xml PRE-CREATION indra/newview/skins/default/xui/en/floater_animation_preview.xml b91d07f8fad9 indra/newview/skins/default/xui/en/notifications.xml b91d07f8fad9 Diff: http://codereview.secondlife.com/r/546/diff/diff Testing ------- See Test Plan in jira Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120207/3780f335/attachment.htm From jhwelch at gmail.com Wed Feb 8 11:31:29 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 08 Feb 2012 19:31:29 -0000 Subject: [opensource-dev] Review Request: STORM-1809 The word "Multiple" does NOT show in the edit window when editing prims or linksets with mixed textures in LL V3 Message-ID: <20120208193129.30476.34135@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/551/ ----------------------------------------------------------- Review request for Viewer. Description ------- When building, a creator has always been able to look at the texture window to see if a prim or linkset is mixed textures or one complete texture by seeing the word "multiple" over the texture. This no longer happens in Viewer 3. This addresses bug STORM-1809. http://jira.secondlife.com/browse/STORM-1809 Diffs ----- doc/contributions.txt 767757e005e3 indra/newview/lltexturectrl.cpp 767757e005e3 indra/newview/skins/default/xui/en/strings.xml 767757e005e3 Diff: http://codereview.secondlife.com/r/551/diff/diff Testing ------- See test plan in jira. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120208/91574596/attachment.htm From jhwelch at gmail.com Wed Feb 8 12:39:35 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 08 Feb 2012 20:39:35 -0000 Subject: [opensource-dev] Review Request: STORM-1807 Play animation floater 2nd play button active while animation is playing Message-ID: <20120208203935.30474.97918@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/552/ ----------------------------------------------------------- Review request for Viewer. Description ------- Part 1 Open your inventory's Animations folder Double click on an animation Click on Play Inworld: Play Inworld is replaced by a Stop button Observed behavior: It is still possible to click on Play Locally, which also is replaced by a Stop button. Clicking on either Stop works and resets the floater back to having both Play buttons showing. Expected behavior: When one of the play buttons is clicked the other should be disabled. Part 2 1 .To reproduce, get any non looping animation. ie, one that plays once and then stops. 2. Right click in inventory and select play in world. 3. The animation dialog appears with play locally and play in world buttons. 4. When the animation is playing, the play in world button changes to a stop button, which makes it stop playing. Now here's the problem: 5. When the animation finishes of it's own accord, the button still says stop. To play it again, you have to click the redundant stop button to make it change back to Play in World, then click that to play again. Expected behaviour, is that when an animation finishes, the stop button should change back of it's own accord. This addresses bug STORM-1807. http://jira.secondlife.com/browse/STORM-1807 Diffs ----- doc/contributions.txt 0a41a8750048 indra/newview/llinventorybridge.cpp 0a41a8750048 indra/newview/llpreviewanim.h 0a41a8750048 indra/newview/llpreviewanim.cpp 0a41a8750048 indra/newview/skins/default/xui/en/floater_preview_animation.xml 0a41a8750048 Diff: http://codereview.secondlife.com/r/552/diff/diff Testing ------- See test plan in jira. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120208/9874921b/attachment.htm From jhwelch at gmail.com Wed Feb 8 15:31:02 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 08 Feb 2012 23:31:02 -0000 Subject: [opensource-dev] Review Request: STORM-1808 Indicate ability to build Message-ID: <20120208233102.30478.34780@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/553/ ----------------------------------------------------------- Review request for Viewer. Description ------- When standing in a parcel it would be helpful to have a graphical indication in the UI if you are able to build/rez. The icon in the (mini) location bar shows parcel properties, not what is available to you as parcel owner or as a member of a group that has rezzing enabled as one of your group roles. Suggested solution: Gray out the build button if it is present on the toolbar, just like the Speak button is grayed out if voice is not available. This addresses bug STORM-1808. http://jira.secondlife.com/browse/STORM-1808 Diffs ----- doc/contributions.txt 0a41a8750048 indra/newview/app_settings/commands.xml 0a41a8750048 indra/newview/llagent.cpp 0a41a8750048 Diff: http://codereview.secondlife.com/r/553/diff/diff Testing ------- See test plan in jira. I also searched the xml files to be sure no other calls to LLAgent::isActionAllowed were being made. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120208/07bff442/attachment.htm From jaeger_Reg at hotmail.com Wed Feb 8 18:10:54 2012 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Thu, 09 Feb 2012 02:10:54 -0000 Subject: [opensource-dev] Review Request: VWR-28264 - Display Z coordinate in Script Error window In-Reply-To: <20120205184305.30479.78738@domU-12-31-38-00-90-68.compute-1.internal> References: <20120205184305.30479.78738@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120209021054.30477.36226@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/550/ ----------------------------------------------------------- (Updated Feb. 8, 2012, 6:10 p.m.) Review request for Viewer. Description ------- This adds the Z coordinate to the displayed location of an erroring script. This addresses bug VWR-28264. http://jira.secondlife.com/browse/VWR-28264 Diffs ----- indra/newview/llfloaterscriptdebug.cpp 37dd400ad721 Diff: http://codereview.secondlife.com/r/550/diff/diff Testing ------- rezzed a prim with a script error in it, observed Z location is displayed as well as x and y in the script warning/error floater Thanks, Tankmaster Finesmith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120209/2197bf77/attachment.htm From sldev at free.fr Thu Feb 9 10:55:31 2012 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 9 Feb 2012 19:55:31 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> Message-ID: <20120209195531.bdb018a2.sldev@free.fr> Greetings, Sorry for my late reply, but I have been busy backporting multiple clothing layers to the Cool VL Viewer this last couple of weeks (released today in Cool VL Viewer v1.26.3.4)... On Mon, 6 Feb 2012 11:13:31 -0800, Jenn Leech wrote: > I should add that we are also testing inventory routing changes on those > sims on aditi as well. Items which are *newly* sent to your inventory > should show up in the Received Items folder (e.g. someone gives you an > item, you purchase an item etc. - these will show up in this new system > folder). And that's why it currently fails with the patch as provided by Oz for v2/3 and backported by me to v1. Here is an example of the log I get in the CG Test 8 region when hitting the "Copy And Wear" button of the "Objects Contents" floater on a prim (named "Copy And Wear Test" containing the items copied from the "Boy Next Door" stock (library) avatar: - On the first try, a new "Received Items" folder is created at the root of the inventory, but nothing appears in it (luckily, the items are copy-ok and therefore not gone from the container prim). - On the second try (i.e. after "Received Items" was created), I get: 2012-02-09T18:28:47Z DEBUG: createNewCategory: Using the CreateInventoryCategory capability. 2012-02-09T18:28:48Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: 5 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(f55dae61-cfe8-e6b6-5429-bfb973639ea9) was NULL 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(7371ea0b-2f57-ab08-02cb-031378564b83) was NULL 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(775690a1-f412-69c3-fafe-2e4698af15d9) was NULL 2012-02-09T18:28:49Z DEBUG: accountForUpdate: accounted: 'Copy And Wear Test' 2 with 1 descendents. .../... (repeated for each item) 2012-02-09T18:28:49Z INFO: processBulkUpdateInventory: Bulk inventory: ffffffff-ffff-ffff-ffff-ffffffffffff 2012-02-09T18:28:49Z DEBUG: accountForUpdate: accounted: 'My Inventory' 902 with 18 descendents. 2012-02-09T18:28:49Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: 5 2012-02-09T18:28:49Z INFO: processBulkUpdateInventory: Bulk inventory: 76ac463f-ca9b-608b-b5f7-80d1cb519463 2012-02-09T18:28:49Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: -1 .../... (repeated for each item) The items then do appear in a sub-folder of "Received Items", but they are not worn. > We plan to announce a public beta for testing these behavior changes in the > next couple of weeks and have been performing primarily internal testing so > far. What we'd need now is the viewer side code dealing with the "Received Items" folder (obviously, it's a new system folder... another of these stupid folders that will crowd the root of our inventory). But I think it's a BAD IDEA to FORCE things to go into a specific folder from the server side (it should be the viewer to decide where it puts the received inventory: either at the root, like v1 always did, or in Received Items" if it exists or if the user configured their viewer to do this): the v3 viewer may perfectly reparent a folder received at the root of the inventory to "Received Items" folder, while a v1 viewer (or a user having deleted the "Received Items" folder because they don't want it) will not be able to deal with reparenting from a non-existent folder to its root folder (and the received items may be lost, which would cause definitive inventory loss for no-copy items...). Please, reconsider this IMO crippled protocol... Regards, Henri. From oz at lindenlab.com Thu Feb 9 11:11:30 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 09 Feb 2012 14:11:30 -0500 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120209195531.bdb018a2.sldev@free.fr> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> <20120209195531.bdb018a2.sldev@free.fr> Message-ID: <4F341A62.9090905@lindenlab.com> On 2012-02-09 13:55 , Henri Beauchamp wrote: > Greetings, > > Sorry for my late reply, but I have been busy backporting multiple > clothing layers to the Cool VL Viewer this last couple of weeks > (released today in Cool VL Viewer v1.26.3.4)... > > On Mon, 6 Feb 2012 11:13:31 -0800, Jenn Leech wrote: > >> I should add that we are also testing inventory routing changes on those >> sims on aditi as well. Items which are *newly* sent to your inventory >> should show up in the Received Items folder (e.g. someone gives you an >> item, you purchase an item etc. - these will show up in this new system >> folder). > And that's why it currently fails with the patch as provided by Oz for > v2/3 and backported by me to v1. Here is an example of the log I get in > the CG Test 8 region when hitting the "Copy And Wear" button of the > "Objects Contents" floater on a prim (named "Copy And Wear Test" > containing the items copied from the "Boy Next Door" stock (library) > avatar: > > - On the first try, a new "Received Items" folder is created at the > root of the inventory, but nothing appears in it (luckily, the items > are copy-ok and therefore not gone from the container prim). > > - On the second try (i.e. after "Received Items" was created), I get: > > 2012-02-09T18:28:47Z DEBUG: createNewCategory: Using the CreateInventoryCategory capability. > 2012-02-09T18:28:48Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: 5 > 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(f55dae61-cfe8-e6b6-5429-bfb973639ea9) was NULL > 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(7371ea0b-2f57-ab08-02cb-031378564b83) was NULL > 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(775690a1-f412-69c3-fafe-2e4698af15d9) was NULL > 2012-02-09T18:28:49Z DEBUG: accountForUpdate: accounted: 'Copy And Wear Test' 2 with 1 descendents. > .../... (repeated for each item) > 2012-02-09T18:28:49Z INFO: processBulkUpdateInventory: Bulk inventory: ffffffff-ffff-ffff-ffff-ffffffffffff > 2012-02-09T18:28:49Z DEBUG: accountForUpdate: accounted: 'My Inventory' 902 with 18 descendents. > 2012-02-09T18:28:49Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: 5 > 2012-02-09T18:28:49Z INFO: processBulkUpdateInventory: Bulk inventory: 76ac463f-ca9b-608b-b5f7-80d1cb519463 > 2012-02-09T18:28:49Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: -1 > .../... (repeated for each item) > > The items then do appear in a sub-folder of "Received Items", but they > are not worn. > >> We plan to announce a public beta for testing these behavior changes in the >> next couple of weeks and have been performing primarily internal testing so >> far. > What we'd need now is the viewer side code dealing with the "Received > Items" folder (obviously, it's a new system folder...another of > these stupid folders that will crowd the root of our inventory). > > But I think it's a BAD IDEA to FORCE things to go into a specific folder > from the server side (it should be the viewer to decide where it puts the > received inventory: either at the root, like v1 always did, or in Received > Items" if it exists or if the user configured their viewer to do this): > the v3 viewer may perfectly reparent a folder received at the root of the > inventory to "Received Items" folder, while a v1 viewer (or a user > having deleted the "Received Items" folder because they don't want it) > will not be able to deal with reparenting from a non-existent folder to > its root folder (and the received items may be lost, which would cause > definitive inventory loss for no-copy items...). > > Please, reconsider this IMO crippled protocol... > Henri, that protocol is not subject to change at this very late date. Thanks for the problem report - hopefully Jenn will be able to coordinate with you to get a proper fix together (I'm going to be on vacation starting tomorrow evening for a bit over a week). From sldev at free.fr Thu Feb 9 11:14:10 2012 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 9 Feb 2012 20:14:10 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <4F341A62.9090905@lindenlab.com> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> <20120209195531.bdb018a2.sldev@free.fr> <4F341A62.9090905@lindenlab.com> Message-ID: <20120209201410.696d47fe.sldev@free.fr> On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote: > Henri, that protocol is not subject to change at this very late date. LOL !... You are kidding me, right ?... What's the use to ask for feedback if everything is already settled ?... That got to be a (very bad) joke !!! Henri. From carlo at alinoe.com Fri Feb 10 05:26:59 2012 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 10 Feb 2012 14:26:59 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120209201410.696d47fe.sldev@free.fr> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> <20120209195531.bdb018a2.sldev@free.fr> <4F341A62.9090905@lindenlab.com> <20120209201410.696d47fe.sldev@free.fr> Message-ID: <20120210142659.77f8c11a@hikaru.localdomain> On Thu, 9 Feb 2012 20:14:10 +0100 Henri Beauchamp wrote: > On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote: > > > Henri, that protocol is not subject to change at this very late > > date. > > LOL !... You are kidding me, right ?... What's the use to ask for > feedback if everything is already settled ?... That got to be a > (very bad) joke !!! This is exactly what you can and should expect from Linden Lab by now... When did they EVER really listen? -- Carlo Wood From tateru.nino at gmail.com Fri Feb 10 06:29:43 2012 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 11 Feb 2012 01:29:43 +1100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120209201410.696d47fe.sldev@free.fr> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> <20120209195531.bdb018a2.sldev@free.fr> <4F341A62.9090905@lindenlab.com> <20120209201410.696d47fe.sldev@free.fr> Message-ID: <4F3529D7.70303@gmail.com> On 10/02/2012 6:14 AM, Henri Beauchamp wrote: > On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote: > >> Henri, that protocol is not subject to change at this very late date. > LOL !... You are kidding me, right ?... What's the use to ask for > feedback if everything is already settled ?... That got to be a > (very bad) joke !!! A small correction: The Lab never asked for feedback, as far as I can tell. What was said was (essentially), "We're changing these things, here's what can go wrong, this is the patch you should apply." I don't recall anyone asking for feedback. From sldev at free.fr Fri Feb 10 08:26:14 2012 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 10 Feb 2012 17:26:14 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <4F3529D7.70303@gmail.com> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> <20120209195531.bdb018a2.sldev@free.fr> <4F341A62.9090905@lindenlab.com> <20120209201410.696d47fe.sldev@free.fr> <4F3529D7.70303@gmail.com> Message-ID: <20120210172614.7d39a550.sldev@free.fr> On Sat, 11 Feb 2012 01:29:43 +1100, Tateru Nino wrote: > On 10/02/2012 6:14 AM, Henri Beauchamp wrote: > > On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote: > > > >> Henri, that protocol is not subject to change at this very late date. > > LOL !... You are kidding me, right ?... What's the use to ask for > > feedback if everything is already settled ?... That got to be a > > (very bad) joke !!! > A small correction: The Lab never asked for feedback, as far as I can > tell. What was said was (essentially), "We're changing these things, > here's what can go wrong, this is the patch you should apply." > > I don't recall anyone asking for feedback. Excepted that the patch is incomplete/non-functional and that feedback *is* requested on the Wiki page for Aditi inventory test region... See: https://wiki.secondlife.com/wiki/InventoryBetaTest#Details Henri. From tateru.nino at gmail.com Fri Feb 10 10:21:03 2012 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 11 Feb 2012 05:21:03 +1100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120210172614.7d39a550.sldev@free.fr> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> <20120209195531.bdb018a2.sldev@free.fr> <4F341A62.9090905@lindenlab.com> <20120209201410.696d47fe.sldev@free.fr> <4F3529D7.70303@gmail.com> <20120210172614.7d39a550.sldev@free.fr> Message-ID: <4F35600F.8000900@gmail.com> On 11/02/2012 3:26 AM, Henri Beauchamp wrote: > On Sat, 11 Feb 2012 01:29:43 +1100, Tateru Nino wrote: > >> On 10/02/2012 6:14 AM, Henri Beauchamp wrote: >>> On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote: >>> >>>> Henri, that protocol is not subject to change at this very late date. >>> LOL !... You are kidding me, right ?... What's the use to ask for >>> feedback if everything is already settled ?... That got to be a >>> (very bad) joke !!! >> A small correction: The Lab never asked for feedback, as far as I can >> tell. What was said was (essentially), "We're changing these things, >> here's what can go wrong, this is the patch you should apply." >> >> I don't recall anyone asking for feedback. > Excepted that the patch is incomplete/non-functional and that > feedback *is* requested on the Wiki page for Aditi inventory > test region... > See: https://wiki.secondlife.com/wiki/InventoryBetaTest#Details > > Henri. Only insofar as to whether it functions or fails to function for the test criteria, as far as I can see. From sldev at free.fr Fri Feb 10 10:31:17 2012 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 10 Feb 2012 19:31:17 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <4F35600F.8000900@gmail.com> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> <20120209195531.bdb018a2.sldev@free.fr> <4F341A62.9090905@lindenlab.com> <20120209201410.696d47fe.sldev@free.fr> <4F3529D7.70303@gmail.com> <20120210172614.7d39a550.sldev@free.fr> <4F35600F.8000900@gmail.com> Message-ID: <20120210193117.b3d514bf.sldev@free.fr> On Sat, 11 Feb 2012 05:21:03 +1100, Tateru Nino wrote: > On 11/02/2012 3:26 AM, Henri Beauchamp wrote: > > On Sat, 11 Feb 2012 01:29:43 +1100, Tateru Nino wrote: > > > >> On 10/02/2012 6:14 AM, Henri Beauchamp wrote: > >>> On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote: > >>> > >>>> Henri, that protocol is not subject to change at this very late date. > >>> LOL !... You are kidding me, right ?... What's the use to ask for > >>> feedback if everything is already settled ?... That got to be a > >>> (very bad) joke !!! > >> A small correction: The Lab never asked for feedback, as far as I can > >> tell. What was said was (essentially), "We're changing these things, > >> here's what can go wrong, this is the patch you should apply." > >> > >> I don't recall anyone asking for feedback. > > Excepted that the patch is incomplete/non-functional and that > > feedback *is* requested on the Wiki page for Aditi inventory > > test region... > > See: https://wiki.secondlife.com/wiki/InventoryBetaTest#Details > > > > Henri. > Only insofar as to whether it functions or fails to function for the > test criteria, as far as I can see. OK... So let's be anal... Quoting the Wiki ("***" highlightings are mine): "Why: To help make Inventory more reliable and faster How: ***However*** you can." and: "Testing will be as simple as rezzing objects and transferring them between yourselves and others ***by any method you can imagine***." and finally: "File JIRAs for any issues you find ..." If it's not a request for feedback, then I don't know what it is.. Granted, I didn't file a JIRA, but since the patch was posted here... Now, if feedback and contributions are not welcome by LL, they could as well close this list and close the sources of their viewer... Henri. From kadah.coba at gmail.com Fri Feb 10 11:03:12 2012 From: kadah.coba at gmail.com (Kadah) Date: Fri, 10 Feb 2012 11:03:12 -0800 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120210193117.b3d514bf.sldev@free.fr> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> <20120128201334.f74c3cfd.sldev@free.fr> <4F2C3C9C.9020005@lindenlab.com> <20120209195531.bdb018a2.sldev@free.fr> <4F341A62.9090905@lindenlab.com> <20120209201410.696d47fe.sldev@free.fr> <4F3529D7.70303@gmail.com> <20120210172614.7d39a550.sldev@free.fr> <4F35600F.8000900@gmail.com> <20120210193117.b3d514bf.sldev@free.fr> Message-ID: <4F3569F0.5070509@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/10/2012 10:31 AM, Henri Beauchamp wrote: > "File JIRAs for any issues you find ..." > > If it's not a request for feedback, then I don't know what it is.. > > Granted, I didn't file a JIRA, but since the patch was posted > here... ^Yeah, that. The server folks don't monitor this list so posting feedback here when a Jira is in order is not going to get this issue attention in a timely manner. Oz's responsibility was to inform us of an impending change(s) to the inventory service but only the viewer side changes required for those service changes themselves are in his purview. If there is a problem with the either of the 2 changes to the inventory service, the product owner needs to know before this gets put in an RC, so file a Jira yesterday. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPNWnwAAoJEIdLfPRu7qE2cgkIAIl8HPKtTRrQfpnjuIkLr2rB oz8fJhLkSnSywo/CDxFX39eXdxsaRPRzpJtlQqpt8AX1wAN/ehS5Zh2aIVoiTFSX 1/SWhnJiQKso7Sg35uZAYPqVXUBRWL1ynYVfz5RVk7SyDjM/bJmh3qPNFoRdERsr UyNAcxYnYWxhksmdSYfjbc27wOoSJDDPYkGpKum8wi1v5A03fjFqej1jwQ4Ye7Wt mPZObr7FNCypr4cMUcKKAtWLlK3K4er0dngWRWr6BjCJnk6T3sJzMx8bkEJ9tgYb VIn4lvSx7ObbpaDEgV6v+IonblAKpo8ppzTZvuMmtFh6bE3le9ags4YQEcP8G5I= =cbNE -----END PGP SIGNATURE----- From Lance.Corrimal at eregion.de Tue Feb 14 00:55:52 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 14 Feb 2012 09:55:52 +0100 Subject: [opensource-dev] do these warnings matter? Message-ID: <1582545.j6WNFKGSGb@nb-20> Hi, I've noticed *TONS* of warnings like this one in my logfiles: 2012-02-14T08:51:24Z WARNING: getChild: Making dummy 8LLUICtrl named "translate_chat_checkbox" in chat_bar what causes them? does it matter (other than inflating log file size)? bye, LC From tinacloud at gmx.de Tue Feb 14 10:42:04 2012 From: tinacloud at gmx.de (Zi Ree) Date: Tue, 14 Feb 2012 19:42:04 +0100 Subject: [opensource-dev] do these warnings matter? In-Reply-To: <1582545.j6WNFKGSGb@nb-20> References: <1582545.j6WNFKGSGb@nb-20> Message-ID: <201202141942.04814.tinacloud@gmx.de> Am Dienstag, 14. Februar 2012, 09:55:52 schrieb Lance Corrimal: > 2012-02-14T08:51:24Z WARNING: getChild: Making dummy 8LLUICtrl named > "translate_chat_checkbox" in chat_bar These are harmless. It means that there are controls referenced in the code, like buttons, frames, sliders, etc., that are not actually in the currently used skin. So skin makers can remove pieces from the UI without the code crashing, because the control is missing. It creates a "dummy" control on the fly that is not visible but acts as a placeholder for the code. > LC Zi From Lance.Corrimal at eregion.de Tue Feb 14 11:11:09 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 14 Feb 2012 20:11:09 +0100 Subject: [opensource-dev] do these warnings matter? In-Reply-To: <201202141942.04814.tinacloud@gmx.de> References: <1582545.j6WNFKGSGb@nb-20> <201202141942.04814.tinacloud@gmx.de> Message-ID: <2143400.W8Q23gmyL2@sai> Am Dienstag, 14. Februar 2012, 19:42:04 schrieb Zi Ree: > Am Dienstag, 14. Februar 2012, 09:55:52 schrieb Lance Corrimal: > > 2012-02-14T08:51:24Z WARNING: getChild: Making dummy 8LLUICtrl named > > "translate_chat_checkbox" in chat_bar > > These are harmless. It means that there are controls referenced in the code, > like buttons, frames, sliders, etc., that are not actually in the currently > used skin. So skin makers can remove pieces from the UI without the code > crashing, because the control is missing. It creates a "dummy" control on > the fly that is not visible but acts as a placeholder for the code. So it would be actually "wise" to change that to LL_DEBUG, like someone else suggested to me... good to know. bye, LC From sllists at boroon.dasgupta.ch Tue Feb 14 13:04:05 2012 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 14 Feb 2012 22:04:05 +0100 Subject: [opensource-dev] do these warnings matter? In-Reply-To: <2143400.W8Q23gmyL2@sai> References: <1582545.j6WNFKGSGb@nb-20> <201202141942.04814.tinacloud@gmx.de> <2143400.W8Q23gmyL2@sai> Message-ID: <4F3ACC45.4080509@boroon.dasgupta.ch> On 02/14/2012 08:11 PM, Lance Corrimal wrote: > Am Dienstag, 14. Februar 2012, 19:42:04 schrieb Zi Ree: >> Am Dienstag, 14. Februar 2012, 09:55:52 schrieb Lance Corrimal: >>> 2012-02-14T08:51:24Z WARNING: getChild: Making dummy 8LLUICtrl named >>> "translate_chat_checkbox" in chat_bar >> These are harmless. It means that there are controls referenced in the code, >> like buttons, frames, sliders, etc., that are not actually in the currently >> used skin. So skin makers can remove pieces from the UI without the code >> crashing, because the control is missing. It creates a "dummy" control on >> the fly that is not visible but acts as a placeholder for the code. > > So it would be actually "wise" to change that to LL_DEBUG, like someone else > suggested to me... good to know. I wouldn't say so. While the viewer still runs fine when these warnings occur, they are indicative of code and XUI files being out of sync in respect to each other. This can also happen, when identifiers are misspelled. If the names match, but the child control is of the wrong type, you'll get different warnings . AFAIK, in both these cases, the running control wouldn't be matched to its XUI specification, so attributes there lose their effect, which most often isn't what's wanted. So the right thing to do is to hunt down the code and XUI of the control causing this warning, see which one of them is "right" and bring them into sync. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120214/01d9fc55/attachment.htm From jhwelch at gmail.com Wed Feb 15 05:12:44 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 15 Feb 2012 13:12:44 -0000 Subject: [opensource-dev] Review Request: STORM-1812 Music stream does not always restart after teleporting Message-ID: <20120215131244.25286.60366@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/556/ ----------------------------------------------------------- Review request for Viewer. Description ------- The music stream does not restart if you teleport within the same parcel. This addresses bug STORM-1812. http://jira.secondlife.com/browse/STORM-1812 Diffs ----- doc/contributions.txt 0a41a8750048 indra/newview/llvieweraudio.h 0a41a8750048 indra/newview/llvieweraudio.cpp 0a41a8750048 indra/newview/llviewerparcelmgr.h 0a41a8750048 indra/newview/llviewerparcelmgr.cpp 0a41a8750048 Diff: http://codereview.secondlife.com/r/556/diff/diff Testing ------- See Test Plan in jira. During early investigation and testing of this fix there were times the play button became grayed out. I have not been able to reproduce this condition recently. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120215/176bad80/attachment.htm From Lance.Corrimal at eregion.de Wed Feb 15 22:27:44 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 16 Feb 2012 07:27:44 +0100 Subject: [opensource-dev] "upload settings file" for mesh upload? Message-ID: <3893756.rG6Mph8q1U@sai> Hi has anyone here ever heard of a "upload settings file" for second life, somehow related to mesh uploads? bye, LC From cinder at cinderblocks.biz Wed Feb 15 22:51:18 2012 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Wed, 15 Feb 2012 23:51:18 -0700 Subject: [opensource-dev] "upload settings file" for mesh upload? In-Reply-To: <3893756.rG6Mph8q1U@sai> References: <3893756.rG6Mph8q1U@sai> Message-ID: <000001ccec77$6396eac0$2ac4c040$@biz> There's an upload config file the viewer downloads to send snapshots to profile feeds, it's not related to mesh, but I don't know any other upload settings files the viewer grabs. Kind regards, -Cinder -----Original Message----- From: Lance Corrimal Sent: Wednesday, February 15, 2012 11:28 PM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] "upload settings file" for mesh upload? Hi has anyone here ever heard of a "upload settings file" for second life, somehow related to mesh uploads? bye, LC From jhwelch at gmail.com Fri Feb 17 09:23:17 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 17 Feb 2012 12:23:17 -0500 Subject: [opensource-dev] Pathfinding alpha announced Message-ID: In case you did not see the announcement yesterday here it is: http://community.secondlife.com/t5/Featured-News/Take-a-Sneak-Peek-at-the-Pathfinding-Experiments-Being-Conducted/ba-p/1386511 From tigrospottystripes at gmail.com Fri Feb 17 16:33:59 2012 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 17 Feb 2012 22:33:59 -0200 Subject: [opensource-dev] Pathfinding alpha announced In-Reply-To: References: Message-ID: Wouldn't it be better if the "types" for the diffferent Walkable coeficients were bitmasks instead of just A, B , C, D? Or perhaps even just an editable list of IDs (integers values) and the associated weights for each integer On Fri, Feb 17, 2012 at 3:23 PM, Jonathan Welch wrote: > In case you did not see the announcement yesterday here it is: > > http://community.secondlife.com/t5/Featured-News/Take-a-Sneak-Peek-at-the-Pathfinding-Experiments-Being-Conducted/ba-p/1386511 > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120217/6f9944d3/attachment.htm From moriz.gupte at gmail.com Fri Feb 17 17:07:48 2012 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Fri, 17 Feb 2012 18:07:48 -0700 Subject: [opensource-dev] avatar NPCs Message-ID: Apologies in advance for my stupid question. Say I want to create a human NPC, the way am understanding the new pathfinding functions is that the we cannot create an NPC bot as easily as in opensim. Are we supposed to create a mesh avatar and then animate the mesh (am not sure this is even doable giving the current status of mesh) then use the pathfinding functions to move that mesh ...? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120217/cd7f8250/attachment.htm From Lance.Corrimal at eregion.de Sat Feb 18 00:28:55 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 18 Feb 2012 08:28:55 -0000 Subject: [opensource-dev] Review Request: VWR-28087: When I upload a texture, the "preview as" dropdown in the preview window is hidden under the texture In-Reply-To: <20120112100600.13488.90029@domU-12-31-38-00-90-68.compute-1.internal> References: <20120112100600.13488.90029@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120218082855.24915.59366@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/532/#review1164 ----------------------------------------------------------- i guess when a CR doesn't get approved right away it falls into oblivion? - Lance Corrimal On Jan. 12, 2012, 2:06 a.m., Lance Corrimal wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/532/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2012, 2:06 a.m.) > > > Review request for Viewer. > > > Description > ------- > > At some point in the last 8 months the height of image previews in the upload preview floater was increased by 20, without adapting the actual floater, leading to VWR-28087. > This small patch fixes that by adapting the preview floater to the new height. > > > This addresses bug VWR-28087. > http://jira.secondlife.com/browse/VWR-28087 > > > Diffs > ----- > > indra/newview/skins/default/xui/en/floater_image_preview.xml 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/532/diff/diff > > > Testing > ------- > > tested with release viewer 3.2.5 and my own TPV, works fine. > > > Thanks, > > Lance Corrimal > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120218/7f1c902d/attachment.htm From Lance.Corrimal at eregion.de Sat Feb 18 00:30:24 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 18 Feb 2012 09:30:24 +0100 Subject: [opensource-dev] webkit for linux builds too old? Message-ID: <2336296.sBirvNyZmp@sai> Hi, I get "webkit too old" log file entries on linux a lot... Is there a special reason why the linux builds use webkit 4.6 while mac and windows use 4.7.1? bye, LC From sldev at free.fr Sat Feb 18 01:49:37 2012 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 18 Feb 2012 10:49:37 +0100 Subject: [opensource-dev] webkit for linux builds too old? In-Reply-To: <2336296.sBirvNyZmp@sai> References: <2336296.sBirvNyZmp@sai> Message-ID: <20120218104937.9007de6e.sldev@free.fr> On Sat, 18 Feb 2012 09:30:24 +0100, Lance Corrimal wrote: > Hi, > > I get "webkit too old" log file entries on linux a lot... > > Is there a special reason why the linux builds use webkit 4.6 while mac and > windows use 4.7.1? Probably because LL didn't figure out the changes to how the new qtwebkit must be packaged and linked now (with jscore that has to be added)... You could use the version I compiled for the Cool VL Viewer: http://sldev.free.fr/libraries/llqtwebkit-linux-qt4.7.1-20110813.tar.bz2 with MD5 hash: 1baafd063d69cc7ae4a54de43debb790 You will also need to change indra/cmake/WebKitLibPlugin.cmake to remove qgif, qjpeg and jpeg from WEBKIT_PLUGIN_LIBRARIES and to add jscore to it. It would then read: .../... elseif (LINUX) set(WEBKIT_PLUGIN_LIBRARIES ${LLQTWEBKIT_LIBRARY} ${QT_LIBRARIES} ${QT_PLUGIN_LIBRARIES}) set(WEBKIT_PLUGIN_LIBRARIES llqtwebkit # qico # qpng # qtiff # qsvg # QtSvg QtWebKit QtOpenGL QtNetwork QtGui QtCore jscore # qgif # qjpeg # jpeg fontconfig X11 Xrender GL # sqlite3 # Xi # SM ) endif (WINDOWS) .../... Henri. From carlo at alinoe.com Sat Feb 18 04:31:52 2012 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 18 Feb 2012 13:31:52 +0100 Subject: [opensource-dev] Pathfinding alpha announced In-Reply-To: References: Message-ID: <20120218133152.1df24987@hikaru.localdomain> On Fri, 17 Feb 2012 22:33:59 -0200 Tigro Spottystripes wrote: > Wouldn't it be better if the "types" for the diffferent Walkable > coeficients were bitmasks instead of just A, B , C, D? Or perhaps > even just an editable list of IDs (integers values) and the > associated weights for each integer Don't try to have influence on what LL designed behind closed doors. It is already set in stone. -- Carlo Wood From garmin.kawaguichi at magalaxie.com Sat Feb 18 05:24:19 2012 From: garmin.kawaguichi at magalaxie.com (Garmin Kawaguichi) Date: Sat, 18 Feb 2012 14:24:19 +0100 Subject: [opensource-dev] Pathfinding alpha announced References: Message-ID: In the blog post we find the acronym NPC http://en.wikipedia.org/wiki/Non-player_character I'd prefer here NPO, non playable object 8); in the video I expected to see clones of Lorca Linden !! Is there going to be future developments? GCI ----- Original Message ----- From: "Jonathan Welch" Sent: Friday, February 17, 2012 6:23 PM Subject: [opensource-dev] Pathfinding alpha announced In case you did not see the announcement yesterday here it is: http://community.secondlife.com/t5/Featured-News/Take-a-Sneak-Peek-at-the-Pathfinding-Experiments-Being-Conducted/ba-p/1386511 From jhwelch at gmail.com Sat Feb 18 05:24:57 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Sat, 18 Feb 2012 13:24:57 -0000 Subject: [opensource-dev] Review Request: STORM-1807 Play animation floater 2nd play button active while animation is playing In-Reply-To: <20120208203935.30474.97918@domU-12-31-38-00-90-68.compute-1.internal> References: <20120208203935.30474.97918@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120218132457.24917.79844@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/552/ ----------------------------------------------------------- (Updated Feb. 18, 2012, 5:24 a.m.) Review request for Viewer. Changes ------- Fix possible compiling issue on Linux Description ------- Part 1 Open your inventory's Animations folder Double click on an animation Click on Play Inworld: Play Inworld is replaced by a Stop button Observed behavior: It is still possible to click on Play Locally, which also is replaced by a Stop button. Clicking on either Stop works and resets the floater back to having both Play buttons showing. Expected behavior: When one of the play buttons is clicked the other should be disabled. Part 2 1 .To reproduce, get any non looping animation. ie, one that plays once and then stops. 2. Right click in inventory and select play in world. 3. The animation dialog appears with play locally and play in world buttons. 4. When the animation is playing, the play in world button changes to a stop button, which makes it stop playing. Now here's the problem: 5. When the animation finishes of it's own accord, the button still says stop. To play it again, you have to click the redundant stop button to make it change back to Play in World, then click that to play again. Expected behaviour, is that when an animation finishes, the stop button should change back of it's own accord. This addresses bug STORM-1807. http://jira.secondlife.com/browse/STORM-1807 Diffs (updated) ----- doc/contributions.txt 0a41a8750048 indra/newview/llinventorybridge.cpp 0a41a8750048 indra/newview/llpreviewanim.h 0a41a8750048 indra/newview/llpreviewanim.cpp 0a41a8750048 indra/newview/skins/default/xui/en/floater_preview_animation.xml 0a41a8750048 Diff: http://codereview.secondlife.com/r/552/diff/diff Testing ------- See test plan in jira. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120218/bba97e8c/attachment-0001.htm From moriz.gupte at gmail.com Sat Feb 18 08:34:10 2012 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Sat, 18 Feb 2012 09:34:10 -0700 Subject: [opensource-dev] Pathfinding alpha announced In-Reply-To: References: Message-ID: I totally agree with you Garmin, it should have been named NPO ... I felt a little disappointed because I was really expecting NPC, actually waiting for that ... I understand pathfinding is part of the deal, but just had to adjust my lowered expectations ... R On Sat, Feb 18, 2012 at 6:24 AM, Garmin Kawaguichi < garmin.kawaguichi at magalaxie.com> wrote: > In the blog post we find the acronym NPC > http://en.wikipedia.org/wiki/Non-player_character > > I'd prefer here NPO, non playable object 8); in the video I expected to see > clones of Lorca Linden !! > > Is there going to be future developments? > > GCI > > ----- Original Message ----- > From: "Jonathan Welch" > Sent: Friday, February 17, 2012 6:23 PM > Subject: [opensource-dev] Pathfinding alpha announced > In case you did not see the announcement yesterday here it is: > > http://community.secondlife.com/t5/Featured-News/Take-a-Sneak-Peek-at-the-Pathfinding-Experiments-Being-Conducted/ba-p/1386511 > _______________________________________________ > 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 > -- 'Consider how the lilies grow. They do not labor or spin.' *Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: 208-282-5333 Blog , LinkedIn , Play2Train -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120218/a037b512/attachment.htm From sythos at gmail.com Sat Feb 18 08:41:30 2012 From: sythos at gmail.com (Sythos) Date: Sat, 18 Feb 2012 17:41:30 +0100 Subject: [opensource-dev] webkit for linux builds too old? In-Reply-To: <20120218104937.9007de6e.sldev@free.fr> References: <2336296.sBirvNyZmp@sai> <20120218104937.9007de6e.sldev@free.fr> Message-ID: <20120218174130.fbccb34926b44272ff4c53ac@gmail.com> On Sat, 18 Feb 2012 10:49:37 +0100 Henri Beauchamp wrote: > On Sat, 18 Feb 2012 09:30:24 +0100, Lance Corrimal wrote: > > > Hi, > > > > I get "webkit too old" log file entries on linux a lot... > > > > Is there a special reason why the linux builds use webkit 4.6 while > > mac and windows use 4.7.1? > > Probably because LL didn't figure out the changes to how the new > qtwebkit must be packaged and linked now (with jscore that has > to be added)... i got another kind of problems, autobuild wrongly detect flags from host OS, i've added by hand ni makefile "--no-avx --no-sse4.1 --no-sse4.2" and forced the cpu/arch, for a reason not clear (to me) autobuild create binaries with SSE4 and AVX registry optimization (probed CPU but not arch/OS) compiling on linux as is from hg don't produce a usable package on my system From sldev at free.fr Sat Feb 18 09:35:56 2012 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 18 Feb 2012 18:35:56 +0100 Subject: [opensource-dev] webkit for linux builds too old? In-Reply-To: <20120218174130.fbccb34926b44272ff4c53ac@gmail.com> References: <2336296.sBirvNyZmp@sai> <20120218104937.9007de6e.sldev@free.fr> <20120218174130.fbccb34926b44272ff4c53ac@gmail.com> Message-ID: <20120218183556.b16a52a9.sldev@free.fr> On Sat, 18 Feb 2012 17:41:30 +0100, Sythos wrote: > i got another kind of problems, autobuild wrongly detect flags from > host OS, i've added by hand ni makefile "--no-avx --no-sse4.1 > --no-sse4.2" and forced the cpu/arch, for a reason not clear (to me) > autobuild create binaries with SSE4 and AVX registry optimization > (probed CPU but not arch/OS) > > compiling on linux as is from hg don't produce a usable package on my > system I don't use autobuild... I built it manually on a Mandriva 2007.1 system (which uses glibc v2.4, so it's compatible with LL's own prebuilt binaries). The instruction given in the REAMDE-linux.txt file, should be ammended to read: 1) BUILDING Qt FOR LINUX LLQTWEBKIT ----------------------------------- Acquire the Qt 4.7.1 source with our patches * Download the source: hg clone https://bitbucket.org/lindenlab/3p-qt * This may take some as the archive contains a lot of files * You should now have a directory ~/3p-qt/qt-everywhere-opensource-src-4.7.1 * Open a terminal window and cd to ~/3p-qt/qt-everywhere-opensource-src-4.7.1 directory * run the following commands (we'll use the QTDIR variable in later steps) export QTDIR=`pwd` export PATH=$QTDIR/bin:$PATH export MAKEFLAGS="-j6" export CFLAGS="-m32 -fno-stack-protector" export CXXFLAGS="-m32 -fno-stack-protector -DQT_NO_INOTIFY" export LDFLAGS="-m32 -fno-stack-protector" export OPENSSL_LIBS="-L`pwd`/../OpenSSL/libraries/i686-linux/lib_release_client -lssl -lcrypto" Configure the Build $ ./configure -v -platform linux-g++-32 -fontconfig -fast -no-qt3support -static -release -no-xmlpatterns -no-phonon -openssl-linked -no-3dnow -no-sse -no-sse2 -no-sse3 -no-ssse3 -no-sse4.1 -no-sse4.2 -no-gtkstyle -no-xinput -no-sm -buildkey LL$(date +%s) -no-sql-sqlite -no-scripttools -no-cups -no-dbus -qt-libmng -no-glib -qt-gif -qt-libjpeg -qt-libtiff -qt-zlib -qt-libpng -opengl desktop -no-xkb -xrender -svg -no-pch -webkit -multimedia -javascript-jit -opensource -nomake examples -nomake demos -nomake docs -nomake translations -nomake tools * Accept the license, if you do. * Wait a few minutes while it churns and bootstraps. * Build Qt: $ make -j6 * Wait ages for it to build. * You're done, but if you want to go on to build llqtwebkit on this machine, you'd really better do... $ sudo make install 2) BUILDING LLQTWEBKIT ---------------------- * set up environment vars - change '4.7.1' as appropriate for your Qt version. $ export QTDIR=/usr/local/Trolltech/Qt-4.7.1 $ export PATH=$QTDIR/bin:$PATH * configure llqtwebkit $ qmake CONFIG-=debug * Are you making a build for redistribution to other people and you are not specifically on Ubuntu Dapper? Then please hack the resulting Makefile and add '-fno-stack-protector' to CXXFLAGS and CFLAGS. This is important! Otherwise your resulting lib will not be usable at runtime on many machines. * build it $ make 3) THE BITS THAT THE VIEWER BUILD NEEDS --------------------------------------- * From Qt: lib/*.a plugins/imageformats/*.a 3p-qt/qt-everywhere-opensource-src-4.7.1/src/3rdparty/webkit/JavaScriptCore/release/libjscore.a * From LLQtWebKit: libllqtwebkit.a llqtwebkit.h Henri. From oz at lindenlab.com Sat Feb 18 13:37:49 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sat, 18 Feb 2012 22:37:49 +0100 Subject: [opensource-dev] ObjectCategory Message-ID: Does anyone know of any current use of the ObjectCategory message or the Category information it carries? http://wiki.secondlife.com/wiki/ObjectCategory From sldev at free.fr Sat Feb 18 14:36:37 2012 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 18 Feb 2012 23:36:37 +0100 Subject: [opensource-dev] ObjectCategory In-Reply-To: References: Message-ID: <20120218233637.0a1a91d9.sldev@free.fr> On Sat, 18 Feb 2012 22:37:49 +0100, Oz Linden (Scott Lawrence) wrote: > Does anyone know of any current use of the ObjectCategory message or > the Category information it carries? It is used in LLSelectMgr::selectionSetObjectCategory(), but this function doesn't seem to be used anywhere in the viewer code... I would say that it would allow to set the category (inventory folder) to which the object is to be "derezzed" (this is normally set on rezzing for objects dragged from the inventory and dropped into the sim, so that when "Taking" the object back, it reappears in the inventory folder from which it was rezzed). Henri. From tateru.nino at gmail.com Sat Feb 18 15:32:06 2012 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun, 19 Feb 2012 10:32:06 +1100 Subject: [opensource-dev] Pathfinding alpha announced In-Reply-To: References: Message-ID: <4F4034F6.8080606@gmail.com> There are always future developments. :) I thought it was clear that we were talking about objects. The 'C' in NPC doesn't imply that you're talking about an agent or an object in SL terms, anyway - in many UGC-based virtual environments, NPCs are *usually* objects rather than agents, though. I imagined it was kind of clear that the project was about objects, and not agents. On 19/02/2012 12:24 AM, Garmin Kawaguichi wrote: > In the blog post we find the acronym NPC > http://en.wikipedia.org/wiki/Non-player_character > > I'd prefer here NPO, non playable object 8); in the video I expected to see > clones of Lorca Linden !! > > Is there going to be future developments? > > GCI > > ----- Original Message ----- > From: "Jonathan Welch" > Sent: Friday, February 17, 2012 6:23 PM > Subject: [opensource-dev] Pathfinding alpha announced > In case you did not see the announcement yesterday here it is: > http://community.secondlife.com/t5/Featured-News/Take-a-Sneak-Peek-at-the-Pathfinding-Experiments-Being-Conducted/ba-p/1386511 > _______________________________________________ > 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 > From jhwelch at gmail.com Sun Feb 19 11:08:57 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Sun, 19 Feb 2012 19:08:57 -0000 Subject: [opensource-dev] Review Request: STORM-1808 Indicate ability to build In-Reply-To: <20120208233102.30478.34780@domU-12-31-38-00-90-68.compute-1.internal> References: <20120208233102.30478.34780@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120219190857.6249.69094@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/553/ ----------------------------------------------------------- (Updated Feb. 19, 2012, 11:08 a.m.) Review request for Viewer. Changes ------- Recoded so build button is not clickable when grayed out. Description ------- When standing in a parcel it would be helpful to have a graphical indication in the UI if you are able to build/rez. The icon in the (mini) location bar shows parcel properties, not what is available to you as parcel owner or as a member of a group that has rezzing enabled as one of your group roles. Suggested solution: Gray out the build button if it is present on the toolbar, just like the Speak button is grayed out if voice is not available. This addresses bug STORM-1808. http://jira.secondlife.com/browse/STORM-1808 Diffs (updated) ----- doc/contributions.txt 0a41a8750048 indra/newview/app_settings/commands.xml 0a41a8750048 indra/newview/llagent.cpp 0a41a8750048 indra/newview/lltoolmgr.h 0a41a8750048 indra/newview/lltoolmgr.cpp 0a41a8750048 Diff: http://codereview.secondlife.com/r/553/diff/diff Testing ------- See test plan in jira. I also searched the xml files to be sure no other calls to LLAgent::isActionAllowed were being made. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120219/82e4a2c7/attachment.htm From kf6kjg at gmail.com Sun Feb 19 11:32:59 2012 From: kf6kjg at gmail.com (Ricky) Date: Sun, 19 Feb 2012 11:32:59 -0800 Subject: [opensource-dev] Pathfinding alpha announced In-Reply-To: <4F4034F6.8080606@gmail.com> References: <4F4034F6.8080606@gmail.com> Message-ID: From robertltux at gmail.com Sun Feb 19 12:32:14 2012 From: robertltux at gmail.com (Robert Martin) Date: Sun, 19 Feb 2012 15:32:14 -0500 Subject: [opensource-dev] MakeHuman and Mesh Avatars Message-ID: Recently MakeHuman gained the ability to use "custom" rigs as a test of this feature the first custom rig created (by my request) was a SecondLife compatible rig. This means that MakeHuman is about 89% of the way to being able to create Mesh Avatars. Could Somebody Linden see about getting them a bit of support?? -- Robert L Martin From jhwelch at gmail.com Sun Feb 19 13:22:36 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Sun, 19 Feb 2012 21:22:36 -0000 Subject: [opensource-dev] Review Request: STORM-1808 Indicate ability to build In-Reply-To: <20120219190857.6249.69094@domU-12-31-38-00-90-68.compute-1.internal> References: <20120219190857.6249.69094@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120219212236.6248.19031@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/553/ ----------------------------------------------------------- (Updated Feb. 19, 2012, 1:22 p.m.) Review request for Viewer. Changes ------- Fix wrong name in XML file. Description ------- When standing in a parcel it would be helpful to have a graphical indication in the UI if you are able to build/rez. The icon in the (mini) location bar shows parcel properties, not what is available to you as parcel owner or as a member of a group that has rezzing enabled as one of your group roles. Suggested solution: Gray out the build button if it is present on the toolbar, just like the Speak button is grayed out if voice is not available. This addresses bug STORM-1808. http://jira.secondlife.com/browse/STORM-1808 Diffs (updated) ----- doc/contributions.txt 0a41a8750048 indra/newview/app_settings/commands.xml 0a41a8750048 indra/newview/llagent.cpp 0a41a8750048 indra/newview/lltoolmgr.h 0a41a8750048 indra/newview/lltoolmgr.cpp 0a41a8750048 Diff: http://codereview.secondlife.com/r/553/diff/diff Testing ------- See test plan in jira. I also searched the xml files to be sure no other calls to LLAgent::isActionAllowed were being made. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120219/3d90d719/attachment.htm From Lance.Corrimal at eregion.de Mon Feb 20 00:46:17 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 20 Feb 2012 08:46:17 -0000 Subject: [opensource-dev] Review Request: OPEN-136: Outdated webkit on linux Message-ID: <20120220084617.6496.15783@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/557/ ----------------------------------------------------------- Review request for Viewer. Description ------- The viewer uses an outdated webkit on linux which contains old security holes. This should not happen. This addresses bug open-136. http://jira.secondlife.com/browse/open-136 Diffs ----- autobuild.xml 0a41a8750048 indra/newview/viewer_manifest.py 0a41a8750048 Diff: http://codereview.secondlife.com/r/557/diff/diff Testing ------- Using that newer webkit in dolphin viewer 3 beta for some time now, no problems. Thanks, Lance Corrimal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120220/3d036871/attachment.htm From kadah.coba at gmail.com Mon Feb 20 17:09:00 2012 From: kadah.coba at gmail.com (Kadah) Date: Mon, 20 Feb 2012 17:09:00 -0800 Subject: [opensource-dev] ObjectCategory In-Reply-To: <20120218233637.0a1a91d9.sldev@free.fr> References: <20120218233637.0a1a91d9.sldev@free.fr> Message-ID: <4F42EEAC.8020605@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/18/2012 2:36 PM, Henri Beauchamp wrote: > On Sat, 18 Feb 2012 22:37:49 +0100, Oz Linden (Scott Lawrence) > wrote: > >> Does anyone know of any current use of the ObjectCategory message >> or the Category information it carries? > > It is used in LLSelectMgr::selectionSetObjectCategory(), but this > function doesn't seem to be used anywhere in the viewer code... > > I would say that it would allow to set the category (inventory > folder) to which the object is to be "derezzed" (this is normally > set on rezzing for objects dragged from the inventory and dropped > into the sim, so that when "Taking" the object back, it reappears > in the inventory folder from which it was rezzed). > > Henri. I've done a datamine on the whole v-d repo history and couldn't fine any usage of LLSelectMgr::selectionSetObjectCategory(). I'd do the same on 1.x but my SVN clone of it isn't handy. I have the feeling that message hasn't been used in a long time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPQu6sAAoJEIdLfPRu7qE2iR4IAIj1nqaGiA0MtuVDov+jp32+ EzI2yP/5U2u4bg2xgSKoZq0GJnr9bB92rt/MBHHmMrkqT1Ck6WoF0i2aAuV2N0+j IeiIlHcgD8oem7GdPvTt0R3JgZJo9Q2I0MC4GLQn1DjDf6itDaBr5n1HDOtALH2M 9E1M8lmWBHcpDhi4q950HEvlQoSCCkXVKs8HJDxcHD9Z+2EqXHq4UD4FA8CmXcCk WgE8/VtS0DkA3I/dnSLMiCqGNP4dUj2YcIPJguFdhJwOgdU2D28l+AiDSXorLpmK bYArVVQNAr891S2YdeAz/yu6+6mFNcBS1dy7iZ+2ueHXYtPhIgKkmxX9QskT9F4= =waVo -----END PGP SIGNATURE----- From oz at lindenlab.com Wed Feb 22 06:51:32 2012 From: oz at lindenlab.com (Oz Linden) Date: Wed, 22 Feb 2012 14:51:32 -0000 Subject: [opensource-dev] Review Request: STORM-1808 Indicate ability to build In-Reply-To: <20120219212236.6248.19031@domU-12-31-38-00-90-68.compute-1.internal> References: <20120219212236.6248.19031@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120222145132.8530.45081@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/553/#review1165 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Feb. 19, 2012, 1:22 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/553/ > ----------------------------------------------------------- > > (Updated Feb. 19, 2012, 1:22 p.m.) > > > Review request for Viewer. > > > Description > ------- > > When standing in a parcel it would be helpful to have a graphical indication in the UI if you are able to build/rez. > > The icon in the (mini) location bar shows parcel properties, not what is available to you as parcel owner or as a member of a group that has rezzing enabled as one of your group roles. > > Suggested solution: Gray out the build button if it is present on the toolbar, just like the Speak button is grayed out if voice is not available. > > > This addresses bug STORM-1808. > http://jira.secondlife.com/browse/STORM-1808 > > > Diffs > ----- > > doc/contributions.txt 0a41a8750048 > indra/newview/app_settings/commands.xml 0a41a8750048 > indra/newview/llagent.cpp 0a41a8750048 > indra/newview/lltoolmgr.h 0a41a8750048 > indra/newview/lltoolmgr.cpp 0a41a8750048 > > Diff: http://codereview.secondlife.com/r/553/diff/diff > > > Testing > ------- > > See test plan in jira. > > I also searched the xml files to be sure no other calls to LLAgent::isActionAllowed were being made. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120222/f1d332ee/attachment.htm From oz at lindenlab.com Wed Feb 22 07:14:15 2012 From: oz at lindenlab.com (Oz Linden) Date: Wed, 22 Feb 2012 15:14:15 -0000 Subject: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy In-Reply-To: <20120207142810.30474.65567@domU-12-31-38-00-90-68.compute-1.internal> References: <20120207142810.30474.65567@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120222151415.8565.77933@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/#review1166 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Feb. 7, 2012, 6:28 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/545/ > ----------------------------------------------------------- > > (Updated Feb. 7, 2012, 6:28 a.m.) > > > Review request for Viewer. > > > Description > ------- > > The SL simulator has recently been fixed so that the CoarseLocationUpdate message properly returns 255 for all altitudes above 1020 meters. > > The code for the mini-map, in drawing the agent locations for equal, above or below needs to take this into account. It currently does not. > > The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. > > In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. > > > This addresses bug STORM-1793. > http://jira.secondlife.com/browse/STORM-1793 > > > Diffs > ----- > > doc/contributions.txt 0010858de5a1 > indra/newview/llnetmap.cpp 0010858de5a1 > indra/newview/llworld.cpp 0010858de5a1 > indra/newview/llworldmapview.h 0010858de5a1 > indra/newview/llworldmapview.cpp 0010858de5a1 > > Diff: http://codereview.secondlife.com/r/545/diff/diff > > > Testing > ------- > > See test plan in jira > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120222/9c2a23ee/attachment.htm From oz at lindenlab.com Wed Feb 22 08:33:53 2012 From: oz at lindenlab.com (Oz Linden) Date: Wed, 22 Feb 2012 16:33:53 -0000 Subject: [opensource-dev] Review Request: STORM-1809 The word "Multiple" does NOT show in the edit window when editing prims or linksets with mixed textures in LL V3 In-Reply-To: <20120208193129.30476.34135@domU-12-31-38-00-90-68.compute-1.internal> References: <20120208193129.30476.34135@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120222163353.8542.36633@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/551/#review1167 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Feb. 8, 2012, 11:31 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/551/ > ----------------------------------------------------------- > > (Updated Feb. 8, 2012, 11:31 a.m.) > > > Review request for Viewer. > > > Description > ------- > > When building, a creator has always been able to look at the texture window to see if a prim or linkset is mixed textures or one complete texture by seeing the word "multiple" over the texture. This no longer happens in Viewer 3. > > > This addresses bug STORM-1809. > http://jira.secondlife.com/browse/STORM-1809 > > > Diffs > ----- > > doc/contributions.txt 767757e005e3 > indra/newview/lltexturectrl.cpp 767757e005e3 > indra/newview/skins/default/xui/en/strings.xml 767757e005e3 > > Diff: http://codereview.secondlife.com/r/551/diff/diff > > > Testing > ------- > > See test plan in jira. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120222/b669fd51/attachment.htm From oz at lindenlab.com Wed Feb 22 09:19:52 2012 From: oz at lindenlab.com (Oz Linden) Date: Wed, 22 Feb 2012 17:19:52 -0000 Subject: [opensource-dev] Review Request: STORM-1807 Play animation floater 2nd play button active while animation is playing In-Reply-To: <20120218132457.24917.79844@domU-12-31-38-00-90-68.compute-1.internal> References: <20120218132457.24917.79844@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120222171952.8542.95870@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/552/#review1168 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Feb. 18, 2012, 5:24 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/552/ > ----------------------------------------------------------- > > (Updated Feb. 18, 2012, 5:24 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Part 1 > Open your inventory's Animations folder > Double click on an animation > Click on Play Inworld: Play Inworld is replaced by a Stop button > > Observed behavior: It is still possible to click on Play Locally, which also is replaced by a Stop button. Clicking on either Stop works and resets the floater back to having both Play buttons showing. > > Expected behavior: When one of the play buttons is clicked the other should be disabled. > > > Part 2 > 1 .To reproduce, get any non looping animation. ie, one that plays once and then stops. > 2. Right click in inventory and select play in world. > 3. The animation dialog appears with play locally and play in world buttons. > 4. When the animation is playing, the play in world button changes to a stop button, which makes it stop playing. > Now here's the problem: > 5. When the animation finishes of it's own accord, the button still says stop. To play it again, you have to click the redundant stop button to make it change back to Play in World, then click that to play again. > > Expected behaviour, is that when an animation finishes, the stop button should change back of it's own accord. > > > This addresses bug STORM-1807. > http://jira.secondlife.com/browse/STORM-1807 > > > Diffs > ----- > > doc/contributions.txt 0a41a8750048 > indra/newview/llinventorybridge.cpp 0a41a8750048 > indra/newview/llpreviewanim.h 0a41a8750048 > indra/newview/llpreviewanim.cpp 0a41a8750048 > indra/newview/skins/default/xui/en/floater_preview_animation.xml 0a41a8750048 > > Diff: http://codereview.secondlife.com/r/552/diff/diff > > > Testing > ------- > > See test plan in jira. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120222/8dd367ea/attachment-0001.htm From malachi at tamzap.com Wed Feb 22 10:44:36 2012 From: malachi at tamzap.com (malachi) Date: Wed, 22 Feb 2012 13:44:36 -0500 Subject: [opensource-dev] ETA on Agni Pathfinding? Message-ID: <4F453794.3090200@tamzap.com> Anyone have any idea of and ETA for pathfinding to go Agni? Any rumors of such a time frame? From jhwelch at gmail.com Wed Feb 22 10:52:56 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Wed, 22 Feb 2012 13:52:56 -0500 Subject: [opensource-dev] ETA on Agni Pathfinding? In-Reply-To: <4F453794.3090200@tamzap.com> References: <4F453794.3090200@tamzap.com> Message-ID: I asked this at the Server meeting yesterday; no release date has been established yet. From hitomi.tiponi at yahoo.co.uk Thu Feb 23 01:31:29 2012 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Thu, 23 Feb 2012 09:31:29 +0000 (GMT) Subject: [opensource-dev] New JIRA Maintenance project In-Reply-To: References: Message-ID: <1329989489.20884.YahooMailNeo@web23903.mail.ird.yahoo.com> Several hundred outstanding JIRA issues/bugs have suddenly been assigned to a new 'Maintenance' project.? Could someone please tell me what this means? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120223/32741d73/attachment.htm From nalates.u at gmail.com Fri Feb 24 15:44:35 2012 From: nalates.u at gmail.com (Nalates Urriah) Date: Fri, 24 Feb 2012 15:44:35 -0800 Subject: [opensource-dev] Viewer Policy Changes Message-ID: Does this new policy essentially eliminate the reason for the existence of 3rd party viewers: 2.k : You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer. http://community.secondlife.com/t5/Second-Life-Viewer/Third-Party-Viewer-Policy-Changes/m-p/1399141 This seems to say all changes can be submitted to LL but not implemented until and unless LL approves them and adds them to the SL viewer. Am I mistaken? -- Nalates Urriah (SL AV) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120224/d619eae0/attachment.htm From xotmid at gmail.com Fri Feb 24 15:51:18 2012 From: xotmid at gmail.com (Brandon Husbands) Date: Fri, 24 Feb 2012 17:51:18 -0600 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: Message-ID: Holy... That's a huge policy change. On Fri, Feb 24, 2012 at 5:44 PM, Nalates Urriah wrote: > Does this new policy essentially eliminate the reason for the existence of > 3rd party viewers: > > 2.k : You must not provide any feature that alters the shared experience > of the virtual world in any way not provided by or accessible to users of > the latest released Linden Lab viewer. > > > http://community.secondlife.com/t5/Second-Life-Viewer/Third-Party-Viewer-Policy-Changes/m-p/1399141 > > This seems to say all changes can be submitted to LL but not implemented > until and unless LL approves them and adds them to the SL viewer. Am I > mistaken? > > -- > Nalates Urriah (SL AV) > > _______________________________________________ > 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 > -- ------------------------------------------------------------------------------------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120224/c5917902/attachment.htm From cinder at cinderblocks.biz Fri Feb 24 16:00:29 2012 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Fri, 24 Feb 2012 17:00:29 -0700 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: Message-ID: <4F48249D.8020307@cinderblocks.biz> Yes, you're mistaken. The key phrase there is "alters the shared experience of the virtual world". A tpv can alter individual user's experiences, (UI, build tools, controls, graphics enhancements) but not the shared experience of the world. IE, exposing information such as the friend online visibility of *other users*. Kind regards, -Cinder On 2/24/2012 4:44 PM, Nalates Urriah wrote: > Does this new policy essentially eliminate the reason for the > existence of 3rd party viewers: > > 2.k : You must not provide any feature that alters the shared > experience of the virtual world in any way not provided by or > accessible to users of the latest released Linden Lab viewer. > > http://community.secondlife.com/t5/Second-Life-Viewer/Third-Party-Viewer-Policy-Changes/m-p/1399141 > > This seems to say all changes can be submitted to LL but not > implemented until and unless LL approves them and adds them to the SL > viewer. Am I mistaken? > > -- > Nalates Urriah (SL AV) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120224/7658ce79/attachment.htm From xotmid at gmail.com Fri Feb 24 16:08:23 2012 From: xotmid at gmail.com (Brandon Husbands) Date: Fri, 24 Feb 2012 18:08:23 -0600 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: <4F48249D.8020307@cinderblocks.biz> References: <4F48249D.8020307@cinderblocks.biz> Message-ID: Guess its how you interpreted it wheww. On Fri, Feb 24, 2012 at 6:00 PM, Cinder Roxley wrote: > Yes, you're mistaken. The key phrase there is "alters the shared > experience of the virtual world". A tpv can alter individual user's > experiences, (UI, build tools, controls, graphics enhancements) but not the > shared experience of the world. IE, exposing information such as the > friend online visibility of *other users*. > > Kind regards, > -Cinder > > > On 2/24/2012 4:44 PM, Nalates Urriah wrote: > > Does this new policy essentially eliminate the reason for the existence of > 3rd party viewers: > > 2.k : You must not provide any feature that alters the shared experience > of the virtual world in any way not provided by or accessible to users of > the latest released Linden Lab viewer. > > > http://community.secondlife.com/t5/Second-Life-Viewer/Third-Party-Viewer-Policy-Changes/m-p/1399141 > > This seems to say all changes can be submitted to LL but not implemented > until and unless LL approves them and adds them to the SL viewer. Am I > mistaken? > > -- > Nalates Urriah (SL AV) > > > > _______________________________________________ > 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 > -- ------------------------------------------------------------------------------------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120224/6cf65dfc/attachment.htm From jessica.lyon at phoenixviewer.com Fri Feb 24 16:18:42 2012 From: jessica.lyon at phoenixviewer.com (Jessica Lyon) Date: Fri, 24 Feb 2012 19:18:42 -0500 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: <4F48249D.8020307@cinderblocks.biz> References: <4F48249D.8020307@cinderblocks.biz> Message-ID: Actually, under 2.k, features like breast physics, secondary attachments, shared parcel WL etc, would have never been permitted to exist. And this means that any feature in the future to which a TPV may conjur up, which effects the shared experience (Ie. something one user could see but another couldn't) will need to be developed for the LL viewer by TPV devs, accepted by LL, released by LL before a TPV may release it themselves. Another example would be the Mesh deformer from Qarl, if LL were not interested in it.. none of us would be allowed to release it in our viewers. Jessica Lyon Project Manager The Phoenix Viewer Project, Inc. On Fri, Feb 24, 2012 at 7:00 PM, Cinder Roxley wrote: > Yes, you're mistaken. The key phrase there is "alters the shared > experience of the virtual world". A tpv can alter individual user's > experiences, (UI, build tools, controls, graphics enhancements) but not the > shared experience of the world. IE, exposing information such as the > friend online visibility of *other users*. > > Kind regards, > -Cinder > > > On 2/24/2012 4:44 PM, Nalates Urriah wrote: > > Does this new policy essentially eliminate the reason for the existence of > 3rd party viewers: > > 2.k : You must not provide any feature that alters the shared experience > of the virtual world in any way not provided by or accessible to users of > the latest released Linden Lab viewer. > > > http://community.secondlife.com/t5/Second-Life-Viewer/Third-Party-Viewer-Policy-Changes/m-p/1399141 > > This seems to say all changes can be submitted to LL but not implemented > until and unless LL approves them and adds them to the SL viewer. Am I > mistaken? > > -- > Nalates Urriah (SL AV) > > > > _______________________________________________ > 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 > -- Jessica Lyon Phoenix Viewer Project Inc http://phoenixviewer.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120224/2c2bdd81/attachment-0001.htm From Celierra at gmail.com Fri Feb 24 16:55:04 2012 From: Celierra at gmail.com (Celierra Darling) Date: Fri, 24 Feb 2012 19:55:04 -0500 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: <4F48249D.8020307@cinderblocks.biz> Message-ID: (I am not a lawyer, but...) From kadah.coba at gmail.com Fri Feb 24 17:16:54 2012 From: kadah.coba at gmail.com (Kadah) Date: Fri, 24 Feb 2012 17:16:54 -0800 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: <4F48249D.8020307@cinderblocks.biz> Message-ID: <4F483686.7060200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think the general rule is here that if its something like Emerald's multi-attach where it doesn't work or causes artifacts for other viewers, it needs to go through LL, get PO approval and a project for getting effected APIs added or changed, as well as viewer support added to V-D for everyone to pull from. On 2/24/2012 4:55 PM, Celierra Darling wrote: > (I am not a lawyer, but...) > > From the text in the blog post, it looks like it's intended to be > an anti-fragmentation measure. I don't think it's literally a > desire to make the TPV devs wait until the official viewer catches > up (and definitely not to make TPV people "develop [features] for > the LL viewer"). > > To help allay the concern, though, I think there could be some sort > of "with specifications released by LL" exception - once an API has > been hashed out and released, I can't think of any benefit to > making the TPV wait. That'd make the rule a little more tightly > focused on getting TPVs to make specs that LL's willing to endorse > and use. > > Celi > > > On Fri, Feb 24, 2012 at 7:18 PM, Jessica Lyon > > wrote: > > Actually, under 2.k, features like breast physics, secondary > attachments, shared parcel WL etc, would have never been permitted > to exist. And this means that any feature in the future to which a > TPV may conjur up, which effects the shared experience (Ie. > something one user could see but another couldn't) will need to be > developed for the LL viewer by TPV devs, accepted by LL, released > by LL before a TPV may release it themselves. Another example would > be the Mesh deformer from Qarl, if LL were not interested in it.. > none of us would be allowed to release it in our viewers. > > Jessica Lyon Project Manager The Phoenix Viewer Project, Inc. > > On Fri, Feb 24, 2012 at 7:00 PM, Cinder Roxley > > wrote: > > Yes, you're mistaken. The key phrase there is "alters the shared > experience of the virtual world". A tpv can alter individual > user's experiences, (UI, build tools, controls, graphics > enhancements) but not the shared experience of the world. IE, > exposing information such as the friend online visibility of *other > users*. > > Kind regards, -Cinder > > > On 2/24/2012 4:44 PM, Nalates Urriah wrote: >> Does this new policy essentially eliminate the reason for the >> existence of 3rd party viewers: >> >> 2.k : You must not provide any feature that alters the shared >> experience of the virtual world in any way not provided by or >> accessible to users of the latest released Linden Lab viewer. >> >> http://community.secondlife.com/t5/Second-Life-Viewer/Third-Party-Viewer-Policy-Changes/m-p/1399141 >> >> >> This seems to say all changes can be submitted to LL but not >> implemented until and unless LL approves them and adds them to >> the SL viewer. Am I mistaken? >> >> -- Nalates Urriah (SL AV) > > > _______________________________________________ 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 > > > > > -- Jessica Lyon Phoenix Viewer Project Inc > http://phoenixviewer.com > > > _______________________________________________ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPSDaGAAoJEIdLfPRu7qE28awH/2OXWBVu4B49rHTipeIzUcax j91sLFRMHTaUd3oiwFzkQkWMDPjvhahceRzLIWLcP0nkIQIfg4yRvjuiFTNdlJuZ NuqGuu0ozkVbTh29MbvC1lm50xwx2xucxd0OYpsUiGXKTFRaH4f3aouLKIfdSX9G VvpcqrddohwznNsoyzMtACu7k/L82vd49nmFrQLqHGSB2X3gZZjDhS5JMf7hyLEP cCd5zeqqin9wOYHX7IumF6j0rm+9SkwiVDiGmJQ+G2u6e/+ZQBwOdfkyb+h+Ij0B LkNcQTLUle4AoTWU4AXFj0prIIL1pacOijTPxvN0AurhCxE5eXwQIgRrqfdb35Q= =axPl -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Fri Feb 24 22:17:26 2012 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 25 Feb 2012 04:17:26 -0200 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: <4F483686.7060200@gmail.com> References: <4F48249D.8020307@cinderblocks.biz> <4F483686.7060200@gmail.com> Message-ID: Alterations of the experience that aren?t shared don?t alter the shared experience, it creates a whole new experience; it doesn?t make sense to consider client side features as part of the shared experience, client side things are only shared if someone is looking over your shoulder? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120225/d539d774/attachment.htm From tillie at xp2.de Sat Feb 25 02:52:04 2012 From: tillie at xp2.de (Tillie Ariantho) Date: Sat, 25 Feb 2012 11:52:04 +0100 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: <4F48249D.8020307@cinderblocks.biz> Message-ID: <4F48BD54.4050302@xp2.de> On 25.02.2012 01:18, Jessica Lyon wrote: > Actually, under 2.k, features like breast physics, secondary attachments, shared parcel WL etc, would have never been permitted to exist. And this means that any feature in the future to which a TPV > may conjur up, which effects the shared experience (Ie. something one user could see but another couldn't) will need to be developed for the LL viewer by TPV devs, accepted by LL, released by LL > before a TPV may release it themselves. Another example would be the Mesh deformer from Qarl, if LL were not interested in it.. none of us would be allowed to release it in our viewers. Yah. I guess Oscars meetings will be crowded now with people asking if this or that is policy compliant or not. So there should be more Lindens at the meeting probably, having answers to that. Cause a "dont know" or "have to ask" or "we have to consider yet" as response wont help at all and make work for TPV devs impossible. Tillie From tillie at xp2.de Sat Feb 25 04:08:28 2012 From: tillie at xp2.de (Tillie Ariantho) Date: Sat, 25 Feb 2012 13:08:28 +0100 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: <4F48BD54.4050302@xp2.de> References: <4F48249D.8020307@cinderblocks.biz> <4F48BD54.4050302@xp2.de> Message-ID: <4F48CF3C.8080205@xp2.de> Hello Oskar, > 2.k You must not provide any feature that alters the shared experience of the virtual world in > any way not provided by or accessible to users of the latest released Linden Lab viewer. Ah hm... - What about text based viewers? - What about viewers on mobile devices? - What about special viewers for disabled people, that may have quite some different representation of everything? Or someone's just trying to connect a C64 virtual machine based viewer to SL, with its own, quite unique representation. What about that? The "shared experience" of all those is quite different from the LL viewer. And more: - What about the shared experience of very old LL viewers? Not allowed to copy/clone if its not in the "latest released Linden Lab viewer"? - What about LL viewers in DEV or BETA status? Have TPV devs to wait till a feature is officially out? Is there any grace period till the new policy is enforced? What about grace periods on client changes later, LL client removes something, do TPV devs have to remove it instantly, too (dont say now there is nothing being removed, I remember Avatar Ratings, for example). Tillie From skyemenjou at gmail.com Sat Feb 25 08:56:38 2012 From: skyemenjou at gmail.com (Skye Menjou) Date: Sat, 25 Feb 2012 17:56:38 +0100 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: <4F48CF3C.8080205@xp2.de> References: <4F48249D.8020307@cinderblocks.biz> <4F48BD54.4050302@xp2.de> <4F48CF3C.8080205@xp2.de> Message-ID: What I am worrying about is that this will also go against RLV, which is in wide use, even outside the Adult community.(We use it for some of our combat systems). LL, are you really trying to force people to use your client and piss off most of SL userbase? I haven't seen such a terrible move since M Linden was in charge. On Sat, Feb 25, 2012 at 1:08 PM, Tillie Ariantho wrote: > Hello Oskar, > > > 2.k You must not provide any feature that alters the shared experience > of the virtual world in > > any way not provided by or accessible to users of the latest released > Linden Lab viewer. > > Ah hm... > > - What about text based viewers? > - What about viewers on mobile devices? > - What about special viewers for disabled people, that may have quite some > different representation of everything? > > Or someone's just trying to connect a C64 virtual machine based viewer to > SL, with its own, quite unique representation. What about that? > > The "shared experience" of all those is quite different from the LL viewer. > > And more: > > - What about the shared experience of very old LL viewers? Not allowed to > copy/clone if its not in the "latest released Linden Lab viewer"? > - What about LL viewers in DEV or BETA status? Have TPV devs to wait till > a feature is officially out? > > Is there any grace period till the new policy is enforced? What about > grace periods on client changes later, LL client removes something, > do TPV devs have to remove it instantly, too (dont say now there is > nothing being removed, I remember Avatar Ratings, for example). > > Tillie > _______________________________________________ > 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 > -- Have a nice day, Skye Menjou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120225/377fe754/attachment-0001.htm From marinekelley at gmail.com Sat Feb 25 09:39:43 2012 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 25 Feb 2012 18:39:43 +0100 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: <4F48249D.8020307@cinderblocks.biz> <4F48BD54.4050302@xp2.de> <4F48CF3C.8080205@xp2.de> Message-ID: I was wondering the same thing. On 25/02/2012, Skye Menjou wrote: > What I am worrying about is that this will also go against RLV, which is in > wide use, even outside the Adult community.(We use it for some of our > combat systems). > LL, are you really trying to force people to use your client and piss off > most of SL userbase? I haven't seen such a terrible move since M Linden was > in charge. > > On Sat, Feb 25, 2012 at 1:08 PM, Tillie Ariantho wrote: > >> Hello Oskar, >> >> > 2.k You must not provide any feature that alters the shared experience >> of the virtual world in >> > any way not provided by or accessible to users of the latest released >> Linden Lab viewer. >> >> Ah hm... >> >> - What about text based viewers? >> - What about viewers on mobile devices? >> - What about special viewers for disabled people, that may have quite some >> different representation of everything? >> >> Or someone's just trying to connect a C64 virtual machine based viewer to >> SL, with its own, quite unique representation. What about that? >> >> The "shared experience" of all those is quite different from the LL >> viewer. >> >> And more: >> >> - What about the shared experience of very old LL viewers? Not allowed to >> copy/clone if its not in the "latest released Linden Lab viewer"? >> - What about LL viewers in DEV or BETA status? Have TPV devs to wait till >> a feature is officially out? >> >> Is there any grace period till the new policy is enforced? What about >> grace periods on client changes later, LL client removes something, >> do TPV devs have to remove it instantly, too (dont say now there is >> nothing being removed, I remember Avatar Ratings, for example). >> >> Tillie >> _______________________________________________ >> 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 >> > > > > -- > Have a nice day, > Skye Menjou > From adeonwriter at live.com Sat Feb 25 10:24:22 2012 From: adeonwriter at live.com (Adeon Writer) Date: Sat, 25 Feb 2012 13:24:22 -0500 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: <4F48249D.8020307@cinderblocks.biz> <4F48BD54.4050302@xp2.de> <4F48CF3C.8080205@xp2.de> Message-ID: I'm pretty sure RLV doesn't modify the shared experience. Any feature of it that others can see will observe it in the same way as the official viewer. Perhaps I am interpreting this incorrectly? This rule will avoid thing like the original double attachments that main viewer saw incorrectly, or that OTR chat encryption thing. It wouldn't disallow derendering, since others on TPV's and others on official see it the same way (ie, they both see nothing happen at all and it doesn't violate privacy) Basically, as an official viewer user, "Don't invade my privacy, don't make me see the world incorrectly." Correct me if wrong. On Feb 25, 2012, at 11:56 AM, Skye Menjou wrote: > What I am worrying about is that this will also go against RLV, which is in wide use, even outside the Adult community.(We use it for some of our combat systems). > LL, are you really trying to force people to use your client and piss off most of SL userbase? I haven't seen such a terrible move since M Linden was in charge. > > On Sat, Feb 25, 2012 at 1:08 PM, Tillie Ariantho wrote: > Hello Oskar, > > > 2.k You must not provide any feature that alters the shared experience of the virtual world in > > any way not provided by or accessible to users of the latest released Linden Lab viewer. > > Ah hm... > > - What about text based viewers? > - What about viewers on mobile devices? > - What about special viewers for disabled people, that may have quite some different representation of everything? > > Or someone's just trying to connect a C64 virtual machine based viewer to SL, with its own, quite unique representation. What about that? > > The "shared experience" of all those is quite different from the LL viewer. > > And more: > > - What about the shared experience of very old LL viewers? Not allowed to copy/clone if its not in the "latest released Linden Lab viewer"? > - What about LL viewers in DEV or BETA status? Have TPV devs to wait till a feature is officially out? > > Is there any grace period till the new policy is enforced? What about grace periods on client changes later, LL client removes something, > do TPV devs have to remove it instantly, too (dont say now there is nothing being removed, I remember Avatar Ratings, for example). > > Tillie > _______________________________________________ > 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 > > > > -- > Have a nice day, > Skye Menjou > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120225/bf8349f9/attachment.htm From kadah.coba at gmail.com Sat Feb 25 11:02:03 2012 From: kadah.coba at gmail.com (Kadah) Date: Sat, 25 Feb 2012 11:02:03 -0800 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: <4F48CF3C.8080205@xp2.de> References: <4F48249D.8020307@cinderblocks.biz> <4F48BD54.4050302@xp2.de> <4F48CF3C.8080205@xp2.de> Message-ID: <4F49302B.2030809@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/25/2012 4:08 AM, Tillie Ariantho wrote: > - What about text based viewers? - What about viewers on mobile > devices? - What about special viewers for disabled people, that may > have quite some different representation of everything? > > - What about the shared experience of very old LL viewers? Not > allowed to copy/clone if its not in the "latest released Linden Lab > viewer"? - What about LL viewers in DEV or BETA status? Have TPV > devs to wait till a feature is officially out? Same thing for out dated 3d viewers, not having current features or features that would be considered basic (like mesh or view of the world in 3d at all) has never been against the TVPD policy and still isn't. 2.k is regarding adding things that change it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPSTAqAAoJEIdLfPRu7qE29CYH/2cr+BMWqVdBcC/HUoUI+iDL NskVMTFz/q6OaCd8pBdHtmcGn2OIVfc8TtOV07Rua/aQh6EYwSSNQNiO0P6DvWqM p7Bdnuh48tXyA6jrWPMLDnylmiCYVlAzBE7K/FSE5dZ2Qa3B3RNKOoJi0acmBESy FwZVEJGEYN2Xne45DGty7Vywjne+VgK+6eblpxRw5WXaX4a9R38EQCCEeBUh9OJ0 p+x55EQzdyLMo0hOwuvZgIJ87VQ5HDeSHDnmOnklavZiKdYEKCEfSDNnE+VraNnH MqjIj/isi42YjHCi7Tp7Wyb89h8D0rJMOXhF6bdraZNVHunZ3uDKrv11M3ck2Ds= =FIGX -----END PGP SIGNATURE----- From adeonwriter at live.com Sat Feb 25 12:21:04 2012 From: adeonwriter at live.com (Adeon Writer) Date: Sat, 25 Feb 2012 15:21:04 -0500 Subject: [opensource-dev] data_online's new requirements Message-ID: I've heard DATA_ONLINE will now only work for "the owner or the creator" of the script. Shouldn't that be instead "owner or compiler" of the script? Any full permission script already written could be used and recoded as a status finder, and I have a feeling this will be what people move to for stalking if it goes by script creator. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120225/d91e8b5c/attachment.htm From tillie at xp2.de Sat Feb 25 13:11:19 2012 From: tillie at xp2.de (Tillie Ariantho) Date: Sat, 25 Feb 2012 22:11:19 +0100 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: <4F48249D.8020307@cinderblocks.biz> <4F48BD54.4050302@xp2.de> <4F48CF3C.8080205@xp2.de> Message-ID: <4F494E77.2070601@xp2.de> On 25.02.2012 19:24, Adeon Writer wrote: > It wouldn't disallow derendering, since others on TPV's and others on official see it the same way (ie, they both see nothing happen at all and it doesn't violate privacy) Derendering is essential for photographers, if there is thise newbie blocking the sight onto something important during a show. It helps a lot to do my work. Tillie From angel_of_crimson at hotmail.com Sat Feb 25 13:41:05 2012 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 25 Feb 2012 16:41:05 -0500 Subject: [opensource-dev] data_online's new requirements In-Reply-To: References: Message-ID: 100% agreed! From: adeonwriter at live.com To: opensource-dev at lists.secondlife.com Date: Sat, 25 Feb 2012 15:21:04 -0500 Subject: [opensource-dev] data_online's new requirements I've heard DATA_ONLINE will now only work for "the owner or the creator" of the script. Shouldn't that be instead "owner or compiler" of the script? Any full permission script already written could be used and recoded as a status finder, and I have a feeling this will be what people move to for stalking if it goes by script creator. _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120225/7d9c51d6/attachment.htm From sythos at gmail.com Sat Feb 25 13:48:07 2012 From: sythos at gmail.com (Sythos) Date: Sat, 25 Feb 2012 22:48:07 +0100 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: <4F494E77.2070601@xp2.de> References: <4F48249D.8020307@cinderblocks.biz> <4F48BD54.4050302@xp2.de> <4F48CF3C.8080205@xp2.de> <4F494E77.2070601@xp2.de> Message-ID: <20120225224807.aa43672baa40856c6acd03f7@gmail.com> On Sat, 25 Feb 2012 22:11:19 +0100 Tillie Ariantho wrote: > On 25.02.2012 19:24, Adeon Writer wrote: > > > It wouldn't disallow derendering, since others on TPV's and others > > on official see it the same way (ie, they both see nothing happen > > at all and it doesn't violate privacy) > > > Derendering is essential for photographers, if there is thise newbie > blocking the sight onto something important during a show. It helps a > lot to do my work. i think this LL's update mean not this kind of things but the ability of other to enjoy SL, if you derender somebody don't affect else than you, like other feature to increase the usability. About portable device and else is the same: if the software render the avy fine inworld (without give 3D on display, like pocket metaverse can rez and rebake too the avy inworld without offer 3D graphic) there are no problem (but this mean all textual client must include code to don't annoy others with clouds or ruth avy for other). Same RLV, affect YOUR way to "live" on SL, but others aren't affected. imho this update mean the "added" feature to TPV viewers like old emerald's extra attachment points (usable by who own the viewer but annoying for other bc see floating attachment around) or... maybe, for full 3D viewer mean not anymore no-mesh viewers (no-mesh viewers show a distorted and broken enviroment to who is around the affected user). alla bove under a giant "imho" umbrella, all we must wait office hour for clarification and explanation :) From ima.mechanique at blueyonder.co.uk Sat Feb 25 16:35:50 2012 From: ima.mechanique at blueyonder.co.uk (Ima Mechanique) Date: Sun, 26 Feb 2012 00:35:50 GMT Subject: [opensource-dev] data_online's new requirements In-Reply-To: References: Message-ID: <20120226003254.0CB8.5FD3A259@blueyonder.co.uk> > > I've heard DATA_ONLINE will now only work for "the owner or the creator" of the script. Shouldn't that be instead "owner or compiler" of the script? Any full permission script already written could be used and recoded as a status finder, and I have a feeling this will be what people move to for stalking if it goes by script creator. I share this concern whole heartedly. The idea of compiler instead of creator is a good one, I think. -- Ima Mechanique ima.mechanique(at)blueyonder.co.uk From j.w.jackson at verizon.net Sun Feb 26 05:08:06 2012 From: j.w.jackson at verizon.net (John Jackson) Date: Sun, 26 Feb 2012 07:08:06 -0600 Subject: [opensource-dev] opensource-dev Digest, Vol 25, Issue 25 In-Reply-To: References: Message-ID: <4F4A2EB6.3000605@verizon.net> It's just another LL intentionally fuzzy policy. This allows them to make whatever ruling they like when the time comes and claim it has been stated "Policy". You will not get any real clarification. On 2/25/2012 2:00 PM, opensource-dev-request at lists.secondlife.com wrote: > Send opensource-dev mailing list submissions to > opensource-dev at lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > or, via email, send a message with subject or body 'help' to > opensource-dev-request at lists.secondlife.com > > You can reach the person managing the list at > opensource-dev-owner at lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of opensource-dev digest..." > > > Today's Topics: > > 1. Re: Viewer Policy Changes (Marine Kelley) > 2. Re: Viewer Policy Changes (Adeon Writer) > 3. Re: Viewer Policy Changes (Kadah) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 25 Feb 2012 18:39:43 +0100 > From: Marine Kelley > Subject: Re: [opensource-dev] Viewer Policy Changes > To: Skye Menjou > Cc: opensource-dev at lists.secondlife.com > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I was wondering the same thing. > > On 25/02/2012, Skye Menjou wrote: >> What I am worrying about is that this will also go against RLV, which is in >> wide use, even outside the Adult community.(We use it for some of our >> combat systems). >> LL, are you really trying to force people to use your client and piss off >> most of SL userbase? I haven't seen such a terrible move since M Linden was >> in charge. >> >> On Sat, Feb 25, 2012 at 1:08 PM, Tillie Ariantho wrote: >> >>> Hello Oskar, >>> >>>> 2.k You must not provide any feature that alters the shared experience >>> of the virtual world in >>>> any way not provided by or accessible to users of the latest released >>> Linden Lab viewer. >>> >>> Ah hm... >>> >>> - What about text based viewers? >>> - What about viewers on mobile devices? >>> - What about special viewers for disabled people, that may have quite some >>> different representation of everything? >>> >>> Or someone's just trying to connect a C64 virtual machine based viewer to >>> SL, with its own, quite unique representation. What about that? >>> >>> The "shared experience" of all those is quite different from the LL >>> viewer. >>> >>> And more: >>> >>> - What about the shared experience of very old LL viewers? Not allowed to >>> copy/clone if its not in the "latest released Linden Lab viewer"? >>> - What about LL viewers in DEV or BETA status? Have TPV devs to wait till >>> a feature is officially out? >>> >>> Is there any grace period till the new policy is enforced? What about >>> grace periods on client changes later, LL client removes something, >>> do TPV devs have to remove it instantly, too (dont say now there is >>> nothing being removed, I remember Avatar Ratings, for example). >>> >>> Tillie >>> _______________________________________________ >>> 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 >>> >> >> >> -- >> Have a nice day, >> Skye Menjou >> > > ------------------------------ > > Message: 2 > Date: Sat, 25 Feb 2012 13:24:22 -0500 > From: Adeon Writer > Subject: Re: [opensource-dev] Viewer Policy Changes > To: Skye Menjou > Cc: "opensource-dev at lists.secondlife.com" > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > I'm pretty sure RLV doesn't modify the shared experience. Any feature of it that others can see will observe it in the same way as the official viewer. > > Perhaps I am interpreting this incorrectly? > > This rule will avoid thing like the original double attachments that main viewer saw incorrectly, or that OTR chat encryption thing. > > It wouldn't disallow derendering, since others on TPV's and others on official see it the same way (ie, they both see nothing happen at all and it doesn't violate privacy) > > Basically, as an official viewer user, "Don't invade my privacy, don't make me see the world incorrectly." > > Correct me if wrong. > > On Feb 25, 2012, at 11:56 AM, Skye Menjou wrote: > >> What I am worrying about is that this will also go against RLV, which is in wide use, even outside the Adult community.(We use it for some of our combat systems). >> LL, are you really trying to force people to use your client and piss off most of SL userbase? I haven't seen such a terrible move since M Linden was in charge. >> >> On Sat, Feb 25, 2012 at 1:08 PM, Tillie Ariantho wrote: >> Hello Oskar, >> >>> 2.k You must not provide any feature that alters the shared experience of the virtual world in >>> any way not provided by or accessible to users of the latest released Linden Lab viewer. >> Ah hm... >> >> - What about text based viewers? >> - What about viewers on mobile devices? >> - What about special viewers for disabled people, that may have quite some different representation of everything? >> >> Or someone's just trying to connect a C64 virtual machine based viewer to SL, with its own, quite unique representation. What about that? >> >> The "shared experience" of all those is quite different from the LL viewer. >> >> And more: >> >> - What about the shared experience of very old LL viewers? Not allowed to copy/clone if its not in the "latest released Linden Lab viewer"? >> - What about LL viewers in DEV or BETA status? Have TPV devs to wait till a feature is officially out? >> >> Is there any grace period till the new policy is enforced? What about grace periods on client changes later, LL client removes something, >> do TPV devs have to remove it instantly, too (dont say now there is nothing being removed, I remember Avatar Ratings, for example). >> >> Tillie >> _______________________________________________ >> 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 >> >> >> >> -- >> Have a nice day, >> Skye Menjou >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120225/bf8349f9/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Sat, 25 Feb 2012 11:02:03 -0800 > From: Kadah > Subject: Re: [opensource-dev] Viewer Policy Changes > To: Tillie Ariantho > Cc: opensource-dev at lists.secondlife.com > Message-ID:<4F49302B.2030809 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/25/2012 4:08 AM, Tillie Ariantho wrote: >> - What about text based viewers? - What about viewers on mobile >> devices? - What about special viewers for disabled people, that may >> have quite some different representation of everything? >> >> - What about the shared experience of very old LL viewers? Not >> allowed to copy/clone if its not in the "latest released Linden Lab >> viewer"? - What about LL viewers in DEV or BETA status? Have TPV >> devs to wait till a feature is officially out? > Same thing for out dated 3d viewers, not having current features or > features that would be considered basic (like mesh or view of the > world in 3d at all) has never been against the TVPD policy and still > isn't. > 2.k is regarding adding things that change it. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPSTAqAAoJEIdLfPRu7qE29CYH/2cr+BMWqVdBcC/HUoUI+iDL > NskVMTFz/q6OaCd8pBdHtmcGn2OIVfc8TtOV07Rua/aQh6EYwSSNQNiO0P6DvWqM > p7Bdnuh48tXyA6jrWPMLDnylmiCYVlAzBE7K/FSE5dZ2Qa3B3RNKOoJi0acmBESy > FwZVEJGEYN2Xne45DGty7Vywjne+VgK+6eblpxRw5WXaX4a9R38EQCCEeBUh9OJ0 > p+x55EQzdyLMo0hOwuvZgIJ87VQ5HDeSHDnmOnklavZiKdYEKCEfSDNnE+VraNnH > MqjIj/isi42YjHCi7Tp7Wyb89h8D0rJMOXhF6bdraZNVHunZ3uDKrv11M3ck2Ds= > =FIGX > -----END PGP SIGNATURE----- > > > ------------------------------ > > _______________________________________________ > opensource-dev mailing list > opensource-dev at lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > > > End of opensource-dev Digest, Vol 25, Issue 25 > ********************************************** > From sllists at boroon.dasgupta.ch Sun Feb 26 06:42:31 2012 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 26 Feb 2012 15:42:31 +0100 Subject: [opensource-dev] Viewer Policy Changes: Clarity vs. giving clarifications (was: opensource-dev Digest, Vol 25, Issue 25) In-Reply-To: <4F4A2EB6.3000605@verizon.net> References: <4F4A2EB6.3000605@verizon.net> Message-ID: <4F4A44D7.6070004@boroon.dasgupta.ch> On 02/26/2012 02:08 PM, John Jackson wrote: > It's just another LL intentionally fuzzy policy. > This allows them to make whatever ruling they like when the time comes and > claim it has been stated "Policy". > > You will not get any real clarification. At an inworld meeting, Oz has given the third party viewer developers some clarification. Though, I'd prefer policies to be written such that they are clear in and of themselves. This doesn't mean they cannot let some room for interpretation, but a policy shouldn't give a reader with common sense but not knowing about the clarifications an impression that clearly contradicts the actual intention of the policy. @Oz: If the policy isn't being changed to be more clear, it might be advantageous to re-state the clarifications you gave us at that meeting (maybe summarized) here in public, as they are relevant for more people than those who were around at the inworld meeting. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120226/b6e6b63d/attachment-0001.htm From tigrospottystripes at gmail.com Sun Feb 26 16:46:14 2012 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 26 Feb 2012 22:46:14 -0200 Subject: [opensource-dev] Viewer Policy Changes: Clarity vs. giving clarifications (was: opensource-dev Digest, Vol 25, Issue 25) In-Reply-To: <4F4A44D7.6070004@boroon.dasgupta.ch> References: <4F4A2EB6.3000605@verizon.net> <4F4A44D7.6070004@boroon.dasgupta.ch> Message-ID: Hasn't LL said in the past that statements by employees should not be interpreted as representing the opinions of LL itself, specially when it comes to policies and rules and such? On Sun, Feb 26, 2012 at 12:42 PM, Boroondas Gupte < sllists at boroon.dasgupta.ch> wrote: > On 02/26/2012 02:08 PM, John Jackson wrote: > > It's just another LL intentionally fuzzy policy. > > This allows them to make whatever ruling they like when the time comes > and > > claim it has been stated "Policy". > > > > You will not get any real clarification. > > At an inworld meeting, Oz has given the third party viewer developers some > clarification. Though, I'd prefer policies to be written such that they are > clear in and of themselves. This doesn't mean they cannot let some room for > interpretation, but a policy shouldn't give a reader with common sense but > not knowing about the clarifications an impression that clearly contradicts > the actual intention of the policy. > > @Oz: If the policy isn't being changed to be more clear, it might be > advantageous to re-state the clarifications you gave us at that meeting > (maybe summarized) here in public, as they are relevant for more people > than those who were around at the inworld meeting. > > Cheers, > Boroondas > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120226/f5ba0e4d/attachment.htm From tateru.nino at gmail.com Sun Feb 26 21:23:46 2012 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 27 Feb 2012 16:23:46 +1100 Subject: [opensource-dev] Viewer Policy Changes: Clarity vs. giving clarifications In-Reply-To: References: <4F4A2EB6.3000605@verizon.net> <4F4A44D7.6070004@boroon.dasgupta.ch> Message-ID: <4F4B1362.4080909@gmail.com> Unless the staff member states specifically that it is an official statement on behalf of the company, yes. It's just hearsay without that or without an announcement through proper channels. On 27/02/2012 11:46 AM, Tigro Spottystripes wrote: > Hasn't LL said in the past that statements by employees should not be > interpreted as representing the opinions of LL itself, specially when > it comes to policies and rules and such? > > On Sun, Feb 26, 2012 at 12:42 PM, Boroondas Gupte > > wrote: > > On 02/26/2012 02:08 PM, John Jackson wrote: > > It's just another LL intentionally fuzzy policy. > > This allows them to make whatever ruling they like when the time > comes and > > claim it has been stated "Policy". > > > > You will not get any real clarification. > > At an inworld meeting, Oz has given the third party viewer > developers some clarification. Though, I'd prefer policies to be > written such that they are clear in and of themselves. This > doesn't mean they cannot let some room for interpretation, but a > policy shouldn't give a reader with common sense but not knowing > about the clarifications an impression that clearly contradicts > the actual intention of the policy. > > @Oz: If the policy isn't being changed to be more clear, it might > be advantageous to re-state the clarifications you gave us at that > meeting (maybe summarized) here in public, as they are relevant > for more people than those who were around at the inworld meeting. > > Cheers, > Boroondas > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120227/0621167e/attachment.htm From sldev at free.fr Tue Feb 28 02:59:03 2012 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 28 Feb 2012 11:59:03 +0100 Subject: [opensource-dev] Viewer Policy Changes In-Reply-To: References: Message-ID: <20120228115903.2843dcc7.sldev@free.fr> Here is my take on this matter: http://sldev.free.fr/forum/viewtopic.php?f=5&t=741&p=3259#p3259 Regards, Henri. From flats_fixed at flatsfixedbicycles.com Tue Feb 28 08:55:08 2012 From: flats_fixed at flatsfixedbicycles.com (Flats Fixed) Date: Tue, 28 Feb 2012 10:55:08 -0600 Subject: [opensource-dev] New JIRA Maintenance project (Hitomi Tiponi) Message-ID: It is very simple. since 2.8.0 has been out I have had many people come to me and ask why I cant rez. So I look at the out put of there system and they are using top of the line equipment. and they are stuck not able to use any of the new viewers. do to layers. for some reason there layers are changing permissions. I rarely ever post here but the problem is huge it is out of hand. https://jira.secondlife.com/browse/VWR-28444?focusedCommentId=312684 it is enough to hurt the hard work of the SL team. I hope this does not turn into a point a finger at one team and another. In the mean time many of these avi's are paying 300 a month "not" to use the utilities. has_perm_maskn :) Team can fix it or they go to another grid. -- FLATS FIXED Emergency repairs flatsfixedbicycles.com This message has been sent by the most powerful bleeding edge operating system known to man SLACKWARE64-CURRENT We Get The Slack Back. It is free. Try it you will never go back just keep the slack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120228/9bafbeef/attachment.htm From oz at lindenlab.com Tue Feb 28 09:10:09 2012 From: oz at lindenlab.com (Oz Linden) Date: Tue, 28 Feb 2012 17:10:09 -0000 Subject: [opensource-dev] Review Request: VWR-28087: When I upload a texture, the "preview as" dropdown in the preview window is hidden under the texture In-Reply-To: <20120112100600.13488.90029@domU-12-31-38-00-90-68.compute-1.internal> References: <20120112100600.13488.90029@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120228171009.14780.87759@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/532/#review1169 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Jan. 12, 2012, 2:06 a.m., Lance Corrimal wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/532/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2012, 2:06 a.m.) > > > Review request for Viewer. > > > Description > ------- > > At some point in the last 8 months the height of image previews in the upload preview floater was increased by 20, without adapting the actual floater, leading to VWR-28087. > This small patch fixes that by adapting the preview floater to the new height. > > > This addresses bug VWR-28087. > http://jira.secondlife.com/browse/VWR-28087 > > > Diffs > ----- > > indra/newview/skins/default/xui/en/floater_image_preview.xml 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/532/diff/diff > > > Testing > ------- > > tested with release viewer 3.2.5 and my own TPV, works fine. > > > Thanks, > > Lance Corrimal > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120228/25bb50e1/attachment.htm