Re: [opensource-dev] Avatar Hover Height feature
On Mon, 2 Feb 2015 20:49:49 +0100
Henri Beauchamp wrote:
> Are you ***kidding*** me
etc...
LOL - Henri, I respect you a LOT, for technical reasons.
I even once told Oz that if you said something he better
listen because it would be worthwhile.
However,
sometimes I wonder why you aren't being smarter than this :p
At the time I was enthusiastic about working on an opensource
viewer (even though that meant given my private info, which I
agree is rather silly and annoying; and I understand why you
refuse that)... That was before Oz - we worked on the viewer
for a YEAR before finally being confronted with the fact that
Linden Lab ('s internal coders) hadn't even LOOKED at our
contributions and EVERYTHING we did had been /dev/null-ed and
not used in their next release. I didn't reconfirmation: I left.
Then Oz came and promised change: everyone would work on the
same repository and be treated the same (Lindens and open source
programmers a-like). I never believed that, but I gave him a chance:
because of his promises I ported ALL of (one year) of work
to the new code base. Then I gave them TWO MONTHS to merge my
work - which failed; and I left again and never returned.
By now (years and years later) it's a blatant fact that the
above was a lie: Lindens and open source coders are still *not*
being treated the same.
Bottom line is. Linden Lab only uses and likes "invented here".
The don't listen to others, nor are they interested in what
others have to say. Things are STILL being developed behind
closed doors mostly (and have been since the very beginning),
that will never change. If you come with a good idea, it will
be shrugged of. Trying to communicate with Linden Lab is a waste
of your time.
When the viewer developers figured this out and therefore
concentrated on COOL INNOVATIVE stuff that they didn't NEED
Linden Lab for; Linden Lab got very very frustrated, until they
finally came with the Third Party Viewer ToS that literally
forbids TPV devs to come with cool innovate stuff; so now
it's again and 100% closed-door-"invented here"-Linden-Only
stuff pushed out to some repository after which it is Oz's task
to make sure all the TPV's copy and support the new functionality
in the name of 'shared experience' etc. At no point in this
development cycle they are going to listen to you, let alone
do something (different) because of a bright insight that you
have.
Stop Wasting Your Time.
Just let them kill SL in peace.
Regards,
Carlo Wood
PS Needless to say that I completely agree with the technical point you
have been making. But it's not just the hover height that is
problematic lol. The whole animation (format) is useless. That format
was never intended to be used by many different shapes (but only by a
single shape, one that the animation is specifically intended for).
However, if you accept that design error then what is really needed
is neither a Z-offset nor a fake bounding box. What a viewer (script)
would need control over are two reals: an offset and a (vertical)
scaling factor.
The problem is this:
If an avatar of 2 meter is standing straight up, then -say- by default
their feet are on the floor (tuned to be on server side).
If the same avatar bends its knees so that the feet--pelvis distance
decreases from 1 meter (say) to 0.4 meter (say), then its feet would
be 0.6 meter above the ground because the pelvis height is fixed (well,
the avatar center is, but that has the same height basically).
Therefore, in order to get the feet on the ground again the used
animation format includes an offset of -0.6m: moving the whole avatar
down 0.6 meter. This is why this format is only usable for a single
shape: that 0.6 meter is only fixed for a given shape.
A smaller avatar, lets say one of 1.5 m (with otherwise the same shape)
has thus a feet--pelvis distance of 1.5/2 = 0.75m. This is "known" by
the server and corrected for: the pelvis is moved down 0.25m so that
the feet touch the floor when standing up.
Then, when that smaller avatar plays the same animation (made for the
2m tall one), it pulls up its feet 0.6/2*1.5 = 0.45 meter and the
animation moves the whole avatar down 0.6 meter... resulting in the
feet being buried 0.15m into the ground.
The old way to "fix" this is by telling the server: Hey, I'm REALLY
1.8 meter tall (instead of 1.5m), causing the server to not move you
down 0.25m but only 0.1m - causing the feet to precisely touch the
ground again. I don't consider that a good solution :p.
The new Hover solution is actually better - except that it was
baked into the shape itself and isn't the correct way to fix this
either - and therefore (like the first case) needs fast and dynamic
changes (ie, every time you change animation) which is no longer
possible - making it MUCH worse than what we used to have.
Still, the Hover is just an offset and therefore not what
Re: [opensource-dev] grid code exploited
On Tue, 1 Oct 2013 02:09:58 -0500 Flats Fixed wrote: > seems your staff OZ has exploited your closed grid code and has > rendered a whole sim on Mainland _ Bailywick Useless. And Staff is > unable to fix it. this is a serious issue OZ fix it. Only people that > have this knowledge of the Closed grid is Staff. > You really should take the meds that your psychiatrist prescribes, otherwise they don't have any effect :/ -- Carlo Wood ___ 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] ThrottleBandwidthKBPS - kilobit per second or kiloBYTE per second?
Well, since everyone has to download the same amount of data in the end, its rather hard to use a "disproportional" amount of resources, unless a viewer just downloads the SAME thing over and over again, which would be severe bug. The only other thing that might be called using too much resources is when the sim is failing to deliver data, and connections that are made just time out. In that case it will be the viewers that have the most aggressive re-try policy that are using the most resources. For clear reason, in those situations it will be the viewers that retry most aggressively that will succeed faster than others to retrieve the data. In my experience, this is V3. Even on servers where most TPV's fail completely to get any data because of huge number of disconnects and timeout - V3 *still* manages to get all data in around 2 minutes time! I'm able to run a V3 viewer myself but independent sources told me that they saw V3 make up to 40+ connections at a time to the texture/mesh service. On Tue, 30 Jul 2013 15:08:28 +0200 Niran wrote: > Names or it didn't happen. > > > 2013/7/30 Kadah > > > > > > > On 7/26/2013 10:47 AM, Argent wrote: > > > > > > On Jul 26, 2013 12:32 PM, "Darien Caldwell" > > > mailto:darien.caldw...@gmail.com>> > > > wrote: > > >> So basically while this system is probably beneficial to those > > >> with > > > bad internet connections, it's rather punitive to those who have > > > excellent, wide pipe connections. The only way to increase the > > > bandwidth max is to recompile the viewer. > > > > > > One should also consider how much of Linden Labs bandwidth one is > > > entitled to before dismissing it as 'punitive'. :) > > > > Indeed. There's been a number of incidents where few users in a > > region on [VIEWER NAME REDACTED] can use a high disproportional > > amount of sim resources and and cause rather sever problems for > > others. Just last week I got trapped in a region due to this. That > > was fun. ___ > > 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 > > -- Carlo Wood ___ 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] ThrottleBandwidthKBPS - kilobit per second or kiloBYTE per second?
On Fri, 26 Jul 2013 13:58:47 +0200 Henri Beauchamp wrote: > This setting is indeed only relevant to UDP traffic, or at least in > LL's and most TPV viewers. IIRC, I saw attempts to account for this > limit with HTTP texture fetching traffic in Singularity, but that > would need to be checked for certainty. Singularity has a separate debug setting for HTTP bandwidth usage (HTTPThrottleBandwidth). -- Carlo Wood ___ 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] Reminder: Collaboration in 3D virtual environments- take the survey and earn 100L$ I need you assistance please
On Wed, 24 Jul 2013 14:32:57 +0200 Ambrosia wrote: > Would you please top spamming this mailing list over and over? > > Thank you. I just added a special spam filter rule to my spamassassin a while back. -- Carlo Wood ___ 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] Serious regression in SSB-enabled regions
On Sun, 24 Feb 2013 20:09:19 +0100 Henri Beauchamp wrote: > > I'm unable to comment on SUN issues (or even make them) > > Gotta love the new closed JIRA !... Way to go, LL... I was about to type "fuck you Linden Lab" in my previous post, but assumed they might be assholes enough to then kick me of this list... The phrase "way to go" is inventive. It would never have occurred to me to use that in this context. This whole "open source" HAHAHA project is a pathetic, lame, grrr - I want to SPIT on it. LL should be sued for fucking CALLING this "open" in ANY way. I hate you. A REAL Open Source coder, Carlo Wood PS I'd add a comment HERE regarding SUN-38, but I learned years ago already that LL doesn't listen to anyone. They are just going to give you the finger Henri (and everyone else in SL) but not going to fix this. I'm not even going to TRY add a (technical) comment. Seriously, why is ANYONE still HELPING them? Why doesn't everyone just leave this list, stop going to their meetings, and stop giving them patches? Are you all stupid or what? ___ 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] Serious regression in SSB-enabled regions
On Sun, 24 Feb 2013 10:36:12 -0800 Darien Caldwell wrote: > Yes, this was brought up to Nyx and Oz at Oz's last User Group > meeting, by inusaito.kanya They were supposed to file a bug under > Sunshine, but probably good to have someone else do it as well, in > case they didn't. I'm unable to comment on SUN issues (or even make > them) but I gave it my vote regardless. I'm unable to add a comment either to this issue. What utter crap is this??? ___ 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: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
Not only sliding doors, my normal door stopped working too more than half the time; and a LOT of others scripted objects... Even watching it doesn't always help. On Sat, 16 Feb 2013 18:53:02 - "MartinRJ Fayray" wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/616/ > --- > > (Updated Feb. 16, 2013, 10:53 a.m.) > > > Review request for Viewer. > > > Description > --- > > Fixes missing childprim- position/rotation-updates when the avatar > was 20+m away and didn't have the object in view when it was changed. > > > Repository: https://bitbucket.org/MartinRJ/bug-840 > > > This addresses bug BUG-840. > https://jira.secondlife.com/browse/BUG-840 > > > Diffs > - > > indra/newview/lldrawable.cpp fbbee98b7512 > > Diff: http://codereview.secondlife.com/r/616/diff/ > > > Testing (updated) > --- > > Create an object with two prims, add a script with a listener on > PUBLIC_CHANNEL and make it change the relative position of the child > prim in the listen-event. > > Move the avatar 20+ m away from the test object, and look in the > opposite direction, so that the object is not in view. > > Shout something in public chat so that the child prim changes its > relative position. > > Turn around so that the test object is in view again. > > Expected result: the prims visibly changed. > > Without this fix, the child prim would not update its position (or > rotation). > > This fix has to be tested against the following related bugs: > BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost > every sliding door script in SL MAINT-2275 [vehiclebug], Child prims > are "left behind" by animated, moving physical objects MAINT-1742 > [selection], Child object does not update position while selected. > MAINT-2247 [selection] Child object does not update rotation while > selected. > > > Thanks, > > MartinRJ Fayray > -- Carlo Wood ___ 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] gcc 4.7.1: lotsa warnings about boost
On Sun, 06 Jan 2013 11:56:31 +0100
Lance Corrimal wrote:
> Hi,
>
>
> Whenever I'm building the current development source on openSUSE 12.2
> (read: with gcc 4.7.1) I get lots of warnings about boost-related
> things. Some of them I've been able to correct myself, others I'm
> stumped... the causes seem to be in 3p-boost itself, and i'd rather
> build with exactly the same libs as the lab...
>
> here's one of many examples:
>
> http://paste.opensuse.org/77018665 (it's way too long and unreadable
> for email)
>
> any ideas / tips / hints for me? google results seem to suggest
> something or the other about namespaces...
This is just one of the many many examples showing that a lot of the
Linden code was written by people who probably learned C++ in a 2 week
course before starting to hack the viewer code.
The solution is rather simple, really. Now I haven't looked at v-d in a
while, but last time I compiled it I compiled it with gcc 4.7.2 and
boost 1.49 and that gave me the same error as I see at the top of your
paste (only looked at the first error by the way), which can be
resolved by simply removing the nonsensical 'namespace boost'.
Everywhere where you see
namespace boost {
// something with *intrusive*
}
remove the 'namespace boost {' and '}'.
--
Carlo Wood
___
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] Formal Animation Set Replacer
On Sat, 3 Nov 2012 11:49:36 -0500 Argent Stonecutter wrote: > I think the requirement for this is somewhat overstated, and I hope > that LL does not include any such function in the viewer. A well > written LSL based AO has very little overhead, because it can get by > with fairly slow timers by using control inputs to detect state > changes. Even the somewhat convoluted Franimation Overrider is low > overhead, and I suspect the overhead of running it is not much > different from the network overhead of a client-based AO. > ___ 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 LSL AO's have always failed majorly. I'd welcome any official server-level support for replacing the standard stand/walk/run/sit/turn animations, so they work like the non-AO ones (not that is flawless... happens too often you "walk" while playing the 'stand' animation :/) -- Carlo Wood ___ 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] Fwd: I'm back baby!
On Sat, 27 Oct 2012 18:11:45 +0100 Gareth Nelson wrote: > Been away from SL for quite a long time, is there a 64-bit binary > build for linux lieing around somewhere? https://github.com/downloads/singularity-viewer/SingularityViewer/Singularity-x86_64-1.7.2.2956.tar.bz2 is linux 64bit. -- Carlo Wood ___ 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: patch potential memory leak in llgl.h
On Thu, 20 Sep 2012 07:08:11 - "Gistya Eusebio" wrote: > > > > On Sept. 19, 2012, 2:12 p.m., Aleric Inglewood wrote: > > > There is semi-colon where it doesn't belong. Otherwise ok > > > (Singularity has this patch since a long time). > > Oh really, where? It compiled and ran fine on my machine. Perhaps it's the ONLY semi-colon you added? Semi-colons have the tendency to compile if you add one at random; still doesn't belong there though. With regard to white-space, you also should start the line with a TAB instead of spaces to match the already existing lines, and the added comment is something that should be in the commit message, not in the code. > > > - Gistya > > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/603/#review1265 > --- > > > On Sept. 19, 2012, 8:26 a.m., Gistya Eusebio wrote: > > > > --- > > This is an automatically generated e-mail. To reply, visit: > > http://codereview.secondlife.com/r/603/ > > --- > > > > (Updated Sept. 19, 2012, 8:26 a.m.) > > > > > > Review request for Viewer. > > > > > > Description > > --- > > > > In llvertexbuffer.cpp we call: delete mFence; > > > > mFence is an instance of class LLGLSyncFence which is a sub-class > > of LLGLFence, which is defined in llgl.h. > > > > However, class LLGLFence should have a virtual destructor because > > it's the base class. This patch fixes that potential memory leak, > > adding a virtual destructor to class LLGLFence. The virtual > > destructor ensures that the destructor for the derived class also > > gets called when we call "delete mfence;". > > > > To quote Björn Pollex, "If you have a class that is supposed to be > > usable polymorphically, it should also be deletable > > polymorphically." > > > > (Unless I'm missing something...!) > > > > NOTE: I notice that related code is commented in methods "void > > LLVertexBuffer::placeFence() const" and "void > > LLVertexBuffer::waitFence() const" -- maybe we commented it out > > because this memory leak was unresolved? Perhaps it can be > > uncommented now? I haven't tried yet. There was no note as to why > > the code is commented out. > > > > > > Diffs > > - > > > > indra/llrender/llgl.h UNKNOWN > > > > Diff: http://codereview.secondlife.com/r/603/diff/ > > > > > > Testing > > --- > > > > I did compile this with OS X 10.8 as a build target successfully. I > > made other changes too, so while my FPS seems improved, it could be > > from any number of issues. I did notice that any llCharacters that > > are moving around don't get rendered properly by my build, but I > > don't know if it's because of this code revision or something else. > > I need to do further testing on that. > > > > > > Thanks, > > > > Gistya Eusebio > > > > > -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Using debian, I installed claws-mail-pgpinline plugin, and can now see your mails as I should :). Thanks for your kind patience! - -- Carlo Wood -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUBxY4m/Sxh1iSsrVAQI+lQP/XSbTU8Jwewvr6vyYo5NW/XqwwZ/S24ZG EtaRpx6jf/Iv6Yq61nNH+iYhEockE3guiVA1+L8SG1jDeqjHTZLBdzMIvXZVRnVr ETs6FowTia4kHfMACC/CDdcuZwG0VKKVDNRq1+SOmAPdaLj3gbvqeIle1/2eYBke lKbivKq+NXM= =8f6F -END PGP SIGNATURE- ___ 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] New HTTP Library & Project Viewer
On Thu, 02 Aug 2012 12:21:20 -0700 Kadah wrote: I stand corrected :/. And I'm disappointed in the mail viewer that I use (Claws Mail). I see nothing, and it treats your message as an attachment. When I click on that it allows me to "Open" it with abiword -- which I normally only need to open .doc documents -- hence my accusation... Before this mail program I used mutt, and that had no problem showing signed mails directly :\ -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Thu, 2 Aug 2012 02:01:45 -0700 Dahlia Trimble wrote: > I can't help but think something is wrong here. A single TCP/IP link > is more than capable of saturating available network bandwidth with > efficient transfers of large volumes of data provided the end-points > can produce and consume quickly enough. > > It seems part of the problem may in the request/response nature of > HTTP. The viewer needs to make a request for each asset it needs as > it discovers it needs it. It sends a request for each asset, and the > provider endpoint then has to do whatever it does to make the asset > available before beginning to send it back to the client. This may > occur relatively instantly in the case of assets in a server memory > cache, or a lot longer depending on where it needs to be pulled from > or how it may need to be prepared. Assuming this is the case, having > multiple overlapping requests can improve the overall download rate > of multiple assets by allowing some downloads to occur while others > are prepared, albeit at the expense of additional connections. Having > a persistent connection reduces some of the delays introduced by > re-establishing a connection for each asset, but it does nothing to > reduce the time that the server endpoint needs to acquire and prepare > the asset to send. > > Now (assuming this isn't the case already) if the producer endpoint > could be made aware of future requests, it could fetch and prepare > the asset for transfer prior to the actual request being received, > thereby reducing or eliminating the time delays inherent in the > request-response paradigm. This *may* be as simple as adding > additional optional UUIDs and parameters to the asset request for > assets that the viewer would likely be requesting next. If this were > the case, a single connection could have a higher effective > throughput by ensuring minimal delays between request and response, > and reduce the need for more simultaneous connections. > > Such a solution may or may not be practical or easily implemented in > existing infrastructure, or may not be as efficient as other designs. > My point is more or less meant to bring more perspectives into the > discussion by considering other bottlenecks that may exist, which if > mitigated, could reduce the need for excessive connections. > > Thoughts? > -dahlia Dahlia, an overwhelming amount of past experience has taught us that Linden Lab is not interested if you "think along" with them about the server, or the viewer-server protocol,either with suggestions, designs or anything. This list is set up to get feedback about viewer bugs, and to announce things they came up with (in most cases someone else came up with than the ones that we're allowed to talk with). So, it's a complete waste of your time to do anything else than to just sit back and read what Linden Lab is going to push through (no matter what arguments you come with, or what flaws you point out). [ That being said, they came up with "pipelining" as the solution for the problem you mention. That allows a viewer to send new requests over the same connection, without having to wait for a reply for former requests. This isn't the most efficient solution, but a lot better (still depending on the closed source server implementation though) than how it works so far. ] -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Tue, 31 Jul 2012 19:03:09 -0700 Kadah wrote: Kadah, Please note that I cannot read your posts. They have no clear text in them, and exist only of a Microsoft(tm) company specific attachment. You might want to fix this. -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Sun, 29 Jul 2012 10:07:18 +0200 Henri Beauchamp wrote: > On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote: > > > On Fri, 27 Jul 2012 16:59:18 -0400 > > holydoughnuts wrote: > > > > The implementation that I wrote for Singularity (not yet in the > > the official release) is more on the side of "blazing fast" :p. > > The bottleneck is entirely server-side, but I've seen download > > speeds of 1 MB/s non-stop till all textures were there. > > With just a few tweakings to the texture fetcher (and in particular > a setting that permits up to 32 concurrent HTTP fetches), I get much > more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the > 10MB/s+ range while rezzing in heavily textured areas and the rezzing > time is pretty low... This has been so for many months (well over > a year actually) already. I agree that that would be an advantage for the user; but it's not clear to me if it is allowed (or will be in the near future) to have 32 concurrent fetches. The rationale that it SHOULD be allowed is that the user will download those textures anyway; so, you might as well allow them to get it quickly, in a short time: this has no influence on the average number of open file descriptors on the server. I understand that LL is afraid that once viewers can keep sockets open (for reuse) that the servers run out of filedescriptors. Of course, this is all to true. Therefore I propose to set a limit on the maximum number of UNUSED filedescriptors. However, there should be no limit or a much higher limit, on the number of connections that are actually in use. The question is then: when is a filedescriptor "unused"? Well, I'd say that for the sake of re-use, it can be considered unused if there hasn't been a new request for it for -say- a second. It's probably best to define multiple stages, that is: * Allow a maximum of 32 connections. * Allow up to 32 connections that are unused for 1 second. * Allow up to 8 connections that are unused for 10 seconds. * Allow up to 2 connections that are unused for 1 minute. * Allow 1 connection to be unused for 20 minutes (or whenever one leaves a region and it can be determined that this server won't be needed or used anymore). Of course this means that upon teleport to a new region with many unknown textures, the viewer will make 32 new SSH connections, but that is MUCH less than one new connection PER TEXTURE, as we have now. Then all those connections are reused until all textures have been downloaded (a few seconds). Other strategies are possible, like NOT immediately creating a new connection as long as the maximum of 32 connections haven't been used up yet, but waiting with that until there's a queue of requests building up. Bottom line is, I'm afraid that Linden Lab is going to take the (too) simplistic route as they often have done in the past, and do something very silly like: * Allow a maximum of 2 connections, and allow to keep them open indefinitely. I hope you see the difference :p I argue that something like that makes no sense and would hurt the user because they'd have to wait unnecessary long before everything downloads. -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Fri, 27 Jul 2012 16:59:18 -0400 holydoughnuts wrote: > On 7/27/2012 1:46 PM, Oz Linden (Scott Lawrence) wrote: > > Project Viewer for testing is here: > > > > http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#HTTP > > > > Especially if you have had problems when you enable the use of > > HTTP, we would very much appreciate your giving this a try. We > > know that it does not yet solve all the problems, but we think that > > it solves some and provides the first steps needed for solving some > > more in the future. > I threw this at a pretty modest CPU, an Athlon II 170u single core > dealie, and the difference there was pretty substantial. Under Linux, > HTTP texture loads went from slightly sluggish, to feeling about the > same as with them switched off. > > On Windows 7, the difference was much more dramatic. Mainstream > viewers have been painful and jerky for a long time on that machine > even with HTTP textures off. This viewer is running firmly on the "I > can live with this" side, even with HTTP textures enabled. Flying > around in some heavily built areas was even tolerable. The implementation that I wrote for Singularity (not yet in the the official release) is more on the side of "blazing fast" :p. The bottleneck is entirely server-side, but I've seen download speeds of 1 MB/s non-stop till all textures were there. This code should be in the next release in about a week. I'm currently working on implementing upcoming support for connection reuse by the servers (although that will still take a long time before they will start to support that, I understood). I'd like to opt that this code will be an alternative for third party viewers, and might very well turn out to be more robust ;) -- Carlo Wood ___ 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] Linux toolchain update... testers needed.
On Wed, 6 Jun 2012 13:59:02 -0700 Christian Goetze wrote: > I believe the main challenge is to rebuild all the third party > dependencies in 64bit ... Rofl - something that LL certainly isn't capable of ;) Loads of third party viewers have done this already however. I have never used anything else than a native 64-bit build, ever since I started using SL. -- Carlo Wood ___ 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] tired of the bad testting
On Mon, 26 Mar 2012 12:15:20 -0400 "Oz Linden (Scott Lawrence)" wrote: > On 2012-03-25 23:56 , Flats Fixed wrote: > the latest stable came out. it broke the teleporters at 2100 meters. > you know guys this is not a jira this is simple testing. love the > new policy but the fact is the team is running people out of SL. test > it befor it goes stable. > > Perhaps you could provide a clear problem report? > > What software were you using? The latest stable. > What did you do? Try to teleport back after teleporting to 2100 meter. > What did you expect to happen? The same as with the older viewers. > What actually happened? It didn't work. ___ 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] Pathfinding alpha announced
On Fri, 17 Feb 2012 22:33:59 -0200 Tigro Spottystripes wrote: > Wouldn't it be better if the "types" for the diffferent Walkable > coeficients were bitmasks instead of just A, B , C, D? Or perhaps > even just an editable list of IDs (integers values) and the > associated weights for each integer Don't try to have influence on what LL designed behind closed doors. It is already set in stone. -- Carlo Wood ___ 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] Inventory Patch you should integrate
On Thu, 9 Feb 2012 20:14:10 +0100 Henri Beauchamp wrote: > On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote: > > > Henri, that protocol is not subject to change at this very late > > date. > > LOL !... You are kidding me, right ?... What's the use to ask for > feedback if everything is already settled ?... That got to be a > (very bad) joke !!! This is exactly what you can and should expect from Linden Lab by now... When did they EVER really listen? -- Carlo Wood ___ 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] Mesh viewers and tcmalloc issues
On Sun, 2 Oct 2011 10:20:47 +0200 Henri Beauchamp wrote: > Really, the only true motivation behind the use of tcmalloc in mesh > viewers (it was not use for non-mesh viewers) is to provide aligned > allocations. Without it, and the way the mesh viewer code is written, > the viewer simply crashes as soon as it tries to perform an SSE2 > operation on an unaligned structure. Use _mm_malloc, if that doesn't exist use posix_memalign and if that also doesn't exist, just use malloc. That will work (for sse2 alignment). tcmalloc is to get speed from not having to lock threads when they allocate memory: they each have their own pool. I never saw any evidence that the main thread is waiting considerable long times (ie > 10 usec) on a lock in malloc because other threads are trying to alloc/free memory, so I don't see the need for tcmalloc in the viewer. I think LL fell in love with it for their server, but the decision to use it for the viewer is wrong. -- Carlo Wood ___ 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 will not be automated
Draw distance never makes a significant difference for me. Strange actually, cause I think it should... But it's not a very important factor it seems :/ Something that seems to correlate a lot with a low FPS is the number of avatars that have to be rendered. On Sun, 19 Jun 2011 06:49:19 -0400 "Oz Linden (Scott Lawrence)" wrote: > This has gotten a bit out of hand... We are absolutely not going to > automate draw distance. > > This got started as a speculative discussion that forked off of the > draw distance slider in which I asked whether or not it might be > possible to create a system that _if_explicitly_requested_, some > smart software could look at what factors in a users configuration > might be changed to improve FPS and advise the user on changes that > might improve performance. While DD might be one such parameter, > the system I asked about would not be an interesting contribution at > all if it were the only factor, and I never envisioned a system that > would actually change anything automatically - it would inform and > educate the user as to what settings changes might be made to improve > performance. > > > ___ > 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 -- Carlo Wood ___ 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] More proposals for draw distance slider icon (Mike Chase)
On Tue, 14 Jun 2011 13:49:30 -0500 Daniel wrote: > For the icon, label it "DD" for draw distance. That will fit in > 16x16 pixels, and not conflict with other symbols. I like this idea. Made an icon for it: -- Carlo Wood <>___ 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 viewer -- draw distance slider
I think that no matter what you draw, the icon will not be clear to the majority of people. The icon only needs to be recognizable to those who saw it before. They will have to learn it's meaning from the tool tip imho. Nevertheless, binoculars are usually used for either zoom or search, so I think another icon would be better. Thinking about an avatar with a (half) sphere around it, I'd use as icon a circle with a dot in it, or a half circle with a vertical line in the center, ie: _ - _ . . / O \ --|-- On Mon, 13 Jun 2011 12:14:11 +0200 Opensource Obscure wrote: > While clear, such an icon doesn't look much self-explaining to me > with regard to its associated Draw Distance functionality. > > I still feel binoculars may be the best option. > > Binoculars may not be a commonly used glyph outside of SL, > but it's a fact that many Second Life features are just .. not > commonly used features. In most applications / online services / > information environments or RL appliances, you just don't have the > concept of "Draw Distance" or anything similar. > > On Mon, Jun 13, 2011 at 11:49, Hitomi Tiponi > wrote: > > Yes it's possible (see attached) - but something like that says > > 'landscape' or 'plants' to me. > > > > > > From: Argent Stonecutter > > To: Hitomi Tiponi > > Cc: a...@skyhighway.com; opensource-dev@lists.secondlife.com > > Sent: Mon, 13 June, 2011 1:58:54 > > Subject: Re: [opensource-dev] Review viewer -- draw distance slider > > > > On 2011-06-12, at 17:30, Hitomi Tiponi wrote: > >> /me looks forward to seeing someone draw this one in a 16x16 pixel > >> grid :) > > > > I think three small pine trees could be rendered in a 16x16 grid. > > > > ___ > > 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 > > > > > -- Carlo Wood ___ 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 viewer -- draw distance slider
If you like Snowglobe v1, then why aren't you using Singularity? http://www.singularityviewer.org/downloads It's been worked on hard to make it entirely Viewer 2 engine with a viewer 1 UI. It's perfect. It's also incredibly much faster due to other improvements ;) On Fri, 10 Jun 2011 20:59:38 -0700 a...@skyhighway.com wrote: > Guys, the whole thing with the easily accessible slider for draw > distance is really great! Inspiring, actually. It's almost enough > to make me wanna try out the v2 viewer again. i hope the feature > gets back-ported to Snowglobe v1 by someone better at that stuff than > me. > > The binocs idea for the icon is the best! It's totally like the > average person is going to think about it. And it's the way our eyes > work. Maybe spend time coming up with the best binocs icon or icon > loc so it doesn't get confused with what everybody sees for "search" > everywhere, but i can't think of anything better unless it was a > magnifying glass (also over-used), eyeglasses, or a telescope. Maybe > somebody wants to look at a collection on the web of what camera mfrs > put on their focus buttons? (Maybe just the word "ZOOM" instead of an > image?) > > And, being able to pull it down as far as possible is a good thing. > Sometimes in tight spaces with lots of avis anything else is just a > waste. Or distraction. Or both. And however far out it can go, even > for short periods or whatever would be awesome! There's the maps and > then there's actually being able to *see* what's up. But one thing i > don't think i've seen in the discussion, wouldn't it be a good idea > to have an auto-reset take place on every tp? Have it go to some > standard value that works pretty good most places, and it'll save > forgetful or excited people problems. i mean, if the control is > right there and easy to adjust, why not make it more useful than just > improved eyesight? > > Thx again! You guys are great! > > - AK > > > In case you missed the message from Oz in a different thread here is > the review viewer for the proposed draw distance slider: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repooz_project-3/rev/232119/index.html > > There is a temporary binocular graphic next to volume slider where you > access the control from. > > There is discussion within LL if this will be taken in. The concerns > are for new residents 1) having too many options on the screen and 2) > performance or experience issues if the slider is moved too far in > either direction. > > Please write back with your feedback, > > -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 -- Carlo Wood ___ 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] STORM-243 - simulator version notifications
Delete! On Tue, Jan 18, 2011 at 10:22:45AM -0500, Kent Quirk (Q Linden) wrote: > Hi, folks. I've just commented on STORM-243, which requests that we have Yet > Another Option to allow suppression of the toast that tells you the simulator > version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions live > on the grid at any time? I don't mean "I can think of an obscure scenario > when someone might care." I mean does anyone really need a notification about > this, or can we just delete it? > > ___ > 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 -- Carlo Wood ___ 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] Very Strange occurrence...
On Wed, Jan 05, 2011 at 04:44:31PM -0500, Kent Quirk (Q Linden) wrote: > So the reason that semi-plausible strings are used for these things is that > they're the only strings available when we use the test floater feature from > the login screen. > > But we should probably try not to use real names. > > And yes, Jonathan, these should mostly never be visible. But sometimes things > happen. Nevertheless, it is a bug; if whatever failed is outside the influence of the viewer itself, then still it should not have shown this. The viewer should be fixed to show the account name, or at least the UUID, in this -hopefully- rare case. -- Carlo Wood ___ 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] Inventory incremental search (VWR-23712)
One reason that it's collecting dust might be that it isn't know if the author of the patch signed the Contribution Argeement. On Tue, Jan 04, 2011 at 03:32:45PM +0100, Satomi Ahn wrote: > Hello and happy new year. > > I hate spamming this list, but there is an easy bug I'd like to see > fixed in the viewer, and which seems to have been only taking dust in > the JIRA for two entire months. > > This is about one of the bugs who contribute to the general feeling of > sluggishness in Viewer 2, so I believe you should really consider > inclusion in viewer-development ;-). > > Enough spoken, everything is there, patch included: > https://jira.secondlife.com/browse/VWR-23712 > > -- > Satomi Ahn > ___ > 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 -- Carlo Wood ___ 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] Very Strange occurrence...
It is still a (serious) bug. The viewer should have showed '???', not Grumpity. On Wed, Dec 29, 2010 at 08:44:02AM -0800, Brian McGroarty wrote: > That was the result of a brief load server configuration problem yesterday, > and > it shouldn't repeat. The message didn't come from Grumpity, and the response > wouldn't have gone back to Grumpity either. The viewer simply didn't know > which > cached name to use. -- Carlo Wood ___ 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] Indicating privacy implications of preference settings (was: STORM-34 Test Binaries)
Ok, good points. I take back what I said :). The best way forward seems to put it where people might first look and then make clear that everyone can see them with text right there. On Tue, Dec 28, 2010 at 10:58:01PM +0100, Boroondas Gupte wrote: > On 12/28/2010 09:40 PM, Celierra Darling wrote: > > It seems a little unclear to try to communicate "this can have privacy > implications" by putting the setting on the privacy tab. It might be > better to write the setting label so it's more explicit (i.e. something > like "Show my favorites to anyone under 'Start At' before logging in" or > "Show my favorites under 'Start At' on login (before authenticating)" or > etc.). > > I have to agree that placing settings on the "privacy" tab is not a good way > to > indicate the fact that they have privacy implications. It goes against the > principle that a setting should be placed where users expect it. I.e., if you > know (or suspect) a setting exists, but don't know where to find it, where > would you first look for it? Education about the consequences of changing the > setting can be postponed until after you found it. > > Of course, besides looking at tab labels, placing similar or related settings > together can help in finding them. But the common property "affects privacy" > seems to me too week a reason for placing settings on the same tab, when that > property is not the goal of a setting but rather a side effect (even although > a > side effect inherent to the goal itself, not just to the setting's > implementation). > > Further, when a user finds a setting on the "privacy" tab and realizes this > placement means the setting has privacy implications, how would she or he know > whether enabling or disabling the setting grants higher privacy? Of course, if > one can derive from the description of a setting what it actually does and > then > thinks it all through, one gets the answer as well as how one's privacy would > be affected. While the users are probably well capable to do that, do they > want > to do that—when they could just as well be told openly about the setting's > effect, e.g. like in Celierra's labeling proposals above? > > Boroondas > ___ > 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 -- Carlo Wood ___ 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] STORM-34 Test Binaries
> I kinda have to agree with hitomi. I agree with Andrew; it's a privacy sensitive thing and users shouldn't accidently flip it without thinking because it's on the normal 'General' page. If they need or want it, then I'm sure they'll find it, like they find everything else. Also, it will take a while before a user needs links to favourite places on their login page: those are not newbies. It's sufficient to put the option in a place that requires more knowledge (and exploration) of the viewer interface. -- Carlo Wood ___ 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] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23")
I can't believe that it isn't possible to create a LM without going there, precisely for this reason. What LL might really mean is that they can't check if it's allowed to *create* a LM without going there first. So, it's a permission problem. But, since there clearly is a way to attempt to go anywhere (by using the map, or an slurl) that whole 'permission' thing is flawed. It's meaningless. I used to have a sim and I didn't allow people to create a LM (I only wanted them to there when I (or another resident) actually was there, and invited them over. However, once they got (group) access, they came anyway, without being invited... I asked how, and they said: simple, I clicked on the map. The problem here is therefore (imho): LL needs to understand it is impossible to control whether or not someone creates a LM and allow us to write code that creates arbitrary LM's for any place, without going there first. On Fri, Dec 24, 2010 at 12:17:21PM +0100, Opensource Obscure wrote: > On Fri, Dec 24, 2010 at 11:03, Vadim Savchuk > wrote: > > > Do you mean creating a landmark in your inventory by pasting a SLURL? > > I'm not sure that's possible: AFAIR, to create a landmark we perform a > > request to the server, which creates landmark of the current location in our > > inventory. The protocol doesn't support remote locations. > > sorry, I was not clear (ouch, my English!) > > What you described is exactly the problem I have with landmarks. > Having to teleport somewhere to get a landmark can be a PITA. > I remember LL confirmed there are no workarounds for this > (as you said, it's a protocol limitation). > > What I was thinking about was a new, different way to achieve > something we usually achieve through landmarks.. > (find a place in our Inventory + teleport there + optionally > share that place reference with other users) > ..a way that could avoid that very limitation you mentioned > (the need to be in a place in order to create a landmark). > > In the past I often didn't use landmarks - instead I copied SLURLs > from web pages and paste them into local chat, then click over > the links, then teleport. > Thanks to some new features, this is now less useful than in > the past - but I think some 1.x viewers users still do this. > > Going through local chat is clearly lame, and confusing for > people around you. That's why I said I would like to > "copy/paste" a SLURL into Inventory, create > (not a landmark) and then clickit to teleport. > I'm thinking about management of Bookmarks in current > main web browsers, where you're allowed to edit > both name and destination of a bookmark, tag it, > assign to multiple folders (or tags). > > Does this make sense to anyone here? > > Opensource Obscure > ___ > 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 -- Carlo Wood ___ 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] Linux 64bit and gstreamer
On Fri, Dec 10, 2010 at 09:33:36PM +0100, Altair Sythos Memo wrote: > On Fri, 10 Dec 2010 12:51:54 -0500 > Mike Chase wrote: > > > Hi all, I have a new machine coming and given the amount of memory it > > has I'd really like to run it 64bit linux (probably ubuntu). I'd > > really like to stay with the ability to run SnowStorm (and the Mesh > > viewer builds). Can someone point me to a summary of 64bit support > > for Linux for that series of viewers? I know in the past I was able > > to run a 32bit version but with no streaming media. Thats a non > > starter for me as I own a club in SL and its kinda nice to be able to > > hear what's being played in the club. > > sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl Huh huh... No need to install 32bit libs! Just compile the viewer yourself! I've been running native 64 bit since day one. -- Carlo Wood ___ 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 v2 progress update
I thought that the big problem with openjpeg v2 is that it doesn't deal with partial streams correctly. Has that changed? On Wed, Nov 10, 2010 at 05:19:52PM -0600, Sheet Spotter wrote: > In the last few days I learned that the current viewer patches for OpenJPEG v2 > (i.e., http://jira.secondlife.com/browse/SNOW-361 ) do not produce a usable > viewer. Decoding a truncated image will report a warning of “Stream has > reached > its end” or “Stream too short”. Almost the entire scene is rendered in gray. > > My focus is now shifting from working on a faster OpenJPEG v2 to ensuring that > OpenJPEG v2 will produce a usable viewer. > > I am interesting in hearing from anyone else (publicly or privately) that has > made progress in creating a usable viewer with OpenJPEG v2. -- Carlo Wood ___ 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] LGPL violation
On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote:
> On 10/28/2010 06:29, Carlo Wood wrote:
> libmedia_plugin_webkit.{sp,dll,dylib}
>
> Make sure you quote examples of static linking when you're talking about
> static linking :)
Make sure you read carefully what I say and understand it before
talking about wrong examples :)
libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with
the Qt libs (as in, linked with .a).
Thus:
Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so
==> LL*.o must be made public (or their source code), or
libmedia_plugin_webkit.so cannot be shipped.
--
Carlo Wood
___
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] LGPL violation
On Wed, Oct 27, 2010 at 10:17:01AM -0400, Oz Linden (Scott Lawrence) wrote:
> On 2010-10-23 7:27, Carlo Wood wrote:
> > I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed
> > library statically against a proprietary executable provided you
> > provide the object code or source code of the work that uses the library.
>
> Not correct. LGPL code may be linked to other source without having the
> viral effect of requiring that other source also be published as open
> source. LGPL _does_ require that if any changes are made to the source
> under that license, then those changes (and the original sources) must
> be open and available either as LGPL or as GPL.
You state pretty firmly, while I believe you are in error.
You are NOT allowed to link statically with an LGPL-ed library unless you
provide the means for the user to relink the library, for example by
providing the .o (object) files that it is linked with.
>From many available links, let me quote an answer from
http://answers.google.com/answers/threadview/id/439136.html:
Q2a: What is the implication of static linking?
A2a: You need to comply with the license requirements. Eban Moglen in
http://www.spinics.net/lists/xf/msg02311.html
indicates that you are producing a "derivative work" of the code in
the library. In the United States the US Copyright Office states at
http://www.copyright.gov/circs/circ14.html
A "derivative work," that is, a work that is based on (or derived
from) one or more already existing works ... [copyright statements].
Both of those statements are pretty clear so section 6 of the LGPL
applies. Note that you can distribute (6a)
... [your work] as object code and/or source code, so that the user
can modify the Library and then relink to produce a modified
executable containing the modified Library
You can thus distribute object files (and protect your source code)
and still comply with the requirements of the LGPL.
However, others (in particular, Richard Stallman) does not necessarily
interpret the LGPL in this way. I strongly recommend you contact the
copyright holder prior to building a statically linked application for
distribution as a commercial product.
In this case, you'd have to contact Troll Tech and ask them if even
this is allowed, but at the very least you can NOT distribute
libmedia_plugin_webkit.{sp,dll,dylib}, which is statically linked
with Qt, without at least providing the object files that it exists
of (in addition to Qt), that you are the copyright holder of.
I think this is extremely logical: The user must at all times
be able to get the source code of the LGPL-ed library, change it,
and *RELINK* it with the application he or she is using.
The BSD guys have a different view though (just to make clear that
you completely orthogonal view really ought to be backed up by one
of your lawyers). Quoting
http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html#ORIGINS-LGPL
(where 'glibc' is used as an example of an LGPL-ed library):
If you statically link an application with glibc, such as is often
required in embedded systems, you cannot keep your application proprietary,
that is, the source must be released. Both the GPL and LGPL require
any modifications to the code directly under the license to be released.
--
Carlo Wood
___
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] LGPL violation
I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed library statically against a proprietary executable provided you provide the object code or source code of the work that uses the library. In other words, it must be possible to make changes to Qt and *relink*. Translating that idea to linking statically with a shared library, it is clear that one still has to be able to make changes to Qt and relink, or they are non-compliant. This means they must provide all the object code that was used to create (link) libmedia_plugin_gstreamer.so, or they must provide the source code so that people can generate this object code themselves. Imho, the only practical solution is to make the source code availabe, and most likely just all the source code of the whole viewer. On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote: > Not sure this is worth sending to the list, but could you clarify that .so > files are statically linked to the executable that they are loaded into? This > is a bit confusing to me. > > Or are they considered statically linked if you use the default dynamic > loading > logic, rather than hand-coding GetProcAddr calls or equivalent? Nah - none of that. libmedia_plugin_gstreamer.so (the extension is different on OS other than linux I guess) is a shared library. However, it is constructed by linking statically with a modified version of Qt that was created by LL. Obviously, the users need to know what those mods are and they should be allowed to make changes of their own. For example, someone who already made changes to this version of Qt would not be able to use the mesh viewer until LL releases the full source code, so they are non-compliant if they release a 'beta' version of a viewer without providing the means to re-link libmedia_plugin_gstreamer.so with a different Qt. -- Carlo Wood ___ 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] (CTS-315) march choice for 64bit builds
Why is SSE2 required now? Sorry if I missed this. On Sat, Oct 23, 2010 at 03:08:26AM +0200, Boroondas Gupte wrote: > Because SSE2 is now required anyway, -march=pentium4 is now passed for > building > lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. > (See > CTS-315.) What should march be set to for 64bit buids, if anything? -- Carlo Wood ___ 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] Mesh Source Code ETA
On Thu, Oct 21, 2010 at 08:56:32PM -0400, Zabb65 wrote: > They have only said they would release source, though they do not have > to release it. They are doing so out of their own good will as a > company, not by legal obligation, please remember this. I suspect they That is not entirely true... You see, they link the webkit plugin statically with Qt code (LGPL), which demands that whatever the resulting code is, is GPL or LGPL. So, if they release a binary that includes a libmedia_plugin_gstreamer.so, which is linked statically with pure LGPL-ed code, then they are legally oblidged to provide the source code of libmedia_plugin_gstreamer.so. Now if LL decides to JUST provide the sources of that plugin lib, or just put the whole mesh repository that was used to compile it on the net, is entirely up to them, of course. -- Carlo Wood ___ 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] Fermi Viewer
Imho, it is not a good idea to start yet-another-viewer. The number of open source coders are limited, they should be working on one viewer - not twenty. We already have more than 10 different viewers based on LL's code. How is it possible we need another? On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: > Fermi Sandbox is looking to put together a team to develop the Fermi Viewer. > Please send inquires to arthur_fe...@fermisandbox.org or in world. > > > > Mission > > The Fermi Viewer projects goals are to create the best viewers for Second Life > that works with all OS Grids. The Fermi Viewer will be open for all to review > and look at, and all in house code will be generated and provided to the > community. > > > > Project Overview > > The Fermi Viewer project will generate 2 separate viewers, one will be a full > featured viewer along the lines of emerald, this will be a general viewer with > a focus on building and sim management. The second view will be as light > weight and fast as can be made, it will have building and sim management as > its > only focus with as many non-essential items moved out. > > Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. A > Version 2 viewer will come later in the project when time and resources are > available to dedicate to a redesign of the interface. > > > > Open Source > > All work coming from the Fermi Viewer project will be returned to the > community, this is a 100% open source project. > > > > Code Review > > All code other than the Linden Labs provide source code will be reviewed by a > peer review committee to ensure that it complies with privacy standards. Once > code is has been reviewed it will not need further review unless it has > changed. > > > > Viewer Privacy Policy > > The Fermi Viewer will contain no code that will gather any information other > than is required for interoperation with the grid it is connected to. No > information will be stored off the client computer, no anonymous tracking data > will be collected. Any violation of this policy will result in the instant > removal from the project. > > > > Arthur Fermi > > > > ___ > 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 -- Carlo Wood ___ 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] fix System.InvalidCastException (was again about scripting issues)
Wow, very good miss! I think that last url is one that Linden Lab should study very closely. I too think that this will the solution for their problem. On Sun, Oct 17, 2010 at 02:43:29PM -0700, miss c wrote: > https://bugzilla.novell.com/buglist.cgi?quicksearch=System.InvalidCastException > > .The bug is listed 5 times... > > > on one of these someone fixed the issue > https://bugzilla.novell.com/show_bug.cgi?id=619929 -- Carlo Wood ___ 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] O.O Display name code DROP!
On Fri, Oct 15, 2010 at 04:53:05AM -0700, Stickman wrote: > If it's not, the Lindens should be waking up soon and see a huge > thread of people screaming that the sky is falling and put some > authority down on the situation. HAHAHA (not) As if they care. You still don't know them do you? -- Carlo Wood ___ 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] O.O Display name code DROP!
On Fri, Oct 15, 2010 at 04:47:21AM -0700, leliel wrote: > On Fri, Oct 15, 2010 at 4:38 AM, Carlo Wood wrote: > > I was hoping that log files are updated very > > frequently, so that if I crash I don't lose > > text. But writing several megabytes to disk > > every line of chat seems unfeasible. > > It's 115 bytes + display name + message per line. Just where are these > several megabytes coming from? -rw-r--r-- 1 carlo carlo 60282480 Sep 28 00:30 chat.txt That is 60 MB. And that is BEFORE we're using LLSD. -- Carlo Wood ___ 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] O.O Display name code DROP!
I didn't know LLSD was capabable of appending, does this new format mean that my 50 MB chat.txt file is going to be re-written from scratch, every time I sync it with the latest chat? I was hoping that log files are updated very frequently, so that if I crash I don't lose text. But writing several megabytes to disk every line of chat seems unfeasible. So, how is this appending being done? -- Carlo Wood ___ 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] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES
Welcome to open source viewer, closed source server. On Sun, Oct 03, 2010 at 10:27:52AM -0400, malachi wrote: > could we please take 5 minutes away from the client that we all obviously > have our second thoughts about to begin with. and focus on grid > infrastructure. > > i honestly dont care if i am forced to use the dreaded 2.x client. if the > grid actually responded to something you did. things like just loading my > clothing. or if i save a script it should still exist after i close the > edit box. but the fact that any script added to a prim inworld gets eaten > and destroyed server side is a huge issue. could LL drop the client work > for 5 minutes and see what is going on on the server? or is that too much > to ask? because as it seems over the last few weeks its been new client > code new client code new client code while the server just gradually falls > off a cliff. what good is a client that runs like fiber when the server it > connects to only speaks in dialup? > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > ___ > 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 -- Carlo Wood ___ 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] Did I break my repository...
Try running: scripts/install.py --list-installed and then scripts/install.py --uninstall the whole list here Then run configure again, it should download everything again. If you remove the whole viewer-linux-* directory (or whatever you build directory is) and reinstall all prebuilts like above and it still fails then either your environment variables are very in the way (ie, you have set LD_LIBRARY_PATH to somewhere with broken libraries, or you have set CXXFLAGS without something horrible etc), or you screwed up your local tree (which you should be able to detect with 'svn status' of course). On Sun, Sep 26, 2010 at 06:09:44PM -0400, Ponzu wrote: > Since I downloaded the latest viewer-develpment yesterday, by local build is > broken. The symptom seems to be that the local artwork is not being found. > For example, the XUI is mostly just plain gray. The buttons on the bottom are > just gray rectangles, etc. > > > • I tried running develop.py again. It says the art work is there. I did a > clean and build. Same same. > • I clone viewer-development, and then pull to there, and update. > • I cloned that to viewer-ponzu, that is the one that is broken. > > > Any ideas welcome. Do not waste a lot of time ont his, I can always just blow > away my repositories and start over. > > Ponzu > ___ > 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 -- Carlo Wood ___ 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] crazy land idea
Hmmm, yes. There is more use to detecting "being inside a prim" and toggling certain render types as a result it seems. Now, an easy way would be to detect if the CAM is inside a prim, and then turn off -say- water fog, or whatever causes one to appear being under water; or turn off rain/snow if that is turned on. However, if then you look out the window, it stopped raining outside too.. so that isn't good enough. On Sun, Sep 26, 2010 at 09:46:09AM -0400, Tammy Nowotny wrote: > This is purely anecdotal (though maybe someone knows more than my anecdote): I > have heard that the SL game engine is not good at determining which points are > under/above/inside an enclosure such as a building. Moreoever, legend has it > that there is a whole weather system in the engine which was never activated > because there was no way to stop rain, snow etc. from going through roofs, > walls, etc. -- Carlo Wood ___ 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] crazy land idea
Each land and water patch is really a very big prim that you only see one side of. If you'd want to suppress a part of that side, you'd have have to start cutting it into pieces I think. The number of water and land "prims" would increase a lot if you sink a lot of prims into them this way. I like the idea. It's probably not COMPLETELY trivial though. -- Carlo Wood ___ 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] Blocking viewers.
This is not a bad idea at all, except that LL is here for the money so they will refuse it. But opensim might use the idea. You just have to adjust a bit ;). Instead of having people pay for a server 24/7, you could allow them to pay for a certain period of the day (many would find 2 hours per day enough). Then the same machine that would host their sim could be used for other sims during the other 22 hours. I'm sure that with that method it should be possible to cut the price of sims to 25%. But then again, Linden Lab is about to screw us all already in this regard by going to limit the resources of every (private) sim to the tiny share that one would have when the sim is fully loaded. So, that means that you can only use those resources that otherwise would have been available if the sim was loaded to the max 24/7 (which is clearly isn't the case on 99.9% of the sims). As a direct result the same hardware can be used for more sims at the same time while you still pay the same (using virtual hosting). The price SHOULD be cut to 10%, so in effect it's the same idea, but now with all financial benefit exclusively for LL. On Thu, Sep 09, 2010 at 09:28:06AM -0400, malachi wrote: > or we could do what that one episode of the outer limits called stasis > where they take and split the population of the world into 3 groups. > alphas betas and elites. then every 72 hours the alphas and betas switch > on a cryogenic freeze. half the population sleep while the other half run > about working and what not. and the elite stay away all the time. Lindens > are the elite i suppose. now if we can just get the system to let only > half of the people log in for 3 days. and the other half stay offline. and > alternate. we would experience much less lag i think lol -- Carlo Wood ___ 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] This is how Linden Lab treats it's customers...
Sorry, but you are ignorant. A running sim is being paid for. That money is paid to Linden Lab. It doesn't matter if that money was first paid by a grandmother to her grandson, then double by gambling in the casino and subsequently paid to some random stranger on Xstreet who give L$ for it, which then were paid to some untrusty game-landlord who gave the game money to yet another random stranger on Xstreet for which he recceived real dollars which then finally are paid to Linden Lab. Namely, if the guy actually using the sim doesn't want to pay for it, the sim can't run. The fact that it runs means someone pays for it and you can bet on it that that comes from the wallet of the person using it (living on it). So, in this case the sim was running a year aka $100 per month. Now the sim isn't running anymore and this income of LL stopped. The renter then offers to continue renting it for $100 per month, by paying *directly* to LL, but that is not accepted. It is this last thing that is ridiculous. Or at the VERY LEAST it should be (or have been) possible to rent an isolated/private homestead directly from Linden Lab. Don't say that 'L$' isn't real money so one has no rights. This is not about what a RL lawyer would say, this is about common sense and people being pissed off till they vomit and want to run away screaming from SL, or at least from Linden Lab. On Sat, Aug 28, 2010 at 11:51:03AM -0400, Joel Foner wrote: > Quick note... if the $100 a month, if this is rent, is not being paid to > Linden > Lab if you're renting. It's paid to another avatar... different picture... It > seems to me the slap in the face is a landlord who does this to a large number > of tenants without notice, actually. > > Joel (also going back to lurking) > > On Sat, Aug 28, 2010 at 11:42 AM, Darmath wrote: > > On 29/08/2010 1:23 AM, Gareth Nelson wrote: > > and pointing out that LL have no contract with tenants of > > rental regions - tenants of such regions are thus not customers. > True. But a premium account holder is a customer of LL. "And to say well > we dont want you $100 a month because your not a full sim owner" is a > slap in the face, period. FWIW i'm a premium account holder...whose now > returning to lurking. > ___ > 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 -- Carlo Wood ___ 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
On Wed, Aug 25, 2010 at 10:16:22PM -0700, Erik Anderson wrote: > " at the end (this is > ). I'm guessing that it > is > thought that no one would notice these unless they were looking for them. Surely you mean ? Because after a quick look it's clear that is the '0' and a '1', so that my version spells 01000101010001010010 = 4F 54 52 = ascii for "OTR" -- Carlo Wood ___ 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
Nevermind, I should have read the rest of the thread first. Looks like a pretty solid protocol. Does anyone know if it is possible for an arbitrary TPV to start an OTR with another TPV? If so, how? Or is it needed to be recognized by the other viewer as being a viewer that has OTR implemented? How do two viewer know if they both can do OTR? On Thu, Aug 26, 2010 at 02:53:25AM +0200, Carlo Wood wrote: > On Wed, Aug 25, 2010 at 01:59:49PM -0700, Brian McGroarty wrote: > > Has anyone spent time looking at the encrypted chat feature included in some > > third-party viewers? It's my understanding that this contacts third-party > > servers in obtaining and validating keys. Is that correct? > > If that is correct, then I'm pretty sure that the owners of > those servers have access to a key that would allow them > to read the encrypted messages. Imho, that is not acceptable :p > > Perhaps in time I'll be interested to implement a better > method. > > Carlo Wood (author of libecc > http://libecc.sourceforge.net/reference-manual/index.html) > ___ > 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 -- Carlo Wood ___ 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
On Wed, Aug 25, 2010 at 01:59:49PM -0700, Brian McGroarty wrote: > Has anyone spent time looking at the encrypted chat feature included in some > third-party viewers? It's my understanding that this contacts third-party > servers in obtaining and validating keys. Is that correct? If that is correct, then I'm pretty sure that the owners of those servers have access to a key that would allow them to read the encrypted messages. Imho, that is not acceptable :p Perhaps in time I'll be interested to implement a better method. Carlo Wood (author of libecc http://libecc.sourceforge.net/reference-manual/index.html) ___ 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] VWR-20879 - Fix packaging/staging for VC Express
I don't know phyton, but looking at the patch the following question comes to mind: This first looks for VisualStudio/8.0, and then for VisualStudio/9.0 then for VCExpress/8.0 and finally for VCExpress/9.0. Is it possible that a different order of searching would make more sense in some cases? On Sat, Aug 21, 2010 at 09:36:12PM +0100, Robin Cornelius wrote: > In Oz's spirit of do first, talk later:- > > http://bitbucket.org/robincornelius/viewer-development-vwr-20879/changeset/994d4512db23 > http://jira.secondlife.com/browse/VWR-20879 > > If someone could review then add to the backlog etc, with this applied > i can build and package viewer-development out of the box and a full > version of VS also builds normally. > > It is currently synced with viewer-development and i can resync as > necessary depending on its position in the queue. > > Robin > ___ > 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 -- Carlo Wood ___ 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, again.
I'm not a Linden, but I think the answers to your questions exist before they are implemented :p. > 1. Will there be procedures in place to prevent someone else to use my > true avatar name as their display name? No, the display name will be distinguishable by color or graphical-something around it (that therefore cannot be faked or changed by changing the display name). > 2. Will there be procedures in place to prevent someone from using a > display name that might be different from my true avatar name but for > all visual verification looks like it, given how there are unicode > characters that have a different code but look like regular > characters? That would be impossible, hence the use of colors or other markings completely OUTSIDE the (control of the) displayname / username, see point 1. > 3. Will there be procedures in place to prevent the case where someone > uses a copyrighted name of a fictional character (like, for example, > "Mickey Mouse" or "Clark Kent") as their display name? I hope not. Once you're finished with filtering all welknown characters in history, all company names, and all profanity, and then went on to attempt to also filter anything that LOOKS like it (M1ckey Mous3), the server would spend 99.5% of it's time on checking is display names are allowed (and still fail). > 4. If the answer to any of the above is not a clear and loud yes: Will > there be procedures in place to protect the original holder of any > true avatar name from legal damages after someone used their name as > their display name for fraudulent uses? I'm starting to feel sick. "Mom! Paul drew 'Carlo' in the sand of the sandbox and then he said 'this is me!'. Now he's peeing on Mrs..." TATUUTATUUU *policemen storming the sandbox and pushing totler 'Paul' face down in the sand 'YOU ARE SURROUNDED! GIVE UP YOUR WATER PISTOL, heh, GIVE UP YOUR SUPER SOAKER 2010! ANYTHING YOU SAY WILL BE USED AGAINST YOU AND YOUR PARENTS!' Welcome to America -- Carlo Wood ___ 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?
ROFL - unique display names Well, I suggested the same, but per SIM -- not globally :p Making them globally unique would kinda void the whole reason they are being introduced imho. I think I saw a very strong argument posted here about not automating anything though: It's near 100% sure that people will be able to LOOK like having the same display name while no computer will be able to notice that. I think that using a different color or rectangle around display names (or user names) to differentiate them is the way to go to make sure nobody will ever think that a display name is someones user name. On Thu, Aug 19, 2010 at 08:08:07PM -0400, mysticaldem...@xrgrid.com wrote: > Seems like twitter has a pretty good solution. Display names are unique. And > your login account isn’t public so you have better security. Default your > display name to your current SL name. After that people can request the name > they want. As far as scripts, chat, everything else, that use your text > version of your name, they all change on other systems and we get by. > > > > Mystical -- Carlo Wood ___ 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 Fri, Aug 20, 2010 at 12:13:42AM +0200, Lance Corrimal wrote: > Totally not. It should even trigger an automated AR for impersonating, Please no. > together with a warning message sent to the current holder of the > login name... "johndoe1234567890 tried to set his display name to your > login name. the resi team has been notified." As long as the viewer code can see the difference, leave it to the viewer codes (TPV's, and us too) how to make clear to everyone that a display name is a display name and a username is a username. No need for yet another way to Abuse Report someone :/ I'd suggest using some kind of colored ornament around usernames and/or display names. Or let the users choose in what color they want to display those names, using a default with two different colors of course. -- Carlo Wood ___ 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] Coping with duplicated display names.
While there may be 1 million users (at some time in the future) using Second Life, the display name would be used for distinguishing friends and people in your neighborhood. Being an old-time IRC developer, I see simularities with IRC nick names (that can collide) and how I'd have solved that if I had been given the chance :p. What I'd do is tag every display name (internally) with the time at which it was set. Then, when someone enters a sim where someone has the same display name, the youngest of the two is reset (the server could reset it to empty and ask at the same time for an alternative; the viewer could be changed to provide an alternative automatically, provided that didn't exist also already). An empty display name would result in the username being displayed, of course, which is supposedly unique. This would reduce griefing a lot, since you'd have to guess what display name someone is going to use before they set it. It would also reduce confusion because it would not be possible for two people to have the same display name when in the same sim. Most of this idea (adding a timestamp and comparing display names when someone logins in or teleports to a new sim; resetting it and asking for an alternative) is almost exclusively server-side though; not sure who to contact to propose it. -- Carlo Wood ___ 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] Update Linux Build Documentation, please?
I fail to see how this would solve the complexity that is currently on http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29 as that mainly deals with installing and finding system libraries (not the prebuilt ones) and with workaround of bugs of the build system. No matter what script you'd provide, all of that would still be needed. On Thu, Aug 19, 2010 at 11:32:35PM -0700, CG Linden wrote: > Of course I'd only do that -after- providing the shared build scripts. -- Carlo Wood ___ 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] To Pie or To List
I think that "Report Abuse" should always be the top-most menu entry in every menu, so that it's easy to find and quick to access. Report first, ask questions later. Why mute or TP away, or HAHAHA just be mature about something, when you can Run to Daddy Linden Lab and Report the suckers!!! On Wed, Aug 18, 2010 at 05:23:37PM -0700, Ricky wrote: > With the new menu, I've almost reported abuse/returned/etc my own > items. -1. It seems to me a little weird that those options show up > when clicking on something you are both the creator and owner of. > It's still a little weird even if not the creator, but still the -- Carlo Wood ___ 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] Snowstorm, JIRA and versions
On Tue, Aug 17, 2010 at 09:45:14PM -0400, Oz Linden (Scott Lawrence) wrote: > > for clarification...). If correct, I'll start moving JIRAs from SNOW > > to VWR when I see fit. > > That's correct. I can see some inconvenience arising from renaming SNOW's to VWR's. We use 'SNOW-xyz' a lot in (text) files to refer to the archive about it in the jira. I don't think that this link should be lost. In other words, a rename should not make it impossible to find it back under the original SNOW-xyz number. -- Carlo Wood ___ 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 Wed, Aug 18, 2010 at 11:41:38AM -0400, Oz Linden (Scott Lawrence) wrote: > We still do require a Contribution Agreement, for good and valid reasons I've > explained many times - most notably that it allows us to improve our license > in > the future. Had we not required the CA in the past, we would not have been > able to change from GPL to LGPL. A major disadvantage of the CA, however, is that you cannot use ANY of the improvements written by TPV developers. If it were possible to cherry pick the improvements of -say- emerald, then that would boost the usability of the viewer imho. In other cases you can almost speak of obstruction of progress: For example, I'd really like to see support of shared windlight settings. This has already been written and is in operation on certain opensim grids. However, we CANNOT use it! If we want this too (and we do) then we'll have to re-invent the wheel JUST because of this license problem. It's not just the extra time that that will cost, it's also necessarily going to using a different, incompatible format, which is going to be highly annoying for the currently existing implementors and their users. Without the CA, the source code would be TRUELY open in the sense that everyone would be able to use the code from everyone and improve on that. As it is, the Third Party Viewers will base their code on viewer-development and then add extensions that only they can exchange among themselves. Extensions that the users will need at some point, so that they HAVE to use a third party viewer. 'Viewer-development' in itself will no longer be used, except by total noobs who just learned about Second Life and were fooled into thinking that that viewer is usable by reading the "official" Linden Lab webpages (that no doubt will continue to advertise the "official viewer" and the Greatest) until a few weeks later one of their friends convinces them otherwise. -- Carlo Wood ___ 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] SNOW-774 "Bad LLMultiGesture version" (SG2.0 works, SG2.1 errors)
IF we had already hg (or git) instead of SVN, so we would really have every commit merged from viewer-external, then it would easy to find using a binary search method... I hope the move to hg is made soon, for many reasons. On Wed, Jul 28, 2010 at 12:16:29PM -0700, Dzonatas Sol wrote: > Hi, > > I have an issue I want to resolve. > > http://jira.secondlife.com/browse/SNOW-774 > > This message I notice from time to time in the error log. You have > probably noticed the message "Unable to load " where gesture is > one of many you have activated. > > There has been some change made between 2.0 and 2.1 that causes this, > yet it is hard to pinpoint the difference among the bulk commits. > > If no one replies to this then I'll assume it basically works for them. > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > ___ > 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 -- Carlo Wood ___ 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] Linux 64 bit libs / 64 bit non-standalone building
On Tue, Jun 15, 2010 at 10:12:00PM +0200, Lance Corrimal wrote: > tell me, how do YOU test a prospective new machine in the shop for "SL > on linux" compatibility? I pick each component separately and do extensive research on the net before I decide to use it. That being said, I think that these days anything will work with a little bit of effort. It's seldom that a piece of hardware is really not supported. I'm currently using the following configuration: - Motherboard: Asus P5B Deluxe - CPU: Intel Core 2 Quad QX6700 2.66GHz - CPU cooler: Scythe ZIPANG-2 - RAM: Two times a Kingston HyperX DC 2GB kit PC2-6400 800 MHz, LL (2x1GB) (KHX6400D2LLK2/2GN) CL 4-4-4-12 (you have to manually tell your BIOS to use that) (so, four DIMMs and 4GB in total, note that motherboard doesn't support DIMMs that are made of 16x 128Mb chips, so 2GB Kingston HyperX should not work). - Soundcard: Creative Labs SB Live! (EMU10K1) (much better than the soundcard on the motherboard). - Videocard: MSI GeForce 9600GT PCIe - Harddisks: Seagate Barracuda 7200.10 320 GB, 7200rpm SATA Three times Western Digital Raptor 74GB, 1rpm SATA (RAID5) - CDrom: Lite-On LH-20A1S 20x8x20x DVDRW, SATA - Powersupply: OCZ GameXStream PSU 700Watt, SLI, ATX/EPS12V - Casing: Antec P180B Super mid Tower Aluminium, ATX, black However, if it is SATA it will work, and the RAM doesn't have to do anything with linux either. The only thing you have to check for compatibility is the motherboard (and the controllers on it), and your videocard. The rest can't be a problem. And, as I said, I don't think those two are a problem either. I have currently videocard lock ups (only 3D) at random moments however. I'm not sure what is causing this instability... might be just a bad card :( I'm also not happy with the speed of my RAID. I'm going to add a 16GB RAM disk (ANS-9010) to speed up compiling of the viewer a bit more. Finally, the 3-speed fans that came with the casing (five 120mm fans!) all locked up, and cleaning them only helped for a while, so I had to replace a few of them with a constant speed fan. It took me a long time to decide on those components (several weeks)! -- Carlo Wood ___ 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] Linux 64 bit libs / 64 bit non-standalone building
> If you want to run the 32bit compile from 64bit machine, this page may help: ... this remark and the one from Lance... Tssk. +1 YES +1 to support for 64bit from Linden Lab! mumble...usb sticks and chroots... come on! Running snowglobe on a 100% 64-bit debian box for 1.5 years now, Carlo Wood ___ 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] Moving #opensl (IRC) to freenode.net
Since nobody reacts, I assume there are no objections. When are we going to move over? -- Carlo Wood ___ 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] Introduction
On Wed, Jun 02, 2010 at 11:51:11AM -0400, Monty Brandenberg wrote: > On 6/1/2010 9:30 PM, Oz Linden (Scott Lawrence) wrote: > > Conflict is > > fine - sometimes it's even productive, as long as it's done in a way > > that recognizes that everyone is > > ___ > > Sorry, people, Oz got into a fight. He'll pick this up again > after the beating... As inspector Clouseau already wisely said in one of his movies: "There is a time for fighting and there is time for not fighting... And the time for fighting is..." -- Carlo Wood ___ 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
On Sat, May 01, 2010 at 06:53:49PM -0400, Glen Canaday wrote: > Though WHY anyone wouldn't want to come HERE to talk about client > detection is far beyond my grasp. That's like AVG not wanting to talk to > Microsoft. Probably because it's a moronic asshole, who is only interested in making money with the product and doesn't care if 1% are false positives. Not until LL comes knocking on their door anyway. I guess that the only reasonable response (unless LL wants to get involved) is to find out how the detection works and write a patch that makes SURE it won't be detected (which then can be used by everyone, but malicious viewers will do this anyway, whether or not we do or not). So, how does this thing "detect" the mentioned "signature"? -- Carlo Wood ___ 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 blacklist to replace the TPV
On Fri, Apr 30, 2010 at 05:21:20PM +0800, Boy Lane wrote: > The questions I raised remain and I hope someone from LL can answer them. Lindens will only reply with already published official statements here, if at all. Ie, someone (once it gets Monday) will quote this from the TPV policy: 6. The Viewer Directory and Self-Certification [...] a. If you are a Developer with a Third-Party Viewer that you would like to list in our Viewer Directory, you must meet the following eligibility criteria: [...] iii. Your Second Life accounts must be in good standing, must not be suspended, and must not have been permanently banned or terminated; and [...] -- Carlo Wood ___ 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 blacklist to replace the TPV directory ?
I told everyone form the start that it was a VERY bad idea to add any viewer to it. This list should have stayed totally empty. On Thu, Apr 29, 2010 at 10:56:58AM +0200, Henri Beauchamp wrote: > Hi again, folks. > > Thinking about the TPV directory, I came to the conclusion that this > tool, first intended as an advertizing one, doesn't currently reach > its goal and even mistakes some users who think they will not be able > to use their favourite viewer after the 30th of April if it's not > listed in the directory: it is seen by many as a censoring tool. -- Carlo Wood ___ 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 has "Spare time" gone in 2.0 ?
On Sun, Apr 25, 2010 at 07:19:41AM -0500, Argent Stonecutter wrote: > On 2010-04-25, at 06:34, Carlo Wood wrote: > >On Sun, Apr 25, 2010 at 08:38:16AM +0200, Marine Kelley wrote: > >>Besides this entry is not even sent by the sim, it is calculated > >>by the viewer > >>as (22.5 - net - physics - sim - agent - images - script), > >>unless I'm mistaken. > >>It would be rather easy to put it in again. > > >That 22.5 seems a bit random ... perhaps it was changed already? > > That 22.5 is 1000/45. The sim is supposed to be running at 45 FPS. > If that was changed, that would be a big deal. Doesn't that assume that the server has nothing else to do than this one sim? What about servers that run more than one sim? (How many sims DO run on one server?) -- Carlo Wood ___ 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 has "Spare time" gone in 2.0 ?
On Sun, Apr 25, 2010 at 08:38:16AM +0200, Marine Kelley wrote: > Besides this entry is not even sent by the sim, it is calculated by the viewer > as (22.5 - net - physics - sim - agent - images - script), unless I'm > mistaken. > It would be rather easy to put it in again. That 22.5 seems a bit random ... perhaps it was changed already? Knowing that we have almost no influence on the server side of things, I think the best way to go is print the sum net + physics + sim + agent + images + script and leave it to the (experienced) user to know what the maximum of that sum normally is? -- Carlo Wood ___ 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] Steps For Uploading a Modification
You should attach the patch, rather than add it as a comment.
If you want to add code in your comments anyway, then put
{code}...{code} around it, to preserve whitespace and indentation.
--
Carlo Wood
___
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] Group IMs and scalability.
On Sat, Apr 17, 2010 at 12:02:57AM -0700, Erik Anderson wrote: > Hey, if you're looking for a review of message queueing agents, I ran across > an > SL review of MQs a while back when trying to choose one for our company's back > end COMET server. It had value in my research and may have for someone trying > to come up with chat alternatives... > > http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes Um... that page links to a page of mine and says: http://www.xs4all.nl/~carlo17/irc/run-irc.htm [Carlo Wood's notes on IRC]. Of note is the fact that IRC does not guarantee message order. I must say that I can't remember to ever have said that. In fact, IRC does garantee message order from the same source (which is all you can ask for), and obviously also between messages where one is a reaction to another. For example: Person A asks "What does LL stand for?" Person B answers "Linden Lab" Then those messages ARE garanteed to be seen in that order by everyone. The *current* group IM system being used in SL manages to reverse even how I see my own messages! I wonder how often different people see messages in a different order :/ The page also says that the largest IRC channels "top out" near 3400 members. The reason for that is that in the IRC protocol every part and join is sent to all members. I added an extention to the protocol (that can be set as channel MODE) to delay join/part messages until someone actually talks. Thus, instead of: 12:10 foo JOIN #channel 12:11 bar JOIN #channel 12:15 xyz JOIN #channel 12:17 foo PRIVMSG #channel :Hello You see: 12:17 foo JOIN #channel 12:17 foo PRIVMSG #channel :Hello I've seen channels with up to 20,000 users work fine like that (large "events"). Nevertheless, even that has a limit, of course: It remains needed to send a message that is spoken on the channel / group to every participant on the channel / group. However, an interesting fact is that groups do not have to grow indefinitely: *active* participants that read messages and write messages can, say read ten times as fast as they can type, that means that beyond 10 active participants the communication will start to slow down because the humans themselves are busy catching up. Non-active participants that haven't said anything for the longest time (you can simply order them like that) to NOT need real time information: you could just queue messages (that have a limit of say 1 per second per group, no matter how large the group is thus) for ... 10 minutes, and thus 600 messages, and then start to drop messages to those that have been silent the longest time. Thus, a new message comes in (that person is bumped to the top of the active participant list). The message is queued for output. The output thread starts sending the message to the top of the active participants list working it's way down; meaning: it puts the messages in the per-member output queues, and stops doing that if the total number of memory is exceeded (note that only one pointer per message is needed, so you can serve a LOT of users that way). If the thread is still busy while a new message comes in, it also stops and starts with the new message, provided that it sent the message at least to those that were active in the past 10 minutes (which will be at most around 10 people (and not grow indefinitely), see above), otherwise the new message is queued (for 1 microsecond) until it did that. That scales to an infinitely sized group, only limited and *automatically* limited by the human digestion speed (if too many messages occur, people will bail off and therefore automatically be skipped after 10 minutes). The only limit then remaining is the problem of having a file descriptor open per member, even those that idle: in order to know if they still idle you have to read their file descriptor... and as we all know, the kernel implementation of watching many sockets isn't optimal on every operating system. There is a limit there between 4000 and 2 open file descriptors per machine. Hence, in order to make groups really scalable, you'll have to kick idling people out. For example: Someone logs into SL, is considered active and is added to all his 500 groups (or maybe the viewer will allow people to say which groups they want to join *automatically* in the future :p. Setting a limit to the number of automatically joined groups makes sense, setting a limit to the groups you can be a member of not). If does read not react to lots of those groups, so he is being kicked out of very active groups after 10 minutes, and out of non-active groups with thousands of members that are logged in, after -say- one hour. Note that typically those latter groups are of the type "access groups", groups that are used for access to a sim, not for chatting. It makes sense to treat th
Re: [opensource-dev] Requesting Linden Response: Please move TPVP Topics to a different mailing list
Scaling of group messages is simple however. With one server per group you get a long way. Lets say, 2000 connections per server on average. Usually about 1/10th of the users is online, so you can keep adding groups to a server until the total number of group members is around 20,000. Then you add a server. The routing to the servers can be done by using the DNS system, for example .groups.secondlife.com And if you throw a good socket library against it (not one using select or poll), you can add to 20,000 users per server; that still won't be a problem CPU-wise. Unfortunately some kernel tweaking and expertise is needed in that case, but just hire some IRC admin of a large server and they can tell you how to do that. On Fri, Apr 16, 2010 at 06:20:21PM +0200, Dale Glass wrote: > IIRC, the main issue with the group limit and IM is scaling. There can be 70K > people online. Suppose you bump the groups limit to 100, and those 70K people > end up belonging to 50 groups on average. Now you've double IM load, and if > you remember the days where most group chat sessions failed, it's probably a > quite heavy loaded system. > > Jabber would have the same issue: how to handle 70K people, many with multiple > conversations and conferences. A small jabber server is easy, but supporting > 70K logged in accounts is a serious undertaking. -- Carlo Wood ___ 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list
On Thu, Apr 15, 2010 at 11:28:00AM -0400, Robert Martin wrote: > LL is only liable for Linden Core Code* > a TPV is only liable for code changed from LLC** > a user is liable for actions on the grid (and whatever changes done to > either LLC or TP code) That is nonsense! An open source developer can NOT bare the burden of being legally liable for ANYTHING. If Linden Lab wants to put in their TPV the warning that they will remove the account of developers (users thus) that don't do they ask, go ahead. But under no circumstances any OS dev in their right mind will work on a project if they will be legally liable for it! This is just too insane for words. -- Carlo Wood ___ 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list
Provided the changes can be made without being liable for damages On Thu, Apr 15, 2010 at 04:09:19PM +0200, Lance Corrimal wrote: > on the other hand, I would like to bet actual money on the following > predictions: > > - 48 hours after the server code is out in the open, the 25 groups limit has > been lifted, AND the whole IM/group chat subsystem has been migrated to XMPP > (including voice via XMPP); another day and there's the possibility to > connect > to jabber.sl.net with any xmpp client, AND talk to friends at any jabber > service. > > - 72 hours after the server code is out in the open, SVC-472 is fixed > > - a few weeks later, all communications between client and server, and the > various server subsystems, has been ported to tcp/ssl and is transaction safe. > > imagine the possibilities. -- Carlo Wood ___ 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] impending lawsuit?
This guy really filed a lawsuit. Such people exist, ... one of the reasons I REALLY don't want to work on a SL viewer when there is a TOS that says I'm responsible and liable for any damages done as a result of using that viewer. On Wed, Apr 14, 2010 at 10:28:55AM +0200, Lance Corrimal wrote: > Hey all, > > just got this notecard inworld: > > "Hello. > > You are reading this because you were listed in a lawsuit by Belial Foulsbane > and Scarlett Vielle. > Somehow you are a victim of his False DMCA claims, and his ongoing effort to > manipulate LL into killing off his competition for the "Emerald Speed Rez". > > If you would like to join the defendants against this paperwork-greifer in a > counter lawsuit please contact me with your SL name and anything else at > prime...@gmail.com > > Do not be scared > 1) Scarlett Vielle claimed that they automaticly had a protected copyright > from the moment they made anything. > (The US copyright office is not aware of every creation in SL, does not issue > free copyrights, and does not issue anything without a proper filing) > > 2) There is no copyright registered in the united states: > http://cocatalog.loc.gov/cgi-bin/Pwebrecon.cgi?DB=local&PAGE=First > > 3) Linden Labs cannot be sued. Yet he filed against them. > > 4) The judges signature on his legal papers he faxed to LL is blank. > > 5) He cannot copyright the word "Emerald" for the same reason he cannot > copyright the word "SecondLife" or "Microsoft". > > He is a paperwork bully filing false DMCA claims as you know. > > If you have any ideas to stop this madman, do please share them. > Lets create a group and fight him off shall we? > > zFire" > > > ... is that guy out of his mind? > > ___ > 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 -- Carlo Wood ___ 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] opensource-dev Digest, Vol 3, Issue 40
You know, this would actually make me feel better if you were a lawyer. Even more so, if you were a Linden Lab lawyer. But since (I assume) neither is the case, this is just your interpretation and I see it differently. On Sat, Apr 10, 2010 at 04:19:00AM +0200, Dirk Moerenhout wrote: > > If the first one was re-written to say "you are responsible for all NEW > > features etc that you ADDED to make a Third-Party Viewer, etc" it would > > be more clear. > > That will create a false sense of safety. When LL removes code from > the source tree for legal reasons you'd make a TPV developer believe > that he's not liable for that code if he keeps on distributing it (as > you just made him believe he's only responsible for what > developed/added himself). Yet when he has been informed that the code > can not be legally distributed willful continued distribution is an > issue and may see him ending up in court. Off course he should know > this if he reads and understands the GPL. The GPL clearly demonstrates > responsibility for distribution in section 7. > > > The second one should simply drop "develop or distribute". The GNU GPL > > license on LL own page states "6. ...You may not impose any further > > restrictions on the recipients' exercise of the rights granted herein." > > (in this case, "you" being Linden Research), and further includes the No > > Warranty > > paragraphs 11 and 12. Therefore any attempt to impose responsibility, > > risks, expenses, etc on a developer appear to conflict with the GPL. > > No it should not. For starters you do not quote it in full. It > actually says "You assume all risks, expenses, and defects of any > Third-Party Viewers that you use, develop, or distribute. Linden Lab > shall not be responsible or liable for any Third-Party Viewers." > Punctuation is used for readability but doesn't remove the second > sentence from the context. This is LL waving responsibility more than > it is about who it transfers to. If you consider section 11 and 12 of > the GPL this is a reiteration of "THE ENTIRE RISK AS TO THE QUALITY > AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE > DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR > CORRECTION.". Note that LL did not restrict you from passing the risks > on to the users of your TPV (they actually imply it transfers to them > already). > > Granted. In the TPVP, like most similar legal documents, they have > reiterated quite a few points that are covered already for example by > the GPL or the TOS. But as I stated before I still need to see the > first sensible example of how this affects somebody beyond what they > should expect regardless of the TPVP. > > Dirk > ___ > 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 -- Carlo Wood ___ 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] Brown-bag meeting to continue dialog on TVPV
If the beta grid (Aditi) does not demand one to accept the TOS before being able to login, then this is by far the best solution I've heard so far. Can someone confirm that logging into the beta grid does NOT ask one to agree with the new TOS? On Fri, Apr 09, 2010 at 11:50:24PM +0800, Boy Lane wrote: > The Betagrid would be such an option, and I assume all involved developers > have accounts old enough to be in the database. -- Carlo Wood ___ 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] Brown-bag meeting to continue dialog on TVPV
In case you're using linux and mutt. I'm using mutt and have in my .mutt/muttrc the following line: auto_view text/html Then I have in ~/.mutt/mailcap the line: text/html; w3m -dump %s; copiousoutput; nametemplate=%s.html On Fri, Apr 09, 2010 at 06:43:51PM -0400, lists.secondlife@trap.wereanimal.net wrote: > Can someone please translate the above into readable English. -- Carlo Wood ___ 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] Brown-bag meeting to continue dialog on TVPV next Tuesday (4/13)
On Fri, Apr 09, 2010 at 07:28:14AM -0400, Robert Martin wrote: > >> Voice is a no-no for me. Being French, I can't speak and understand > >> spoken English (and worst, American English...) well and fast enough > >> to hold a conversation in voice. > > > also unless im not mistaken holding it in Voice also guarantees that > there will not be a transcript of what was said. Unless there is now a > rock solid low lag real time way of transcribing the voice parts since > we are going to be discussing legal matters it needs to be recordable. That is probably exactly the reason why they want it to be in voice: so that there is no transcript and nobody can use whatever is going to be said in court at a later time. It is meant to be "informational" only, which is probably not very useful indeed, unless the information flows both ways and this will lead to a change of the TPV policy. -- Carlo Wood ___ 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] Can you legally agree to incomprehensible conditions
Ok, IANAL as well, but here's what I understood (somewhere in the past): LL is a single legal entity, "distributing" sources internally is not considered to be distribution and using binaries on multiple PC's within the company is also not considered distribution (it doesn't change owner). Therefore, they can link GPL-ed code with non-GPL-ed code (ie the server). The result would not be something that they can legally distribute, but that is not being done when they keep it strictly internal. If however they would sell (or even give) the server binary to another company, that is something entirely different. In that case they may not link with any GPL code, not even GPL shared libraries unless that binary is GPL-ed, meaning that the receiving company also needs to get source code, fully GPL-ed, which gives that company the right to distribute it on the internet as well. If LL wouldd sell that binary and give the source code but created an NDA for it; then they'd break the law and could be sued by the copyright holder of the GPL-ed part of their server (mostly like the FSF). On Sat, Apr 03, 2010 at 09:53:39AM +0200, Anders Arnholm wrote: > Sending in that fax and giveing the LL copyright for tha patches. We all > knew that LL had an internal code base mixed with the server code > containing non-gpl:ed code. -- Carlo Wood ___ 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] Can you legally agree to incomprehensible conditions
That is an 'if', what is the actual reason? On Fri, Apr 02, 2010 at 02:19:31PM +0100, Gareth Nelson wrote: > If these people also work on the viewer, they're banned from > contributing patches to opensim -- Carlo Wood ___ 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] Can you legally agree to incomprehensible conditions
What is the reason that those fixes aren't incorporated in "pure" opensim? On Thu, Apr 01, 2010 at 09:57:13PM -0600, Maya Remblai wrote: > That all is true of pure OpenSim, but not necessarily true of > OpenSim-compatible grids. ReactionGrid and InWorldz are > OpenSim-compatible, meaning they use the same viewers and started > with OpenSim code, but they've fixed many of the problems and are > working to fix the others. Personally I favor InWorldz, and am now > developing my avatars there before SL. > > Maya > > Carlo Wood wrote: > > >I would move to opensim immediately, but: > > > >1) It crashes non-stop > >2) It can TOTALLY not deal with packetloss: > > 2a) Avatar textures are extremely often corrupt. > > 2b) Attachment won't attach/detach > > 2c) I suffer from "rubber banding" > > 2d) If I import stuff it literally ends up all over the sim. > >3) Many other bugs have been there for years now > > and seem not to be fixed or addressed. For example, > > 3a) Try sitting on a prim > > 3b) Try standing on a slope > > 3c) Try writing a script > > and so on. > > > >There simply is no alternative :( > > > >The opensim servers are very VERY buggy and bad quality, > >so much so that I seriously doubt the competence of it's > >developers to every deliver anything usable. > > > >What we need is to start over, write a new server from > >the ground up (in C++ if I'm to participate). > > > -- Carlo Wood ___ 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] Can you legally agree to incomprehensible conditions
On Thu, Apr 01, 2010 at 11:06:59PM +0800, Boy Lane wrote: > What are you still doing here? I would move to opensim immediately, but: 1) It crashes non-stop 2) It can TOTALLY not deal with packetloss: 2a) Avatar textures are extremely often corrupt. 2b) Attachment won't attach/detach 2c) I suffer from "rubber banding" 2d) If I import stuff it literally ends up all over the sim. 3) Many other bugs have been there for years now and seem not to be fixed or addressed. For example, 3a) Try sitting on a prim 3b) Try standing on a slope 3c) Try writing a script and so on. There simply is no alternative :( The opensim servers are very VERY buggy and bad quality, so much so that I seriously doubt the competence of it's developers to every deliver anything usable. What we need is to start over, write a new server from the ground up (in C++ if I'm to participate). -- Carlo Wood ___ 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 note on preserving "NO WARRANTY" for SL TPV developers
On Thu, Apr 01, 2010 at 01:39:22PM -0500, Jonathan Irvin wrote: > it's > still > every much in Linden Lab's right to protect itself from those liabilities of > allowing third-party viewers to connect to its service. > > It's no different than allowing people to connect to an open network and > expecting them not to abuse it. You have to protect yourself. Dude, wake up... It has been spelled out often now: If LL only wants to say "We are not liable" and/or "We can do anything to block TPVs", then SHOULD SAY SO! And *NOT* "if you are a Developer than you are liable, and responsible for any damages". Hell? -- Carlo Wood ___ 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 note on preserving "NO WARRANTY" for SL TPV developers
On Wed, Mar 31, 2010 at 04:06:52PM +, Gareth Nelson wrote: > LL as copyright holder (or joint holder) can change the GPL with extra > restrictions as much as they like - so long as they make it clear. That would be EXTREMELY against the spirit of open source and the use of GPL. It would also make it impossible for any TPV to use their code anymore: TPV's added patches that are pure-GPL. LL does not have copyright on those patches, so those remain GPL. Therefore it is not possible to link code resulting from those patches with code that is GPL+TPVP, which would be non-GPL because it has extra restrictions. Thus, if this is true (or if they'd do that in the future) then it is EXTERMELY important to understand; because it DOES mean that all TPV's have to stop using any additional code released by LL after 30 April 2010. -- Carlo Wood ___ 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: extending avatar wearables
I can't seem to figure out where to start a new thread about outfits and inheritance. How/where should we continue this discussion? -- Carlo Wood ___ 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 note on preserving "NO WARRANTY" for SL TPV developers
single line, they take full responsibility for the result". > That is, the current wording seems to require viewer developers to take on > responsibilities for their code that the Lab itself explicitly doesn't take on > for theirs. > > I suggested somewhere that the bit about how the developer of a third-party > viewer is responsible for anything bad that might ever happen anywhere in the > world was typical lawyer over-reaching. Someone that I suspect is an actual > lawyer replied that no lawyer would ever voluntarily sign off on wording that > was that silly, and it must have been some ignorant business manager insisting > on it. Whichever explanation is true :) it would be nice if this were fixed, > so that the TPV policy really did talk only about the key things I've tried to > summarize in those three bullets there, and didn't wander off into the weeds > demanding legal representations and warrantees from every developer of a piece > of software that someone else might use to connect to the grid. > > Just in case it's helpful (and to apologize to Morgaine :) ), > Dave Chess / Dale Innis > ___ > 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 -- Carlo Wood ___ 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: extending avatar wearables
You mean he'll be developing in viewer-public then? On Mon, Mar 29, 2010 at 09:44:09PM -0700, Philippe (Merov) Bossut wrote: > Nyx stated he wanted to develop this feature "in the open" which means that > he'll be developing in viewer-internal which is exported on each successful > build (so we avoid those breakage) to viewer-external (see http:// > wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy for naming > conventions). -- Carlo Wood ___ 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
I like this idea! To translate it back to it's purest abstract form, we would like to be able to construct outfits in an object oriented way: be able to derive an outfit from other outfits. The "folder link" would be a pointer to the "base class" so to speak. However, we have to solve the following problems: 1) If I'd add a link from every outfit to 'naked', then right-clicking an outfit folder and selecting "Remove items" would become pointless (broken). 2) If the derived outfit has an attachment on the same spot as one of the base outfits, then we need to make sure that most-derived one prevails. I doubt that is already functional. 3) Once it is allowed to wear more than one wearable of the same type, it becomes totally unclear what you want to do with "add to outfit". I doubt that in most cases you want to actually only put on extra shirts and not take off the previous ones. Combining folders in this object oriented way should allow to specify if, at the derive level, if a "add" action should *remove* the items of the same type in the base outfit(s) (like happens with attachements), or that you want those to stay, and just add to it. 4) Finally, such way to derive from another outfit would make it impossible to specify an ordering of the combined wearables: what to do? Always put all new shirts in the derived outfit on TOP of the ones in the base class outfit? Also unclear. On Mon, Mar 29, 2010 at 04:28:30PM +0200, Kitty wrote: > > This method as several disadvantages: it's a lot of work, I > > have to find back the folder outfit that I'm currently > > wearing, there is the danger that I accidently click 'replace > > outfit' in the last step and it causes often two or three > > rebakes instead of one. > > > > What I'd like is an improvement here, a way to switch outfits > > with a single click. > > > > Does anyone have ideas? > > Folder links would work fine for that... > > Create a folder link to your "Naked" folder inside of both the "Swim outfit" > and "Disco Outfit": when you right-click and "Replace Outfit" from one of > the other LLAppearanceMgr::updateCOF() would follow the folder link inside > of the outfit folder and collect in the items from the "Naked" folder as > well. > > Right now it doesn't actually follow folder links but since there is code in > place for it (take a peek at LLInventoryModel::collectDescendentsIf I > think), it's probably on the roadmap *somewhere* :). If not, it probably > shouldn't take that much coaxing to get it working :p. > > [Personally I really dislike like the "Outfit concept" though and much > prefer "Add to Outfit" on the new folder followed by a "Remove from Outfit" > on the old folder if need be because it's infinitely more flexible than > being forced to always wear a certain "outfit" one specific way] > > Kitty > -- Carlo Wood ___ 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
Hi Nyx and list, I (finally) realized that there IS something that would be a great improvement of wearables that won't be too hard to implement :). I don't have a solution (yet), but let me describe the problem, and maybe the list can come up with the solution. I store wearables in folders, and call those "outfits". However, fact is that I have two different types of "outfits": clothing, and things that make me myself, things that belong to the avatar, to the naked avatar so to speak: * Hair, AO, earring, shape, eyes, necklace that I "never" take off, swimmer, braces, tatoos, skin, radar... The number of things that belong to the "naked" avatar are quite large in fact. Outfits can also be pretty large, especially the number of attachments. Allowing people to wear multiple layers of pants, shirts and jackets will increase the number of clothing items too. Now lets say I have all the base things that belong to the avatar in a folder "naked", and clothing outfits in folders "swim outfit", "disco outfit", "samourai outfit"... Then, when I want to switch from 'disco outfit' to 'swim outfit', there are currently two "paths" one can take: 1) Click on 'naked' and do "replace outfit", then click on 'swim outfit' and do "add to outfit". this makes me temporarily naked, and is therefore often not desirable, so that leaves 2) Click on 'swim outfit' and do "add to outfit", then click on 'disco outfit' and do "Take off items", then click on 'naked' and do "add to outfit". The last step is needed because some outfits DO replace some of the 'naked' items. This method as several disadvantages: it's a lot of work, I have to find back the folder outfit that I'm currently wearing, there is the danger that I accidently click 'replace outfit' in the last step and it causes often two or three rebakes instead of one. What I'd like is an improvement here, a way to switch outfits with a single click. Does anyone have ideas? -- Carlo Wood ___ 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
Yup, makes sense if you can put wearables anywhere.
Better than having a category called "shirt" and then fill it
with shirts a jackets.
Bottom line, also Jacek wants to be able to determine the order
of anything that might give a different result with a different
order.
On Fri, Mar 26, 2010 at 07:49:29PM -0500, Jacek Antonelli wrote:
> 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
--
Carlo Wood
___
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: extendingavatarwearables
Jonathan, I have no disrespect at all for Nyx. And yes, it's highly appreciated that he asks us for input instead of just implementing it. Still, if nothing in his original design is going to be changed then the effect is almost the same; except if this list is convinced that his original design is indeed the best. Apparently that stands or falls with having time (money) to do anything beyond what he already planned to do, and therefore explaining that is the only way to make the list understand this. Hence my question. Not because I think he is wrong, but because I want to know (and understand): Why not implement the extra requests from this list and then release the whole feature three months later? Imho it IS better to delay the feature and release a really well-thought-out new feature that will really work for a long time, than to be 3 months sooner and have people feel frustrated about little shortcomings for the next 3 years. Specifically to Jonathan: I'm sure this is a misunderstanding in the way my post came across. I appologise for that. It's sometimes hard to come accross correctly in written emails (I'm not even good at it in RL). On Fri, Mar 26, 2010 at 02:52:39PM -0500, Jonathan Irvin wrote: > > On Fri, Mar 26, 2010 at 06:56, Carlo Wood wrote: > > It bothers me a bit that we (you) would choose to go > for an implementation that is not the best or the > ideal one, ONLY because you want to push out a new > feature "in time". > > > Carlo, it pains me to see you have this attitude towards the > Lindens...especially those who are in here trying to communicate with us. > ***Linden Labs has limited resources*** They can't just magically allocate > time > and money to a feature that would be awesome because you think so. They have > time and money constraints. > > > Personally, I'd first design how I'd want it to look > from the user point of view (what most of the discussion > from the community is about) without taking into account > coding arguments. And once we have that, I'd just > implement it, no matter the costs or time needed. > That is what coders do: they implement what is requested. > > > This is a blind perspective to have. Coding constraints come into play > because > coding takes time and when you are on a payroll with a budget, time = money. > You have to sacrifice the really awesome feature that will take a while for > the > ones that are easy, but have an ok benefit. > > The Lindens aren't tools, my friend. Perhaps showing more respect for them > will give you respect in return by getting us new features. And, keep in > mind, > this is an OpenSource forum. If you have an idea, make it happen and pitch it > to us. Code it yourself and post it to the open forum. The lindens have > enough on their plate as it is which is why they went the opensource route to > begin with...having the assistance of the community make a better product. > > > Thus, since for almost everything we said so far your > argument is: we can't do that within the given timeframe; > can you defend, or at least make acceptable and understandable > that "a" new feature has to be added in 3 months, even if > that new feauture is a bit inferior compared to what > that UI could have looked like? > > > Again, show some respect here. The lindens have a lot on their plate and are > wanting you to make a business case for this. They need to know a feasible, > tangible way they can impliment feature ABC while not over taxing their > resources. Also, this feature needs to be used by the whole and not a small > percentage of users. > > > Changing it AGAIN in the near future (ie, 6 months later) > is probably not going to happen for several reasons :/ > So, not doing it right now has almost the same implications > as deciding to never do it. I'd really like to understand > why that is the best thing to do. > > Thanks for discussing this with us, > Carlo Wood > > PS With regards to the UI design. > I like the concept of "click wear" inserts the wearable > in a default place, after which you can reorder it. > And where this inserting means "at the top of a folder > that one of the currently existing wearable categories". > It just makes sense. > > But, in the end the goal should be that wearer can > determine the order of every texture layer, or at > least to a great extend, including: > - Tucking in jackets or not (jacket <-> pants ordering) > (my proposal was to add a pseudo jacket, below or >
Re: [opensource-dev] Open Development project: extendingavatarwearables
On Fri, Mar 26, 2010 at 07:39:39AM -0500, Argent Stonecutter wrote: > >Assume that the project will result in jackets > >(the canonical example) can be tucked in and/or being > >worn under shirts. Would you really still need it to > >be converted to a shirt? > > If the project was going to achieve that goal, then they wouldn't > really *be* jackets vs shirts vs undershirts any more, they'd just > be "tops". But that's not what Nyx has proposed. That is not really true. The big difference between jackets and shirts is that jackets have a texture on the lower part too. Also, the default insertion point when wearing a new item would still be different. -- Carlo Wood ___ 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: extendingavatarwearables
On Fri, Mar 26, 2010 at 05:41:10AM -0500, Argent Stonecutter wrote: > I'm not proposing "wear as undershirt". > > I'm proposing "convert this into an undershirt". But with what goal? If the goal is to be able to tuck a jacket in and wear it below other shirts, then I think it's too much of a hack. People would want to wear an item below a shirt one day and wear it over their pants another day. Converting it back is going to be a bit hard if you cut off the lower part and then make the sleeves at length again manually. If the goal is to be able to change the type, then I don't feel it should be part of this particular project. Assume that the project will result in jackets (the canonical example) can be tucked in and/or being worn under shirts. Would you really still need it to be converted to a shirt? -- Carlo Wood ___ 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: extendingavatarwearables
On Thu, Mar 25, 2010 at 10:48:24PM +0100, Latif Khalifa wrote: > 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. +1 The type is the type. Converting types will lead us nowhere. -- Carlo Wood ___ 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
