Oz Linden

I must have misunderstood your question before, but what you are describing is the intended functionality.... The entries in the Sun menus are shortcuts to the Second Life default settings for those four fixed skys - they are not controls to change the time of day in the region. If you want to manually switch between fixed skys that you have in your presets, then you must use the World>Environment Editor>Environment Settings dialog. Sorry for the misunderstanding.

Create a Sky preset for each of your key times (9, 12, 3); save each of those settings with its own name (my-9, my-12, my-3). Create a Day Cycle preset. In that preset, insert a marker at each of those times and set each marker to the appropriate sky preset. Save that Day Cycle preset with its own name (my-day). Open the Environment editor, select 'Use Custom Settings', and select your saved day (my-day).

See sticky post in this forum on this topic

The 'time' in the SL 4-hour day can be read in LSL with llGetSunDirection. Making this at least approximately agree with the sun position in the SL sky can be done in the new environment settings controls: the sun position in a sky setting is set using a time of day, so if that position matches the time in the day cycle that the setting is used, the time and the sun will be in rough agreement. These new controls can be used now in the Windlight Region Settings Project Viewer and will be in the 2.8.0 Beta

You can now download a Project Viewer that allows you to set the Environment Settings for your regions, and any user entering the region will see the settings you set (for now, only if they are also running the project viewer). We've revamped the interface for editing environment settings as part of this feature, and are looking for your feedback on it here. See http://community.secondlife.com/t5/Land/This-Project-Viewer-Lets-Landowners-Control-Environment-Settings/ba-p/925883

If it is that Mac problem (you didn't say whether or not you were on a Mac), we believe it is fixed in the current Beta viewer; try that...

prim attachments won't move, but a tattoo layer will...

Enhanced Avatar Physics

https://jira.secondlife.com/browse/STORM-1100 tracks making a bunch of updates to the GPU recognition in the viewer.  Many thanks to the several people who have been checking and contributing updated entries. A test viewer for this issue can be download from the wiki at https://wiki.secondlife.com/wiki/Downloading_test_builds#Developer_Builds Note: this is a developer test viewer; it may well not be as stable as released viewers.  It will not automatically update the way released viewers do. If you have been having trouble with your GPU being recognized or you believe it has been incorrectly classified, then please download that viewer and report by adding a comment STORM-1100 You can find relevant log entries in your SecondLife.log file by searching for 'GPU'.

Known problem for which we have a fix - it will be in the next update. https://jira.secondlife.com/browse/SH-1319

It's unlikely that anyone can help unless you provide quite a bit more information. For example, you didn't say what viewer you're running or what version it is, where you were or what you were doing when you crash, etc. A better place to report problems like this is the Jira, but read the advice on how to report a bug https://wiki.secondlife.com/wiki/Issue_tracker and make sure that you attach the log files (there's a link there to how to find them).

This is not the right place to report a crash. Go follow the steps at https://wiki.secondlife.com/wiki/Bug_Tracker#Steps_to_create_a_good_report Make sure you attach a log file to your report (there is a link there for how to find it on your system).

The same goes with Viewer 2, but Linden Lab insists on this being the standard Viewer, and probably the mandatory one in a short time. Let me say this as clearly and succinctly as possible: Linden Lab has no plans to make any single viewer (2 or any other) mandatory. We don't have any plans to make any such plans.

What's really scary about this thread not only for Second Life but real life is that two major coder Lindens, Oz and Yoz, have come on to soothingly explain why we can't have democracy, citing the usual code-constrained geek arguments. Suddenly, you come up with this idea that "the votes aren't democractic enough and don't include enough of the user base" to claim that as your reason for making less democracy. We didn't say that we removed them because they were not democratic - we said that we removed them because having them was not useful. I note that in the poll you posted on the subject, you gave 6 possilble answers rather than just "yes" or "abstain". Those are the two choices one has with Jira voting. It isn't surprising to me that you chose to offer more granularity than that - it makes the results more interesting and useful. In any event, who said that product decisions about Second Life should be democratic? Democrocy is fine in its place - I'm a huge fan of New England Town Meeting style government for small civic groups, for example, but that doesn't mean that it's the only way to make decisions, or that it's the best way in every circumstance. Linden Lab has many stakeholders to consider in each of its product decisions, emphatically including our customers; but even our customers don't all have the same interests, and there are other stakeholders and many considerations in any product decision. We have to listen to as many perspectives as we can (which is what this entire initiative is about), gather the wisest heads we can find, and make the best decision we can think of. Being human, we will on occasion not make a perfect decision the first time, so we'll have to keep on listening and sometimes revise our thinking. It helps that process if those giving us feedback can be more nuanced than a yes/abstain bit. It also helps if they discuss the actual issue in a civil and constructive way rather than competing to see who can come up with the most insidious interpretation of our motives, or the most colorful flame. We're making an effort to improve how we listen in hopes that you, our customers and our fellow Second Life residents, will engage in a positive way.

One thing I've been meaning to ask / suggest regarding User Groups: It would be great if we had an easy way to submit agenda suggestions for particular User Groups. I know that this can often be achieved at the meeting itself (i.e. suggesting an agenda at the end for the next meeting). However, why waste time putting together an agenda at the meeting itself if agenda items could be pulled together in advance? Most of the user groups do have a way for you to do that ... if nothing else, you can always contact the Linden responsible for the meeting. For example, my twice-weekly Open Development User Group agenda is on a wiki page you can edit.

Why doesn't Linden Labs pay attention to JIRA voting currently? Why is removing our ability to vote the solution that was chosen? Will we be able to shut off the spammy emails that "watching" a JIRA issue entails? I believe that you really are sincere about trying to improve communication. Thanks for giving us the benefit of the doubt on that... :-) It is perhaps slightly overstating things to say that we don't pay attention; we have certainly looked at the vote numbers on issues and at least some of the time taken them into consideration, but there are many factors that make Jira vote counts a poor quality measure of broad customer sentiment. After all, consider that several hundred votes is a high number as jira votes go, but miniscule compared to almost any subset of the customer base you choose. Combine that with the lack of negative votes, and you're left with a mechanism for making real-world business tradeoffs that's essentially a yes-or-abstain input - we probably would not serve our customers well by making it a dominant factor. We didn't want to develop a new solution... we'd rather focus on making Second Life better than on making Jira better, so we decided to choose from the alternatives it already has. Yes, using Watch gets you emails from all the people who write comments, and some of those comments will probably be pretty low value flames. Some will also be updates on what is happening with the issue. Jira does not have a separate control for turning those off (see previous comment about not spending our time working on Jira). I hope that people will recognize how little value those have and reduce how often they are posted, but we'll see. We will be reading them (whatever you may think, we've been reading them right along). I've got a pretty long watch list, myself. My own feeling is that the fact that watching means signing up for the emails will cause people (as someone noted earlier) to make a concious choice to only watch the ones that they think really matter one way or the other. That means that we Lindens can treat the number of watchers as a better guage of how much people care than we ever could with votes.

There is a flaw in the logic of what you have been doing and what you propose to continue doing. You are assuming that a 'Watch' is a vote in favour. What about the people who hate the idea, and are watching to keep an eye out for arguments in favour that they would come in an speak against? That's not quite right... we'll use "Watching" as a guage of interest, not of support. That's one of the flaws in the Jira voting system that makes it hard to really use to make our choices: you can only vote for something, but not against it. In order to understand why people are interested, we'll read the comments in the issue, and everyone watching will get them too. It's no accident that this will put a premium on thoughtful commentary and will, we hope, provide some disincentive to just flame.

Since you are removing voting in JIRA (we kinda suspected you did not use it anyway, hehe), would it be possible for to publish a flowchart on how product improvements/requests are handled, and what stages they move through so we better can understand the process? The Snowstorm team, which does Viewer work and integrates work both by other Linden teams and open source contributions has a detailed flowchart on the wiki of how issues move through the change process. That's the workflow for the STORM project, so there's an implied step not show in which the VWR issues are triaged and moved to that flowchart...

As part of launching our new more open viewer development process, we changed the open source license for the new viewer code base from the GPL with an exception to allow use with certain other open source licenses (the "FLOSS Exception") to the LGPL. Some people have been asking about what this change means, and what our intentions are in making it. In particular, the LGPL requires that the code first be compiled into a library and then may be used in an application. Since the open source we make available does not directly provide for building this way, some people have speculated that the new license may actually be a barrier to other viewer developers. I'll try to answer this as clearly as I can. At Linden Lab, our intent is to enable the development of third party viewers and the improvement of our own viewer through mutual sharing of the requisite common technology. We think that LGPL is a better license to accomplish that sharing. Even though it was originally written to apply only to libraries, there is significant room for interpretation when using it. Our interpretation is this: modifying the build procedures provided in the source code to produce a library containing a subset of the licensed code is a minor programming exercise. The result of linking that library (which may be either a static library or a shared one, and either is allowed) with whatever other code is used to build a viewer is again a minor problem. The results are essentially indistinguishable from those in which the developer just modified the build procedures in place to produce an executable application. Essentially, the details of the linkage procedures used are a matter of packaging and have no end user effect. In practical programming terms, a library is just a convenient package - the requirement in the LGPL is like requiring that a grocery store sell a product only if it is first placed into a shopping cart while inside the store. Essentially a library is just that - a shopping cart full of individually compiled modules, so there's no real difference between using a library and just using the modules separately (one could build a library containing exactly one module, or build an application that had only one module and one library). It is our intent that developers be able to use the components that we have licensed under the LGPL to produce viewer applications, regardless of the linkage procedures used, so long as they make available any changes to those components as specified in the license.