Re: [opensource-dev] Review Request: Change pre-login viewer display URL to prepare for new community information display
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/399/#review883 --- indra/newview/app_settings/settings.xml http://codereview.secondlife.com/r/399/#comment922 Setting the default value to something other than an empty string would override the selected grid's login page in LLGridManager::getGridInfo and LLGridManager::getLoginPage, which is probably not the desired result. In fact, I wonder why this setting is persistent at all. This should probably be renamed to CmdLineLoginPage, to be consistent with CmdLineLoginURI etc. - Thickbrick On July 16, 2011, 6:12 a.m., Oz Linden wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/399/ --- (Updated July 16, 2011, 6:12 a.m.) Review request for Viewer. Summary --- This changes the URL from which the upper part of the viewer window is loaded prior to login. At the moment, the new URL is internally redirected to the same content as before, but shortly it will have new community and activity information on what's going on in Second Life. This addresses bug storm-1510. http://jira.secondlife.com/browse/storm-1510 Diffs - indra/newview/app_settings/settings.xml c6f2f4af65e5 indra/newview/llviewernetwork.cpp c6f2f4af65e5 indra/newview/tests/llviewernetwork_test.cpp c6f2f4af65e5 Diff: http://codereview.secondlife.com/r/399/diff Testing --- Confirmed using the log file that the new URL is being requested. Changed the settings file locally to point to an internal prototype of the new screen and confirmed that it is displayed correctly. Thanks, Oz ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] A CALL FOR HHHEEELLLPPP
That error message is basically saying you can't assign to a const variable. Line 21 in your paste is reusing file_name, which is one of the method's arguments, and is const. You need a local variable which isn't const there. But, I don't think this makes sense otherwise. In what cases will from_id be null? I would guess you will have no way to recover a name in those cases. If that really happens, I think that's a server bug. I think a better approach is to look for the places that call this method, and make sure it is passed a username and not a legacy name or complete name as its first argument. You can convert a legacy name (but not a complete name!) to a username with the static method LLCacheName::buildUsername(), without needing to look it up in the name cache. I see these occurrences: llgiveinventory.cpp 314:LLIMModel::instance().logToFile(full_name, LLTrans::getString(SECOND_LIFE), im_session_id, LLTrans::getString(inventory_item_offered-im)); llimview.cpp 859:if (log2file) logToFile(session_id, from_name, from_id, utf8_text); 2471: LLIMModel::instance().logToFile(session_name, SYSTEM_FROM, LLUUID::null, message.getString()); llnotificationhandlerutil.cpp 278:LLIMModel::instance().logToFile(session_name, from, from_id, message); /* rant, please ignore... */ Considering the level of scrutiny trivial patches get here, how did the display names code got merged into the viewer in the first place? It made already messy code much more messy and inconsistent. Name-handling methods now rely on the caller knowing which of the different 4-5 kinds a name argument is expected to be (username, legacy (2 kinds of that?), complete, or display). Display and legacy names should have been banished to the lest steps of the chain, leaving them for display only, and everything else should have been converted to usernames, or preferably, a new type (not std::string.) Looks like there was some attempt to do that with LLAvatarName, but logic that depends on knowledge of internals of this class is all over the place. On Wednesday 16 March 2011 03:30:02 WolfPup Lowenhar wrote: First References: Jira : https://jira.secondlife.com/browse/STORM-941 Code Snippet : http://codepad.org/9cVTMJTD Now the problem: When I compile the code I get error C2678: binary '=' : no operator found which takes a left-hand operand of type 'const std::string' (or there is no acceptable conversion) in reference to line 21of the code snippet. I need to be able to force the user name in this case. Here is how this case can happen: PersonA dose not use Display Names or is on a non-Display Names viewer. PersonB dose use Display Names and also keeps logs of all chat, Group and P2P messages. PersonA offers PersonB and inventory item after PersonA has talked to PersonB in P2P conversation. PersonB checks their logs later to read about item again to discover there are now two logs for the same person one log is using the Legacy name and contains only the system message about the inventory offer while the other log that is named using the user name contains the conversation about that item. -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: storm-1038: crash in texture cache pruning
On Thursday 03 March 2011 22:12:54 Oz Linden wrote: http://jira.secondlife.com/browse/storm-1038 ... Diff: http://codereview.secondlife.com/r/172/diff Isn't this the same bug as the one patched by Aleric in VWR-24337? (I haven't followed the logic through, but it seems to trigger the same assert.) See: https://jira.secondlife.com/browse/VWR-24337 https://codereview.secondlife.com/r/93/ -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/ --- (Updated March 1, 2011, 8:28 a.m.) Review request for Viewer. Changes --- New diff, fixes the typo in the comment pointed out by Merov. Summary --- When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: // *FIX: retry upload after n seconds, asset server could be busy This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) This addresses bug VWR-24889. http://jira.secondlife.com/browse/VWR-24889 Diffs (updated) - indra/newview/llassetuploadresponders.h 767feb16f05f indra/newview/llassetuploadresponders.cpp 767feb16f05f indra/newview/lltexlayer.h 767feb16f05f indra/newview/lltexlayer.cpp 767feb16f05f Diff: http://codereview.secondlife.com/r/152/diff Testing --- Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for Baked full res texture upload for region name failed log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. Thanks, Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/ --- (Updated March 1, 2011, 8:58 a.m.) Review request for Viewer. Changes --- More comment spelling. Summary --- When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: // *FIX: retry upload after n seconds, asset server could be busy This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) This addresses bug VWR-24889. http://jira.secondlife.com/browse/VWR-24889 Diffs (updated) - indra/newview/llassetuploadresponders.h 767feb16f05f indra/newview/llassetuploadresponders.cpp 767feb16f05f indra/newview/lltexlayer.h 767feb16f05f indra/newview/lltexlayer.cpp 767feb16f05f Diff: http://codereview.secondlife.com/r/152/diff Testing --- Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for Baked full res texture upload for region name failed log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. Thanks, Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/ --- (Updated Feb. 19, 2011, 9:08 a.m.) Review request for Viewer. Summary (updated) --- When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: // *FIX: retry upload after n seconds, asset server could be busy This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) This addresses bug VWR-24889. http://jira.secondlife.com/browse/VWR-24889 Diffs (updated) - indra/newview/llassetuploadresponders.h 379da6bd50a5 indra/newview/llassetuploadresponders.cpp 379da6bd50a5 indra/newview/lltexlayer.h 379da6bd50a5 indra/newview/lltexlayer.cpp 379da6bd50a5 Diff: http://codereview.secondlife.com/r/152/diff Testing --- Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for Baked full res texture upload for region name failed log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. Thanks, Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.
On Feb. 17, 2011, 1:59 p.m., Boroondas Gupte wrote: Both comments are addressed in the new diff. - Thickbrick --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/#review375 --- On Feb. 19, 2011, 9:08 a.m., Thickbrick Sleaford wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/ --- (Updated Feb. 19, 2011, 9:08 a.m.) Review request for Viewer. Summary --- When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: // *FIX: retry upload after n seconds, asset server could be busy This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) This addresses bug VWR-24889. http://jira.secondlife.com/browse/VWR-24889 Diffs - indra/newview/llassetuploadresponders.h 379da6bd50a5 indra/newview/llassetuploadresponders.cpp 379da6bd50a5 indra/newview/lltexlayer.h 379da6bd50a5 indra/newview/lltexlayer.cpp 379da6bd50a5 Diff: http://codereview.secondlife.com/r/152/diff Testing --- Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for Baked full res texture upload for region name failed log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. Thanks, Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Hacking up to Visual Studio 2010 ...
On Friday 18 February 2011 15:50:11 Twisted Laws wrote: When I try running autobuild on Linux (Ubuntu) using this autobuild and viewer-autobuild2010, it immediately fails with a pathcheck error looking for boto. Looking at common.py (in /usr/local/lib/python2.6/dist-packages/autobuild/common.py) I see that the pathcheck lines in there contain lib/python2.5/ So I'm assuming that this doesn't work with Python 2.6 ?? I had a similar problem after I installed the autobuild package system-wide with the setup.py that came with it (./setup.py build sudo ./setup.py install). It turns out it does not work when installed system wide. As far as I could tell, the python version in the pre-packaged files' path don't matter. Also, it seems prone to leaving bad files /var/tmp/$USER/install.cache/ when bailing due to exceptions, and barfing when encountering those files on subsequent runs. -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Hacking up to Visual Studio 2010 ...
On Friday 18 February 2011 16:55:06 Twisted Laws wrote: Thanks i'm unclear of what i should do next then. (I primarily work in windows) Can i just delete the files in /usr/local/lib/python2.6/dist-packages/autobuild ? That's what I did (together with /usr/local/bin/autobuild). Maybe there's a proper way of removing packages installed with easy_install, but I couldn't figure it out... -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: When a bake texture upload fails, retry instead of giving up.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/ --- Review request for Viewer. Summary --- When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: // *FIX: retry upload after n seconds, asset server could be busy This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) This addresses bug VWR-24889. http://jira.secondlife.com/browse/VWR-24889 Diffs - indra/newview/llassetuploadresponders.h 379da6bd50a5 indra/newview/llassetuploadresponders.cpp 379da6bd50a5 indra/newview/lltexlayer.h 379da6bd50a5 indra/newview/lltexlayer.cpp 379da6bd50a5 Diff: http://codereview.secondlife.com/r/152/diff Testing --- Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for Baked full res texture upload for region name failed log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. Thanks, Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: VWR-24420: PNG images which specify background color lose alpha layer when imported.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/74/ --- Review request for Viewer. Summary --- Current code composites RGBA PNG images that contain a bKGD chunk down to RGB, discarding the alpha channel. This patch removes that code, since it contradicts purpose of the bKGD chunk as described in the PNG spec and as commonly used. This addresses bug VWR-24420. http://jira.secondlife.com/browse/VWR-24420 Diffs - doc/contributions.txt UNKNOWN indra/llimage/llpngwrapper.h UNKNOWN indra/llimage/llpngwrapper.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/74/diff Testing --- Tested uploading the 2 images attached to VWR-24420 with and without the patch. Before patch, bad alpha.png was uploaded as RGB, after patch, both images were uploaded as RGBA. Thanks, Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test)
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review13 --- indra/newview/llappviewer.cpp http://codereview.secondlife.com/r/2/#comment7 Somewhat tangential to this patch: this line is wrong. It should use gFrameIntervalSeconds, not gFarmeTimeSeconds. As it is, max_idle_time will always be clamped to 0.005. The comment is also wrong/outdated. It should be something like 50 ms/second, up to 5 ms/frame. - Thickbrick On 2010-12-01 19:57:24, Oz Linden wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/ --- (Updated 2010-12-01 19:57:24) Review request for Viewer. Summary --- This review is mostly a first test of reviewboard. I do have an esthetic dislike for the 'break' statement anywhere but as the end of a case, so I chose to change some instances of break usage that were not justified by any extreme need. This addresses bug storm-606. http://jira.secondlife.com/browse/storm-606 Diffs - indra/newview/llappviewer.cpp bf98b026bcb1 Diff: http://codereview.secondlife.com/r/2/diff Testing --- None at all... have not even compiled it yet. Thanks, Oz ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Draw Distance
On Sunday 22 August 2010 18:22:56 Lance Corrimal wrote: related line of thought: how much faster could the viewer be if every single of these do not change this ever settings was replaced with a #define in a central include file? or in other words, what is the cpu cycle penalty for a SavedSettings.getBOOL() and the others? Please, no #defines... You can cache the value of a settings and rely on callback magic to change the cached var when the setting has changed: #include llcontrol.h (or llviewercontrol.h in 1.x, with a slightly different constructor) static LLCachedControlbool cached_foo(gSavedSettings, SettingFoo); This way you can use cached_foo to get the value of the setting in methods that get called often, without doing a lookup in a big std::map. bye, LC -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Closing on SG2.0 : Releasing Snowglobe 2.0.2 (RC2)
On Thursday 29 July 2010 19:26:24 Ricky wrote: Ok, I don't yet fully understand the properties of the installer template Thickbrick added to the Snowglobe wiki page... :/ Could someone update it who does? (and maybe explain how to help maintain this. Or a link to somewhere that explains it! I'm used to regular wiki editing, but functions and variables in a wiki page are rather unusual...) Thanks, Ricky Cron Stardust I didn't create those templates, I just made copies of the 1.x ones for 2.x installers. I think Rob Linden wrote them originally. Those templates create the three platform links from the build number, and the versions numbers. There's an added complication that the trunk templates use another template for localization of the description and for the purpose of alternating between Test build (trunk) and Release Candidate. (at least I think that's the reason.) I think that the idea is that the Release template always points to a released build (i.e. 1.3.2 currently for 1.x). The trunk template should point to trunk most of the time, except for during the RC stages, after a release branch is branched, but before it is deemed released,. During that stage it should point to the RC builds. I updated the 2.x trunk and branch and 1.x trunk templates already. I hope Merov doesn't object. The relevant wiki pages for 2.x are: * https://wiki.secondlife.com/wiki/Template:Snowglobe_2-installers (which points to 2.0.2 (RC2). This is against the rule I wrote above, but we don't have a released 2.x build yet.) * https://wiki.secondlife.com/wiki/Template:Snowglobe_2-installers-trunk (which point to 2.1.0) * https://wiki.secondlife.com/wiki/Template:Snowglobe_2-installers-trunk/en And for 1.x: https://wiki.secondlife.com/wiki/Template:Snowglobe-installers (1.3.2, no change here) https://wiki.secondlife.com/wiki/Template:Snowglobe-installers-trunk (1.4.1 RC1, this is now tracking release candidates until we release 1.4) https://wiki.secondlife.com/wiki/Template:Snowglobe-installers-trunk/en I hope that clears things up (and didn't include false info...) I also put a mockup of my suggestion on how to clarify prettify the snowglobe download links a bit here: https://wiki.secondlife.com/wiki/User:Thickbrick_Sleaford/Sandbox -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Linux + QtWebKit + Flash 10.1.x = Crash
Hello all, It looks like recent (10.1) Flash versions can't work with any QtWebKit browser including the webkit plugin in Snowglobe 1.x and Viewer 2 on Linux. This is because those versions of Flash don't initialize gtk properly (Adobe assuming that the browser is gtk based, i.e. Firefox.) This results in the crash of the SLPlugin process when trying to show the login page, or any other web page (though some of the pages sometimes get half-rendered). There is a fix for this in upstream QtWebKit, but this would require rebuilding the prebuilt llqtwebkit packages. Until then, Linux users who are trying to stay safe have a problem, because Flash 10.0 is not getting security updates on Linux anymore, apparently (and the chances of Adobe fixing this are close to zero.) So I think we need to solve this as quickly as possible. Here are the relevant bugs: http://jira.secondlife.com/browse/SNOW-548 https://bugs.webkit.org/show_bug.cgi?id=40567 This is what Flash spits out on stdout before crashing: (process:2096): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to call g_type_init() (process:2096): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (process:2096): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Migrating open development focus to 2.x
On Friday 28 May 2010 00:50:55 Oz Linden (Scott Lawrence) wrote: Please respond to this thread with your favorite reasons not to move development to 2.x. We will review the list at the 6 June open source meeting with the goal of setting some priorities. Oz, I think open source developers will naturally spend most of their time working on the viewer they use most. And there are problems with 2.0 that for me are much more insurmountable than just changes to muscle memory: * Modal UI. Enough was said about this already. * Most important for me, I just can't read the fonts in 2.0 without straining. UI Widgets are too big and fonts are too small, for any UI size setting that leaves a bit of 3d-world visible. I guess I am in the minority here (having bad eyesight,) but I think this is a big minority group of existing and potential SL users that would simply write off 2.0 as unusable. Yes, there are improvements in 2.0 as well, but I can't enjoy them. On Friday 28 May 2010 15:45:14 Lance Corrimal wrote: ... backport the alpha layer / tattoo layer / inventory links / script info from about land into snowglobe 1.4... 50% of that are already done anyways, want a patch? Yes please! I wonder, can we flex the rule about contributor agreement for patches backporting code that was originally written by linden lab? -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] HTTP viewer map on non-Agni grids (SNOW-77)
Hello all, I attached a new patch (based on Geyeda Bechir's earlier patch) to SNOW-77. I think this answers Eddy Stryker's comments there regarding the Opensim side of things with my previous patch. The question that remains now is what do Lindens (Merov in particular) think about this: Is there something in the pipeline that will be incompatible with this? It's time we resolved this, as currently Snowglobe and Viewer 2.0 have an almost useless map on Aditi, and a completely useless map on Opensim grids. Patch: http://jira.secondlife.com/secure/attachment/39646/SNOW-77_map_url_cap.diff Relevant JIRAs: http://jira.secondlife.com/browse/SNOW-77 http://jira.secondlife.com/browse/VWR-17711 Quick summary of what that patch does: Once per region, fetches the LLSD map from the address given by the HTTPMapURLRequest capability, and uses the value of the the key mapurl as the base url for http map tiles. If there's no capability, it uses a debug setting which defaults to the SL/Agni map. Please review and discuss... -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Banning by client
I don't know if this store is (badly) detecting client versions/channels through the media plugins' user agent strings, or if it's just that I didn't move enough for their taste after teleporting. I went there with my test alt, using Snowglobe 2.0.0 () Apr 22 2010 00:11:09 (CommunityDeveloper) on linux, and was banned and ejected after a couple of minutes: [13:14] Second Life: You have been teleported home by the object 'zF RedZone v3.2.3' on the parcel 'Furniture and Prefabs @ The Loft II'. [13:14] zF RedZone v3.2.3: You have been removed for using copybot. On Saturday 01 May 2010 22:20:26 Glen Canaday wrote: That's me on the list. You go in Snowglobe V2? My partner was also there in Emerald and did not get banned - that's why I was asking about client-based ban (and hence why I even brought it up on this list, even though it's only on topic in a very cursory way). --GC -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP viewer map (was: Oh, the drama.)
See http://jira.secondlife.com/browse/SNOW-77 This has been stagnant for too long (incidentally, it was brought up at yesterday's Snowglobe meeting.) I think the way forward is standardizing this in a way that allows opensim to implement it, not going back to UDP, region-local map tiles. SNOW-77 has a patch attached that handles using a capability to find the base url for the map tiles, but still sticks to assumptions about the url structure. I added a comment there last December, and will repeat it here, that I think the grid should not just tell the viewer about the base url, but send a template to prevent depending on a rigid url structure. This looks like something RUSS can be used for, but that has a dire warning about security implications of using an untrusted format string: http://wiki.secondlife.com/wiki/Recursive_URL_Substitution_Syntax I don't know if this is a problem here (is it?), but I think we should find *some* way to prevent hard-coding the url structure in the viewer. On Friday 30 April 2010 14:00:43 Tateru Nino wrote: The most obvious solution - from where I'm sitting - is to abstract it, and provide different access methods underneath. The higher levels of the viewer application should neither know nor care just where the map tiles are coming from, beyond making an API call to fetch one. Later, one can look at a method by which a grid service might make certain representations as to where and how those tiles are located and to be fetched, but compartmentalizing the hard-wired knowledge (at this stage) seems to be the best option, presently. On 30/04/2010 8:20 PM, Lance Corrimal wrote: patching opensim... ...how do you patch the people who provide a service for free, to make them rent an expensive distributed storage provider for their map tiles? are you going to rent S3 yourself, for your own little local grid? -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Source of boost libraries
The boost packages are not in svn, but the urls for the packages are listed in install.xml, and they are downloaded and unpacked into the build tree by the build system. You only need to provide your own boost if you are doing a standalone build (which I assume you aren't, since you are on windows,) or using a version of VS for which there's no prebuilt boost packages (2005 only, I think.) On Friday 30 April 2010 18:51:19 Jonathan Welch wrote: I'm trying to compile Snowglobe 1.4 on Windows XP / VC 2005 Express Edition (aka VC80) and was told the boost libraries would be part of the svn, but apparently they are not. Can some kind soul please point me to where I can pick them up? -jonathan ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] test on SG2
On Tuesday 20 April 2010 20:55:57 Tayra Dagostino wrote: is there a way to: ... 2) enable/disable SLPlugin (totally, if audio and multimedia turned off one SLPlugin session lunched anyway) I think that one SLPlugin is the QtWebKit loaded at startup to show the login page. I don't know of any way to prevent this, short of deleting the plugins' .so files or editing skins/default/xui/en/mime_types_linux.xml to remove all the instances of media_plugin_webkit. -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Quiet amendments of TPV (again)
On Tuesday 20 April 2010 17:02:26 Joe Linden wrote: Boy, There was nothing quiet, or in the background about it, believe me. This update is the topic of conversation at the noon PDT brown bag I'm hosting today. The changes were pushed live ahead of the meeting, so there would be no question they are incorporated in to the TPV and TOS, both of which are effective on 4/30. I'll see those of you still interested in the subject at noon here: http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29 -- joe This is somewhat belated, but: Thank you Joe! The TPVp is still not ideal from my perspective, but it is now certainly something I think an open source community can work with. I still wish it would not force viewers to enforce DRM, specifically in cases where the user has an appropriate license from the creator that supersedes the DRM. But I guess this is pretty much a given when a user chooses to create their content in a grid that is very much DRM-centric. Hopefully the DRM will be extended soon to include an export ok flag, now that the TPVp made it a critical thing. Anyway, thanks for listening! -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] SG 1-4 artwork zip file corrupted. SNOW-604
On Friday 09 April 2010 20:45:41 Nicky Perian wrote: http://jira.secondlife.com/browse/SNOW-604?ticket=ST-1291-Du2hp64P1FjUKtaRa 4G1hKGawJEXOEadOKW-20 Could a Linden please take a look? Thanks Nicky The S3 urls in doc/asset_urls.txt give a 403 error (Access Denied): http://svn.secondlife.com/trac/linden/browser/projects/2009/snowglobe/trunk/doc/asset_urls.txt This looks like it's the same problem as with build log urls from sldev-commit messages, which we discussed yesterday at the open source meeting. Merov said he will be looking into it, IIRC. -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question related with rotation of object
On Wednesday 17 March 2010 17:06:27 Rustam Rakhimov wrote: Reason why I need it, I want to know what's rotation has an object, then I can rotate it back, But actually I want to calculate rotation of some point in 3D world, so that's why I decide learn how's rotations are going. There are a lot of things related with matrix, Quaternion class, LLVector3 class. Anyway I need that value, and I want to know where exactly these values are located. LLViewerObject inherits from LLPrimitive which inherits from LLXform. If you look at LLXform you can see it stores rotation as a quaternion, in mRotation. The various ways of getting and setting that rotation (matrix, Euler angles) all translate to/from LLQuaternion eventually. http://omvviewer.byteme.org.uk/snowglobe_1_x_doxygen/classLLViewerObject.html And last question is what does it means jira from your sentence which jira is relevant to this? http://jira.secondlife.com/ I hope this helps... -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
On Thursday 18 February 2010 17:57:52 Kent Quirk (Q Linden) wrote: This makes me sad. I've been trying to have an open discussion about some of the design issues in my office hours, specifically to understand the constraints and requirements of the community. But every office hour seems to be followed up by flames on this list and in other forums interpreting what was said in the worst possible way. I'm afraid the tone and direction of this discussion are making it impossible for us to talk about this project productively. Q I think this is a good point in this budding flamewar to bring this up: http://lwn.net/Articles/370157/ Josh Berkus' patented ten-step method on how to free a project of unwelcome community involvement. (A little) more seriously, if the current trend towards secrecy at LL is a result of 3rd party viewers based on LL code stealing mindshare, it should be pointed that the developers of those viewers chose that route mainly as a result of LLs past lack of involvement with open source contributors, and (again, past) opaque and SLOW process of patch submission. To move this to a more productive direction, can you give a summary of what Firefly is, for those of us who weren't at your office hour? -- Thickbrick ___ 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
