Re: [opensource-dev] New HTTP Library & Project Viewer
Good to see everyone having the HTTP spec discussion.This is the preverbial elephant in the room for this network solution. Regards Teravus On Tue, Oct 23, 2012 at 8:04 PM, Dahlia Trimble wrote: > I believe the 2 persistent HTTP connections/server recommendation is just > that: a maximum of 2 *persistent* connections *per server*. Torrent > downloads are more likely 1 connection per server with many servers. > Torrent clients also have the ability for users to specify maximum outbound > transfer rates and trying to overcome them by opening more connections to a > particular server will likely not be fruitful. > > Also, networked system designers may have control of how endpoints are > implemented but if the public internet is used as a transfer medium then > they have little (if any) control over what happens between those > endpoints. ISPs can (and often do) control traffic via whatever criteria > they deem fit. Choke points likely exist in many places and end users may > be powerless to understand and/or resolve issues caused by over-zealous > connection hoarding. > > > On Tue, Oct 23, 2012 at 5:21 PM, Henri Beauchamp wrote: > >> On Tue, 23 Oct 2012 10:28:37 -0400, Monty Brandenberg wrote: >> >> > Here's a chart I keep forwarding: >> > >> http://www.smallnetbuilder.com/lanwan/router-charts/bar/77-max-simul-conn >> > Not officially endorsed by Linden, etc., but a useful measure of >> > one metric that is likely to predict problems. At the bottom of >> > that chart you'll find members of router families that are both >> > very common and very often a source of problems in SL. >> >> Very interesting chart... And quite frigthening too, seeing all the >> so-called "routers" that can't even handle 1K connections ! >> >> This said, such routers would also stall on torrent downloads. >> >> Henri. >> ___ >> 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 > ___ 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 Inventory Transfer
One way to eliminate the possibility of accidental transfers is a mandatory confirmation window on the transfer when it's done via dragging an edit window. When the item is dragged, a confirmation box wouldn't be necessary..just when dragging the window.On the other hand, I don't know of any other interface that creates actions upon dragging a window. Regards Teravus On Thu, Aug 19, 2010 at 8:56 PM, Ricky wrote: > Very good question, and was the reason for my note bout accidental > inventory transfers. > > The solution I alluded to was to pop up an "are you sure" style dialog > box. However, I hate those with a passion. So I'm fishing for more > optimal solutions. It is possible there may be no good solution to > this difficulty, but at least it will have been discussed, and may > spawn other improvements or be revisited later. > > Ricky > Cron Stardust > > On Thu, Aug 19, 2010 at 1:51 PM, Baloo Uriza wrote: >> On Wed, 18 Aug 2010 17:25:05 -0700, Ricky wrote: >> >>> Well, she was recently instructed by my dad (an advanced user like >>> myself) to send him a notecard she was editing. She asked how. My dad >>> instructed her to "drag it to the IM window." This she knew how to >>> find. She then complained that it didn't work. This brought me to look >>> at what she was doing. She was trying to drag the notecard edit window >>> onto the chat popup to send him the notecard. >> >> Sounds like your mom might also be relatively inexperienced with working >> with subwindows as well. However, the instructions given to her could >> have been slightly more clear as well; "drag it to the IM window from >> your inventory" might have worked better. >> >>> Because of this, I would like to put forth the suggestion for further >>> study of allowing the user to drag asset windows (notecards, textures, >>> etc.) onto the varied existing ways of sending content. (IMs, Profile >>> pages, etc) >> >> How would you differentiate someone trying to reorganize subwindows >> within a viewer with inventory transfer events, then? I think that >> problem makes this suggestion entirely unworkable in practice. >> >> ___ >> 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 > ___ 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?
Apparently imprudence and meta7 supports sim side setting of Windlight settings. Maybe this could be built upon? http://opensimulator.org/wiki/LightShare http://imprudenceviewer.org/wiki/LightShare Apparently it was developed by meta7 http://www.meta7.com/wiki.php?page=LightShare and contributed to OpenSimulator Regards Teravus On Sat, Sep 25, 2010 at 1:16 PM, Brandon Husbands wrote: > I have actually thought Windlight should be set server side. > I wanted to add that to emerald and store the sim settings on the server > and push down. But there are some windlight settings that can be used > maliciously and crash viewers. > > So it was nixed. > > > On Sat, Sep 25, 2010 at 12:11 PM, Marine Kelley wrote: > >> >> >> On 25 September 2010 19:05, Ponzu wrote: >> >>> >>> I haven't always monitored closely, but I think I can agree with this. >>> However, it seems to me that there will and should always be TPVs, even if >>> it becomes easier for non-Linden changes to get in. For one example, the >>> Restrained Life stuff might never be acceptable to Lindens for Public >>> Relations or Legal issues. >>> >>> >> That's why I never bothered asking. However I do think that if the name >> were different, the regular viewer would really benefit from some of the >> features of the RLV, such as sharing Windlight settings, setting the avatar >> rotation, changing the clothes remotely etc. >> >> Or even all of the restrictions like no-detach, no-IMs etc which are, >> after all, only "hooks" that are in the viewer to make scripts decide >> whether or not an ability can be used according to the circumstances. It >> really enhances the experience and allows for products that would never have >> been made otherwise. And since all the RLV features can be turned off by >> changing one debug setting and relogging, there is no real additional threat >> from griefers. >> > > > > -- > > --- > This email is a private and confidential communication. Any use of email > may be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > > --- > > --- > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
When working on IdealistViewer, I noticed that, generally, third party 'general purpose' renderers like Irrlicht and Ogre are not well suited for rendering objects at the quantity that SecondLife prims require. Rendering prims /can/ be done with them, however, not at the level that can be done with the SecondLife viewer. With Irrlicht, for example, the memory load of a typical 5000 prim scene runs up against the 2GB memory limit. With SecondLife prims, it's more about segmenting the render data so that only the unique things are kept and everything else is a reference to something that was calculated before. Out of the box, Irrlicht requires per-instance knowledge about texture, mesh buffer, face and lighting settings configurations. This and reference/const/value type semantics used in the engine causes far more data duplications then are necessary. Prims are strange for rendering. The prim's mesh result is complex in terms of vertex count however, in a given 5000 prim scene there's on average 130 'unique' prim mesh. Those 130 unique mesh are duplicated with various textures, colors, orientations and associated data to make for the entire prim count in the region. In theory, you can manage memory reasonably well by using a 'mesh factory' pattern where by the mesh factory keeps track of instance counts and generates a new mesh when required. In practice, however, the associated data makes this very difficult. In Irrlicht, the API is such that the texture configuration data is 'stuck in with' the mesh data object.So, to get the variability that the secondlife prim scene requires, you're also duplicating the mesh and making small changes to the object's visual configuration data. Irrlicht, like Ogre, is better optimized for a smaller number of more complex mesh objects then a very large number of highly 'instancable' objects with very small differences. I'd comment on the opposite of the last statement... but I don't really know about how the SecondLife viewer works under the hood to do so (OpenSimulator Developer). I don't think that this issue is going to 'go away'. In fact, introducing mesh in the viewer is going to make that memory, speed, and instancing balance even more difficult to maintain.The gap between the viewer and 3rd party 'general purpose' rendering tools will narrow in both directions.. the viewer will get better at managing arbitrary mesh and 3rd party 'general purpose' rendering tools will be able to render secondlife scenes better because there will be less 'prim' to render as a result of there being arbitrary mesh. In either case, the future is full of interesting technical challenges.I think in unity, like with Irrlicht, smaller, more specialized scenes will work OK with regards to prim rendering. And, I don't think 3rd party renderers are going to be able to come close to the capability of the SecondLife viewer when dealing with prim. They're just not designed for the same type of data. The object models and API just are not really appropriate for prim. I'm not saying that it isn't worth pursuing a render plugin architecture. I am saying, however, that given that 3rd party 'general purpose' renderers are never going to be able to meet the SecondLife viewer's capability in rendering prim, it probably shouldn't be very high on the priority of things to do. Regards Teravus On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands wrote: > Ive used it, and fount it blehh. I think we are failing to communicate > about our conception of what is possible and what is used. > > Are you saying that the normal user would have full access to what you use > to develop the "client"? > As its a middle ware really i fail to see how your going to implement that. > I could be wrong. There are so many propitiatory things that you'd have to > code in and handle rendering for with sl. Also remember you can not change > the server backend. I just do not see it possible or powerful enough to > handle what sl uses and does. I guess its the same concept between higher > level langs and lower level ones. I could be wrong about this and just be > old school in my thoughts. > > If your so sure that it can do what needs to be done why have you not > already done a prototype. > From what your saying should be easy to get connected and render the scene. > > > I would love to be wrong in that regard but then again i just don't see how > your going to handle such things in a closed source engine. > > > > > On Sun, Oct 3, 2010 at 9:36 PM, wrote: > >> Obviously these are subjective statements but I think your statements >> are based on an incomplete understanding of the tool and probably limited >> experience using it. >> >> >> >> Not sure how you can say it is clunky. I have a scene hierarchy where I >> can list and see every object in my seen. It’s like seeing every prim in my >> region. I can select any object and view it in the inspector. >> >> >> >> Scripts are assign
Re: [opensource-dev] Replying to OpenSource-Dev using Gmail.
On that note, there's a gmail Lab feature which makes 'Reply to All' default and makes it so you have to dig for 'Reply' when you want to reply to someone individually off list. I use it for this e-mail address..but be careful. It might not be appropriate for every situation. -Teravus On Fri, Oct 15, 2010 at 7:21 PM, SuezanneC Baskerville wrote: > I switched my listmanager settings from Digest to individual messages > recently. > > I use Gmail. > > I just tried to reply to an OSD thread, and it appears that the mail would > be going to one individual rather than to the mailing list. > > I didn't seem to have this problem with the list set to send digests, > however then the mail is filled with repeatedly quoted text. > > Also with the list sent to not use digest mode, the From field in Gmail > shows an individual's name rather than Open Source Dev Request like it does > when the list is in digest mode. > > Anyone know how to make Gmail do a little better with this list? > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Diva Distro + Mono 2.8 + Mac 10.6.4? Login exception...
Daniel, You might want to send this to [OpenSim-Users] or [OpenSim-dev] instead of here because it seems like an OpenSimulator specific issue. -Teravus On Mon, Nov 8, 2010 at 11:49 PM, Daniel Smith wrote: > > Getting a login error - Test User authenticates, but then: > 20:33:19 - [LLOGIN SERVICE]: Exception processing login for Test User: > System.TypeInitializationException: An exception was thrown by the type > initializer for OpenSim.Framework.NetworkUtil ---> System.ArgumentException: > length > > Please reference the paste at: http://tinypaste.com/0c26bd > > Check the error at the bottom of the paste... Trying to run Diva Distro.. > > I am working on a Mac USB Key .. MacSimStick, but am tripped up > by this networking error. > > Mac OS X 10.6.4 > diva-r13981 > Mono JIT compiler version 2.8 (tarball Sat Nov 6 19:05:27 PDT 2010) > > thanks for any leads! > > Daniel Smith > javajo...@gmail.com > > > -- > Daniel Smith - Sonoma County, California > http://daniel.org/resume > > > ___ > 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
