Re: [opensource-dev] Comments solicited -- distinguishing name vs message in chat
I've added similar functionality in firestorm last week. Names are colored and have their own preference color. I think the next step forward for plaintext chat is to fix the vertical line spacing issue that still appears to be neglected. On Sun, Dec 5, 2010 at 3:53 PM, Kitty wrote: > It's https://jira.secondlife.com/browse/STORM-578 that needs to be > reverted/redone (for chat toasts). > > There's https://jira.secondlife.com/browse/STORM-579 as well (for plain > text > chat history) and there seems to be a partial (un)fix at > https://bitbucket.org/seth_productengine/storm-579/changeset/bdc0809e25a0 > but it hasn't been pulled into viewer-development/viewer-beta yet I think. > > Kitty > > -Original Message- > From: opensource-dev-boun...@lists.secondlife.com > [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Jonathan > Welch > Sent: zondag 5 december 2010 16:01 > To: opensource-dev@lists.secondlife.com > Subject: [opensource-dev] Comments solicited -- distinguishing name vs > message in chat > > Hey folks, > > This one just came to my attention -- a little change to be able to > distinguish where the name in chat leaves off and where the message > begins. With Display Names now active it's no longer easy to figure > this out. > > Please take a look at this and put in a little comment on what you think. > > https://jira.secondlife.com/browse/VWR-24076 > > -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 > ___ 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] building on Mac OS X 10.6 is giving me multiple headaches... anyone able to help?
Here's some example lines I use for building firestorm on macosx. You'll want to change the variables,strings,and optimizations to fit Dolphin. I hope this helps. A key takeaway is to use "xcodebuild" for command line builds and not make. ./develop.py -t $BTYPE configure -DPACKAGE:BOOL=ON -DVIEWER_CHANNEL:STRING=Firestorm-$CHANNEL -DVIEWER_LOGIN_CHANNEL:STRING=Firestorm-$CHANNEL # LL build wants this directory to exist, but doesn't make it itself. mkdir -p ./build-darwin-i386/newview/Release/Firestorm.app xcodebuild -project build-darwin-i386/SecondLife.xcodeproj \ -alltargets -configuration $BTYPE GCC_VERSION=4.2 \ -sdk macosx10.5 GCC_OPTIMIZATION_LEVEL=3 ARCHS=i386 \ GCC_ENABLE_SSE3_EXTENSIONS=YES On Mon, Jan 24, 2011 at 4:29 AM, Lance Corrimal wrote: > Hi there, > > I'm trying to build 2.4.x based on Mac OS X and I'm having several problems > with that... > > > - I'm pretty sure that I've located every place in the source that defines > the > name of the resulting .app and changed them to read "Dolphin Viewer 2.app" > instead of "Second Life.app" and yet, the build process still tries to > install > some of the resulting stuff in Second Life.app and some in Dolphin Viewer > 2.app, and at that point only Second Life.app exists so the build fails. > > -how do i configure the build on mac os to use GCC 4.0 instead of 4.2 If i > want to build using unix makefiles instead of the xcode gui? > > - how do i configure the build process to builds against the 10.5 SDK > instead > of the 10.6 SDK when using unix makefiles instead of xcode gui? > > > > anyone got hints for me? > > > > bye, > LC > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Need Clarification on interfacing with web-based UI elements
This is an open question I've tried to ask at a few different linden office hours, but haven't yet received a response one way or the other. There's a couple different viewer UI elements now in the pipeline that are effectively full web pages- the search window, and now the profile window. It seems like there is more to come. As a community developer interested in customizing that user interface for particular audiences, can LL clarify a best practice for working with these elements? >From a glance it appears that the presentation info and data model are commingled, complicating client-side customization of the presentation. It may be possible to scrape out data, but unmanaged minor server-side adjustments to the presentation page may break scraping activity suddenly without warning. For an example of this, one can look at the number of times LSL scripts which display profile pictures by scraping UUID's from web lookups have been broken over the last few years. I'm hoping that LL can clarify which interface a community developer can use to request and retreive this web-based data, particularly for avatar profile page information, that will not be prone to casual breakage after a third party viewer has been released. Thanks, and my apologies if the answer for this is someplace obvious I've overlooked. ___ 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] Need Clarification on interfacing with web-based UI elements
I'm concerned that I haven't received a response. I've already asked this question a few times at office hours for Lindens involved in development, and now here. Even if the answer is "LL will not support a a stable API to web services" at least it is some kind of answer. "LL will continue to provide existing non-web APIs for this same data for the indefinite future" may be an option as well, but I haven't heard this either. "We're working on this, check back in a month" is also an answer that would be welcomed over silence. As a developer I'm looking for a documentation, examples, and best practice methodology for how to customize the presentation of data LL provides via web pages, such as web-based profiles. Specifically I'm looking for an interface to extract at a minimum: - Profile text - "Real World" text - a user's entered web URL - birthdate info - payment status - partner status & partner - "picks" data - profile picture at its original resolution - "real world" profile picture at its original resolution >From the current web-based profile pages and viewer implementations I've seen in 2.6, these fields aren't tagged with metadata in a way that would make them easy and reliable to extract, or provided in a format separate from the heavyweight presentation layer. Even if this data was tagged in some way, I'm looking for assurances that it would be a protected, stable interface, not likely to be broken by casual changes without warning. Can anyone provide insight on this topic? Thanks, -A ___ 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] Widespread, Reproducible Profile Total Data Loss - Tolerated for multiple releases, why?
The subject says it all. If you were not aware, editing profile data using the web profile interface can result in whatever section of data that you edited being completely erased, wiped out, 8-24hrs later. This issue was first reported back in 2.5.0. I was bit by it myself. I updated my "Real World" info using the web profile UI on the official 2.5 viewer, and the next day my real world bio text was completely empty. I chalked this up to an unstable new feature. In the 2.6 official viewer, I edited my RL photo, RL bio, SL photo, SL bio. All looked fine. The next day when I logged in, all of these fields were completely empty. Apparently this is a widely known problem. When I started asking around, many people told me that editing your web profile results in total data loss of the edited area. I searched around for a JIRA. There is one: https://jira.secondlife.com/browse/WEB-3750 It's been open since February with no fix. I opened up a support ticket, hoping to raise awareness that there's reproducible, wide impact data loss problem. Thank you for contacting Linden Lab support! I'm sorry to hear that you are having > issues with your profile. I know how frustrating that must be for you. > Unfortunately > there is no way for me to rollback the profile, nor block profile editing. > > This is more than likely a bug in the new viewer release that you should > report in > the jirra. > > > > It appears that support is unable to do the basic task of opening a JIRA ticket themselves, much less recognizing a scenario that warrants escalation. As a last plea I'm posting here for the purposes of raising awareness. I find it hard to believe that this kind of ongoing data loss issue in a very public-facing feature would be tolerated if it were known. The impact to the platform, especially for new user retention and satisfaction, I would think would be too high. ___ 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] Minimum draw distance
On Mon, Jun 6, 2011 at 12:37 PM, Jonathan Welch wrote: > ... > If you have an opinion of why it should be lowered from what it is > now, 64, please reply to this message with your reasoning. > > I'd say it is common for me to lower draw distance to 32, for densely populated events where the rendering of avatars alone, even with imposters, imposes a severe rendering burden and interferes with smooth behavior of stage effects, event effects, animations, etc. Less common but still about 1/week, I may have to reduce draw distance to zero briefly as a way to force texture refetches at a congested event. Typically this happens when an annoying threshhold of avatars I'm standing next to have seemingly permanently grey textures, because for whatever reason, their texture fetches failed when I initially arrived, perhaps due to poor bandwidth management/rescheduling. Despite the traffic that briefly reducing draw distance to zero may cause, in is highly reliable at filling on all previously grey textures that despite 10's of minutes of waiting, will not otherwise load. ___ 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] An SL appliance...
In the past it has been possible to do accelerated openGL-over-X11 over a network with particular drivers, specifically some versions of the linux NVidia drivers. Still, it's quite exotic, limited, and probably would not result in the effect the original poster intended. On Thu, Jul 14, 2011 at 11:06 AM, Lance Corrimal wrote: > Am Do, 14.07.2011, 16:56 schrieb Lee ponzu: > > Does the Linux viewer use X? > > yes. > > > If you DISPLAY SL on another computer running > > an XServer, does it behave OK. > > no. no openGL app does. > > > > If so, could you assemble a small Linux host with a high end GPU and then > > DISPLAY SL on a different computer on the same local network? > > no. see above. > > bye, > LC > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp
The underlying code segment here needs a rewrite. This is one of the rare cases where GCC is actually complaining for a very valid reason. On Fri, Sep 2, 2011 at 11:35 AM, Mysty Saunders wrote: > Ubuntu 32 GCC 4.4 > > Any idea's y'all. Im pretty much clueless about programming but with dumb > newbie luck I was able to compile if I changed > > verticesp->mV[3] = 0.f; > to > verticesp->mV[2] = 0.f; > > Compiled but particles looked bad (duh..) > > Any help would be great :) > > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp: In > member function ‘virtual void LLVOPartGroup::getGeometry(S32, > LLStrider&, LLStrider&, LLStrider&, > LLStrider&, LLStrider&)’: > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:332: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:334: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:336: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:338: > error: array subscript is above array bounds > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer UI mode merge
Thanks for sharing Oz, Although I like the general direction of the improvements and believe they have good potential, I feel the obligation to point out to your own presentation with Esbee and Qarl two years ago coming off of the difficult Viewer 2 rollout, where the three of you stood up before everyone at SLCC and told us that LL wasn't going drop these large UI rewrites on the community as surprises. I'm glad it's there, I think it has potential, but the communication and coordination with the greater development community was poor at best, and at worst, contrary to what LL directly communicated. It would perhaps have been better to have these as project viewers well in advance of a sweeping merge. On Tue, Oct 18, 2011 at 6:04 PM, Oz Linden (Scott Lawrence) < o...@lindenlab.com> wrote: > Today the Viewer UI mode merge project is coming to viewer-development. > This project combines basic and advanced modes and brings an updated, more > flexible workspace to the Viewer. > > At the time of integration with viewer-development today, there are still a > number of outstanding issues the team is working on to prepare for beta and > release. So if you're running the development Viewer, please be aware that > some things may not yet work correctly. Here's a quick rundown of some of > the known issues: > > > - The Viewer floater camera views and presets do not work. > - The Nearby Voice panel does not update to a new call or from > nearby voice info once opened. > - Viewer crashes when updating UI size in preferences. > - The Speak button is activated when dragging and dropping between > toolbars and/or moving back to the Tool Box. > - Viewer crash when moving the speak button from one toolbar to > another when there is an active call request. > - Teleport history doesn't display visited locations. > - Viewer crash when double-clicking the mini-map in People > Nearby. > - Notification and conversation chiclets overlap. > - WASD controls don't move avatar while the Move floater is in > focus. > - Closing voice controls while a group or p2p call also closes the > group call/IM window > - Viewer crash after teleport > - Hitting back in the 'Create Group' panel or 'Blocked' panel > requires multiple clicks for action to occur. > > The team is busily addressing these issues and will be updating as we > plan the next couple of beta releases. If you see other issues, please > report them in Jira as always and we'll make sure they are routed > appropriately. > > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1793 Viewer needs to treat all mini-map altitudes above 1020 m as the same height
--- 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 > > ___ 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-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
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. ___ 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] OSX 10.8 / Xcode 4.5 compile support (wasReview Request: patch potential memory leak in llgl.h)
On Wed, Sep 19, 2012 at 11:58 AM, gistya eusebio wrote: > > I did compile this with OS X 10.8 as a build target successfully. > I couldn't help but notice this blurb at the end. Did you need to make any adjustments to base viewer-dev dependent packages / cmake /. other in order to build with XCode 4.5.x? ___ 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] Open Viewer Development Announcement
On Mon, Aug 16, 2010 at 11:56 AM, Oz Linden (Scott Lawrence) o...@lindenlab.com> wrote: > I've said this before, and I'll repeat it again here: > > Don't waste everyones time suggesting that we throw away Viewer 2, or > that > we revert the UI to Viewer 1. It is absolutely not going to happen, and > any suggestion to that effect will be ignored.> Casting the debate as whether or not 1.0 is better may not be productive, but recognizing that 2.0's UI is major barrier to adoption is essential. Perhaps a transparent task group could be formed to propose, map level of effort, and prioritize UI improvements. It might be a test of LL's stated community commitment. ___ 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] Open Viewer Development Announcement
I realize that there's pros and cons to this UI selection vs box popups. However I don't believe the choice is at all cut and dry. When I stopped using the pie menu (because it doesn't exist in viewer 2.x) I discovered all sorts of navigation difficulties that where previously unknown. - The box dropdown requires the user to have greater precision and care when making selections - The pie menu supported muscle-memory for choices better - The pie menu does a better job of hiding the rarely used options and conversely making the most popular options highly visible. - The pie menu obscured less of the screen when it was active - The pie menu as implemented does a better job of cloaking/disabling unusable choices, the box menu greys them out but they are still visually harder to navigate. - The pie menu always pops up directly under the cursor, the box menu pops up to an indeterminent side depending on position. This is more predictable behavior and requires less mouse movement. - There's a large number of users already familiar with the pie menu. - After using both methods for a while, the pie menu is my personal preference by a fair margin. I looked at the XUI API docs to see what would be involved in bringing them back. I was concerned to see that the pie menu status lists as "deprecated". I believe this should be re-examined and hopefully be in the backlog for debate. ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
As someone who was using the Emerald viewer at the time this was going
on, I researched this subject with some concern.
It doesn't matter who the target was at all, whether he is a good guy
or a bad guy, it's not of consequence. ModularSystems is responsible
for using my login process to send a sizeable body of undisclosed,
irrelevant traffic to harass someone. This isn't just 'embarassing',
it's unacceptable from inception to execution.
This simply adds to the ongoing pattern of Third Party Viewer Policy
violations already exposed regarding ModularSystems builds of Emerald
that speak to a culture of irresponsibility in the persons that
control the ModularSystems site. I am not lawyer, but just looking at
the third party viewer policy I can pick out a number of criteria that
might not be met.
TPVP 2.d : "You must not launch Denial of Service ("DoS") attacks,
engage in griefing, or distribute other functionality that Linden Lab
considers harmful or disruptive to Second Life or the Second Life
community. " This appears to be violated by code in the viewer's
login page
http://webcache.googleusercontent.com/search?q=cache:jD_B973EpVUJ:modularsystems.sl/app/login/+http://modularsystems.sl/app/login/
TPVP 1.C.iii There must be disclosure of "Any surprising or unexpected
functionality, including any limitations on features and functionality
generally available to Second Life users through Linden Lab's
viewers.". The leakage of pathnames in by emdku code does not appear
to have been disclosed, despite it being an internal topic of
discussion months earlier. The leakage of any information, regardless
of how innocent, to other avatars via the path of baked textures
hasn't been disclosed even now to my knowledge.
TPVP 3.B.iii Distribution must adhere to the terms of the GPL 2.0.
ModularSystems may not be distributing emkdu in a way that qualifies
it as a separate work under the GPL. It's transparently distributed to
the user's system without notification. No alternatives (such as
llkdu, openjpeg) or opt-out options are presented, and the library is
linked by the emerald runtime. Since the emkdu source is not
distributed, the distribution of the viewer may be in violation.
Compare this with other viewers such as CoolViewer and Imprudence with
specifically deal with distribution of closed source binaries as a
completely separate, user-initiated, optional process to fullfill GPL
2.0 compliance.
TPVP 6.3 : "Your Second Life accounts must be in good standing, must
not be suspended, and must not have been permanently banned or
terminated". The operators of the Modular Systems website possess
accounts that have been permanently banned or terminated and readily
acknowledge this.
===
Beyond the above, the way in which these issues were addressed are
concerning. The emdku issue was only addressed because someone from
outside ModularSystems exposed it. The DDoS came to light because it
was exposed from the outside. There may not be a history of
ModularSystems successfully policing themselves. It appears that those
who try end up leaving the project.
External communication similarly does not inspire confidence. On the
ModularSystem web page, there is no mention of emkdu and how in
released builds it leaked information. Neither is there a patch or new
download listed. The tone of communication is slanted to draw diminish
critics, instead of clearly articulate information for users to make
an informed decision. As a user I had to read other blogs and talk to
developer peers personally to find out what was really happening.
ModularSystems didn't tell me.
On this thread an Emerald developer stated that many of these issues
stem from the people who control ModularSystems being less than
responsible and embarrassing the team. One has to ask if this is the
case, why not vote "No Confidence" and move your website and your
builds to someplace with greater credibility, and change LL's official
point of contact for Emerald from "ModularSystems" to something else?
___
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 Mon, Aug 23, 2010 at 3:22 PM, Erik Anderson wrote: > > Shouldn't the SL client be able to figure out what a good draw distance > would be? Maybe have it start autodetecting draw distance based on rolling > average number of polygons visible or something? > It's not that simple, there are are a number of use cases that call for different draw distances. If you're playing with some kinds of vehicles, you may have the best experience with a medium-low draw distance to keep framerates high but still let you see where you're going. If you're in the audience of a high-traffic event, you may have the best experience with an extremely low draw distance. If you're taking photographs, particularly of scenery, you will turn draw distance up very high and not be so concerned with framerates. If you're trying to keep an eye on a particular spot on a sim X distance from you, you'll want to use a draw distance of at least X. If you're in an indoor area with confined spaces, a very small draw distance may be optimal. If you're trying to get 'the lay of the land' for how a region is spread out, a higher draw distance may be necessary so you can see buildings and landscaping together. This is just off the top of my head. Many of these depend on user's preference for framerate vs scene details at a moment in time, and can't be reliably guessed purely from inworld behavior (although there are hints, I will grant). I find myself frequently adjusting draw distance in practice, mainly for photographcs, music events, and some types of vehicle use. Viewers that have some quick UI for for this are far more handy than the clicks involved in navigating to custom graphics preferences. ___ 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] Encrypted chat & third-party servers
Some of the TPVs implement the OTR protocol for encrypted messaging: http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html This does not involve 3rd party servers, or disclose information. In fact it's designed not to disclose anything, ___ 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] Openjpeg/KDU the cold hard metrics
Is it possible for you to release your test harness for these comparisons, including the texture set? I noticed there isn't data for linux or mac platforms, which I am curious about. My eyeball tells me KDU is more optimized for windows than other platforms, but I'd like to test this empirically, as well as see how well my hardware compares to these results using the same test. ___ 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
