Re: [opensource-dev] Fixing the 2.0 chat bar focus problem?
On Tue, Mar 16, 2010 at 2:42 PM, Argent Stonecutter wrote: > OK, here's a design problem in the new viewer that maybe can be > figured out here. > > From the Jira, I missed this response to one of my comments, some > time ago. Apologies, I forgot to "watch" the item: > > From Q Linden: >> Argent: the focus problem differs this time because the chat bar is >> always present; we have no mechanism to make it go away, so if we >> always gave it focus it would block normal keyboard use. Personally, >> I'm an AWSD movement person, so I actually find this works really >> well for me. It's not quite as obviously wrong as you seem to think. >> However, I understand the use case and we'll talk about it internally. > > This is exactly the same problem that we had the last two times. This > is exactly the same discussion we had the last two times. There are > many many people who never use any of the keyboard accelerators in SL, > and always have the chat bar up and in focus. The chat bar focus NEVER > goes away. For us, normal keyboard use does not involve anything the > chat bar blocks. Q is right, this is a different scenario than in the past, because the chat bar is now always visible. In Viewer 2.0, having the chat bar gain focus by default would be totally incompatible with the AWSD movement keys and all the other single letter hotkeys. (I observed that the following keys are used in Viewer 2.0: ACDEFGHMSW. B was used in 1.XX, but that shortcut changed to Ctrl+B in 2.0.) That said, I agree it's an important usability issue that should be addressed. > So, how could this be fixed in the 2.0 viewer without causing > discombobulation? > > An option "chat bar is the default focus"? Yes, I think such an option would be the best solution. That is assuming the Lindens are not planning to (or willing to) make the chat bar hide when not in use, like it did in 1.XX. If they are, then I would say restoring the old behavior from 1.XX is a better solution. > What would that actually break? As I mentioned above, enabling such an option would make it impossible to use any of the single letter hotkeys. If we can think of a good way to indicate to the user that those hotkeys would be (effectively) disabled by enabling the proposed option, then I don't see any reason not to implement it. Any ideas? - Jacek ___ 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] oh give me a break
This thread is approaching 100 emails in size after 3 days, and of those hundred perhaps a dozen have been even vaguely on topic. I would like to gently remind everyone that this mailing list is not an appropriate venue to discuss the merits or nonmerits of DRM. - Jacek ___ 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] Off-Topic Emails
On Wed, Mar 17, 2010 at 8:13 AM, Jonathan Irvin wrote: > * I'm probably going to get flamed for this * > > Egos aside, folks. > > I rely on the scripting, open-source, and sl-beta mailing lists to interact > with peers on technical topics related to the mailing list I'm subscribed > to. This is a great platform for networking as well as learning about new > ways to do things and even interact with Linden Labs. One thing I love is > hearing all the different ways to accomplish things and hearing the new > things the Lindens are throwing out into the wild. > > That being said... > > Lately, I've seen many of you light your keyboards on fire with the things > said on the opensource mailing list. > Either you are hating on LL or you are hating on people that don't agree > with you. > In any case, even with gmail, you are inflating my mailbox & wasting > bandwidth with your opinions. > Calm down, there are better things in life to be concerned about right now. > > I *assume* that we are all adults here so I'd expect you all to act > professionally. Yes, I said professionally. > Believe it or not, whether you are using your RL name or SL name, you are a > professional on some level or another. > > You represent yourself. You represent Second Life including Linden Labs. > Just being a resident means you are apart of it all...and all that comes > with it. > > So, and I believe I speak for all on this: > > Be professional and courteous. > Think positive. > Don't blame others for your problems. > Don't blame Linden Labs, Lindens, the SL Client for XYZ. > If you think something should be fixed, take initiative to fix it. > Get people involved, network, develop, etc. > If your idea gets rejected, take your feedback responsibly. Rethink it, if > possible, or put it on the backburner for later. > Don't lash out because others don't feel the same way about your idea. > If you don't someone's way of thinking, provide counter-points as needed, > but don't lash out because your ego was hurt. > If you can't be professional or LL or SL has you at your wits end, just > uninstall your client, leave the mailing list, and save us all bandwidth and > time. > > I'm not trying to offend any one and if you are offended by what was said, > please close the email. > Just to save you some time, if you need to vent, vent to a blog, facebook, > twitter, etc. Venting here to me will just fall on deaf ears and you will > be wasting your time making a point in the first place. > > While this email may not fix the off-topic posts, hopefully it will remind > everyone that we are in a professional environment and it does behoove us to > act accordingly. > > Otherwise, we'll never get anywhere. Personally, I can see why LL doesn't > want to work with us. Think about what they have to deal with! > > That's my L$2. > > -JI > Very true, and very well said. I'm tired of the speculation, accusation, and hostility that is routinely expressed on this list. Much of the tone and behavior lately has actually made me feel embarrassed to be a part of this community. - Jacek ___ 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] Snowglobe Mecurial Repository
On Fri, Mar 19, 2010 at 1:13 PM, Carlo Wood wrote: > Actually, I think I understand why. > > LL is using hg internally, and has been for a while. > They just pushed things out as svn for public access, but that process > caused all the meta data to be lost and had to be done manually, and > therefore only sometimes in big large chunks. > > It is for the benefit of snowglobe that commits to the internal > repository are available with meta data and as the original change sets, > once they are merged with the public repository. > > With hg this is possible: just push the changeset to the "public > hg repository", but only if that public repository run hg itself. > > On top of that, merging branches is much easier (according to > http://hginit.com/00.html), that holds for merging changes from internal > into snowglobe but also for TPV's assuming they switch to hg as well. > It should become much easier for us and for others using hg to merge > 'upstream' changes with the ever growning set of local patches and > extensions. Yep, I would guess those are all some of LL's reasons for switching away from SVN. Also, speaking from my experience using SVN for several years before switching to Git (which is close enough to Hg), using a distributed version control system just changes the way you work, and the way you think about version control and software development. Personally, I think that mental shift is even more important than the new features and tools and easy merges (which are also very nice, of course). Think of the old lock-based systems, where one team member would "check out" a file, and no one else could edit it until they were done. Once people switched to systems like CVS or SVN that let all the developers keep working without blocking each other (as much), it really altered and improved how software was developed and how teams worked together. Distributed systems take this to the next step, and again it alters and improves the way developers work and collaborate. Plus everything's just way faster. :-D I never realized how much time I spent waiting for a SVN commit to finish -- or even checking the log -- until I used Git. Now I'm completely spoiled, and waiting 10 seconds to contact the server just to look at the log, or 30 seconds (or even minutes (!) for big changes) to commit feels like an eternity to me. It may seem like a little thing, but it feels so much nicer when nearly every operation is near-instantaneous. - Jacek ___ 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] llcamera
On Fri, Mar 19, 2010 at 8:56 AM, Thomas Schindler wrote: > Hi there, > > I have a question to the llcamera.cpp code. There is a function that > calculates frustum planes. Four variables are existing: top, bottom, left, > right. The bottom is the negative value of top, the same with left and > write. If I change now the values and add +20 behind left and right, I > expected an effect in which my avatar would stand not in the middle of the > viewer window, but somewhere more left or right. But if I compile and run > the viewer, I don't see any difference. Does anybody can explain it to me, > please? I'm not an OpenGL expert, but I believe the frustum is used for determining whether an object can be seen from the current camera view (e.g. it's not behind the camera or off to the sides). I don't think the frustum controls the camera position or rotation, though. For that, I think you want to look at the LLCoordFrame class (llmath/llcoordframe.cpp), which is inherited by the llCamera class. Hope that helps. :-) - Jacek ___ 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] left and right arrows change to strafing in mouselook
On Sat, Mar 20, 2010 at 2:11 AM, Stickman wrote: > Why not just skip a half-way solution and implement full key mapping? Not to pick on you personally, Stickman, but it peeves me when somebody suggests that someone else should "just" do something that's thousands and thousands of times more difficult than the original proposal. It's not a very helpful attitude to take, and can be really demotivating to potential contributors. And not just the one with the original proposal, but also other people who may have been thinking about contributing but were put off by the unfriendly atmosphere. Anyway, turning to the idea being proposed... I can see how an option like that would benefit users who like to use a first-person view, but don't want to (or can't) use the mouse to turn. For example, I can picture someone walking through an art gallery with one hand on the keyboard, a mug of coffee in the other hand. :-D My only concern would be "option bloat". The Preferences window is already pretty crowded and complex, so there's a trade-off to adding anything more there. If an option is only somewhat useful, or is useful only to a relatively small percent of users, then it might be better to put it in the Advanced menu, for example. I don't use mouselook very often, so I wouldn't be a good person to weigh the benefit of this particular proposed option versus the added complexity. But I will point out that the "Input & Camera" preference panel (in the SL 1.x UI) is not overly crowded, so the cost of putting a new option there would not be very high. For the SL 2.0 UI, it could potentially be squeezed in to the "Setup" preference panel, although it would be a tighter fit. So, to summarize: I think it's a good idea and you (or someone) should go for it. :-) - Jacek ___ 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 Development project: extendingavatar wearables
On Thu, Mar 25, 2010 at 11:08 AM, Nyx Linden wrote:
>
> We're trying to make the system as flexible as possible. Think of it
> this way: you have a bunch of 'categories' or 'slots' - one for each
> type of wearable (pants, shirts, jackets). Inside each category, you can
> have multiple items up to a reasonable maximum. When you "wear" a shirt,
> it gets added to the top of the list of shirts that you are wearing. If
> you don't want it to be on top, you can push it down below other shirts.
>
> [snip]
>
> there is not a concept of a "shirt1" slot, vs "shirt 2" etc - the list
> of your shirts can change size according to how many shirts you want to
> wear at the time. The order in which you wear your clothing is
> completely up to the end-user who is constructing the outfit.
>
> a couple things to note with this approach:
> 1) the listed order of clothing probably will change to something that
> makes a bit more sense.
> 2) the list is wearable-focused, not texture-focused. Hence tattoos
> won't be split up into upper/lower/head, as they are a single wearable item.
> 3) the "order" will be able to be changed frequently and will not
> require any change to the item itself - only how it is stored in
> inventory. Hence, you don't need mod privs to re-order a shirt.
>
> Thus, pants are not inherently set to "pants 3", they're just pants! The
> consumer of said pants will determine if there are any other pants above
> or below it. This has the other advantage of allowing you to take a
> single pair of pants ("blue jeans") and having it be the bottom layer in
> one outfit, and the 3rd layer in a different outfit, even if they refer
> to the same wearable item!
>
> I hope that clarifies the proposed design - I hope to get more detailed
> information up in a central location sometime next week. In the
> meantime, keep poking at the proposal on-list!
>
> -Nyx
I really like this design, for the most part. But I think it would be
much better, and would address everyone's wishes for more flexibility
in clothing order, if a few things were changed:
1. Instead of having categories for each wearable type (shirts, pants,
shoes, etc.), have categories for "layer" (as when getting dressed in
RL):
* Outer Layer: jacket, gloves, shoes
* Inner Layer: shirt, pants, and skirt
* Under Layer: underpants, undershirt, and socks
* Body Layer: skin, tattoos, and (maybe) alpha
This is just an example. I'm not picky about the number of layers, or
what they're called, or which types go in which layer. But the idea is
that higher layers render on top of lower layers. The same is also
true within each category, an Nyx said: higher items render on top of
lower items.
2. When a wearable is worn, it goes to the top of the appropriate
layer (as above). But the user can open up the outfit editor and drag
the wearable to any layer they want, or reorder the items within a
layer. I think this would be a good solution, because wearing clothes
would "just work", yet users still have total control over the order
of layers, with a simple and natural way of modifying the order.
- Jacek
___
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] Soft body physics
Personally, I would keep soft body effects as purely client-side eye candy, without any impact on the world, like flexi prims and particles are today. Sending the deformation data from the server to the client, or vice versa, would be very bandwidth intensive, and a huge headache to keep in sync. And some users would need to disable the feature altogether, because it would also be costly to process the effect. - Jacek On Wed, Apr 7, 2010 at 2:48 PM, Glen Canaday wrote: > I came to the same conclusion, with the exception that a lookahead for a > collision would be helpful in the client. If they use the same physics > engine and the client does no more than implement a collision check, I think > it could be a good thing. I'm looking at several free physics engines atm > and thought I would clear my thinking up some. Collisions with soft bodies > deform the collision mesh itself so yeah it gets a little tricky when you > split them. > > --GC > > On 04/07/2010 11:14 AM, Moriz Gupte wrote: > > I feel you are right. Makes more sense to have it implemented client side > for many soft body dynamic behaviors... eg cloth, hair etc... > but I think in areas where rigid body behaviors impact local soft body > dynamics, there will be lots of timing and synch problems to deal with. > So there's where I think that perhaps all physics need to be done at the > same site. > R > > On Wed, Apr 7, 2010 at 9:03 AM, Glen Canaday wrote: >> >> >> Soft body physics are best implemented in a local viewer, leaving the >> rigid-body collision detection to the server, am I right in this? >> >> --GC >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > > -- > 'Consider how the lilies grow. They do not labor or spin.' > Rameshsharma Ramloll PhD Research Assistant Professor Idaho State > University, PocatelloTel: 208-282-5333 > More info at http://tr.im/RRamloll > > > > ___ > 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] texture problem on avatars
We have been seeing exactly the same thing with Imprudence 1.3 recently (which is based on SL 1.23 with some Snowglobe mixed in), also when connected to OpenSim. I'm not sure why it only seems to occur on OpenSim, but I can confirm that it's related to the change in texture channels, as Nyx said. We'll be working on this issue soon; if we find a fix, we'll be sure to share it. - Jacek On Wed, Apr 21, 2010 at 9:12 AM, Chang Liu wrote: > Hi, Nyx, > > We were using viewer 1.23.4. Interestingly, the official 1.23.4 viewer > binary release does not have this problem. But after we compiled and > packaged the 1.23.4 source release, we saw this problem. We didn't mix 2.0 > at all. > Since this is related to compiling and packaging, could it be a particular > library that's referred to in the code? > Thanks! > > ~Chang > > > On Tue, Apr 20, 2010 at 5:42 PM, Nyx Linden wrote: >> >> What version of the viewer are you using? Viewer-1.23 redefined the >> fourth channel of baked textures to be "alpha mask" instead of "bump map". >> If you load old baked textures that generated a fourth channel intending it >> to be a bump map, and use it as a baked texture for a 1.23+ viewer, the >> viewer will incorrectly interpret the fourth channel as an alpha mask, >> resulting in images like you included in your email. >> >> Were the avatars on the sim a mix of 2.0 and 1.22 (or previous) versions >> by any chance? >> >> -Nyx >> >> >> Chang Liu wrote: >>> >>> Hi, all, when we connect a modified version of Second Life Client Viewer >>> to OpenSim, we notice that from time to time, textures on avatars may turn >>> into mosaic and hollow like what's shown in the attached screenshots. Has >>> anyone seen this before? Any clues as to what may have gone wrong? Many >>> thanks. >>> >>> ~Chang ___ 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] Where are the new LSL functions in viewer 2 ?
On Sat, Jun 19, 2010 at 11:47 AM, Henri Beauchamp wrote: > I was in the process of creating a patch to backport the new LSL functions > to viewer v1.23, but I noticed that some of these functions, while > already implemented server-side, are not even implemented in viewer 2... > > For example, llGetLinkPrimitiveParams() does compile (in any viewer) but > isn't highlighted because this function is not declared in > indra/lscript/lscript_library/lscript_library.cpp > Since the functions in this file cannot be added in a random order, one > can't add it by their own accord till LL provides the updated file, with > whatever order they chose for all the new functions. Third party viewers can add anything to that file in any order with no real consequence. The big scary warnings in that file are a legacy of the old days when the viewer compiled its own bytecode. That file might also be used by the server code these days, but even if so, that's of no real concern to third party viewer developers. McCabe added the new functions and keywords to Imprudence recently, here's the commit with the changes: http://github.com/jacek/imprudence/commit/a3182539 I can email it to you as a patch if you want, just let me know (privately). Regards, - Jacek P.S. In Viewer 2, the tooltips seem to be defined in indra/newview/skins/default/xui/en-us/strings.xml (I guess the ones in lscript_library.cpp are ignored now). But, it is missing llGetLinkPrimitiveParams. Perhaps someone affected by this should file a JIRA ticket for the missing tooltip. ___ 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] Where are the new LSL functions in viewer 2 ?
On Sun, Jun 20, 2010 at 1:03 PM, Henri Beauchamp wrote: > Plus, there is still the issue that since the new functions are not yet > implemented in the official viewer, their server side implementation > could change without notice and render our own wiewer-side implementation > deprecated or even incompatible... I'm not sure what you mean by "not yet implemented in the official viewer". If you mean the tooltips for the script editor, they are defined in Viewer 2 in the strings.xml file, as I said in my previous message. That's where we backported the descriptions from. The only one missing from strings.xml is llGetLinkPrimitiveParams. > There are quite a few things missing in this patch to actually make it a > functional one, namely changes to indra.l, lllslconstants.h and > llclickaction.h. indra.l is not used by the viewer anymore, nor are those parts of lllslconstants.h (only the value of MAX_PAY_BUTTONS is used by the viewer). The additions to llclickaction.h are only necessary when porting over the entire new media system, which we have not done yet. None of those additions are necessary for the tooltips, which was the point of the patch. > Also, PRIM_NAME doesn't (yet) exist server-side (I checked for all possible > unused integer constants) If you have a look at the wiki, you will see that PRIM_NAME will be appearing in server 1.40: http://wiki.secondlife.com/wiki/PRIM_NAME > and PRIM_TEXT is wrongly documented in your > keywords.ini as referring to the prim description instead of its hovertext You're right, this was a mistake. That line should have been PRIM_DESC, and another line added to describe PRIM_TEXT. > (I do agree however, that a mean of changing and retreiving prim description > is *definitely* required if we want to be able to get rid of all secondary > scripts in child prims You will be happy to hear that PRIM_DESC is also coming in server 1.40: http://wiki.secondlife.com/wiki/PRIM_DESC > I got a proper, working patch if you want it (will be part of the next > release of the Cool VL Viewer)... Sorry that our proper, working patch was not up to your standards. ;-) - Jacek ___ 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] display names = the end of 1.x viewers?
On Tue, Aug 17, 2010 at 4:34 PM, Lance Corrimal wrote: > > ... I guess that means the end for logging in with 1.x based viewers, > does it? I'm sure third party viewer developers are capable of backporting something as simple as display names. ;-) (Besides all the points mentioned above about how you will still be able to log in with old viewers even if they don't support display names.) - Jacek ___ 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] Off-topic chatter (Was: Display names, again.)
On Fri, Aug 20, 2010 at 1:38 AM, Lance Corrimal wrote: > Is it just me or did the lindens stop replying to this topic? They probably stopped replying because nearly all of the chatter about Display Names has been off-topic and inappropriate for this list, and continuing to discuss it here just further wastes the time of everyone who subscribed to the list to follow the discussion about Snowglobe, Snowstorm, and other open source projects at Linden Lab. - Jacek ___ 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] What is the license status of UI sounds ?
On Tue, Nov 16, 2010 at 2:17 PM, Oz Linden (Scott Lawrence) wrote: > Don't get me wrong ... I think that Henri posted a very good analysis > and it seems to me that the whole idea is worth looking at more > closely. My note was intended to answer the immediate question of what > the license on those particular sounds is right now - nothing more. So, how should we get the ball rolling on (hopefully) getting the UI sounds released under the same CC-BY-SA-3.0 license as the UI artwork? File a JIRA? Poke a certain Linden? Bribe with chocolate? :) - Jacek ___ 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
