Hi,
We discussed this subject again at the Hippo meeting today.
Forums didn't have much takers though I'll try to spend time there and see
for myself how the dynamic works.
The extra IW meeting was better received. Tuesday seemed to work but we
couldn't decide on a time, 2pm PST works for those
Hi,
Thanks Robin for the summary of the Hippo discussion. It's consistent with
Q's schema and the point of the discussion was to avoid Merov becoming the
bottleneck for merges in Snowglobe trunk...
Another thing we said this week was that the export (from viewer-public to
viewer-external, process
It would also require completely de-constructing the current layers
system, and rebuilding it based on the added parameters (I'd actually
argue making the parameters part of the links used to create an outfit,
not the wearables themselves but that's a side note).
-Nyx
Mike Monkowski wrote:
>
Argent Stonecutter wrote:
> On 2010-03-25, at 15:44, Nyx Linden wrote:
>> I'd argue that's an insufficient solution. Parameters such as sleeve
>> length and color have fairly dramatic impacts on how a wearable
>> appears. Converting only the textures would result in a fairly
>> disappointing res
Nyx Linden wrote:
> Interesting proposal, and one probably worthy of further investigation.
> My concern with this plan is that the conversion from one wearable type
> to another is very much non-trivial. The wearable parameters (sleeve
> length, etc) have no relation to each other between weara
On 2010-03-25, at 16:48, Latif Khalifa wrote:
> Not to mention that some span over more than one bake, like jacket,
> tattoo and alpha.
Yes, I explicitly noted that already in my previous message:
>> For clothes that are modify, add an option "change wearable type",
>> between compatible types.
Th
On 2010-03-25, at 15:44, Nyx Linden wrote:
> I'd argue that's an insufficient solution. Parameters such as sleeve
> length and color have fairly dramatic impacts on how a wearable
> appears. Converting only the textures would result in a fairly
> disappointing result, I think.
As a user, I w
Not to mention that some span over more than one bake, like jacket,
tattoo and alpha. I don't think changing wearable type is feasible.
On Thu, Mar 25, 2010 at 9:44 PM, Nyx Linden wrote:
> I'd argue that's an insufficient solution. Parameters such as sleeve
> length and color have fairly dramatic
I'd argue that's an insufficient solution. Parameters such as sleeve
length and color have fairly dramatic impacts on how a wearable appears.
Converting only the textures would result in a fairly disappointing
result, I think.
-Nyx
Argent Stonecutter wrote:
>
> On 2010-03-25, at 15:07, Nyx Li
On 2010-03-25, at 15:07, Nyx Linden wrote:
> Interesting proposal, and one probably worthy of further
> investigation.
> My concern with this plan is that the conversion from one wearable
> type
> to another is very much non-trivial. The wearable parameters (sleeve
> length, etc) have no rela
On 2010-03-25, at 13:55, Nyx Linden wrote:
> Specifying an arbitrary order in inventory that is unrelated to
> wearable type is absolutely trivial.
> The difficult part comes when you go to render your baked textures.
How about this?
For clothes that are modify, add an option "change wearable t
On 2010-03-25, at 12:48, Nyx Linden wrote:
> My initial answer to that request is "we don't have time to
> implement that right now", but I'd be happy to have a more in-depth
> technical discussion as to how that could be implemented in the
> future.
OK, I can live with the awesome knob set
Avatar cloth doesn't just make clothing wave in the breeze. Just turning
it on and flying. It makes your butt wave in the breeze, too.
--GC
On 03/25/2010 01:55 PM, Nyx Linden wrote:
> There is the "avatar cloth" graphics setting in preferences (if you
> enable advanced preferences). Though
All,
If layers are to be truly arbitrary, then we would need to go all the
way with it so that items can be sold as only 1 item and not on multiple
layers w/ xfer. Argent's got the idea partly in one of his posts.
Of course, multiple wearables of the same type at once kind of wrecks
the argume
Interesting proposal, and one probably worthy of further investigation.
My concern with this plan is that the conversion from one wearable type
to another is very much non-trivial. The wearable parameters (sleeve
length, etc) have no relation to each other between wearables. For
example, "sleev
> Again, if any open source developer wants to look at the code
> architecture and draw up a plan for how this can be done in a
> reasonable amount of time, I'm all ears. My current ideas on
> how to implement this would push us well out of the timeframe
> that we were hoping to ship this set o
On Thu, Mar 25, 2010 at 7:55 PM, Nyx Linden wrote:
[snip]
> As I stated previously, I'm not completely stuck on the current
> structure, its just one that I know I can finish and ship in the given
> timeframe. I can think of ways to re-re-architect the structure yet
> again to enable this reque
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
unless the briefs are indecent, around here i don't think anyone would
directly complain (they might talk about it being unusual with other
people, but i don't think anyone would be forbidden to enter a store,
restaurant etc just because of an slightly
Specifying an arbitrary order in inventory that is unrelated to wearable
type is absolutely trivial.
The difficult part comes when you go to render your baked textures.
Currently each baked texture is specified by a "layerset" which is a
vector of texture layers in rendering order. So the upper
Interesting topic. Thought I'd share some thoughts.
1. I like the idea of wearables being in folders allowing the user to
drag and drop the article in different folders to taste. This allows the
user to choose where the wearable goes.
2. Adding to that, we can create limits on the o
On Thu, Mar 25, 2010 at 01:48:39PM -0400, Nyx Linden wrote:
> My initial answer to that request is "we don't have time to implement
> that right now", but I'd be happy to have a more in-depth technical
> discussion as to how that could be implemented in the future. If the
> community is able to
Arbitrary wearable re-ordering (if you want to be a superhero with
underwear over your pants) is a rather difficult problem. I'll get into
more detail once the forums are set up, but its probably beyond what I
can reasonably do for this project cycle. I'm open to ideas from the
community on how
There is the "avatar cloth" graphics setting in preferences (if you
enable advanced preferences). Though the effect appears to be subtle and
not used for terribly much. There is certainly the possibility to extend
this functionality to be more explicit and improve it to be better, but
I bel
OMG yes! Especially if THAT flexi doesn't "pass through" the avatar!
How great wouldn't it be to have flexies (which are client side)
that respect other things around them, like avatars, ground,
and even other prims, and won't pass through them but rather
fold around them! (You could make this a c
Argent Stonecutter wrote:
>
> On 2010-03-25, at 11:08, Nyx Linden wrote:
>> 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
The advantages of this:
* Automatic insertion that makes sense
* No need to edit (no-mod) items
The disadvantage:
* Still can't wear a shirt over a jacket, or
a designated "undie" over a "pants".
* Giving an outfit to someone else might
change unexpectedly change the order in
which the ite
If its extra awesome we are after...any chance of eliminating the need for
half the prim skirts and capes by adding a flexi-layer mode to the
layer...So the clothes can flutter and maybe stretch in the wind?
Jonathan Bishop
___
Policies and (un)subsc
On 2010-03-25, at 11:08, Nyx Linden wrote:
> 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
Wow great discussion so far - these are a lot of the issues I've been
thinking on for a good while now, and I'm glad they're being brought up
immediately.
I'm still working on getting the forums set up, where this conversation
would ideally take place, but in the meantime, I'll try to respond on
solved... "unset http_proxy https_proxy no_proxy" at the start of the launch
script, because gstreamer suddenly lost the ability to stream thru a proxy.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource
...yes i know this is not the support hotline...
But chances are high that there's someone around on this list who could point
me at the one right library dependency in five minutes, whereas a support
ticket would take several weeks, and then be closed with spurious reasons but
no actual soluti
Kitty wrote:
> If someone sells a full-top + high pants combination they wouldn't have to
> struggle with defining which shirt layer goes on top of which other one by
> messing with numbers - since those will still result in conflicts with what
> it's being worn in combination with - but you just l
> Ah yes, using the descriptions would avoid the need for extra
> protocol changes.
>
> I'd suggest to use the keywords "skin", "tatoo", "underwear",
> "shirt", "jacket", but also allow "shirt 2", "shirt 3", etc
> to put things inbetween shirt and jacket.
Doesn't most of the confusion stem fro
> I'm greatly in favor to create bits for wearables and objects
> that stay user changable even for no-mods.
General agreement.
Needs some thought to make sure that it's not too easy to change them
accidentally and lose the creator-intended settings forever (maybe save
the original settings an
I begin to think about libraries bundled with viewer Maybe LL
should check again the versions... I still have glibc segfault on SL2
on font loading (libxft?)
--
Sent by iPhone
Il giorno 25/mar/2010, alle ore 13.52, Michael Dickson ha scritto:
> Thanks! I just upgraded to the 10.4 beta
Am Donnerstag, 25. März 2010 13:38:28 schrieb Carlo Wood:
> If I go to shop in real life, it's also ME who decides
> in what order I put clothes on, not the creator of the
> clothes.
oh? try wearing your briefs on top of your pants in public...
___
Pol
Thanks! I just upgraded to the 10.4 beta, I'll give it a try. I was
having problems on a similar setup with x64 Fedora but that issue may
have been related to the 64bit distro.
Mike
On Wed, 2010-03-24 at 23:26 +, Opensource Obscure wrote:
> On Wed, 24 Mar 2010 18:11:03 -0500, Michael Dickson
I said: I want to be able to change the priority of
(no-mod) animations regardless, as user.
I definitely also want to be able to change the
order in which a wearable is layered, as opposed to
that the creator does that for me.
If I go to shop in real life, it's also ME who decides
in wha
Ah yes, using the descriptions would avoid the need
for extra protocol changes.
I'd suggest to use the keywords "skin", "tatoo", "underwear",
"shirt", "jacket", but also allow "shirt 2", "shirt 3", etc
to put things inbetween shirt and jacket.
On the downside, no-mod wearables would disallow reor
+1 Carlo, the specific priority on animations has caused confusion of
when to set them to 1, 2, 3, or 4. If it is not set correctly, then it
could mess up the other animations.
I would like to see that confusion avoided with outfits.
Carlo Wood wrote:
> On an equal note, it's extremely annoying
On Wed, Mar 24, 2010 at 10:57:45PM -0400, Glen Canaday wrote:
> No change for the creator - none. Not a thing. The user gets a "bump up"
> or "bump down" item in the current "wear" submenu.. that's all. Max 3 or
> so, and they act like layers in Photoshop or Gimp, which is essentially
> what the
On an equal note, it's extremely annoying that the priority
of animations is determined at creation time.
Why can't I, as user, determine in what order I want animations
to take precedence?
On Wed, Mar 24, 2010 at 10:20:19PM -0400, Glen Canaday wrote:
> Actually, I don't mind "undies, shirt, and
While this may protect a viewer developer from direct responsibility towards
a user, it does not provide any protection against LL. Assuming I have to
clickwrap-accept TPV by 30 April before I'm allowed to connect to the
SecondLife grid, I still accept universal guilt towards LL.
Example: A con
It's obvious the TPV is directed at sources and distributors that do not
conform to specifications as implemented/documented by the GPL code in
Snowglobe.
If you implement a third-party network protocol, it probably would be of
benefit to you to to publish how your version of the network protoc
Hmm... something came up on SLU...
on the bottom of the pile is the GPL, because every piece of source code for
the viewer says "licensed under GPL v2".
on top of that is the TPV, because linden labs think they can say so.
...regarding "connecting to Second Life" they actually can.
...regardin
> That's actually what I would like to avoid, specifically.
> That forces the creator to continue to dictate whether your
> underwear goes on top of your pants or not. There's no added
> flexibility for the resident in that.
>
> Here's why I'll be an advocate of just a few extra numbered
> lay
46 matches
Mail list logo
