From laurent.bechir at madonie.org Sun Jan 1 15:20:28 2012 From: laurent.bechir at madonie.org (Laurent Bechir) Date: Mon, 02 Jan 2012 00:20:28 +0100 Subject: [opensource-dev] Build of Second Life with XCode 4.2 Message-ID: <4F00EA3C.1020503@madonie.org> Hello, Is it possible to build Second Life with XCode 4.2 ? And if no, any plan to make it possible ? Thank you and happy new year... From jhwelch at gmail.com Tue Jan 3 05:25:22 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Tue, 3 Jan 2012 08:25:22 -0500 Subject: [opensource-dev] Testers needed for OPEN-130 (Modify autobuild to allow control over where libraries are downloaded) Message-ID: I just tested this little patch on Windows. If you build on Mac or Linux it would be helpful if you could test this and report back in a jira comment. https://jira.secondlife.com/browse/OPEN-130 Thanks, -Jonathan From oz at lindenlab.com Wed Jan 4 06:07:13 2012 From: oz at lindenlab.com (Oz Linden) Date: Wed, 04 Jan 2012 14:07:13 -0000 Subject: [opensource-dev] Review Request: STORM-1790 Provide a Develop sub-menu to change the default logging level In-Reply-To: <20111223171515.14052.6716@domU-12-31-38-00-90-68.compute-1.internal> References: <20111223171515.14052.6716@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120104140713.29774.52107@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/530/#review1132 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Dec. 23, 2011, 9:15 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/530/ > ----------------------------------------------------------- > > (Updated Dec. 23, 2011, 9:15 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Provide a 1) login screen Debug and 2) Develop sub-menu to change the default logging level > > > This addresses bug STORM-1790. > http://jira.secondlife.com/browse/STORM-1790 > > > Diffs > ----- > > doc/contributions.txt 3a521e980fbf > indra/llcommon/llerror.cpp 3a521e980fbf > indra/llcommon/llerrorcontrol.h 3a521e980fbf > indra/newview/llviewermenu.cpp 3a521e980fbf > indra/newview/skins/default/xui/en/menu_login.xml 3a521e980fbf > indra/newview/skins/default/xui/en/menu_viewer.xml 3a521e980fbf > > Diff: http://codereview.secondlife.com/r/530/diff/diff > > > Testing > ------- > > Opened debug log on screen and adjusted setting via the menu. Noted that logging adjusted to what the level was set to, at least for Debug (which also is All), Info, Warning, and None. I did not test Error, which probably is a bit of a moot point, as it is supposed to cause a crash. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120104/4cb44b0e/attachment.htm From oz at lindenlab.com Wed Jan 4 06:31:51 2012 From: oz at lindenlab.com (Oz Linden) Date: Wed, 04 Jan 2012 14:31:51 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111225231717.1740.39499@domU-12-31-38-00-90-68.compute-1.internal> References: <20111225231717.1740.39499@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120104143151.29774.28588@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/516/#review1133 ----------------------------------------------------------- indra/newview/llpreviewscript.cpp Why not take the '!' off that test, and put the following code inside the 'then' block - then you don't need an early and deeply nested return indra/newview/llpreviewscript.cpp Use braces per coding standard, or even better, just use a conditional expression in the return statement: return (self && self->mEditor) ? self->mEditor->canLoadOrSaveToFile() : FALSE; - Oz Linden On Dec. 25, 2011, 3:17 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/516/ > ----------------------------------------------------------- > > (Updated Dec. 25, 2011, 3:17 p.m.) > > > Review request for Viewer. > > > Description > ------- > > Changes to allow opened script window to save/load to/from files on the users computer. > > > This addresses bug storm-1708. > http://jira.secondlife.com/browse/storm-1708 > > > Diffs > ----- > > doc/contributions.txt a1319d553db9 > indra/llui/lltexteditor.h a1319d553db9 > indra/llui/lltexteditor.cpp a1319d553db9 > indra/newview/llfilepicker.h a1319d553db9 > indra/newview/llfilepicker.cpp a1319d553db9 > indra/newview/llfloaternamedesc.h a1319d553db9 > indra/newview/llfloaternamedesc.cpp a1319d553db9 > indra/newview/llpreviewscript.h a1319d553db9 > indra/newview/llpreviewscript.cpp a1319d553db9 > indra/newview/llviewerfloaterreg.cpp a1319d553db9 > indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 > indra/newview/skins/default/xui/en/strings.xml a1319d553db9 > > Diff: http://codereview.secondlife.com/r/516/diff/diff > > > Testing > ------- > > Successfully opened and saved scripts from/to local files. > > > Thanks, > > Ima Mechanique > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120104/092ded37/attachment.htm From Ima.Mechanique at blueyonder.co.uk Wed Jan 4 07:20:34 2012 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Wed, 04 Jan 2012 15:20:34 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111225231717.1740.39499@domU-12-31-38-00-90-68.compute-1.internal> References: <20111225231717.1740.39499@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120104152034.28478.72428@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/516/ ----------------------------------------------------------- (Updated Jan. 4, 2012, 7:20 a.m.) Review request for Viewer. Changes ------- Changes per Oz's comments Description ------- Changes to allow opened script window to save/load to/from files on the users computer. This addresses bug storm-1708. http://jira.secondlife.com/browse/storm-1708 Diffs (updated) ----- doc/contributions.txt a1319d553db9 indra/llui/lltexteditor.h a1319d553db9 indra/llui/lltexteditor.cpp a1319d553db9 indra/newview/llfilepicker.h a1319d553db9 indra/newview/llfilepicker.cpp a1319d553db9 indra/newview/llfloaternamedesc.h a1319d553db9 indra/newview/llfloaternamedesc.cpp a1319d553db9 indra/newview/llpreviewscript.h a1319d553db9 indra/newview/llpreviewscript.cpp a1319d553db9 indra/newview/llviewerfloaterreg.cpp a1319d553db9 indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 indra/newview/skins/default/xui/en/strings.xml a1319d553db9 Diff: http://codereview.secondlife.com/r/516/diff/diff Testing ------- Successfully opened and saved scripts from/to local files. Thanks, Ima Mechanique -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120104/ef7c9b3f/attachment-0001.htm From Lance.Corrimal at eregion.de Wed Jan 4 09:21:46 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 04 Jan 2012 17:21:46 -0000 Subject: [opensource-dev] Review Request: STORM-1790 Provide a Develop sub-menu to change the default logging level In-Reply-To: <20111223171515.14052.6716@domU-12-31-38-00-90-68.compute-1.internal> References: <20111223171515.14052.6716@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120104172146.29770.88011@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/530/#review1134 ----------------------------------------------------------- works for me, but unless the default log level is set to something less verbose than "INFO" this is nice to have but almost useless... alternatively, the selected log level could be saved in settings. - Lance Corrimal On Dec. 23, 2011, 9:15 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/530/ > ----------------------------------------------------------- > > (Updated Dec. 23, 2011, 9:15 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Provide a 1) login screen Debug and 2) Develop sub-menu to change the default logging level > > > This addresses bug STORM-1790. > http://jira.secondlife.com/browse/STORM-1790 > > > Diffs > ----- > > doc/contributions.txt 3a521e980fbf > indra/llcommon/llerror.cpp 3a521e980fbf > indra/llcommon/llerrorcontrol.h 3a521e980fbf > indra/newview/llviewermenu.cpp 3a521e980fbf > indra/newview/skins/default/xui/en/menu_login.xml 3a521e980fbf > indra/newview/skins/default/xui/en/menu_viewer.xml 3a521e980fbf > > Diff: http://codereview.secondlife.com/r/530/diff/diff > > > Testing > ------- > > Opened debug log on screen and adjusted setting via the menu. Noted that logging adjusted to what the level was set to, at least for Debug (which also is All), Info, Warning, and None. I did not test Error, which probably is a bit of a moot point, as it is supposed to cause a crash. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120104/1cf9a707/attachment.htm From Lance.Corrimal at eregion.de Wed Jan 4 09:34:01 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 04 Jan 2012 17:34:01 -0000 Subject: [opensource-dev] Review Request: STORM-1790 Provide a Develop sub-menu to change the default logging level In-Reply-To: <20111223171515.14052.6716@domU-12-31-38-00-90-68.compute-1.internal> References: <20111223171515.14052.6716@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120104173401.28484.12348@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/530/#review1135 ----------------------------------------------------------- Ship it! Ship It! - Lance Corrimal On Dec. 23, 2011, 9:15 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/530/ > ----------------------------------------------------------- > > (Updated Dec. 23, 2011, 9:15 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Provide a 1) login screen Debug and 2) Develop sub-menu to change the default logging level > > > This addresses bug STORM-1790. > http://jira.secondlife.com/browse/STORM-1790 > > > Diffs > ----- > > doc/contributions.txt 3a521e980fbf > indra/llcommon/llerror.cpp 3a521e980fbf > indra/llcommon/llerrorcontrol.h 3a521e980fbf > indra/newview/llviewermenu.cpp 3a521e980fbf > indra/newview/skins/default/xui/en/menu_login.xml 3a521e980fbf > indra/newview/skins/default/xui/en/menu_viewer.xml 3a521e980fbf > > Diff: http://codereview.secondlife.com/r/530/diff/diff > > > Testing > ------- > > Opened debug log on screen and adjusted setting via the menu. Noted that logging adjusted to what the level was set to, at least for Debug (which also is All), Info, Warning, and None. I did not test Error, which probably is a bit of a moot point, as it is supposed to cause a crash. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120104/38ffc822/attachment.htm From Lance.Corrimal at eregion.de Wed Jan 4 09:34:15 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 04 Jan 2012 17:34:15 -0000 Subject: [opensource-dev] Review Request: STORM-1790 Provide a Develop sub-menu to change the default logging level In-Reply-To: <20120104173401.28484.12348@domU-12-31-38-00-90-68.compute-1.internal> References: <20120104173401.28484.12348@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120104173415.4201.61697@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 4, 2012, 9:34 a.m., Lance Corrimal wrote: > > Ship It! it actually works exactly as expected and described in the jira... - Lance ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/530/#review1135 ----------------------------------------------------------- On Dec. 23, 2011, 9:15 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/530/ > ----------------------------------------------------------- > > (Updated Dec. 23, 2011, 9:15 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Provide a 1) login screen Debug and 2) Develop sub-menu to change the default logging level > > > This addresses bug STORM-1790. > http://jira.secondlife.com/browse/STORM-1790 > > > Diffs > ----- > > doc/contributions.txt 3a521e980fbf > indra/llcommon/llerror.cpp 3a521e980fbf > indra/llcommon/llerrorcontrol.h 3a521e980fbf > indra/newview/llviewermenu.cpp 3a521e980fbf > indra/newview/skins/default/xui/en/menu_login.xml 3a521e980fbf > indra/newview/skins/default/xui/en/menu_viewer.xml 3a521e980fbf > > Diff: http://codereview.secondlife.com/r/530/diff/diff > > > Testing > ------- > > Opened debug log on screen and adjusted setting via the menu. Noted that logging adjusted to what the level was set to, at least for Debug (which also is All), Info, Warning, and None. I did not test Error, which probably is a bit of a moot point, as it is supposed to cause a crash. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120104/90020321/attachment.htm From CronoCloud at mchsi.com Thu Jan 5 11:17:36 2012 From: CronoCloud at mchsi.com (Ron Rogers Jr.) Date: Thu, 5 Jan 2012 13:17:36 -0600 Subject: [opensource-dev] Anyone see crashes VERY similar to VWR-28031 in the current development 3.2.6 246959 Message-ID: <20120105131736.7bacb94b.CronoCloud@mchsi.com> I'm seeing crashes like this on Linux: https://jira.secondlife.com/browse/VWR-28031 CronoCloud -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120105/31e01d74/attachment.pgp From cinciasingh at gmail.com Thu Jan 5 12:51:22 2012 From: cinciasingh at gmail.com (Cincia Singh) Date: Thu, 5 Jan 2012 14:51:22 -0600 Subject: [opensource-dev] Anyone see crashes VERY similar to VWR-28031 in the current development 3.2.6 246959 Message-ID: I have been able to reproduce this crash in the Windows build of each dev viewer and each TPV I've tried. On Thu, Jan 5, 2012 at 2:00 PM, 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. Anyone see crashes VERY similar to VWR-28031 in the current > development 3.2.6 246959 (Ron Rogers Jr.) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 5 Jan 2012 13:17:36 -0600 > From: "Ron Rogers Jr." > Subject: [opensource-dev] Anyone see crashes VERY similar to VWR-28031 > in the current development 3.2.6 246959 > To: opensource-dev > Message-ID: <20120105131736.7bacb94b.CronoCloud at mchsi.com> > Content-Type: text/plain; charset="us-ascii" > > I'm seeing crashes like this on Linux: > > https://jira.secondlife.com/browse/VWR-28031 > > CronoCloud > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 198 bytes > Desc: not available > Url : > http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120105/31e01d74/attachment-0001.pgp > > ------------------------------ > > _______________________________________________ > 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 24, Issue 5 > ********************************************* > -- *?We can't solve problems by using the same kind of thinking we used when we created them.? Albert Einstein* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120105/6cb9967a/attachment.htm From oz at lindenlab.com Fri Jan 6 13:15:58 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 06 Jan 2012 16:15:58 -0500 Subject: [opensource-dev] Inventory Patch you should integrate Message-ID: <4F07648E.7050108@lindenlab.com> We're going to deploying changes to the inventory backend soon that improve robustness and performance, but in testing those changes we found that existing viewers relied on certain things being strictly ordered. With the new backend, that assumption does not always hold true. Changeset d327dcc8ae51 from viewer-development implements the viewer change needed to avoid race conditions. It should be straightforward to apply to any viewer, and is safe to release before the changes are deployed (it is compatible with the services as they are now). You are strongly urged to port this patch and get it deployed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120106/0093373d/attachment.htm From sldev at free.fr Fri Jan 6 14:25:24 2012 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 6 Jan 2012 23:25:24 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <4F07648E.7050108@lindenlab.com> References: <4F07648E.7050108@lindenlab.com> Message-ID: <20120106232524.9c871435.sldev@free.fr> On Fri, 06 Jan 2012 16:15:58 -0500, Oz Linden (Scott Lawrence) wrote: > We're going to deploying changes to the inventory backend soon that > improve robustness and performance, but in testing those changes we > found that existing viewers relied on certain things being strictly > ordered. With the new backend, that assumption does not always hold true. > > Changeset d327dcc8ae51 > > from viewer-development implements the viewer change needed to avoid > race conditions. It should be straightforward to apply to any viewer, > and is safe to release before the changes are deployed (it is compatible > with the services as they are now). > > You are strongly urged to port this patch and get it deployed. How urgent is it ?... Do we have days or weeks ? Will there be any testing ground available (e.g. on the beta grid or in some sandbox on the main grid) ?... "You are strongly urged" to provide more accurate details... ;-P Thank you in advance. Henri. From jhwelch at gmail.com Fri Jan 6 14:43:10 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 6 Jan 2012 17:43:10 -0500 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120106232524.9c871435.sldev@free.fr> References: <4F07648E.7050108@lindenlab.com> <20120106232524.9c871435.sldev@free.fr> Message-ID: If you do not have this patch there is a 50% chance that when you open a box with an outfit and pick Copy and Wear not all items will be worn. (If I have gotten these facts wrong please correct me Oz). On Fri, Jan 6, 2012 at 5:25 PM, Henri Beauchamp wrote: > On Fri, 06 Jan 2012 16:15:58 -0500, Oz Linden (Scott Lawrence) wrote: > >> We're going to deploying changes to the inventory backend soon that >> improve robustness and performance, but in testing those changes we >> found that existing viewers relied on certain things being strictly >> ordered. With the new backend, that assumption does not always hold true. >> >> Changeset d327dcc8ae51 >> >> from viewer-development implements the viewer change needed to avoid >> race conditions. It should be straightforward to apply to any viewer, >> and is safe to release before the changes are deployed (it is compatible >> with the services as they are now). >> >> You are strongly urged to port this patch and get it deployed. > > How urgent is it ?... Do we have days or weeks ? Will there be any > testing ground available (e.g. on the beta grid or in some sandbox > on the main grid) ?... > > "You are strongly urged" to provide more accurate details... ;-P > > Thank you in advance. > > Henri. > _______________________________________________ > 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 oz at lindenlab.com Fri Jan 6 14:49:28 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 06 Jan 2012 17:49:28 -0500 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120106232524.9c871435.sldev@free.fr> References: <4F07648E.7050108@lindenlab.com> <20120106232524.9c871435.sldev@free.fr> Message-ID: <4F077A78.3010004@lindenlab.com> On 2012-01-06 17:25, Henri Beauchamp wrote: > On Fri, 06 Jan 2012 16:15:58 -0500, Oz Linden (Scott Lawrence) wrote: > >> We're going to deploying changes to the inventory backend soon that >> improve robustness and performance, but in testing those changes we >> found that existing viewers relied on certain things being strictly >> ordered. With the new backend, that assumption does not always hold true. >> >> Changeset d327dcc8ae51 >> >> from viewer-development implements the viewer change needed to avoid >> race conditions. It should be straightforward to apply to any viewer, >> and is safe to release before the changes are deployed (it is compatible >> with the services as they are now). >> >> You are strongly urged to port this patch and get it deployed. > How urgent is it ?... Do we have days or weeks ? Will there be any > testing ground available (e.g. on the beta grid or in some sandbox > on the main grid) ?... > I'm not sure of the exact deployment schedule - more than days, probably less than a month. I believe that there is no known risk of inventory loss or damage without the patch, but it is true that some operations can result in accidental nudity, which some users might be unhappy about. From Lance.Corrimal at eregion.de Fri Jan 6 16:23:07 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 7 Jan 2012 01:23:07 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <4F07648E.7050108@lindenlab.com> References: <4F07648E.7050108@lindenlab.com> Message-ID: <201201070123.07925.Lance.Corrimal@eregion.de> Am Freitag, 6. Januar 2012 schrieb Oz Linden (Scott Lawrence): > We're going to deploying changes to the inventory backend soon that > improve robustness and performance, but in testing those changes we > found that existing viewers relied on certain things being strictly > ordered. With the new backend, that assumption does not always > hold true. > > Changeset d327dcc8ae51 > cc8ae51> from viewer-development implements the viewer change > needed to avoid race conditions. It should be straightforward to > apply to any viewer, and is safe to release before the changes are > deployed (it is compatible with the services as they are now). > > You are strongly urged to port this patch and get it deployed. I am not amused: usr/src/packages/BUILD/dolphinviewer3- beta/indra/newview/llinventorymodel.cpp:463:8: error: prototype for 'LLUUID LLInventoryModel::createNewCategory(const LLUUID&, LLFolderType::EType, const std::string&)' does not match any in class 'LLInventoryModel' /usr/src/packages/BUILD/dolphinviewer3- beta/indra/newview/llinventorymodel.h:364:9: error: candidate is: LLUUID LLInventoryModel::createNewCategory(const LLUUID&, LLFolderType::EType, const std::string&, void (*)(const LLSD&, void*), void*) make[2]: *** [newview/CMakeFiles/secondlife- bin.dir/llinventorymodel.o] Error 1 make[1]: *** [newview/CMakeFiles/secondlife-bin.dir/all] Error 2 make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.NI5LZ0 (%build) From Lance.Corrimal at eregion.de Sat Jan 7 00:44:43 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 7 Jan 2012 09:44:43 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <201201070123.07925.Lance.Corrimal@eregion.de> References: <4F07648E.7050108@lindenlab.com> <201201070123.07925.Lance.Corrimal@eregion.de> Message-ID: <201201070944.44276.Lance.Corrimal@eregion.de> My bad. note to self, do not merge patches when sleepy. > usr/src/packages/BUILD/dolphinviewer3- > beta/indra/newview/llinventorymodel.cpp:463:8: error: prototype for > 'LLUUID LLInventoryModel::createNewCategory(const LLUUID&, > LLFolderType::EType, const std::string&)' does not match any in > class 'LLInventoryModel' > /usr/src/packages/BUILD/dolphinviewer3- > beta/indra/newview/llinventorymodel.h:364:9: error: candidate is: > LLUUID LLInventoryModel::createNewCategory(const LLUUID&, > LLFolderType::EType, const std::string&, void (*)(const LLSD&, > void*), void*) > make[2]: *** [newview/CMakeFiles/secondlife- > bin.dir/llinventorymodel.o] Error 1 > make[1]: *** [newview/CMakeFiles/secondlife-bin.dir/all] Error 2 > make: *** [all] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.NI5LZ0 (%build) > > _______________________________________________ > 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 hitomi.tiponi at yahoo.co.uk Sat Jan 7 15:41:17 2012 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Sat, 7 Jan 2012 23:41:17 +0000 (GMT) Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: References: Message-ID: <1325979677.64149.YahooMailNeo@web23905.mail.ird.yahoo.com> Will a patch be provided for Viewer 1, and will a more general announcement be made, as not all TPV devs (or people who compile or use their own viewers) follow this list closely? ________________________________ > >Date: Fri, 06 Jan 2012 16:15:58 -0500 >From: "Oz Linden (Scott Lawrence)" >Subject: [opensource-dev] Inventory Patch you should integrate >To: opensource-dev >Message-ID: <4F07648E.7050108 at lindenlab.com> >Content-Type: text/plain; charset="iso-8859-1" > >We're going to deploying changes to the inventory backend soon that >improve robustness and performance, but in testing those changes we >found that existing viewers relied on certain things being strictly >ordered.? With the new backend, that assumption does not always hold true. > >Changeset d327dcc8ae51 > >from viewer-development implements the viewer change needed to avoid >race conditions.? It should be straightforward to apply to any viewer, >and is safe to release before the changes are deployed (it is compatible >with the services as they are now). > >You are strongly urged to port this patch and get it deployed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120107/ac577714/attachment.htm From kadah.coba at gmail.com Mon Jan 9 10:11:09 2012 From: kadah.coba at gmail.com (Kadah) Date: Mon, 09 Jan 2012 10:11:09 -0800 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <1325979677.64149.YahooMailNeo@web23905.mail.ird.yahoo.com> References: <1325979677.64149.YahooMailNeo@web23905.mail.ird.yahoo.com> Message-ID: <4F0B2DBD.6080706@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/7/2012 3:41 PM, Hitomi Tiponi wrote: > Will a patch be provided for Viewer 1 No. But which ever V1 TPV gets around to porting it first can provide it to the others to save them time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPCy29AAoJEIdLfPRu7qE2VBwIAMJr0O7+lHhLGgXKjsDFLujL HfyrVjbYJnwsw+v5+2ExcV4PXuJ6Tb0QkdoChkT6A2icn1HROv3M0wO28K6Q7lVn yacdWgRadRCepiICl2MUlzd7Zp6O98U7qCVOa/qWh6l8Xao257JSDnNkThC9gDn/ 3XUGM9zUJ94T3Jelk8rhP5f+2fRglspkMt38dwnyk4ECH+3BzlldgPTwanxxpvaA qE/ggAi3N8JALS+8in0o+axoViW+nr7RA80Na+QRmkW/d8xLvJUUL5tuz/cfw31d LzaKODFsuF9SZyeHWSu+2jErZfDCX3djN6XTmqs8pLGbSvnYMqTTeaH47gweHXg= =dXxc -----END PGP SIGNATURE----- From sldev at free.fr Tue Jan 10 05:23:42 2012 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 10 Jan 2012 14:23:42 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <1325979677.64149.YahooMailNeo@web23905.mail.ird.yahoo.com> References: <1325979677.64149.YahooMailNeo@web23905.mail.ird.yahoo.com> Message-ID: <20120110142342.48033fa0.sldev@free.fr> On Sat, 7 Jan 2012 23:41:17 +0000 (GMT), Hitomi Tiponi wrote: > Will a patch be provided for Viewer 1, Here is a patch that should apply to v1 viewers (you may perhaps get rejects due to spacing changes, but they should be dead easy to work around). Note that by lack of any testing ground, I could not test the new capability-based code path, but the old code path still works with this patch applied. Henri. -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-v1-copy_and_wear.patch Type: application/octet-stream Size: 10082 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120110/9525804f/attachment.obj From latifer at streamgrid.net Tue Jan 10 08:25:00 2012 From: latifer at streamgrid.net (Latif Khalifa) Date: Tue, 10 Jan 2012 17:25:00 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120110142342.48033fa0.sldev@free.fr> References: <1325979677.64149.YahooMailNeo@web23905.mail.ird.yahoo.com> <20120110142342.48033fa0.sldev@free.fr> Message-ID: On Tue, Jan 10, 2012 at 2:23 PM, Henri Beauchamp wrote: > On Sat, 7 Jan 2012 23:41:17 +0000 (GMT), Hitomi Tiponi wrote: > >> Will a patch be provided for Viewer 1, > > Here is a patch that should apply to v1 viewers (you may perhaps get > rejects due to spacing changes, but they should be dead easy to work > around). Thank you very much Henri. From sldev at free.fr Wed Jan 11 01:07:55 2012 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 11 Jan 2012 10:07:55 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120110142342.48033fa0.sldev@free.fr> References: <1325979677.64149.YahooMailNeo@web23905.mail.ird.yahoo.com> <20120110142342.48033fa0.sldev@free.fr> Message-ID: <20120111100755.9204197a.sldev@free.fr> Oops... There was a bug in the patch I sent for v1 viewers (I forgot to replace mFolderAdded(FALSE) with mFolderAdded(folder_added) in the constructor of LLInventoryCopyAndWearObserver). Attached to this email is the fixed patch. Henri. -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-v1-copy_and_wear_v2.patch Type: application/octet-stream Size: 10089 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120111/309661c6/attachment.obj From armin.weatherwax at googlemail.com Wed Jan 11 06:46:32 2012 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Wed, 11 Jan 2012 15:46:32 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <20120111100755.9204197a.sldev@free.fr> References: <20120110142342.48033fa0.sldev@free.fr> <20120111100755.9204197a.sldev@free.fr> Message-ID: <201201111546.32536.Armin.Weatherwax@googlemail.com> Am Wednesday 11 January 2012 10:07:55 schrieb Henri Beauchamp: > Oops... > > There was a bug in the patch I sent for v1 viewers (I forgot to replace > mFolderAdded(FALSE) with mFolderAdded(folder_added) in the constructor > of LLInventoryCopyAndWearObserver). > > Attached to this email is the fixed patch. > > Henri. Thank you for porting, Henri! And yes, it would be very good to have somwhere to test in the betagrid, there are a couple of things I think it would good to have an eye on: * in LLFloaterOpenObject::moveToInventory it looks to me that at least a LLCategoryCreate object gets leaked if a null category_id is returned, however all the // If we get a null category ID, we are using a capability in // createNewCategory and we will handle the following in the // callbackCreateInventoryCategory routine. if (category_id.notNull()) seems to contradict whats actally happening in LLInventoryModel::createNewCategory: null id returned on 2 possible failures, non-null in all other cases including success. * LLInventoryModel::createNewCategory returns a non-null id, even though requesting the cap failed if : - one or both of callback or user_data == NULL (ok, that is both rather unlikely) - the cap url is empty (e.g. the capability response didn't arrive (yet)). About that Im not so sure that it can not happen: buy new avatar, tp to busy sandbox on a busy weekend and have a bad network route anyway, rezz - open - copy and wear directly after teleport ... not sure yet how to simulate that in the betagrid, but I want to see what happens before it does to users. Armin From Lance.Corrimal at eregion.de Thu Jan 12 00:23:50 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 12 Jan 2012 08:23:50 -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 Message-ID: <20120112082350.22533.37534@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/ ----------------------------------------------------------- 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/20120112/431e19c3/attachment.htm From jhwelch at gmail.com Thu Jan 12 01:31:09 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 12 Jan 2012 09:31: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: <20120112082350.22533.37534@domU-12-31-38-00-90-68.compute-1.internal> References: <20120112082350.22533.37534@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120112093109.13487.19278@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/#review1137 ----------------------------------------------------------- indra/newview/skins/default/xui/en/floater_image_preview.xml Why are you changing this by 25 when in the other two locations you are only increasing by 20? - Jonathan Yap On Jan. 12, 2012, 12:23 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, 12:23 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/20120112/7d209123/attachment.htm From Lance.Corrimal at eregion.de Thu Jan 12 01:41:15 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 12 Jan 2012 09:41:15 -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: <20120112093109.13487.19278@domU-12-31-38-00-90-68.compute-1.internal> References: <20120112093109.13487.19278@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120112094115.13525.29316@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 12, 2012, 1:31 a.m., Jonathan Yap wrote: > > indra/newview/skins/default/xui/en/floater_image_preview.xml, line 111 > > > > > > Why are you changing this by 25 when in the other two locations you are only increasing by 20? it looks better that way :) - Lance ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/532/#review1137 ----------------------------------------------------------- On Jan. 12, 2012, 12:23 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, 12:23 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/20120112/2aab9ed0/attachment.htm From Lance.Corrimal at eregion.de Thu Jan 12 02:06:00 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 12 Jan 2012 10:06:00 -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: <20120112082350.22533.37534@domU-12-31-38-00-90-68.compute-1.internal> References: <20120112082350.22533.37534@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120112100600.13488.90029@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/ ----------------------------------------------------------- (Updated Jan. 12, 2012, 2:06 a.m.) Review request for Viewer. Changes ------- on second thought the additional 5 pixels are not really necessary. 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 (updated) ----- 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/20120112/1dc8f9d1/attachment-0001.htm From jhwelch at gmail.com Thu Jan 12 12:47:49 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 12 Jan 2012 20:47:49 -0000 Subject: [opensource-dev] Review Request: STORM-1798 'Block' menuitem title isn't changed after blocking item in object inspector Message-ID: <20120112204749.14083.64780@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/533/ ----------------------------------------------------------- Review request for Viewer. Description ------- 1. Open object inspector on an object 2. Click 'Gear' button>'Block' 3. Open object inspector again 4. Click 'Gear' button Actual: Menu item is still 'Block' (although item is already blocked) Expected: Menu item is changed to 'Unblock' This addresses bug STORM-1798. http://jira.secondlife.com/browse/STORM-1798 Diffs ----- indra/newview/llviewermenu.cpp 3a521e980fbf indra/newview/skins/default/xui/en/menu_inspect_object_gear.xml 3a521e980fbf Diff: http://codereview.secondlife.com/r/533/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/20120112/79bb4ddb/attachment.htm From jhwelch at gmail.com Mon Jan 16 05:12:49 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 16 Jan 2012 13:12:49 -0000 Subject: [opensource-dev] Review Request: STORM-1793 Viewer needs to treat all mini-map altitudes above 1020 m as the same height Message-ID: <20120116131249.3058.46418@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/534/ ----------------------------------------------------------- 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. LLNetMap::globalPosToView() computes a relative position: LLVector3d relative_pos_global = global_pos - gAgentCamera.getCameraPositionGlobal(); The Z value needs to take the global camera pos, and slam anything above 1020 to be 1020, and all our problems will be solved. Also, new artwork, an X, needs to be displayed for the case of avatar B and your camera position being at or above 1020m, where the relative height positions are unknown. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs ----- doc/contributions.txt 4982ab91ef6a indra/newview/llnetmap.cpp 4982ab91ef6a indra/newview/llworldmapview.h 4982ab91ef6a indra/newview/llworldmapview.cpp 4982ab91ef6a indra/newview/skins/default/textures/map_avatar_unknown_32.tga 4982ab91ef6a Diff: http://codereview.secondlife.com/r/534/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/20120116/c2a7309e/attachment.htm From Lance.Corrimal at eregion.de Mon Jan 16 05:35:51 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 16 Jan 2012 13:35:51 -0000 Subject: [opensource-dev] Review Request: VWR-17587: Added "Fly/Land on holding up/down" option under Move preferences In-Reply-To: <20111205230139.14773.41710@domU-12-31-38-00-90-68.compute-1.internal> References: <20111205230139.14773.41710@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120116133551.3056.23754@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/523/#review1139 ----------------------------------------------------------- Ship it! tested with 3.2.5, works as expected. - Lance Corrimal On Dec. 5, 2011, 3:01 p.m., Kadah Coba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/523/ > ----------------------------------------------------------- > > (Updated Dec. 5, 2011, 3:01 p.m.) > > > Review request for Viewer. > > > Description > ------- > > Quick patch to add back the long missing AutomaticFly aka "Fly/Land on holding up/down". The setting still existed but only has a debug setting with no exposure under preferences. This change only added a check box for it under Move preferences. > > Repo: https://bitbucket.org/Kadah_Coba/vwr-17587 > Changeset: https://bitbucket.org/Kadah_Coba/vwr-17587/changeset/2e717f07efbe > > > This addresses bug VWR-17587. > http://jira.secondlife.com/browse/VWR-17587 > > > Diffs > ----- > > indra/newview/skins/default/xui/en/panel_preferences_move.xml a984f7ffeb4b > > Diff: http://codereview.secondlife.com/r/523/diff/diff > > > Testing > ------- > > Patch was tested on Second Life 3.2.4.245931 and is diff against 3.2.5. > > > Thanks, > > Kadah Coba > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120116/e3fb65c5/attachment.htm From jhwelch at gmail.com Mon Jan 16 09:20:07 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 16 Jan 2012 17:20:07 -0000 Subject: [opensource-dev] Review Request: STORM-1799 Object doesn't appear in Block list if trying to block from Remote object inspector Message-ID: <20120116172007.3059.47477@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/535/ ----------------------------------------------------------- Review request for Viewer. Description ------- 1. Create an object and add default script 2. Click this object 3. Open plain text log and click on object name 4. Click 'Block' button ==> Actual: Block List is opened in the sidebar, but object is NOT added to your Blocked List Expected: Object is added to your Block List This addresses bug STORM-1799. http://jira.secondlife.com/browse/STORM-1799 Diffs ----- doc/contributions.txt 4982ab91ef6a indra/newview/llinspectremoteobject.cpp 4982ab91ef6a Diff: http://codereview.secondlife.com/r/535/diff/diff Testing ------- Performed steps per Description, object is blocked. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120116/28cb3e40/attachment.htm From jhwelch at gmail.com Mon Jan 16 11:33:20 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 16 Jan 2012 19:33:20 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" Message-ID: <20120116193320.3504.33702@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/536/ ----------------------------------------------------------- Review request for Viewer. Description ------- With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me Get together with: Avatar B (not a friend of A) Avatar C (a friend of A) Using avatar B establish an ad-hoc chat with A and C and write a message Observed result: Avatar A and C receive the message Expected result: Only avatar C receives the message This addresses bug STORM-1795. http://jira.secondlife.com/browse/STORM-1795 Diffs ----- doc/contributions.txt 4982ab91ef6a indra/newview/llimview.cpp 4982ab91ef6a Diff: http://codereview.secondlife.com/r/536/diff/diff Testing ------- Created a 3-way ad-hoc session per Description. Avatar C does not receive the message, but does get an ad-hoc session icon, even when B initiates the ad-hoc session. I think this is correct behavior because C may change their preferences to allow messages from everyone. You do not want to reject the session (that was handled by a different jira recently for blocked residents), only suppress messages. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120116/651c7789/attachment.htm From arrehn at gmail.com Mon Jan 16 12:59:50 2012 From: arrehn at gmail.com (Arrehn Oberlander) Date: Mon, 16 Jan 2012 20:59:50 -0000 Subject: [opensource-dev] Review Request: STORM-1793 Viewer needs to treat all mini-map altitudes above 1020 m as the same height In-Reply-To: <20120116131249.3058.46418@domU-12-31-38-00-90-68.compute-1.internal> References: <20120116131249.3058.46418@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120116205950.3713.96603@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/534/#review1141 ----------------------------------------------------------- In a number of ways this change is a step backwards and should be rejected / revisited. 1) Ambiguity. Previously, when an agent was "out of resolution" they were reported as 0m. This has the advantage of being an improbable edge value and easy for the viewer to detect and interpret as "out of resolution". However, this new proposed change would mark a user in the "out of resolution" state as 255, which translates to much more plausible value of ~1020m altitude. Agents are much more likely to be naturally at this altitude! Because of this change, it's much harder for the viewer to correctly determine that the reported value is out of resolution, or if the detected agent is actually at ~1020m. 2) Efficiency. I am not sure how aware LL is of the tremendous inefficiency the limited z axis range causes gridwide. More than 2/3rds of ALL SL GRID USERS are now using LSL-based "radar" systems to either feed viewers correct z heights or display the correct heights directly via a HUD. Not only is the overhead associated with transmitting this information every scan interval via LSL staggering, but it means that the original 8bit z axis field is largely being largely wasted. By increasing the resolution of the z-axis field provided directly to the viewer, LL would be saving enormous amounts of overhead and bandwidth by obsoleting LSL-based systems. Continuing to ignore this is penny wise, pound foolish. - Arrehn Oberlander On Jan. 16, 2012, 5:12 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/534/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2012, 5:12 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. > > LLNetMap::globalPosToView() computes a relative position: > > LLVector3d relative_pos_global = global_pos - gAgentCamera.getCameraPositionGlobal(); > > The Z value needs to take the global camera pos, and slam anything above 1020 to be 1020, and all our problems will be solved. > > Also, new artwork, an X, needs to be displayed for the case of avatar B and your camera position being at or above 1020m, where the relative height positions are unknown. > > > This addresses bug STORM-1793. > http://jira.secondlife.com/browse/STORM-1793 > > > Diffs > ----- > > doc/contributions.txt 4982ab91ef6a > indra/newview/llnetmap.cpp 4982ab91ef6a > indra/newview/llworldmapview.h 4982ab91ef6a > indra/newview/llworldmapview.cpp 4982ab91ef6a > indra/newview/skins/default/textures/map_avatar_unknown_32.tga 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/534/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/20120116/4d96e0d6/attachment.htm From wolfpup67 at earthlink.net Mon Jan 16 14:22:55 2012 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Mon, 16 Jan 2012 17:22:55 -0500 Subject: [opensource-dev] A CALL TO MAC DEVELOPERS! Message-ID: <000c01ccd49d$64eba2e0$2ec2e8a0$@net> Subject: https://jira.secondlife.com/browse/STORM-1797 Need help verifying if this is affecting those that use Mac OS. Please test against viewer-development tip. Reply here or post a comment in the above mentioned issue. There is a test plan in the issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120116/9a42524f/attachment.htm From laurent.bechir at madonie.org Mon Jan 16 17:50:11 2012 From: laurent.bechir at madonie.org (Laurent Rathle) Date: Tue, 17 Jan 2012 02:50:11 +0100 Subject: [opensource-dev] Anim format files upload Message-ID: Hello, Is it possible to add the following patch : In indra/newview/llviewermenufile.cpp. Locate the function upload_new_resource, and circa line 800 (search for DoNotSupportBulkAnimationUpload ) after the following code: else if (exten == "bvh") { error_message = llformat("We do not currently support bulk upload of animation files\n"); upload_error(error_message, "DoNotSupportBulkAnimationUpload", filename, args); return; } add the following: else if (exten == "anim") { asset_type = LLAssetType::AT_ANIMATION; filename = src_filename; } as seen on this web page : http://blog.machinimatrix.org/avastar/avastar-anim-format/ Should I open a Jira as feature request for this ? Thank you From stickman at gmail.com Mon Jan 16 17:59:25 2012 From: stickman at gmail.com (Stickman) Date: Mon, 16 Jan 2012 17:59:25 -0800 Subject: [opensource-dev] Anim format files upload In-Reply-To: References: Message-ID: > Is it possible to add the following patch : To add my support. Using BVH to upload files has serious drawbacks. Being able to upload a raw anim file natively in the official SL viewer opens all sorts of wonderful avenues, such as a Maya or Blender plugin that exports directly into the anim format. This allows us to have more accurate animations with less waste, and to put the details where we want them, instead of having them automatically assigned. Laurent, let me know if you find/create a Jira. It would have my support. Stickman From laurent.bechir at madonie.org Mon Jan 16 18:13:29 2012 From: laurent.bechir at madonie.org (Laurent Rathle) Date: Tue, 17 Jan 2012 03:13:29 +0100 Subject: [opensource-dev] Anim format files upload In-Reply-To: References: Message-ID: <9E613F41-09A6-4BD3-8B9E-3F4199743309@madonie.org> Here we go : https://jira.secondlife.com/browse/VWR-28143 Le 17 janv. 2012 ? 02:59, Stickman a ?crit : >> Is it possible to add the following patch : > > To add my support. Using BVH to upload files has serious drawbacks. > Being able to upload a raw anim file natively in the official SL > viewer opens all sorts of wonderful avenues, such as a Maya or Blender > plugin that exports directly into the anim format. This allows us to > have more accurate animations with less waste, and to put the details > where we want them, instead of having them automatically assigned. > > Laurent, let me know if you find/create a Jira. It would have my support. > > Stickman From jhwelch at gmail.com Tue Jan 17 00:17:21 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Tue, 17 Jan 2012 03:17:21 -0500 Subject: [opensource-dev] Anim format files upload In-Reply-To: References: Message-ID: It is easy to add that code change, but what happens at the server when it receives an .anim file? From nexiim at gmail.com Tue Jan 17 05:31:57 2012 From: nexiim at gmail.com (Nexii Malthus) Date: Tue, 17 Jan 2012 13:31:57 +0000 Subject: [opensource-dev] Anim format files upload In-Reply-To: References: Message-ID: The server already receives anim files by default. The real question is, what happens if the server receives a bvh file? The client has always converted the BVH into the internal format using aggressive and badly tuned algorithms. (Or at least, for a very very long time that lindens lost the original tools/original knowledge to make anims on the internal format (hint: hacking in special lines into anim.ini each time you upload an anim)) On Tue, Jan 17, 2012 at 8:17 AM, Jonathan Welch wrote: > It is easy to add that code change, but what happens at the server > when it receives an .anim file? > _______________________________________________ > 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/20120117/95c96787/attachment.htm From adeonwriter at live.com Tue Jan 17 07:14:39 2012 From: adeonwriter at live.com (Adeon Writer) Date: Tue, 17 Jan 2012 10:14:39 -0500 Subject: [opensource-dev] Anim format files upload In-Reply-To: References: Message-ID: I strongly support this patch; the internal animation format can do many unique animation tricks that the bvh cannot; including: -Different animation priorities per-joint -Keyframed animation control of eyes! -Variable length joint offsets per frame (allowing cartoon-like "stretchy" bones) -Keyframed rotation and repositioning of attachments (which meshes can weight to; to use as new child bones :) ) -ClientSide scaling of attachments and default mesh Just to name a few. -Adeon Writer On Jan 16, 2012, at 8:50 PM, Laurent Rathle wrote: > > Hello, > > Is it possible to add the following patch : > > In indra/newview/llviewermenufile.cpp. Locate the function upload_new_resource, and circa line 800 (search for DoNotSupportBulkAnimationUpload ) after the following code: > > else if (exten == "bvh") > { > error_message = llformat("We do not currently support bulk upload of animation files\n"); > upload_error(error_message, "DoNotSupportBulkAnimationUpload", filename, args); > return; > } > add the following: > > else if (exten == "anim") > { > asset_type = LLAssetType::AT_ANIMATION; > filename = src_filename; > } > > as seen on this web page : > > http://blog.machinimatrix.org/avastar/avastar-anim-format/ > > Should I open a Jira as feature request for this ? > > Thank you > _______________________________________________ > 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 oz at lindenlab.com Tue Jan 17 10:59:38 2012 From: oz at lindenlab.com (Oz Linden) Date: Tue, 17 Jan 2012 18:59:38 -0000 Subject: [opensource-dev] Review Request: STORM-1798 'Block' menuitem title isn't changed after blocking item in object inspector In-Reply-To: <20120112204749.14083.64780@domU-12-31-38-00-90-68.compute-1.internal> References: <20120112204749.14083.64780@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120117185938.3056.11912@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/533/#review1145 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Jan. 12, 2012, 12:47 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/533/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2012, 12:47 p.m.) > > > Review request for Viewer. > > > Description > ------- > > 1. Open object inspector on an object > 2. Click 'Gear' button>'Block' > 3. Open object inspector again > 4. Click 'Gear' button > > Actual: Menu item is still 'Block' (although item is already blocked) > > Expected: Menu item is changed to 'Unblock' > > > This addresses bug STORM-1798. > http://jira.secondlife.com/browse/STORM-1798 > > > Diffs > ----- > > indra/newview/llviewermenu.cpp 3a521e980fbf > indra/newview/skins/default/xui/en/menu_inspect_object_gear.xml 3a521e980fbf > > Diff: http://codereview.secondlife.com/r/533/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/20120117/af891a9e/attachment.htm From kaluura at gmail.com Wed Jan 18 09:29:26 2012 From: kaluura at gmail.com (Kaluura Boa) Date: Wed, 18 Jan 2012 18:29:26 +0100 Subject: [opensource-dev] Changing the name Message-ID: <201201181829.26900.kaluura@gmail.com> Hello List, Simple question: What is the best way to change the name of the viewer once you have cloned the mercurial repository? A lot of variations of the name "SecondLife" in various cases are all over the build tree. Some occurences can be replaced with more or less care, some must not. Assuming I want my viewer to say "FooBar" in the About floater, to have a "do-no-run-directly-foobar-bin" executable, to work in ~/.foobar, etc, how do I do that without too many problems? I do not intend to distribute anything in any foreseeable future, I just have some itches to scratch in the UI --which I find very uncooperative with my skinning expectations sometimes. Thanks, -- ==================== kaluura_AT_gmail.com ==================== From cinder at cinderblocks.biz Wed Jan 18 09:55:28 2012 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Wed, 18 Jan 2012 10:55:28 -0700 Subject: [opensource-dev] Changing the name In-Reply-To: <201201181829.26900.kaluura@gmail.com> References: <201201181829.26900.kaluura@gmail.com> Message-ID: <000001ccd60a$5dfc88f0$19f59ad0$@biz> Hi! Most of what you're looking for can be found in ./indra/newview/viewer_manifest.py , ./indra/llcommon/llversionviewer.h , and ./autobuild.xml -- King regards, Cinder -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Kaluura Boa Sent: Wednesday, January 18, 2012 10:29 AM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Changing the name Hello List, Simple question: What is the best way to change the name of the viewer once you have cloned the mercurial repository? A lot of variations of the name "SecondLife" in various cases are all over the build tree. Some occurences can be replaced with more or less care, some must not. Assuming I want my viewer to say "FooBar" in the About floater, to have a "do-no-run-directly-foobar-bin" executable, to work in ~/.foobar, etc, how do I do that without too many problems? I do not intend to distribute anything in any foreseeable future, I just have some itches to scratch in the UI --which I find very uncooperative with my skinning expectations sometimes. Thanks, -- ==================== kaluura_AT_gmail.com ==================== From jhwelch at gmail.com Wed Jan 18 09:58:41 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Wed, 18 Jan 2012 12:58:41 -0500 Subject: [opensource-dev] Changing the name In-Reply-To: <000001ccd60a$5dfc88f0$19f59ad0$@biz> References: <201201181829.26900.kaluura@gmail.com> <000001ccd60a$5dfc88f0$19f59ad0$@biz> Message-ID: There is one non-obvious place that I came across a while ago--the startup code takes out a mutex, probably so it has a way of seeing if you are trying to run more than one viewer at a time (and have the setting for that disabled). -jonathan From jhwelch at gmail.com Wed Jan 18 10:03:52 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Wed, 18 Jan 2012 13:03:52 -0500 Subject: [opensource-dev] Changing the name In-Reply-To: References: <201201181829.26900.kaluura@gmail.com> <000001ccd60a$5dfc88f0$19f59ad0$@biz> Message-ID: Also see strings.xml which defines APP_NAME and CAPITALIZED_APP_NAME From oz at lindenlab.com Fri Jan 20 08:05:23 2012 From: oz at lindenlab.com (Oz Linden) Date: Fri, 20 Jan 2012 16:05:23 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120116193320.3504.33702@domU-12-31-38-00-90-68.compute-1.internal> References: <20120116193320.3504.33702@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120120160523.3713.88053@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/536/#review1144 ----------------------------------------------------------- indra/newview/llimview.cpp What's wrong with ' != NULL ' here? I'm a fan of conditional expressions, but this is overdoing it. really, I think that all this could be folded into the if expression... - Oz Linden On Jan. 16, 2012, 11:33 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/536/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2012, 11:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me > > Get together with: > Avatar B (not a friend of A) > Avatar C (a friend of A) > > Using avatar B establish an ad-hoc chat with A and C and write a message > > Observed result: Avatar A and C receive the message > Expected result: Only avatar C receives the message > > > This addresses bug STORM-1795. > http://jira.secondlife.com/browse/STORM-1795 > > > Diffs > ----- > > doc/contributions.txt 4982ab91ef6a > indra/newview/llimview.cpp 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/536/diff/diff > > > Testing > ------- > > Created a 3-way ad-hoc session per Description. Avatar C does not receive the message, but does get an ad-hoc session icon, even when B initiates the ad-hoc session. I think this is correct behavior because C may change their preferences to allow messages from everyone. You do not want to reject the session (that was handled by a different jira recently for blocked residents), only suppress messages. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120120/9e632899/attachment.htm From jhwelch at gmail.com Fri Jan 20 08:41:04 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 20 Jan 2012 16:41:04 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120116193320.3504.33702@domU-12-31-38-00-90-68.compute-1.internal> References: <20120116193320.3504.33702@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120120164104.3056.49591@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/536/#review1147 ----------------------------------------------------------- indra/newview/llimview.cpp I think there may be something else wrong with this logic: you do not have calls/IMs restricted and someone is your friend, this would not show the message (false AND true produce false), or am I missing something here? - Jonathan Yap On Jan. 16, 2012, 11:33 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/536/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2012, 11:33 a.m.) > > > Review request for Viewer. > > > Description > ------- > > With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me > > Get together with: > Avatar B (not a friend of A) > Avatar C (a friend of A) > > Using avatar B establish an ad-hoc chat with A and C and write a message > > Observed result: Avatar A and C receive the message > Expected result: Only avatar C receives the message > > > This addresses bug STORM-1795. > http://jira.secondlife.com/browse/STORM-1795 > > > Diffs > ----- > > doc/contributions.txt 4982ab91ef6a > indra/newview/llimview.cpp 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/536/diff/diff > > > Testing > ------- > > Created a 3-way ad-hoc session per Description. Avatar C does not receive the message, but does get an ad-hoc session icon, even when B initiates the ad-hoc session. I think this is correct behavior because C may change their preferences to allow messages from everyone. You do not want to reject the session (that was handled by a different jira recently for blocked residents), only suppress messages. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120120/52d68115/attachment.htm From oz at lindenlab.com Fri Jan 20 09:01:11 2012 From: oz at lindenlab.com (Oz Linden) Date: Fri, 20 Jan 2012 17:01:11 -0000 Subject: [opensource-dev] Review Request: STORM-1799 Object doesn't appear in Block list if trying to block from Remote object inspector In-Reply-To: <20120116172007.3059.47477@domU-12-31-38-00-90-68.compute-1.internal> References: <20120116172007.3059.47477@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120120170111.3713.79597@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/535/#review1148 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Jan. 16, 2012, 9:20 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/535/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2012, 9:20 a.m.) > > > Review request for Viewer. > > > Description > ------- > > 1. Create an object and add default script > 2. Click this object > 3. Open plain text log and click on object name > 4. Click 'Block' button > ==> > Actual: Block List is opened in the sidebar, but object is NOT added to your Blocked List > Expected: Object is added to your Block List > > > This addresses bug STORM-1799. > http://jira.secondlife.com/browse/STORM-1799 > > > Diffs > ----- > > doc/contributions.txt 4982ab91ef6a > indra/newview/llinspectremoteobject.cpp 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/535/diff/diff > > > Testing > ------- > > Performed steps per Description, object is blocked. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120120/d7bebe51/attachment.htm From jhwelch at gmail.com Fri Jan 20 11:17:47 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 20 Jan 2012 19:17:47 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120116193320.3504.33702@domU-12-31-38-00-90-68.compute-1.internal> References: <20120116193320.3504.33702@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120120191747.3711.94904@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/536/ ----------------------------------------------------------- (Updated Jan. 20, 2012, 11:17 a.m.) Review request for Viewer. Changes ------- Fixed logic error checking to see if message should be displayed or not. Description ------- With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me Get together with: Avatar B (not a friend of A) Avatar C (a friend of A) Using avatar B establish an ad-hoc chat with A and C and write a message Observed result: Avatar A and C receive the message Expected result: Only avatar C receives the message This addresses bug STORM-1795. http://jira.secondlife.com/browse/STORM-1795 Diffs (updated) ----- doc/contributions.txt 4982ab91ef6a indra/newview/llimview.cpp 4982ab91ef6a Diff: http://codereview.secondlife.com/r/536/diff/diff Testing ------- Created a 3-way ad-hoc session per Description. Avatar C does not receive the message, but does get an ad-hoc session icon, even when B initiates the ad-hoc session. I think this is correct behavior because C may change their preferences to allow messages from everyone. You do not want to reject the session (that was handled by a different jira recently for blocked residents), only suppress messages. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120120/23c3af22/attachment-0001.htm From jhwelch at gmail.com Fri Jan 20 11:27:40 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 20 Jan 2012 19:27:40 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120120191747.3711.94904@domU-12-31-38-00-90-68.compute-1.internal> References: <20120120191747.3711.94904@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120120192740.3056.27918@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/536/ ----------------------------------------------------------- (Updated Jan. 20, 2012, 11:27 a.m.) Review request for Viewer. Changes ------- Fix misspelled variable name. Description ------- With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me Get together with: Avatar B (not a friend of A) Avatar C (a friend of A) Using avatar B establish an ad-hoc chat with A and C and write a message Observed result: Avatar A and C receive the message Expected result: Only avatar C receives the message This addresses bug STORM-1795. http://jira.secondlife.com/browse/STORM-1795 Diffs (updated) ----- doc/contributions.txt 4982ab91ef6a indra/newview/llimview.cpp 4982ab91ef6a Diff: http://codereview.secondlife.com/r/536/diff/diff Testing ------- Created a 3-way ad-hoc session per Description. Avatar C does not receive the message, but does get an ad-hoc session icon, even when B initiates the ad-hoc session. I think this is correct behavior because C may change their preferences to allow messages from everyone. You do not want to reject the session (that was handled by a different jira recently for blocked residents), only suppress messages. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120120/fc293364/attachment.htm From jhwelch at gmail.com Fri Jan 20 11:29:34 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 20 Jan 2012 19:29:34 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120120192740.3056.27918@domU-12-31-38-00-90-68.compute-1.internal> References: <20120120192740.3056.27918@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120120192934.3711.98849@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/536/ ----------------------------------------------------------- (Updated Jan. 20, 2012, 11:29 a.m.) Review request for Viewer. Changes ------- Pointed test plan field to jira; no need to have two unsynchronized copies Description ------- With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me Get together with: Avatar B (not a friend of A) Avatar C (a friend of A) Using avatar B establish an ad-hoc chat with A and C and write a message Observed result: Avatar A and C receive the message Expected result: Only avatar C receives the message This addresses bug STORM-1795. http://jira.secondlife.com/browse/STORM-1795 Diffs ----- doc/contributions.txt 4982ab91ef6a indra/newview/llimview.cpp 4982ab91ef6a Diff: http://codereview.secondlife.com/r/536/diff/diff Testing (updated) ------- See test plan in jira Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120120/da2ad9b2/attachment.htm From Lance.Corrimal at eregion.de Sat Jan 21 03:36:18 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 21 Jan 2012 11:36:18 -0000 Subject: [opensource-dev] Review Request: OPEN-125 Open source mesh upload using hacd. In-Reply-To: <20111119202616.28175.81323@domU-12-31-38-00-90-68.compute-1.internal> References: <20111119202616.28175.81323@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120121113618.3504.13196@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/519/#review1149 ----------------------------------------------------------- Does not build on Mac OS X. - Lance Corrimal On Nov. 19, 2011, 12:26 p.m., Nicky Perian wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/519/ > ----------------------------------------------------------- > > (Updated Nov. 19, 2011, 12:26 p.m.) > > > Review request for Viewer and Lance Corrimal. > > > Description > ------- > > Refer to https://jira.secondlife.com/browse/OPEN-124 for modified library detail. Built viewer-development and TPV kokua under windows 7/64 bit and Debian Squeeze 32 bit linux with modified HACD. Logged to aditi, local opensim host and osgrid. Uploaded a several mesh models without problem. > > > This addresses bug https://jira.secondlife.com/browse/OPEN-125. > http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/OPEN-125 > > > Diffs > ----- > > autobuild.xml 36e901f3531c > indra/cmake/CMakeLists.txt 36e901f3531c > indra/cmake/FindHACD.cmake PRE-CREATION > indra/cmake/HACD.cmake PRE-CREATION > indra/cmake/LLConvexDecomposition.cmake 36e901f3531c > indra/cmake/ViewerMiscLibs.cmake 36e901f3531c > indra/newview/CMakeLists.txt 36e901f3531c > indra/newview/llmeshrepository.cpp 36e901f3531c > > Diff: http://codereview.secondlife.com/r/519/diff/diff > > > Testing > ------- > > Logged to aditi, local opensim host and osgrid. Uploaded a several mesh models without problem. > > > Thanks, > > Nicky Perian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120121/dfe4896c/attachment.htm From nickyperian at yahoo.com Sat Jan 21 07:47:31 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Sat, 21 Jan 2012 15:47:31 -0000 Subject: [opensource-dev] Review Request: OPEN-125 Open source mesh upload using hacd. In-Reply-To: <20111119202616.28175.81323@domU-12-31-38-00-90-68.compute-1.internal> References: <20111119202616.28175.81323@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120121154731.3059.13484@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/519/#review1150 ----------------------------------------------------------- I have no access to a MAC. Need a MAC developer to help out. - Nicky Perian On Nov. 19, 2011, 12:26 p.m., Nicky Perian wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/519/ > ----------------------------------------------------------- > > (Updated Nov. 19, 2011, 12:26 p.m.) > > > Review request for Viewer and Lance Corrimal. > > > Description > ------- > > Refer to https://jira.secondlife.com/browse/OPEN-124 for modified library detail. Built viewer-development and TPV kokua under windows 7/64 bit and Debian Squeeze 32 bit linux with modified HACD. Logged to aditi, local opensim host and osgrid. Uploaded a several mesh models without problem. > > > This addresses bug https://jira.secondlife.com/browse/OPEN-125. > http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/OPEN-125 > > > Diffs > ----- > > autobuild.xml 36e901f3531c > indra/cmake/CMakeLists.txt 36e901f3531c > indra/cmake/FindHACD.cmake PRE-CREATION > indra/cmake/HACD.cmake PRE-CREATION > indra/cmake/LLConvexDecomposition.cmake 36e901f3531c > indra/cmake/ViewerMiscLibs.cmake 36e901f3531c > indra/newview/CMakeLists.txt 36e901f3531c > indra/newview/llmeshrepository.cpp 36e901f3531c > > Diff: http://codereview.secondlife.com/r/519/diff/diff > > > Testing > ------- > > Logged to aditi, local opensim host and osgrid. Uploaded a several mesh models without problem. > > > Thanks, > > Nicky Perian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120121/d315546e/attachment.htm From oz at lindenlab.com Mon Jan 23 08:52:20 2012 From: oz at lindenlab.com (Oz Linden) Date: Mon, 23 Jan 2012 16:52:20 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120120192934.3711.98849@domU-12-31-38-00-90-68.compute-1.internal> References: <20120120192934.3711.98849@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120123165220.21302.42087@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/536/#review1151 ----------------------------------------------------------- indra/newview/llimview.cpp Couldn't this all be folded into the 'if' without the flag variable as: if ( !LLMuteList::getInstance()->isMuted(other_participant_id, LLMute::flagTextChat) && ! (gSavedSettings.getBOOL("VoiceCallsFriendsOnly") && (LLAvatarTracker::instance().getBuddyInfo(other_participant_id) == NULL)) (that probably won't format well) - Oz Linden On Jan. 20, 2012, 11:29 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/536/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2012, 11:29 a.m.) > > > Review request for Viewer. > > > Description > ------- > > With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me > > Get together with: > Avatar B (not a friend of A) > Avatar C (a friend of A) > > Using avatar B establish an ad-hoc chat with A and C and write a message > > Observed result: Avatar A and C receive the message > Expected result: Only avatar C receives the message > > > This addresses bug STORM-1795. > http://jira.secondlife.com/browse/STORM-1795 > > > Diffs > ----- > > doc/contributions.txt 4982ab91ef6a > indra/newview/llimview.cpp 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/536/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/20120123/30153a9c/attachment.htm From jhwelch at gmail.com Mon Jan 23 09:13:05 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 23 Jan 2012 17:13:05 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120123165220.21302.42087@domU-12-31-38-00-90-68.compute-1.internal> References: <20120123165220.21302.42087@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120123171305.21302.41917@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 23, 2012, 8:52 a.m., Oz Linden wrote: > > indra/newview/llimview.cpp, lines 2462-2470 > > > > > > Couldn't this all be folded into the 'if' without the flag variable as: > > > > if ( !LLMuteList::getInstance()->isMuted(other_participant_id, LLMute::flagTextChat) > > && ! (gSavedSettings.getBOOL("VoiceCallsFriendsOnly") && (LLAvatarTracker::instance().getBuddyInfo(other_participant_id) == NULL)) > > > > (that probably won't format well) > > There are two issues: 1) Clarity of code for future programmers (I think having the flag variable helps here) 2) Does your folded-in solution work properly for all 4 cases of VoiceCalls true/false and friend/not-friend? Am I having a dumb moment or does the case of VoiceCalls=false and is-friend=false not work properly here (!(false && false)) = false, when it should be true? - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/536/#review1151 ----------------------------------------------------------- On Jan. 20, 2012, 11:29 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/536/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2012, 11:29 a.m.) > > > Review request for Viewer. > > > Description > ------- > > With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me > > Get together with: > Avatar B (not a friend of A) > Avatar C (a friend of A) > > Using avatar B establish an ad-hoc chat with A and C and write a message > > Observed result: Avatar A and C receive the message > Expected result: Only avatar C receives the message > > > This addresses bug STORM-1795. > http://jira.secondlife.com/browse/STORM-1795 > > > Diffs > ----- > > doc/contributions.txt 4982ab91ef6a > indra/newview/llimview.cpp 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/536/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/20120123/5d6f97f7/attachment-0001.htm From jhwelch at gmail.com Mon Jan 23 14:45:34 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 23 Jan 2012 22:45:34 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120120192934.3711.98849@domU-12-31-38-00-90-68.compute-1.internal> References: <20120120192934.3711.98849@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120123224534.21297.357@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/536/ ----------------------------------------------------------- (Updated Jan. 23, 2012, 2:45 p.m.) Review request for Viewer. Changes ------- Slight reformatting/logic change. I think this is a good compromise between my too-wordy multi-line if statement and Oz's compact everything into one if statement approach. This is readable and doesn't waste space. Description ------- With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me Get together with: Avatar B (not a friend of A) Avatar C (a friend of A) Using avatar B establish an ad-hoc chat with A and C and write a message Observed result: Avatar A and C receive the message Expected result: Only avatar C receives the message This addresses bug STORM-1795. http://jira.secondlife.com/browse/STORM-1795 Diffs (updated) ----- doc/contributions.txt 4982ab91ef6a indra/newview/llimview.cpp 4982ab91ef6a Diff: http://codereview.secondlife.com/r/536/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/20120123/477d6936/attachment.htm From oz at lindenlab.com Tue Jan 24 09:43:36 2012 From: oz at lindenlab.com (Oz Linden) Date: Tue, 24 Jan 2012 17:43:36 -0000 Subject: [opensource-dev] Review Request: STORM-1795 Ad-hoc messages are received even when "Only friends and groups can call or IM me" In-Reply-To: <20120123224534.21297.357@domU-12-31-38-00-90-68.compute-1.internal> References: <20120123224534.21297.357@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120124174336.22909.55667@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/536/#review1156 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Jan. 23, 2012, 2:45 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/536/ > ----------------------------------------------------------- > > (Updated Jan. 23, 2012, 2:45 p.m.) > > > Review request for Viewer. > > > Description > ------- > > With avatar A: check on Preferences->Privacy->Only friends and groups can call or IM me > > Get together with: > Avatar B (not a friend of A) > Avatar C (a friend of A) > > Using avatar B establish an ad-hoc chat with A and C and write a message > > Observed result: Avatar A and C receive the message > Expected result: Only avatar C receives the message > > > This addresses bug STORM-1795. > http://jira.secondlife.com/browse/STORM-1795 > > > Diffs > ----- > > doc/contributions.txt 4982ab91ef6a > indra/newview/llimview.cpp 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/536/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/20120124/04f3948c/attachment.htm From dave at meadowlakearts.com Tue Jan 24 14:02:40 2012 From: dave at meadowlakearts.com (Dave Booth) Date: Tue, 24 Jan 2012 16:02:40 -0600 Subject: [opensource-dev] mesh upload crash in recent builds... Message-ID: <4F1F2A80.2060906@meadowlakearts.com> Somewhere between the branch for the current beta and the tip is a mistake leading to an instant crash when selecting "upload -> model" from the inventory floaters "+" menu. It's a 0xc00005 exception, the windows equivalent of your garden-variety segfault, pulling up the dmp file in vs2010 looks like the viewer is passing a null pointer into a call to strstr somewhere. From jhwelch at gmail.com Tue Jan 24 14:10:44 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Tue, 24 Jan 2012 17:10:44 -0500 Subject: [opensource-dev] mesh upload crash in recent builds... In-Reply-To: <4F1F2A80.2060906@meadowlakearts.com> References: <4F1F2A80.2060906@meadowlakearts.com> Message-ID: It sounds like you are running a self-compiled viewer, in which case OPEN-113 probably applies (Build > Upload > Model is not disabled in OS built viewers) https://jira.secondlife.com/browse/OPEN-113 From jhwelch at gmail.com Tue Jan 24 14:20:14 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Tue, 24 Jan 2012 17:20:14 -0500 Subject: [opensource-dev] mesh upload crash in recent builds... In-Reply-To: <4F1F2A80.2060906@meadowlakearts.com> References: <4F1F2A80.2060906@meadowlakearts.com> Message-ID: Do you get the same result/crash when trying to upload via a different menu entry point? From dave at meadowlakearts.com Tue Jan 24 14:32:15 2012 From: dave at meadowlakearts.com (Dave Booth) Date: Tue, 24 Jan 2012 16:32:15 -0600 Subject: [opensource-dev] mesh upload crash in recent builds... In-Reply-To: References: <4F1F2A80.2060906@meadowlakearts.com> Message-ID: <4F1F316F.5060507@meadowlakearts.com> On 1/24/2012 4:20 PM, Jonathan Welch wrote: > Do you get the same result/crash when trying to upload via a different > menu entry point? > Yep, Build > Upload > Model produces the same result as Inventory Floater > + > Upload > Model. Immediate crash with the same exception before the dialog to select a .dae is displayed. Its mesh-specific, no crash trying to upload any other kind of asset. It's relatively recent, whichever changeset caused it, a little while ago I was able to upload meshes no problem and the problem is not present in the current beta download. From nickyperian at yahoo.com Tue Jan 24 14:33:39 2012 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 24 Jan 2012 14:33:39 -0800 (PST) Subject: [opensource-dev] mesh upload crash in recent builds... In-Reply-To: References: <4F1F2A80.2060906@meadowlakearts.com> Message-ID: <1327444419.54507.YahooMailNeo@web43511.mail.sp1.yahoo.com> Here is a mesh up load test viewer (hours old) using hacd. Please keep in mind that this is in no way a production viewer and is not supported by linden lab. Best try with an alt and on aditi. It worked for me just a few minutes ago. http://bitbucket.org/NickyP/viewer-development-os-mesh-upload/downloads/Second_Life_3-2-8-0_LindenDeveloper_Setup.exe ________________________________ From: Jonathan Welch To: Dave Booth Cc: Viewer Sent: Tuesday, January 24, 2012 4:20 PM Subject: Re: [opensource-dev] mesh upload crash in recent builds... Do you get the same result/crash when trying to upload via a different menu entry point? _______________________________________________ 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/20120124/a7150a24/attachment.htm From dave at meadowlakearts.com Tue Jan 24 15:16:44 2012 From: dave at meadowlakearts.com (Dave Booth) Date: Tue, 24 Jan 2012 17:16:44 -0600 Subject: [opensource-dev] mesh upload crash in recent builds... In-Reply-To: <4F1F316F.5060507@meadowlakearts.com> References: <4F1F2A80.2060906@meadowlakearts.com> <4F1F316F.5060507@meadowlakearts.com> Message-ID: <4F1F3BDC.30002@meadowlakearts.com> Clarifying "relatively recent" - my last successful mesh uploads on the dev snapshot builds were on Jan 2nd, using 3.2.6.246889 from Dec 20th (I only update my download when the commits list gets a note) so whatever introduced this was in the 31 changesets on 1/6, the 41 on 1/8, the 6 (in two merges) on 1/9, the 15 on 1/17 or the 11 on 1/23. Obviously any of those merges predating the branch for the current beta can be excluded, which makes me look exceptionally suspiciously at the two builds since the version was updated to 3.2.8, namely 247796 on 1/22 and 248202 on 1/23 - but that dont stop me suspecting every build since I last successfully used it to upload a mesh :P Spending 30 years as a sysadmin makes me VERY willing to believe that a developer can break stuff in ways that defy logic :) On 1/24/2012 4:32 PM, Dave Booth wrote: > On 1/24/2012 4:20 PM, Jonathan Welch wrote: >> Do you get the same result/crash when trying to upload via a different >> menu entry point? >> > Yep, Build> Upload> Model produces the same result as Inventory > Floater> +> Upload> Model. Immediate crash with the same exception > before the dialog to select a .dae is displayed. > > Its mesh-specific, no crash trying to upload any other kind of asset. > It's relatively recent, whichever changeset caused it, a little while > ago I was able to upload meshes no problem and the problem is not > present in the current beta download. From jhwelch at gmail.com Wed Jan 25 04:46:50 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 25 Jan 2012 12:46:50 -0000 Subject: [opensource-dev] Review Request: STORM-1804 Details... button on PERMISSION_DEBIT dialog triggers run_time_permissions() with a deny action Message-ID: <20120125124650.21297.68291@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/ ----------------------------------------------------------- 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/20120125/58a9f44e/attachment.htm From jhwelch at gmail.com Wed Jan 25 04:47:06 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 25 Jan 2012 12:47:06 -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: <20120125124650.21297.68291@domU-12-31-38-00-90-68.compute-1.internal> References: <20120125124650.21297.68291@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120125124706.21301.52022@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/ ----------------------------------------------------------- (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/20120125/213dced8/attachment-0001.htm From jhwelch at gmail.com Wed Jan 25 04:49:20 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 25 Jan 2012 12:49:20 -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: <20120125124920.22918.90511@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/#review1157 ----------------------------------------------------------- indra/newview/llviewermessage.cpp Oz, here is the early return you thought might be present. Want to suggest an alternative? - Jonathan Yap 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/20120125/adece794/attachment.htm From robertltux at gmail.com Wed Jan 25 10:56:24 2012 From: robertltux at gmail.com (Robert Martin) Date: Wed, 25 Jan 2012 13:56:24 -0500 Subject: [opensource-dev] Questions on Mesh Avatars Message-ID: Okay first off let me say that the documents on Mesh Avatars (unless they have been updated in the last week of so) are either outdated or partly fictional. Does anybody have access to a decent and complete spec as to what is needed to make a Rigged Mesh Avatar?? 1 mesh Complexity should be below XK 2 how do you setup the mesh bones for correct rigging?? Also does anybody have access to a ready to upload Human avatar (simplebot.dae does not count and that avastar file is useless) and any hints on how to get it to work properly?? last bit if you after doing the upload edit the object to include say an avatar overide and or a RVL relay would that work properly?? -- Robert L Martin From dave at meadowlakearts.com Wed Jan 25 18:46:14 2012 From: dave at meadowlakearts.com (Dave Booth) Date: Wed, 25 Jan 2012 20:46:14 -0600 Subject: [opensource-dev] mesh upload crash in recent builds... In-Reply-To: <4F1F2A80.2060906@meadowlakearts.com> References: <4F1F2A80.2060906@meadowlakearts.com> Message-ID: <4F20BE76.2020006@meadowlakearts.com> reverified with todays build, VWR-28207 created. On 1/24/2012 4:02 PM, Dave Booth wrote: > Somewhere between the branch for the current beta and the tip is a > mistake leading to an instant crash when selecting "upload -> model" > from the inventory floaters "+" menu. It's a 0xc00005 exception, the > windows equivalent of your garden-variety segfault, pulling up the dmp > file in vs2010 looks like the viewer is passing a null pointer into a > call to strstr somewhere. > _______________________________________________ > 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 alistair at inrevo.com Thu Jan 26 05:51:30 2012 From: alistair at inrevo.com (Alistair McDonald) Date: Thu, 26 Jan 2012 13:51:30 +0000 Subject: [opensource-dev] Building Viewer 2, can't get audio to work Message-ID: <4F215A62.7020003@inrevo.com> Hi all, I need some help. I am trying to build Viewer 2 from the Mercurial repository ( http://hg.secondlife.com/viewer-development) using VS2010, and failing to get audio to work in the viewer (except voice). So, no effects when flying, clicking menus, etc. I think the reason is that fmod is not included in my build I have read and believe I've followed the instructions in http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds In particular, I have done: hg clone https://bitbucket.org/lindenlab/3p-fmod cd 3p-fmod autobuild build --all autobuild package Then I have added the hash to the autobuild.xml file (at this stage I don't think I will be pushing anything back, so I haven't copied the autobuild.xml file) with the command autobuild installables edit fmod platform=windows hash= url=file:/// Then, I have performed cd viewer-development autobuild configure -c ReleaseOS FMOD=YES At this stage, the output includes these lines: ... checking package ndofdev installing ndofdev from archive extracting ndofdev ... but the created build-vc100/llaudio/llaudio.vcproj file does not have a reference to and of the *_fmod.cpp files. And if I build with autobuild build -c ReleaseOS --no-configure then no fmod.dll is copied/packaged. If I attempt to configure with the target Release, instead of ReleaseOS, then the output from configure starts with checking package fmod installing fmod from archive extracting fmod checking package quicktime ... but later on the configure fails to download installing llconvexdecomposition from archive downloading llconvexdecomposition archive from http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/3p-llconvexdecomposition/rev/238959/arch/CYGWIN/installer/llconvexdecomposition-0.1-windows-20110819.tar.bz2 unable to download file: So, can anyone help me to get around this problem? I have googled and searched without success. Thanks in advance, Alistair From jhwelch at gmail.com Thu Jan 26 05:58:30 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 26 Jan 2012 08:58:30 -0500 Subject: [opensource-dev] Building Viewer 2, can't get audio to work In-Reply-To: <4F215A62.7020003@inrevo.com> References: <4F215A62.7020003@inrevo.com> Message-ID: > autobuild configure -c ReleaseOS FMOD=YES The only thing I can see at a quick glance that deviates from the instructions is the above line. Delete your build directory (build-vc100) and redo the configuration command with autobuild configure -c ReleaseOS -- -DLL_TESTS:BOOL=FALSE -DPACKAGE:BOOL=FALSE -DFMOD:BOOL=TRUE From alistair at inrevo.com Thu Jan 26 06:01:51 2012 From: alistair at inrevo.com (Alistair McDonald) Date: Thu, 26 Jan 2012 14:01:51 +0000 Subject: [opensource-dev] Building Viewer 2, can't get audio to work In-Reply-To: <4F215A62.7020003@inrevo.com> References: <4F215A62.7020003@inrevo.com> Message-ID: <4F215CCF.9000003@inrevo.com> On 26/01/2012 13:51, Alistair McDonald wrote: > Hi all, > > I need some help. I am trying to build Viewer 2 from the Mercurial > repository ( http://hg.secondlife.com/viewer-development) using VS2010, > and failing to get audio to work in the viewer (except voice). So, no > effects when flying, clicking menus, etc. > ... > Then, I have performed > cd viewer-development > autobuild configure -c ReleaseOS FMOD=YES > I'm a fool, I should have been using autobuild configure -c ReleaseOS -DFMOD:BOOL=TRUE Sorry to all! From Lance.Corrimal at eregion.de Thu Jan 26 06:03:05 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 26 Jan 2012 15:03:05 +0100 Subject: [opensource-dev] Building Viewer 2, can't get audio to work In-Reply-To: <4F215A62.7020003@inrevo.com> References: <4F215A62.7020003@inrevo.com> Message-ID: <1763686.eyeg1nD6H9@nb-20> Am Donnerstag, 26. Januar 2012, 13:51:30 schrieb Alistair McDonald: > autobuild configure -c ReleaseOS FMOD=YES that should read: autobuild configure -c ReleaseOS -- -DFMOD=TRUE that should do the trick. bye, LC From jhwelch at gmail.com Thu Jan 26 06:05:53 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 26 Jan 2012 09:05:53 -0500 Subject: [opensource-dev] Building Viewer 2, can't get audio to work In-Reply-To: <4F215CCF.9000003@inrevo.com> References: <4F215A62.7020003@inrevo.com> <4F215CCF.9000003@inrevo.com> Message-ID: If you have more immediate questions look for help on IRC system Freenode, channel #opensl From stickman at gmail.com Thu Jan 26 07:44:29 2012 From: stickman at gmail.com (Stickman) Date: Thu, 26 Jan 2012 07:44:29 -0800 Subject: [opensource-dev] Questions on Mesh Avatars In-Reply-To: References: Message-ID: Robert, You know, I don't even know what mailing list this should go to. I don't think there is a "general creators mailing list" for SL. Just scripting. > Okay first off let me say that the documents on Mesh Avatars (unless > they have been updated in the last week of so) are either outdated or > partly fictional. Yeah, that's how wikis tend to go, unless they have a champion. Technical wikis tend to work better because you get a lot of people who can't stand incomplete or incorrect information. > Does anybody have access to a decent and complete spec as to what is > needed to make a Rigged Mesh Avatar?? > 1 mesh Complexity should be below XK I'd recommend keeping it below 6000 tris. If you need more, you'd better be making something awesome and for specific rather than general use. Here's what some of my professors from college did with 5000 tris: http://chunlu3d.com/robot2.html Granted, they don't have detailed faces. But the detail is elsewhere which a normal avatar wouldn't need. > 2 how do you setup the mesh bones for correct rigging?? This is going to vary all over the place. Depends on what 3D modeler you're using, what version you're using, etc. I recommend joining the Avatar Maker's Guild in SL and asking in there. A lot of avatar makers are there, and are usually willing to share information. Especially when asking specific questions, and is actually trying to learn something. > last bit if you after doing the upload edit the object to include say > an avatar overide and or a RVL relay would that work properly?? This sentence sense make not. Rephrase? Mesh is an object like any other. Throw an AO in it with some animations, and it'll act like you expect. Stickman From robertltux at gmail.com Thu Jan 26 09:40:43 2012 From: robertltux at gmail.com (Robert Martin) Date: Thu, 26 Jan 2012 12:40:43 -0500 Subject: [opensource-dev] Questions on Mesh Avatars In-Reply-To: References: Message-ID: On Thu, Jan 26, 2012 at 10:44 AM, Stickman wrote: > Robert, > > You know, I don't even know what mailing list this should go to. I > don't think there is a "general creators mailing list" for SL. Just > scripting. > the lack of a decent list for this is why i punted to the developers general list (since this has the best chances of being seen by somebody that can use their head for more than a hatrack) > > Yeah, that's how wikis tend to go, unless they have a champion. > Technical wikis tend to work better because you get a lot of people > who can't stand incomplete or incorrect information. > .. Yah folks don't like doing docs so folks have to do things like ask in a mailing list > I'd recommend keeping it below 6000 tris. If you need more, you'd > better be making something awesome and for specific rather than > general use. Cool beans somebody that can give a number (i take it that this would be on a per mesh thing??) -- Robert L Martin From kf6kjg at gmail.com Thu Jan 26 12:33:56 2012 From: kf6kjg at gmail.com (Ricky) Date: Thu, 26 Jan 2012 12:33:56 -0800 Subject: [opensource-dev] Questions on Mesh Avatars In-Reply-To: References: Message-ID: It depends on the mesh. The example given of around 6k tris is what I'd consider to be the max for a whole avatar mesh - including a few basic attachments. A shirt mesh would be a whole lot less. I'd recommend taking some courses, or at least hunting around on the 'net for info, on how to create low-poly characters for games. While SL doesn't (yet) have support for normal maps, you can get away with a lot in the diffuse texture that it does have. The reason to keep your tricount as low as possible is this: the more tris in a scene the worse the lag - both network lag when loading and client lag while on-screen. I can't give a number for "low as possible" because it entirely depends on what is being built and the skill of the creator. If you want to see how badly the client is currently being tortured by the prim attachments a lot of people wear, switch to wireframe mode in the viewer: you'll see every tri displayed, and I've seen many avatars almost solid with the black lines of the triangle edges they were so dense. Such avatars cause a fair amount of client lag every time they are visible - the exact amount of lag depends on the computer and the graphics card of the observer. Hope that helps, Ricky Cron Stardust On Thu, Jan 26, 2012 at 9:40 AM, Robert Martin wrote: > On Thu, Jan 26, 2012 at 10:44 AM, Stickman wrote: > > Robert, > > > > You know, I don't even know what mailing list this should go to. I > > don't think there is a "general creators mailing list" for SL. Just > > scripting. > > > the lack of a decent list for this is why i punted to the developers > general list (since this has the best chances of being seen by > somebody that can use their head for more than a hatrack) > > > > Yeah, that's how wikis tend to go, unless they have a champion. > > Technical wikis tend to work better because you get a lot of people > > who can't stand incomplete or incorrect information. > > > .. Yah folks don't like doing docs so folks have to do things like ask > in a mailing list > > > I'd recommend keeping it below 6000 tris. If you need more, you'd > > better be making something awesome and for specific rather than > > general use. > Cool beans somebody that can give a number (i take it that this would > be on a per mesh thing??) > > > -- > Robert L Martin > _______________________________________________ > 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/20120126/afec3a71/attachment.htm From stickman at gmail.com Thu Jan 26 13:27:56 2012 From: stickman at gmail.com (Stickman) Date: Thu, 26 Jan 2012 13:27:56 -0800 Subject: [opensource-dev] Inworld Building Efficiency Education Message-ID: sl-dev, On Thu, Jan 26, 2012 at 12:33 PM, Ricky wrote: > If you want to see how badly the client is currently being tortured by the > prim attachments a lot of people wear, switch to wireframe mode in the > viewer: you'll see every tri displayed, and I've seen many avatars almost > solid with the black lines of the triangle edges they were so dense. Such > avatars cause a fair amount of client lag every time they are visible - the > exact amount of lag depends on the computer and the graphics card of the > observer. I believe that one of LL's biggest failings, and larger problems, is user education. I remember mention of some Content Creator's thing that's in the works. But I haven't heard anything but the name, and wasn't able to press for more information at the time. Ages back, one of my solution ideas for this was certification. Even if it was just a title or account flag, it could end up being a sort of certificate people can put on their products that people would hopefully end up looking for. "LL says this guy knows at least the minimum about what it takes to make something efficient." Is that actually happening? Anyone know any details? Thanks, Stickman From jhwelch at gmail.com Fri Jan 27 05:40:01 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 27 Jan 2012 13:40:01 -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 Message-ID: <20120127134001.21299.30543@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/ ----------------------------------------------------------- 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/20120127/71019145/attachment.htm From tinacloud at gmx.de Fri Jan 27 10:45:37 2012 From: tinacloud at gmx.de (Zi Ree) Date: Fri, 27 Jan 2012 19:45:37 +0100 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: <201201271945.37605.tinacloud@gmx.de> Am Freitag, 27. Januar 2012, 14:40:01 schrieb Jonathan Yap: > The SL simulator has recently been fixed so that the CoarseLocationUpdate > message properly returns 255 for all altitudes above 1020 meters. "Properly" is a very ... unusual term for this kind of behavior. It still returns a wrong value, just a slightly more wrong one than before. > Jonathan Yap Zi From oz at lindenlab.com Fri Jan 27 12:24:26 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 27 Jan 2012 15:24:26 -0500 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: <201201271945.37605.tinacloud@gmx.de> References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> Message-ID: <4F2307FA.7090300@lindenlab.com> On 2012-01-27 13:45 , Zi Ree wrote: > Am Freitag, 27. Januar 2012, 14:40:01 schrieb Jonathan Yap: > >> The SL simulator has recently been fixed so that the CoarseLocationUpdate >> message properly returns 255 for all altitudes above 1020 meters. > "Properly" is a very ... unusual term for this kind of behavior. It still > returns a wrong value, just a slightly more wrong one than before. 'wrong' is not really a relative term... The new value (255) is at least in the same direction for anyone under the maximum coarse location altitude, which removes some silly edge cases in which the reported altitude is rises until is suddenly becomes zero. In any event... this is the change that we've decided to make, and Jonathan appears to have done a good job of making the best of an admittedly awkward situation. Short of a major change to the coarse location messages (which would be completely incompatible with older viewers), I think this is the best that can be done. From oz at lindenlab.com Fri Jan 27 13:57:20 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 27 Jan 2012 16:57:20 -0500 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <4F07648E.7050108@lindenlab.com> References: <4F07648E.7050108@lindenlab.com> Message-ID: <4F231DC0.8010202@lindenlab.com> On 2012-01-06 16:15 , Oz Linden (Scott Lawrence) wrote: > We're going to deploying changes to the inventory backend soon that > improve robustness and performance, but in testing those changes we > found that existing viewers relied on certain things being strictly > ordered. With the new backend, that assumption does not always hold true. > > Changeset d327dcc8ae51 > > from viewer-development implements the viewer change needed to avoid > race conditions. It should be straightforward to apply to any viewer, > and is safe to release before the changes are deployed (it is > compatible with the services as they are now). > > You are strongly urged to port this patch and get it deployed. > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120127/e994e729/attachment.htm From kf6kjg at gmail.com Fri Jan 27 15:18:28 2012 From: kf6kjg at gmail.com (Ricky) Date: Fri, 27 Jan 2012 15:18:28 -0800 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: <4F2307FA.7090300@lindenlab.com> References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> <4F2307FA.7090300@lindenlab.com> Message-ID: A couple of questions Oz: 1. Would the client have a problem if another word was added to the message giving - duplicating the data, but allowing newer clients to choose to use the new word while older clients use the old byte? 2. Would the client have any problems if the CoarseLocationUpdate message was never sent? If not then that message could be deprecated, with a removal date set for some time in the future, while a new message that could handle much higher detail information was put in place and all newer clients were switched to it? I ask because this limitation of the message really puts a pinch in https://jira.secondlife.com/browse/VWR-27577. Ricky Cron Stardust On Fri, Jan 27, 2012 at 12:24 PM, Oz Linden (Scott Lawrence) < oz at lindenlab.com> wrote: > On 2012-01-27 13:45 , Zi Ree wrote: > > Am Freitag, 27. Januar 2012, 14:40:01 schrieb Jonathan Yap: > > > >> The SL simulator has recently been fixed so that the > CoarseLocationUpdate > >> message properly returns 255 for all altitudes above 1020 meters. > > "Properly" is a very ... unusual term for this kind of behavior. It still > > returns a wrong value, just a slightly more wrong one than before. > > 'wrong' is not really a relative term... > > The new value (255) is at least in the same direction for anyone under > the maximum coarse location altitude, which removes some silly edge > cases in which the reported altitude is rises until is suddenly becomes > zero. > > In any event... this is the change that we've decided to make, and > Jonathan appears to have done a good job of making the best of an > admittedly awkward situation. Short of a major change to the coarse > location messages (which would be completely incompatible with older > viewers), I think this is the best that can be done. > > > _______________________________________________ > 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/20120127/93dafe27/attachment.htm From jhwelch at gmail.com Fri Jan 27 15:37:44 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 27 Jan 2012 18:37:44 -0500 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: References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> <4F2307FA.7090300@lindenlab.com> Message-ID: > Would the client have a problem if another word was added to the message > giving - duplicating the data, but allowing newer clients to choose to use > the new word while older clients use the old byte? Yes, because the coarseupdate packet holds many positions, it is not just 1 packet per avatar, but as many as can be packed into the coarseupdate packet as will fit. So it is not possible to alter this packets' format in any way. Doing so would break all existing viewers that expect it to have its current format. > Would the client have any problems if the CoarseLocationUpdate message was > never sent? Yes, with a small exception, you would not know where anyone is anymore. > date set for some time in the future, while a new message that could handle > much higher detail information was put in place and all newer clients were > switched to it? This has been discussed several times at the server group meetings. Fixing this just to have a fully correct map display is more trouble than it is worth; having to run two packet formatters in parallel forever, having to query the viewer what packet format it wants, etc. is just not worth such a big effort. From kadah.coba at gmail.com Fri Jan 27 15:44:06 2012 From: kadah.coba at gmail.com (Kadah) Date: Fri, 27 Jan 2012 15:44:06 -0800 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: References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> <4F2307FA.7090300@lindenlab.com> Message-ID: <4F2336C6.3080105@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/27/2012 3:37 PM, Jonathan Welch wrote: >> Would the client have a problem if another word was added to the >> message giving - duplicating the data, but allowing newer clients >> to choose to use the new word while older clients use the old >> byte? > > Yes, because the coarseupdate packet holds many positions, it is > not just 1 packet per avatar, but as many as can be packed into > the coarseupdate packet as will fit. So it is not possible to > alter this packets' format in any way. Doing so would break all > existing viewers that expect it to have its current format. > >> Would the client have any problems if the CoarseLocationUpdate >> message was never sent? > > Yes, with a small exception, you would not know where anyone is > anymore. > >> date set for some time in the future, while a new message that >> could handle much higher detail information was put in place and >> all newer clients were switched to it? > > This has been discussed several times at the server group > meetings. Fixing this just to have a fully correct map display is > more trouble than it is worth; having to run two packet formatters > in parallel forever, having to query the viewer what packet format > it wants, etc. is just not worth such a big effort. I just wanted to add that the message containing all agents is only packed once per update, then sent in bulk to all agents. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPIzbGAAoJEIdLfPRu7qE2/lIIALVQq2mlITepS90gzriRFRPh BnFrnddJk7aD9J+SUtAw11FFqDqF+wGDX0l0Iu1oJqaPPtgjLweTXg0xNLzTOVIz /fdh1Nr711EdIoMZZFPWhpH/SP2lb7DwhZhmREONs2aAdlX1AKahaMclkbhJOFvY SGF1BAK5RrmewQFvgr96uiHJQaXwjo44DFpRWmeiCrCtCapPNu5U7Fz4iCGS7LxG kL6pSLBaDM7VcqkL3vHHALHeXgKLvLsEDqS36hwvTyNlWuqci7A1OZC6iKD2sNDz 03l7y8HnK9OWRcWhUxWoUbQM/ig33T1Ka0ZcuYESE1T9mB1ETlgKiyy3v9icmgo= =3c8S -----END PGP SIGNATURE----- From kf6kjg at gmail.com Fri Jan 27 16:14:13 2012 From: kf6kjg at gmail.com (Ricky) Date: Fri, 27 Jan 2012 16:14:13 -0800 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: References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> <4F2307FA.7090300@lindenlab.com> Message-ID: It just means that having a proper clientside radar system is now truly stuck. And I did mean a finite time period for the deprecation: I agree that such things are unmaintainable in the long term. However the current state of affairs isn't viable for long either, so a plan has to be readied. Kadah's note also shows that it is something that is not able to change per-viewer, so the only viable route is the deprecation model: for a period of time, say one year, the old message AND the new message are sent to all clients. The older clients should discard any message they don't recognize, in this case the new message, while the newer clients will discard the older message for the same reason. After the deprecation period is over the old message code is purged leaving only the new message and anyone who is running an un-updated client simply no long can tell altitude differences in the minimap. As to the format, one byte is not great, but now I at least understand why it was chosen: maximum data density. Currently the message uses absolute coordinates interpreted linearly across the space in the range [0, 255] * 4 meters. This worked when the region was only 1024m high. Here is another idea, trying to keep in what I think was the original spirit of the message: switch to using dynamic scale. Use the existing packet format, therefore keeping the bulk of the code the same, but have the client and the server agree that the scale value, currently set at 4 meters per message unit, is to be computed from the size of the region. This would mean that old-school 1024-meter-high regions would have the calculation for the scalar as so: 1024 / 255 = 4, resulting in the current value that worked so well for those regions. (Yes, I know such regions no longer exist.) Current regions would have the scalar calculated as 4096 / 255 = 16. Future regions with even higher ceilings would just continue that idea, resulting in the message's number being more like a percentage. Just make sure that this math is done for X and Y as well - not just Z. Otherwise we are right back here again if in the future estates can choose to have a different region size than other estates... (And yes it could be done. A LOT of work, but it could be done.) Ricky Cron Stardust PS: I really want to be able to get rid of my lag-creating Sensor-based HUD for a pure client-side system. Hence my active commentary. On Fri, Jan 27, 2012 at 3:37 PM, Jonathan Welch wrote: > > Would the client have a problem if another word was added to the message > > giving - duplicating the data, but allowing newer clients to choose to > use > > the new word while older clients use the old byte? > > Yes, because the coarseupdate packet holds many positions, it is not > just 1 packet per avatar, but as many as can be packed into the > coarseupdate packet as will fit. So it is not possible to alter this > packets' format in any way. Doing so would break all existing viewers > that expect it to have its current format. > > > > > Would the client have any problems if the CoarseLocationUpdate message > was > > never sent? > > Yes, with a small exception, you would not know where anyone is anymore. > > > date set for some time in the future, while a new message that could > handle > > much higher detail information was put in place and all newer clients > were > > switched to it? > > This has been discussed several times at the server group meetings. > Fixing this just to have a fully correct map display is more trouble > than it is worth; having to run two packet formatters in parallel > forever, having to query the viewer what packet format it wants, etc. > is just not worth such a big effort. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120127/ab6268a5/attachment-0001.htm From jhwelch at gmail.com Fri Jan 27 16:21:54 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 27 Jan 2012 19:21:54 -0500 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: References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> <4F2307FA.7090300@lindenlab.com> Message-ID: > PS: I really want to be able to get rid of my lag-creating Sensor-based HUD > for a pure client-side system. Hence my active commentary. The server team is not going to be making changes to the current system; they have said the cost of doing that, the additional load on the servers, etc. is not worth having more accurate z values. Much better for them to put their efforts on more important changes, etc. Now, given all that, the LL viewer is about to catch up to what the TPVs have been been doing for some time. It will use Z data for avatars near you, so if you are at 2,000m and someone is not too far away then your mini-map will show a proper height icon. The other part of that change will be to show an "X" if the relative height of you and someone else is not known (no more down pointing chevron for group of people standing around together at 2,000m). From arrehn at gmail.com Fri Jan 27 17:34:47 2012 From: arrehn at gmail.com (Arrehn Oberlander) Date: Fri, 27 Jan 2012 20:34:47 -0500 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: References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> <4F2307FA.7090300@lindenlab.com> Message-ID: On 1/27/12, Jonathan Welch wrote: > This has been discussed several times at the server group meetings. > Fixing this just to have a fully correct map display is more trouble > than it is worth; having to run two packet formatters in parallel > forever, having to query the viewer what packet format it wants, etc. > is just not worth such a big effort. It's 2012. If this is seriously the official reason why SL's premier client can't support more than 8 bits of z-height data, no one's buying it, least of all professional software developers. I could have said that same thing for 2002 as well. Wake up people.. More than 1/2 of the grid is already working around this architectural deficiency via all manner of LSL-based hacks. What do you think the cost of that is compared to making it right? In one word: apalling and embarassing. As it should be. From secret.argent at gmail.com Fri Jan 27 18:21:30 2012 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 27 Jan 2012 20:21:30 -0600 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: References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> <4F2307FA.7090300@lindenlab.com> Message-ID: <74EACE8A-FAF4-4056-B71A-B760218E7537@gmail.com> How about reducing the vertical resolution of the packet by 4? From kadah.coba at gmail.com Fri Jan 27 18:27:30 2012 From: kadah.coba at gmail.com (Kadah) Date: Fri, 27 Jan 2012 18:27:30 -0800 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: <74EACE8A-FAF4-4056-B71A-B760218E7537@gmail.com> References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201271945.37605.tinacloud@gmx.de> <4F2307FA.7090300@lindenlab.com> <74EACE8A-FAF4-4056-B71A-B760218E7537@gmail.com> Message-ID: <4F235D12.1060602@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/27/2012 6:21 PM, Argent Stonecutter wrote: > How about reducing the vertical resolution of the packet by 4? This was also brought up several times during the various discussions. It would break old/existing clients more than the current change, and the vertical resolution of 12m is a very significant height difference, agents could be on 2 or 3 different floors of a building and all report as being at the same level. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPI10SAAoJEIdLfPRu7qE2St8IAJOVYz59LYlbaD+w4jRNonKC qw9oP30TkNU25SUVVonm+9MF8X1jAv0a2m+laXDFReyBnVr8r55xXs7R7VEotc+k +0XThCYUxW61ildjekaUXz5fx1OefwX3Ds1kq0EOEmQ+XFq8Udkues18LNd77fTc rKRYfXr/2y64Y1x6Wj4c1DVbz559FeVPMzzDss+Va8wDFwrliPk06r/SOo/PrtWh BIhFik0icNlub8fHGZOIL/aLKTO14OSybazzuKW56pU8b56hHZV2kr3X4hXMRZxM ltRgNRjsFBnOGXPKMYS9x2r0ChNxOeTdoAFhRqdOfZA1INLi1wdfDDyD7aihPYU= =egRA -----END PGP SIGNATURE----- From dave at meadowlakearts.com Fri Jan 27 18:47:49 2012 From: dave at meadowlakearts.com (Dave Booth) Date: Fri, 27 Jan 2012 20:47:49 -0600 Subject: [opensource-dev] mesh upload crash in recent builds... In-Reply-To: <4F20BE76.2020006@meadowlakearts.com> References: <4F1F2A80.2060906@meadowlakearts.com> <4F20BE76.2020006@meadowlakearts.com> Message-ID: <4F2361D5.5050600@meadowlakearts.com> Dan took it into SH as SH-2918. Guess its gonna be fixed :) On 1/25/2012 8:46 PM, Dave Booth wrote: > reverified with todays build, VWR-28207 created. > > On 1/24/2012 4:02 PM, Dave Booth wrote: >> Somewhere between the branch for the current beta and the tip is a >> mistake leading to an instant crash when selecting "upload -> model" >> from the inventory floaters "+" menu. It's a 0xc00005 exception, the >> windows equivalent of your garden-variety segfault, pulling up the dmp >> file in vs2010 looks like the viewer is passing a null pointer into a >> call to strstr somewhere. >> _______________________________________________ >> 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 > From armin.weatherwax at googlemail.com Fri Jan 27 21:33:30 2012 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Sat, 28 Jan 2012 06:33:30 +0100 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: References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <201201280633.30684.Armin.Weatherwax@googlemail.com> Am Saturday 28 January 2012 00:37:44 schrieb Jonathan Welch: > Yes, because the coarseupdate packet holds many positions, it is not > just 1 packet per avatar, but as many as can be packed into the > coarseupdate packet as will fit. ?So it is not possible to alter this > packets' format in any way. ?Doing so would break all existing viewers > that expect it to have its current format. Old viewers have all sorts of issues if their code isn't maintained anymore, most of them are way more important. Imagine the Z- byte transformation was made non-linear: that would still give better results than we have right now, be a small change to new viewers, have low impact on old viewers, and generate no extra network load. Example: (1*1 + 2*2 + 4*4 + 8*8 + 16*16 + 32*32 + 64*64 + 128*128)m = 21845m range. Armin From sldev at free.fr Sat Jan 28 11:13:34 2012 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 28 Jan 2012 20:13:34 +0100 Subject: [opensource-dev] Inventory Patch you should integrate In-Reply-To: <4F231DC0.8010202@lindenlab.com> References: <4F07648E.7050108@lindenlab.com> <4F231DC0.8010202@lindenlab.com> Message-ID: <20120128201334.f74c3cfd.sldev@free.fr> 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 ? Henri. From sl.nicky.ml at googlemail.com Sun Jan 29 16:39:13 2012 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Mon, 30 Jan 2012 01:39:13 +0100 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: <201201280633.30684.Armin.Weatherwax@googlemail.com> References: <20120127134001.21299.30543@domU-12-31-38-00-90-68.compute-1.internal> <201201280633.30684.Armin.Weatherwax@googlemail.com> Message-ID: Or you could as well make a new message, then alternate it with the current one. Eg. instead of sending CoarseLocation update every x (lets say 5 ) seconds,you send 0 - CoarseLocation 5 - CoarseLocationNew 10 - CoarseLocation 15 - CoarseLocationNew And so on. - Old clients would lose update precision. But not be broken. - New clients would use both messages and get X/Y updates at the same interval as today. For Z they could interpolate if the old message send an 'out of range'-Z value. Or just live with the lower Z update frequency. Both would still be vastly better than what we have now. - The amount of message the simulator has to send would not increase. Phase out the old message by reducing its frequency after a few month, then stop sending it at all. Whoever did not update their code by that time could be considered badly outdated. From jhwelch at gmail.com Mon Jan 30 06:26:08 2012 From: jhwelch at gmail.com (Jonathan Welch) Date: Mon, 30 Jan 2012 09:26:08 -0500 Subject: [opensource-dev] Odd disappearing vehicle Message-ID: Someone just reported to me that they had found a vehicle at http://slurl.com/secondlife/Fortuna/5/243/26 If you try to select it or if you try to right click on it it disappears. How can this be possible? I used the object scanner in Radegast to do a bit more sleuthing, but even in there if you click on the name in the list (which is usually Loading...) it disappears right away. Can someone investigate and report back? I am curious what is going on here. Also, maybe drop a note to Laetizia Coronet, who discovered this. From cinder at cinderblocks.biz Mon Jan 30 07:22:58 2012 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Mon, 30 Jan 2012 08:22:58 -0700 Subject: [opensource-dev] Odd disappearing vehicle In-Reply-To: References: Message-ID: <000101ccdf63$0cbb7570$26326050$@biz> Greetings, The creator is Yasen Tomcast, so you may try asking her for details. You can see the object profile if you click it as it enters the region. (She's placed it on a border to prevent autoreturn.) It uses a MOAP hack to disappear. On right clicking: 2012-01-30T15:11:20Z INFO: LLViewerMediaImpl::navigateInternal: media id= 9c8badee-5539-3447-4a2d-9ca9d5ae3202 url=about:blank mime_type= 2012-01-30T15:11:20Z INFO: LLViewerMedia::getCurrentUserAgent: SecondLife/3.2.8.2 (Milkshake; default skin) 2012-01-30T15:11:20Z INFO: LLViewerMediaImpl::loadURI: Asking media source to load URI: about:blank 2012-01-30T15:11:20Z WARNING: LLUICtrl::initCommitCallback: No callback found for: 'Media.ResetCurrentUrl' in control: current_url_reset_btn 2012-01-30T15:11:20Z INFO: LLViewerMediaImpl::navigateInternal: media id= 9c8badee-5539-3447-4a2d-9ca9d5ae3202 url=data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%22100%%22 height=%22100%%22 %3E%3Cdefs%3E%3Cpattern id=%22checker%22 patternUnits=%22userSpaceOnUse%22 x=%220%22 y=%220%22 width=%22128%22 height=%22128%22 viewBox=%220 0 128 128%22 %3E%3Crect x=%220%22 y=%220%22 width=%2264%22 height=%2264%22 fill=%22#ddddff%22 /%3E%3Crect x=%2264%22 y=%2264%22 width=%2264%22 height=%2264%22 fill=%22#ddddff%22 /%3E%3C/pattern%3E%3C/defs%3E%3Crect x=%220%22 y=%220%22 width=%22100%%22 height=%22100%%22 fill=%22url(#checker)%22 /%3E%3C/svg%3E mime_type= 2012-01-30T15:11:20Z INFO: LLViewerMediaImpl::loadURI: Asking media source to load URI: data:image/svg+xml,%3Csvg%20xmlns=%22http://www.w3.org/2000/svg%22%20width=% 22100%%22%20height=%22100%%22%20%3E%3Cdefs%3E%3Cpattern%20id=%22checker%22%2 0patternUnits=%22userSpaceOnUse%22%20x=%220%22%20y=%220%22%20width=%22128%22 %20height=%22128%22%20viewBox=%220%200%20128%20128%22%20%3E%3Crect%20x=%220% 22%20y=%220%22%20width=%2264%22%20height=%2264%22%20fill=%22#ddddff%22%20/%3 E%3Crect%20x=%2264%22%20y=%2264%22%20width=%2264%22%20height=%2264%22%20fill =%22#ddddff%22%20/%3E%3C/pattern%3E%3C/defs%3E%3Crect%20x=%220%22%20y=%220%2 2%20width=%22100%%22%20height=%22100%%22%20fill=%22url(#checker)%22%20/%3E%3 C/svg%3E 2012-01-30T15:11:20Z INFO: LLMediaCtrl::handleVisibilityChange: visibility changed to false 2012-01-30T15:11:21Z INFO: LLPluginProcessParent::receiveMessage: plugin version string: Webkit media plugin, Webkit version 2.02.47681 (QtWebKit version 4.7.1) 2012-01-30T15:11:21Z INFO: LLPluginProcessParent::receiveMessage: message class: base -> version: 1.0 2012-01-30T15:11:21Z INFO: LLPluginProcessParent::receiveMessage: message class: media -> version: 1.0 2012-01-30T15:11:21Z INFO: LLPluginProcessParent::receiveMessage: message class: media_browser -> version: 1.0 2012-01-30T15:11:21Z INFO: LLFloater::openFloater: Opening floater toolbox floater 2012-01-30T15:11:21Z WARNING: LLFloaterTools::refresh: Failed to get selected object 2012-01-30T15:11:22Z WARNING: LLFloaterTools::refresh: Failed to get selected object 2012-01-30T15:11:22Z WARNING: LLFloaterTools::refresh: Failed to get selected object -- Kind regards, -Cinder -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Jonathan Welch Sent: Monday, January 30, 2012 7:26 AM To: OpenSource Mailing List Subject: [opensource-dev] Odd disappearing vehicle Someone just reported to me that they had found a vehicle at http://slurl.com/secondlife/Fortuna/5/243/26 If you try to select it or if you try to right click on it it disappears. How can this be possible? I used the object scanner in Radegast to do a bit more sleuthing, but even in there if you click on the name in the list (which is usually Loading...) it disappears right away. Can someone investigate and report back? I am curious what is going on here. Also, maybe drop a note to Laetizia Coronet, who discovered this. From cinder at cinderblocks.biz Mon Jan 30 09:39:41 2012 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Mon, 30 Jan 2012 10:39:41 -0700 Subject: [opensource-dev] Odd disappearing vehicle References: Message-ID: <000801ccdf76$261224c0$72366e40$@biz> That should actually be Tomcat, not Tomcast. :/ -----Original Message----- From: Cinder Roxley [mailto:cinder at cinderblocks.biz] Sent: Monday, January 30, 2012 8:23 AM To: 'OpenSource Mailing List' Subject: RE: [opensource-dev] Odd disappearing vehicle Greetings, The creator is Yasen Tomcast, so you may try asking her for details. From lee.ponzu at gmail.com Tue Jan 31 10:29:24 2012 From: lee.ponzu at gmail.com (Lee ponzu) Date: Tue, 31 Jan 2012 13:29:24 -0500 Subject: [opensource-dev] View on Lion Message-ID: Would someone be willing to give a short summary of the status of using the viewer on Lion. For that matter, what is the status of Lion, period. OS Xista? Or is it ok? lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120131/943ed5c7/attachment.htm From da5idkronfeld at gmail.com Tue Jan 31 10:36:34 2012 From: da5idkronfeld at gmail.com (Da5id Kronfeld) Date: Tue, 31 Jan 2012 10:36:34 -0800 Subject: [opensource-dev] View on Lion In-Reply-To: References: Message-ID: On 2012-01-31, at 10:29 AM, Lee ponzu wrote: > Would someone be willing to give a short summary of the status of using the viewer on Lion. > > For that matter, what is the status of Lion, period. OS Xista? Or is it ok? I'm running Lion on an early 2011 MBP ( quad core i7 @ 2.2GHz, 8GB RAM, AMD 6750M GPU, SSD ) and the last two LL viewers have been really good. VBO settings work again and the viewer on High graphics setting is smooth and stable. Overall, I love Lion for it's very good implementation of multiple desktops ( aka (the unfortunately named) Mission Control ). I do a lot of things at once, in general that this is the nicest desktop OS that I've ever used for that. It benefits greatly from a trackpad though. From kadah.coba at gmail.com Tue Jan 31 11:22:39 2012 From: kadah.coba at gmail.com (Kadah) Date: Tue, 31 Jan 2012 11:22:39 -0800 Subject: [opensource-dev] View on Lion In-Reply-To: References: Message-ID: <4F283F7F.2060508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've ran it on my 2011 mini mac and it runs ok, but with really bad color distortions, which are possibly due to it only have the cheap Intel gfx chip. Building the viewer (at least with Firestorm) on Lion seems to also work without any special setups other than xcode 4.whatever and cmake. On 1/31/2012 10:29 AM, Lee ponzu wrote: > Would someone be willing to give a short summary of the status of > using the viewer on Lion. > > For that matter, what is the status of Lion, period. OS Xista? Or > is it ok? > > lee > > > _______________________________________________ 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/ iQEcBAEBAgAGBQJPKD9/AAoJEIdLfPRu7qE2hZEIAKBoiKrJig2xWclN26IdSn0E Mc2Xoqev8zeORCdur+vCkanPax+E+ewh07qNS33umQl2K04C23JR2jLc4gDHKHX8 WryjhyOiTeqcyNNcN5LudWDESgTV79NU9cHOd+yPcHbS8qdLPIsnbFdtUiHeDfud FbW9EErKnryVZd0JKxcPZne+/S6yeidUgUlskWcZjgOTIM5vLD7kfuUOxtwMHkKP uUS8CkSUqdfTIMEPVWrvPQT/IDyX23v8XA3wkCUzY/fWH+i13eQQFD/Zp7MgTG+U xnAtblvgcL0D+M4so4jUUXgb5RgpGUTIe6ddVJSErZHhEVDW2mqE8/W7e/vtsIk= =cJ44 -----END PGP SIGNATURE----- From jhwelch at gmail.com Tue Jan 31 14:07:19 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 31 Jan 2012 22:07:19 -0000 Subject: [opensource-dev] Review Request: STORM-1803 Adding raw anim file upload support Message-ID: <20120131220719.10598.61740@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/ ----------------------------------------------------------- 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/20120131/0ba48cd7/attachment.htm From kf6kjg at gmail.com Tue Jan 31 19:30:44 2012 From: kf6kjg at gmail.com (Ricky) Date: Tue, 31 Jan 2012 19:30:44 -0800 Subject: [opensource-dev] View on Lion In-Reply-To: <4F283F7F.2060508@gmail.com> References: <4F283F7F.2060508@gmail.com> Message-ID: Yeah, on the Intel card there seems to be a texture corruption caused by one of the atmo shaders. Really psychedelic if you tune the settings certain ways! Ricky Cron Stardust On Tue, Jan 31, 2012 at 11:22 AM, Kadah wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I've ran it on my 2011 mini mac and it runs ok, but with really bad > color distortions, which are possibly due to it only have the cheap > Intel gfx chip. > > Building the viewer (at least with Firestorm) on Lion seems to also > work without any special setups other than xcode 4.whatever and cmake. > > On 1/31/2012 10:29 AM, Lee ponzu wrote: > > Would someone be willing to give a short summary of the status of > > using the viewer on Lion. > > > > For that matter, what is the status of Lion, period. OS Xista? Or > > is it ok? > > > > lee > > > > > > _______________________________________________ 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/ > > iQEcBAEBAgAGBQJPKD9/AAoJEIdLfPRu7qE2hZEIAKBoiKrJig2xWclN26IdSn0E > Mc2Xoqev8zeORCdur+vCkanPax+E+ewh07qNS33umQl2K04C23JR2jLc4gDHKHX8 > WryjhyOiTeqcyNNcN5LudWDESgTV79NU9cHOd+yPcHbS8qdLPIsnbFdtUiHeDfud > FbW9EErKnryVZd0JKxcPZne+/S6yeidUgUlskWcZjgOTIM5vLD7kfuUOxtwMHkKP > uUS8CkSUqdfTIMEPVWrvPQT/IDyX23v8XA3wkCUzY/fWH+i13eQQFD/Zp7MgTG+U > xnAtblvgcL0D+M4so4jUUXgb5RgpGUTIe6ddVJSErZHhEVDW2mqE8/W7e/vtsIk= > =cJ44 > -----END PGP SIGNATURE----- > _______________________________________________ > 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/20120131/e0aafead/attachment.htm