Re: [opensource-dev] client-side physics and general relativity
That's true for the case of non-static objects. We could, however, predict how fast an object changes and negotiate that limit, and that's basically what there is to agree upon for what is relative. For example, let's say an avatar moves around a sim of mostly static objects. It can do most of the work for client-side physics, so those updates are lowered traffic. When the avatar touches a non-static object, it could just send a signal to the sim that it touched the object. The sim then decides if it needs to send an update back to the client. If the object acts like a static object even if it is set non-static, then no update is needed from sim to client. Another example, lets say the avatar has lots of animated attachments. The avatar also moves around a sim of mostly static object, but the attachments are obvious non-static since they animate. Since the attachments are all within the avatar's relative space, the client-side physics can handle all the motion of the attachments. The sim may not need to know anything about the attachments unless they bump into something non-static. Soft body physics in mind... Tateru Nino wrote: > Hmm. However, with virtual objects the physical properties aren't fixed. > Unlike regular matter, the physical properties of an SL object can > change at any time. In fact - and I grant I only have anecdotal > information to support this - I think it is less likely for an object's > physical properties to remain constant than it is for them to change. > > On 16/04/2010 2:57 PM, Dzonatas Sol wrote: > >> I want to share a use-case/concept for physic simulation where the >> client and sever wouldn't have to send object updates, or at least there >> wouldn't be as many updates needed to send from the sim to the client. >> >> Given we can use general relativity more as a mutual agreement rather >> than assume it is the only way reality changes; we could further expend >> such mutual agreement between a server and client as they simulate >> physics. Now don't expect FTL changes for this, yet we can use the same >> analogy and define a limit. Let's use one that LL has already defined as >> max velocity an object moves through a sim. >> >> Now, let's say we have two objects. Object (A) is within 10m to an >> avatar. Another object (B) is 50m away for that avatar. Now, since >> object (A) is within a distance an object can move within a second of >> max velocity, the client can be given rights to simulate object (A), and >> the simulator wouldn't send any updates to the client if the client does >> such. Since object (B) is outside the distance of an object can move >> within a second at max velocity, the simulator would continue to send >> updates to the client about object (b) only if in view (as it does now). >> >> If object (A) and object (B) are static, as in they never move, then the >> client would fully control its position within that relative second of >> space and all physics. If the avatar bounces off the static object, the >> client doesn't need to send updates to the sim unless the object needs >> to know if it was touched. >> >> If the objects aren't static or if there are more avatars, then there >> are several negotiation and scenarios that could happen, yet let's not >> digress immediately away from the basic use-case/concept stated above. >> >> Bottomline, this should be negotiable. The sim may not allow it at all >> if if the sim needs full physics control. The avatar may want to only be >> in sims that don't take full control of physics. If the client simulates >> some objects then the sim is expect to simulate the same objects. The >> two simulations should be basically in sync, yet accuracy of being in >> sync should be negotiable also. >> >> Relative second of space can be quickly calculated, for example, ( max >> diameter of avatar + 1 second distance of max velocity ) * 3.333... >> (basically like pi r squared) >> >> =) >> >> >> ___ >> 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] 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] 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] client-side physics and general relativity
I don't think you thought through all cases. Consider blind users, as they would only be concerned with objects within relative space, then even on a busy sim the sim would not have to send any updates to the client. Even if not blind, lets say someone has their view limit set only to relative space, as would be the potential possibility for those that mainly leave their client open for chat. Normally the viewer is set to greater than 64m away view distance, yet if someone has the chat window maximized then that distance isn't really needed. It would be an option to have the viewer automatically drop viewable distance to 30m or less, which would be optimal for chat distance. It's a use-case/concept that is low-hanging fruit for client-side physics. Dale Glass wrote: > It seems to me you're optimizing for rather narrow cases: sims of mostly > static objects, and presumably nobody else around. But why optimize for > something that is going to be very fast already? > > The most benefit would be gained from improving the performance of busy > sims, but it sounds like those ideas would rarely work in such a case. > > > ___ 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 04:09:19PM +0200, Lance Corrimal wrote: > - 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. Very likely, but it doesn't necessarily work for SL. 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. Of course none of this would be an issue for a third party grid with 50 concurrent users. > > - 72 hours after the server code is out in the open, SVC-472 is fixed Region crossing is complicated in SL. OpenSim doesn't seem to do a lot better. If you'd be willing to improve it there, I'm sure many people would love it. But I agree, cool things could happen as a result :-) ___ 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 Fri, 16 Apr 2010 17:11:22 +0200 Carlo Wood wrote: > 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. so if i create a software and with few printf i broadcast a lot of harassment, injuries, falsity about you and i sign my software as GPL you cannot take me in front of a judges? or i write and distribute a software like worm, something written to nuke remote systems or ddos networks, i append GPL license to it and nobody can tell something to me? your fantastic world is very nice GPL protect the software, not developers, "as is" and "no warranty" is about the requirement a user can ask to the developer, not about developer liability in front of him software... ___ 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] SG2 build 3326
Program received signal SIGSEGV, Segmentation fault. 0x09220aea in LLImageGL::setCategory(int) () uhm... same of build 3318, some hint to diagnose deeper this? SG don't start, asap first login screen appear it crash... ___ 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] SG2 build 3326
On Fri, 16 Apr 2010 18:40:34 +0200 Tayra Dagostino wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x09220aea in LLImageGL::setCategory(int) () > > uhm... same of build 3318, some hint to diagnose deeper this? > > SG don't start, asap first login screen appear it crash... great... turning OFF AuditTexture it 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] Snowglobe 2.0 trunk binaries available
On 14.04.2010 01:49, Philippe (Merov) Bossut wrote:
> Whohoo! Yes! We now have the parabuild automated build system running
> correctly on the 3 platforms and posting results to S3 successfully! The
> only thing that's missing to make ua perfectly happy is having the
> notification email working too... One last little snag to fix...
The installer displays ${VIEWERNAME} instead of Snowglobe 2 yet.
Tillie
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Snowglobe 2.0 trunk binaries available
On 14.04.2010 01:49, Philippe (Merov) Bossut wrote: > Hi, > > Whohoo! Btw. would it be possible to configure the installer that way that it doesnt require admin login on windows? I guess it's probably just the "install for all users" feature of the installer. Tillie ___ 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
The warranty disclaimer protects from liability for mistakes, not maliciousness On Fri, Apr 16, 2010 at 5:34 PM, Tayra Dagostino wrote: > On Fri, 16 Apr 2010 17:11:22 +0200 > Carlo Wood wrote: > >> 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. > > so if i create a software and with few printf i broadcast a lot of > harassment, injuries, falsity about you and i sign my software as GPL > you cannot take me in front of a judges? > > or i write and distribute a software like worm, something written to > nuke remote systems or ddos networks, i append GPL license to it and > nobody can tell something to me? > > your fantastic world is very nice > > GPL protect the software, not developers, "as is" and "no warranty" is > about the requirement a user can ask to the developer, not about > developer liability in front of him software... > ___ > 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 > -- “Lanie, I’m going to print more printers. Lots more printers. One for everyone. That’s worth going to jail for. That’s worth anything.” - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.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
[opensource-dev] No Media Plugin was found to handle the "text/html" mime type. Media of this type will be unavailable.
After VC90 builds Release and RelWithDebInfo the No Media Plugin notification alarms and of course when trying video media the same notifications alarm. Could this be related to the gstreamer problem that occured on the linux builds? If so is there a known work around or patch. The build was with Boost 1-36 complied libraries. NickyP ___ 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] client-side physics and general relativity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 currently attachments don't bump on anything, and animations do not affect what the avatar collides with, avatars got a static bounding box and that is it On 16/4/2010 10:45, Dzonatas Sol wrote: > That's true for the case of non-static objects. We could, however, > predict how fast an object changes and negotiate that limit, and that's > basically what there is to agree upon for what is relative. > > For example, let's say an avatar moves around a sim of mostly static > objects. It can do most of the work for client-side physics, so those > updates are lowered traffic. When the avatar touches a non-static > object, it could just send a signal to the sim that it touched the > object. The sim then decides if it needs to send an update back to the > client. If the object acts like a static object even if it is set > non-static, then no update is needed from sim to client. > > Another example, lets say the avatar has lots of animated attachments. > The avatar also moves around a sim of mostly static object, but the > attachments are obvious non-static since they animate. Since the > attachments are all within the avatar's relative space, the client-side > physics can handle all the motion of the attachments. The sim may not > need to know anything about the attachments unless they bump into > something non-static. > > Soft body physics in mind... > > > Tateru Nino wrote: >> Hmm. However, with virtual objects the physical properties aren't fixed. >> Unlike regular matter, the physical properties of an SL object can >> change at any time. In fact - and I grant I only have anecdotal >> information to support this - I think it is less likely for an object's >> physical properties to remain constant than it is for them to change. >> >> On 16/04/2010 2:57 PM, Dzonatas Sol wrote: >> >>> I want to share a use-case/concept for physic simulation where the >>> client and sever wouldn't have to send object updates, or at least there >>> wouldn't be as many updates needed to send from the sim to the client. >>> >>> Given we can use general relativity more as a mutual agreement rather >>> than assume it is the only way reality changes; we could further expend >>> such mutual agreement between a server and client as they simulate >>> physics. Now don't expect FTL changes for this, yet we can use the same >>> analogy and define a limit. Let's use one that LL has already defined as >>> max velocity an object moves through a sim. >>> >>> Now, let's say we have two objects. Object (A) is within 10m to an >>> avatar. Another object (B) is 50m away for that avatar. Now, since >>> object (A) is within a distance an object can move within a second of >>> max velocity, the client can be given rights to simulate object (A), and >>> the simulator wouldn't send any updates to the client if the client does >>> such. Since object (B) is outside the distance of an object can move >>> within a second at max velocity, the simulator would continue to send >>> updates to the client about object (b) only if in view (as it does now). >>> >>> If object (A) and object (B) are static, as in they never move, then the >>> client would fully control its position within that relative second of >>> space and all physics. If the avatar bounces off the static object, the >>> client doesn't need to send updates to the sim unless the object needs >>> to know if it was touched. >>> >>> If the objects aren't static or if there are more avatars, then there >>> are several negotiation and scenarios that could happen, yet let's not >>> digress immediately away from the basic use-case/concept stated above. >>> >>> Bottomline, this should be negotiable. The sim may not allow it at all >>> if if the sim needs full physics control. The avatar may want to only be >>> in sims that don't take full control of physics. If the client simulates >>> some objects then the sim is expect to simulate the same objects. The >>> two simulations should be basically in sync, yet accuracy of being in >>> sync should be negotiable also. >>> >>> Relative second of space can be quickly calculated, for example, ( max >>> diameter of avatar + 1 second distance of max velocity ) * 3.333... >>> (basically like pi r squared) >>> >>> =) >>> >>> >>> ___ >>> 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFA
Re: [opensource-dev] client-side physics and general relativity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 visually impaired people would still need to know if the door is open, if the trolley is on the station, if someone bumped into them etc On 16/4/2010 12:48, Dzonatas Sol wrote: > I don't think you thought through all cases. Consider blind users, as > they would only be concerned with objects within relative space, then > even on a busy sim the sim would not have to send any updates to the client. > > Even if not blind, lets say someone has their view limit set only to > relative space, as would be the potential possibility for those that > mainly leave their client open for chat. Normally the viewer is set to > greater than 64m away view distance, yet if someone has the chat window > maximized then that distance isn't really needed. It would be an option > to have the viewer automatically drop viewable distance to 30m or less, > which would be optimal for chat distance. > > It's a use-case/concept that is low-hanging fruit for client-side physics. > > Dale Glass wrote: >> It seems to me you're optimizing for rather narrow cases: sims of mostly >> static objects, and presumably nobody else around. But why optimize for >> something that is going to be very fast already? >> >> The most benefit would be gained from improving the performance of busy >> sims, but it sounds like those ideas would rarely work in such a case. >> >> >> > > ___ > 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIzXgACgkQ8ZFfSrFHsmX2nQCdHlBNhgn/8HtaivsklbcaMeRK oWUAnAmJsLFRcl9l9dlzAD+hKJvHfNV0 =Avci -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] Requesting Linden Response: Please move TPVP Topics to a different mailing list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With so many machines at their disposal, why things don't work in a more distributed way? I can't understand why there is so much centralized stuff. On 16/4/2010 13:20, Dale Glass wrote: > On Thu, Apr 15, 2010 at 04:09:19PM +0200, Lance Corrimal wrote: >> - 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. > Very likely, but it doesn't necessarily work for SL. > > 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. > > Of course none of this would be an issue for a third party grid with 50 > concurrent users. > >> >> - 72 hours after the server code is out in the open, SVC-472 is fixed > Region crossing is complicated in SL. OpenSim doesn't seem to do a lot better. > > If you'd be willing to improve it there, I'm sure many people would love it. > > > But I agree, cool things could happen as a result :-) > > ___ > 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIzecACgkQ8ZFfSrFHsmX8KgCfQ2Jt8ZmbKPxj+sdaH/2PXkd3 WxAAnAh/2iSUHc99BrA3UlcEvY9RA7Dw =yXOz -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] client-side physics and general relativity
This thread isn't about a mere box as you suggest. There thread is about how to take physics beyond that and allow the client to do part of the simulation, given a single use-case. Tigro Spottystripes wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > currently attachments don't bump on anything, and animations do not > affect what the avatar collides with, avatars got a static bounding box > and that is it > > On 16/4/2010 10:45, Dzonatas Sol wrote: > >> That's true for the case of non-static objects. We could, however, >> predict how fast an object changes and negotiate that limit, and that's >> basically what there is to agree upon for what is relative. >> >> For example, let's say an avatar moves around a sim of mostly static >> objects. It can do most of the work for client-side physics, so those >> updates are lowered traffic. When the avatar touches a non-static >> object, it could just send a signal to the sim that it touched the >> object. The sim then decides if it needs to send an update back to the >> client. If the object acts like a static object even if it is set >> non-static, then no update is needed from sim to client. >> >> Another example, lets say the avatar has lots of animated attachments. >> The avatar also moves around a sim of mostly static object, but the >> attachments are obvious non-static since they animate. Since the >> attachments are all within the avatar's relative space, the client-side >> physics can handle all the motion of the attachments. The sim may not >> need to know anything about the attachments unless they bump into >> something non-static. >> >> Soft body physics in mind... >> >> >> Tateru Nino wrote: >> >>> Hmm. However, with virtual objects the physical properties aren't fixed. >>> Unlike regular matter, the physical properties of an SL object can >>> change at any time. In fact - and I grant I only have anecdotal >>> information to support this - I think it is less likely for an object's >>> physical properties to remain constant than it is for them to change. >>> >>> On 16/04/2010 2:57 PM, Dzonatas Sol wrote: >>> >>> I want to share a use-case/concept for physic simulation where the client and sever wouldn't have to send object updates, or at least there wouldn't be as many updates needed to send from the sim to the client. Given we can use general relativity more as a mutual agreement rather than assume it is the only way reality changes; we could further expend such mutual agreement between a server and client as they simulate physics. Now don't expect FTL changes for this, yet we can use the same analogy and define a limit. Let's use one that LL has already defined as max velocity an object moves through a sim. Now, let's say we have two objects. Object (A) is within 10m to an avatar. Another object (B) is 50m away for that avatar. Now, since object (A) is within a distance an object can move within a second of max velocity, the client can be given rights to simulate object (A), and the simulator wouldn't send any updates to the client if the client does such. Since object (B) is outside the distance of an object can move within a second at max velocity, the simulator would continue to send updates to the client about object (b) only if in view (as it does now). If object (A) and object (B) are static, as in they never move, then the client would fully control its position within that relative second of space and all physics. If the avatar bounces off the static object, the client doesn't need to send updates to the sim unless the object needs to know if it was touched. If the objects aren't static or if there are more avatars, then there are several negotiation and scenarios that could happen, yet let's not digress immediately away from the basic use-case/concept stated above. Bottomline, this should be negotiable. The sim may not allow it at all if if the sim needs full physics control. The avatar may want to only be in sims that don't take full control of physics. If the client simulates some objects then the sim is expect to simulate the same objects. The two simulations should be basically in sync, yet accuracy of being in sync should be negotiable also. Relative second of space can be quickly calculated, for example, ( max diameter of avatar + 1 second distance of max velocity ) * 3.333... (basically like pi r squared) =) ___ 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] client-side physics and general relativity
Do you understand the use-case I noted? As stated earlier: "If the objects aren't static or if there are more avatars, then there are several negotiation and scenarios that could happen, yet let's not digress immediately away from the basic use-case/concept stated above." Tigro Spottystripes wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > visually impaired people would still need to know if the door is open, > if the trolley is on the station, if someone bumped into them etc > > On 16/4/2010 12:48, Dzonatas Sol wrote: > >> I don't think you thought through all cases. Consider blind users, as >> they would only be concerned with objects within relative space, then >> even on a busy sim the sim would not have to send any updates to the client. >> >> Even if not blind, lets say someone has their view limit set only to >> relative space, as would be the potential possibility for those that >> mainly leave their client open for chat. Normally the viewer is set to >> greater than 64m away view distance, yet if someone has the chat window >> maximized then that distance isn't really needed. It would be an option >> to have the viewer automatically drop viewable distance to 30m or less, >> which would be optimal for chat distance. >> >> It's a use-case/concept that is low-hanging fruit for client-side physics. >> >> Dale Glass wrote: >> >>> It seems to me you're optimizing for rather narrow cases: sims of mostly >>> static objects, and presumably nobody else around. But why optimize for >>> something that is going to be very fast already? >>> >>> The most benefit would be gained from improving the performance of busy >>> sims, but it sounds like those ideas would rarely work in such a case. >>> >>> >>> >>> >> ___ >> 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 >> >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.12 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvIzXgACgkQ8ZFfSrFHsmX2nQCdHlBNhgn/8HtaivsklbcaMeRK > oWUAnAmJsLFRcl9l9dlzAD+hKJvHfNV0 > =Avci > -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 > > ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 a program that says things could still be protected under free speech, and could be considered art, and manufacturing pistols isn't illegal, even if some people kill people with them, but of course, if you build a pistol, and then use it to kill someone, then you probably would have to deal with the law enforcement people On 16/4/2010 13:34, Tayra Dagostino wrote: > On Fri, 16 Apr 2010 17:11:22 +0200 > Carlo Wood wrote: > >> 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. > > so if i create a software and with few printf i broadcast a lot of > harassment, injuries, falsity about you and i sign my software as GPL > you cannot take me in front of a judges? > > or i write and distribute a software like worm, something written to > nuke remote systems or ddos networks, i append GPL license to it and > nobody can tell something to me? > > your fantastic world is very nice > > GPL protect the software, not developers, "as is" and "no warranty" is > about the requirement a user can ask to the developer, not about > developer liability in front of him software... > ___ > 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIzzsACgkQ8ZFfSrFHsmWPdACff0XEvLLY/mjC6hvbWdg+iSJZ /FAAnj2IJs5ovYbqjh0lkkurcprNeLjo =MJIM -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] Requesting Linden Response: Please move TPVP Topics to a different mailing list
> deal with the law enforcement people > Chuckle @ wording ;) --GC ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
