Re: [opensource-dev] Review Request: Put the viewer version into marker files, and report errors only when the version matches
Wouldn't this only be an issue, normally, for people switching from one the viewer to another, where there was an leftover crash filer from the older viewer? Doesn't seem like leaving these events out would cause significant deviation. On Thu, Nov 1, 2012 at 11:09 AM, Ricky wrote: > Wouldn't it be better if the crash could be reported anyway - just marking > the correct version? With this in place at least crashes won't be > misreported, but they also will be not reported to the servers at all, > causing statistical deviation - what I believe is the core idea to be > fixed. More comments in the JIRA, > > Ricky > Cron Stardust > ___ 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 Jul 26, 2013 12:32 PM, "Darien Caldwell" 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'. :) ___ 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 Tools Upgrades - with a call for help
Ok, well, I'll be sad to see lscript go, I had some good times there, but it makes sense. ___ 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] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers
Look, Geir, not so many years ago the now-deprecated and soon defunct garbage collector was the new hotness. If we'd followed the course you're suggesting now, of always switching to Apple's latest APIs, we'd really be in a pickle now. On Jul 9, 2016 8:58 AM, "Geir Nøklebye" wrote: > In comment to Geenz Spad : > > > > There is much more to it than the knee jerk opensource community reaction > of resisting to "Apple made it the default for new projects, so you should > too!” > > By migrating the code to to the Apple defaults makes the code much more > portable across macOS system versions and often ensures that the code runs > with few or no modifications even if Apple makes big breaks to the > underlying system software or even hardware. Having worked in Apple > Product Management I have seen it over and over again that developers who > fail to maintain their code according to the Apple guidelines suffer badly > when Apple does something “unexpected. Very good examples of this is the > disaster that Microsoft Office has been on macOS for years, as also is the > case for almost the entire Adobe product suite. Others are using QT that > often result in sub par experiences both for developers and users. Many of > these applications simply vanish from the market as the developers are not > able to move the application forward. > > One such example of an “unexpected” change is the introduction of Metal, > where the viewer rendering code has not been changed for this fact > resulting in a GPU crash on any version of the viewer when running on macOS > 10.11. (regardless of LL or TPV developed.) The GPU crash has been both > acknowledged by Apple product development and by LL, but the LL code needs > to be fixed for it to work. This crash is clearly related to memory > management both on the GPU and on the main system. (NVDA(Graphics): Channel > exception! Exception type = 0x1f Access Violation Error (MMU Error 2)) It > happens because macOS 10.11 use Metal for compositing the desktop so memory > usage has changed. Installing NVIDIA’s driver removes the crash, but it > results in a loss of typically 10 fps for the viewer. > > > By acknowledging that a macOS application is distinctly different from the > standard C++ application, and structuring the code for the macOS version > thereafter, one would not only do everyone, including LL, a favor but it > would also make the path for a viewer running on iOS devices much shorter. > It would improve performance, give macOS users access to system services > they find across their application portfolio, and would make development > more consistent and reliable. It would possibly also reduce the number of > issues reported to the LL service desk and improve retention for new > signups. > > > I’ll have macOS 10.12 beta 2 installed today and see how the viewers run, > but on beta 1 only one of all the tested viewers ran (still with crashing > plugins.) One popular viewer compiled with the old GCC could not start at > all. > > My intention is to remove all the code that prevents compilation with ARC, > acknowledging that MRC will still be needed for some interfacing with > Foundation and C++. > > For the Renderer issue I am not in a position to fix the GPU crash. I have > yet to confirm if this issue still exist on 10.12 as that requires a viewer > that actually runs on it without one or more components crashing. > > TC, > Geir > > > > > ___ > 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] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers
The point is, They announced garbage collection and then deprecated it only a few years later. Meanwhile traditional manual memory management which is like 25 years old, that's still supported. So the odds are, the course of action you're proposing ... it would have lead to TWO big development efforts, one to switch to GC, and one to switch back, and there would be a big debate about whether to go back or forward. For what? And I've been working on Swift code for the last two months, half of which has been converting Swift 2 code so it'll be more likely to automatically convert cleanly when we pull the Swift 3 switch. So, no, MRR isn't going away any time soon, and Objective C isn't either. ___ 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] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers
I've been following Apple for over 35 years now, and they have introduced and abandoned technologies on a regular basis. You can't dismiss the fact that they introduced and abandoned GC in only a few years and confidently declare that Swift won't go the same way. It might stick. It might not. It might be like FFS and ZFS and 64 bit Carbon and Blue Box and Metal. Or it may be like Yellow Box and turn into the next Cocoa. Same with their new memory management. Best keep on doing what works instead of diving into the churn. ___ 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
Well, look there, the ability to type in chat while interacting with objects in the world isn't on the spreadsheet anywhere. This is a complete show-stopper for viewer 2 for me, and for many of my friends who interact primarily in text and do not use voice chat. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] display names = the end of 1.x viewers?
On Tue, Aug 17, 2010 at 6:47 PM, Michael Schlenker wrote: > Am 18.08.2010 um 01:16 schrieb Bryon Ruxton: > > And 2. you should also prevent anyone to use a display name baring the > name > > of an existing username in my opinion. > > NO. That would limit the usefulness for some kind of RP for sure. Can you elaborate on what kind of RP would require you to be able to set your display name to "Argent Stonecutter"? ___ 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] no "allow create landmark" in 2.1?
On Fri, Aug 20, 2010 at 10:26 AM, Aimee Linden wrote: > Apparently this option is no longer supported on the server, If this means you can now create landmarks anywhere, three cheers! ___ 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 oh where has my rendering gone?
On Wed, Oct 6, 2010 at 10:57 AM, Joshua Bell wrote: > Of course, once you have monochrome output, you could tweak the shader and > get sepia-toned rendering. Old-timey SL, anyone? Don't forget the vignetting and cracquelaire effect. ___ 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 for "Attachments displayed in mouselook" bug
I don't normally gripe about stuff like this, but somehow this one triggered my twitches from 20 years of supporting PhD programmers. Brilliant guys, but sometimes it's SO hard to figure out what they're trying to do. This is a case where the trinary "?:" operator is much more readable and understandable. (type == 0) ? FALSE : mRenderTypeEnabled[type]; But even better: if(type == 0) return FALSE; // explain why here .. eg "in this context we are always rendering attached prims on the head when blah blah..." else return mRenderTypeEnabled[type]; ___ 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] SL Browsification
On Wed, Nov 17, 2010 at 8:35 PM, Daniel Smith wrote: > On Wed, Nov 17, 2010 at 6:29 PM, wrote: >> the mail below is a copy of a msg i got from SL this afternoon. Is it >> some kinda sign that the viewer is in danger of going extinct? > No, it would just be yet another way to get to the same experience. Not even that much. The browser viewer is cloud rendered and so even if it wasn't seriously limited (and it is) it would require dedicating a fairly high end cloud server instance (with CPU and GPU) to EACH logged in user. That might eventually be plausible, but right now it'd be like taking on the cost of about 10 additional grids with no additional income. ___ 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] ReviewBoard email to this list?
On 2010-12-02, at 07:52, Oz Linden (Scott Lawrence) wrote: > This will mean a considerable increase in list traffic, I think, since every > commit to viewer-development should be reviewed. I think that the increase > in transparency of what is happening, and the opportunities for everyone to > learn more about more of the code base makes this increase worth it, but am > interested in the opinions of other list members. I remember a number of occasions where discussions were shut down because of the effect on traffic on this list. I don't disagree with any of those occasions, I think "a substantial increase in list traffic" needs to be viewed with some alarm. ___ 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] Arrow Keys Always Move Me
See STORM-560 for more details. On 2010-12-03, at 19:48, Glen Canaday wrote: > Hey, > > I'm a little curious - what's the expected behavior of "Arrow Keys Always > Move > Me"? I was under the impression that this was meant to cause the arrow keys > to > be the only movement keys, freeing up the rest of the keyboard for chat. I'm > wrong, aren't I? > > --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 "Welcome back, Anonymous, we're glad to see you again!" ___ 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
You know what would really help people get over the hump of setting up for building SL? A VMware appliance containing a working SL build environment, for 32 and 64 bit Linux. On 2010-12-12, at 09:02, Aidan Thornton wrote: > On 12/12/10, Marc Adored wrote: >> Awesome I will checkout the latest then and try to compile it. I >> wasn't aware it was even close to working. I'm excited now. > > It's actually been possible for a while, but until recently you had to > manually dig up patches from the Wiki in order to compile a 64-bit > viewer successfully. Last time I tried, the major obstacles were: > * Having compiled Google Breakpad, getting the viewer build process to > find it is fiddly. It seems to require a slightly odd layout for the > header files. I had to manually create some directories with the > correct names and copy the headers to them. > * Building a 64-bit version of llqtwebkit is a real pain. I believe > the Imprudence developers have created a pre-compiled version of this > recently - if it was available when I was trying, I'd have been > tempted to use 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 "Welcome back, Anonymous, we're glad to see you again!" ___ 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 2010-12-12, at 20:03, Mike Chase wrote: > On 12/12/2010 04:09 PM, Argent Stonecutter wrote: >> You know what would really help people get over the hump of setting up for >> building SL? >> >> A VMware appliance containing a working SL build environment, for 32 and 64 >> bit Linux. > Or a KVM/qemu image assuming the target audience is running 64bit Linux. VMware Player runs just fine under 64 bit Linux. I have a number of users using that combination for their meagre Windows needs. Really, an OVF image would be best, so it can be run under any VM. ___ 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")
Why not just paste it into a notecard? On 2010-12-24, at 10:09, Garmin Kawaguichi wrote: > > - Original Message - > From: "Opensource Obscure" > To: "OpenSource Mailing List" > Sent: Friday, December 24, 2010 12:17 PM > Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS > (was "Daily Scrum Summary - dec. 23") > > >> What I was thinking about was a new, different way to achieve >> something we usually achieve through landmarks.. > ... >> I'm thinking about management of Bookmarks in current >> main web browsers,... > > Something like : > secondlife:///app/teleport/furvata/132/126/96 (which can be used to direct > teleport when clicked) > > but > > stored in the inventory as a new asset item different from asset item #3 > (INVENTORY_LANDMARK) and defined as a web link directly usable in the > viewer. This link can be created in the inventory with a right click New > Link and can be edited. > > GCI > > ___ > 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 "Welcome back, Anonymous, we're glad to see you again!" ___ 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
On 2010-12-28, at 14:40, 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.). Add a "login" tab, which would make room for a notation indicating that there are privacy issues (as there are for "remember my password", or enabling message/chat logging). ___ 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...
> > There should be a few fallback strategies like: > a) Try to keep the old cache entry. > b) Use the normal user name. > c) Maybe even use the UUID. > > But just showing everyone (in the worst case) as ??? really screws > things up IMO. Agreed. The TPV I'm using seems to use the Legacy Name if the Display Name is not available. ___ 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] Convexdecomposition for open source devs
On 2010-12-30, at 08:47, WolfPup Lowenhar wrote: > That is why I put the link to the sites where the source is hosted so you can > check this and the license they are using are full GPL which is compatible > with LGPL if I remember correctly. If you use a full GPL component then you have to use full GPL for the whole viewer, rather than the LGPL. It's better to say "the LGPL is compatible with the GPL" rather than the other way around. ___ 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: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.
On 2011-01-10, at 13:03, Zi Ree wrote: > Am Montag 10 Januar 2011 17:34:08 schrieb Ponzu: > >> What if the upload dialog had a check box? >> >>[ ] This texture should have an alpha channel. > > Would it be possible to do this on a per-face basis rather than on texture > upload? So people could use the same texture as alpha texture and as > non-alpha > as well? > > Edit Texture > [x] Use Alpha How about: [_] Full Alpha, [x] 1-bit Alpha, [_] No Alpha. ___ 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] web profiles.
On 2011-01-11, at 21:47, Simon Quinnell wrote: > How about you specify the security and privacy issues? No-one here is a mind > reader. Well, the obvious minor privacy issue is sharing information about your account with sites outside Linden Lab, if only because you're passing cookies and browser tags to Facebook and Twitter. I would be more comfortable if there was by default no data fetched from anywhere but LL by the viewer. Suggested options: [x] Hide third party badges on profiles I'm viewing. [x] Hide third party badges on my profile. I would also rather not have any RL information displayed in profiles I'm viewing unless I deliberately click through to a "RL tab", as in the 1.x profile. [x] Hide RL information on profiles I'm viewing. [x] Hide RL information on my profile on the web. ___ 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] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages
On 2011-01-12, at 16:32, Joel Foner wrote: > Skype still supports /me... Many of the folks I know use /me regularly, for > what it's worth. Skype displays the difference much more obviously, placing > the text centered with different styling than normal chat with /me, so it has > more emphasis than in sl visually. I don't understand why it needs to be highlighted at all. Just get rid of the ":" and if there's punctuation the following space. I find the italics in viewer two stupidly annoying. ___ 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
On 2011-01-18, at 15:58, Sarah (Esbee) Kuehnle wrote: > This is not a feature belongs in the Viewer. If there's more data you want > out of llGetEnv(), I'd suggest filing an SVC feature request. "Just wait, next month we'll have someone needing help figuring out why llGetEnv is broken on the latest BlueSteel" :) :) :) :) (No, I'm not arguing, I'm being amused) (in case the smileys didn't get that across) ___ 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] from debug to prefences
On 2011-01-24, at 11:25, Erin Mallory wrote: > Here's how it would work. We take the existing advanced preferences tab and > turn it into a floater activated if you click on where the advanced tab is > now. we then bump many of the preferences that are in the debug over. we can > do it in kinda a category form as the sketch here shows or break it up into > tabs. I like the general idea. How about making it like the "about:config" screen in Firefox? That's an interface that works well for complex preferences, doesn't require any significant per-reference customization, is familiar to people who are likely to be messing with it, and is much easier to browse than the debug window? ___ 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-3156
On 2011-01-25, at 03:09, Nexii Malthus wrote: > It would be great if the mini bar graphs would make a comeback. But I think > they might need some improvement so they can be easier to "relate to". Be very careful. The last time they decided to "improve" them the result was the worthless lag meter. Humans are very good at pattern matching and pattern detection. Let us use that capability. ___ 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-9 - sharing location and status message to Twitter
On 2011-03-20, at 13:43, Opensource Obscure wrote: > I just commented STORM-9, that is > "As a User, I want to share my location and a custom status with friends > on Twitter so they can follow what I’m up to in Second Life" Thanks for bringing this to my attention. This is not something that belongs in the viewer. It could be implemented securely as user generated content using an external website and a HUD. There's no reason for Linden Lab to be in the loop at all. ___ 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 2.6.1 with Advanced and Basic mode
I like the suggestion that the "basic" mode be called something like "tourist" or "introductory" or "beginners" mode. There's just so much stuff that people need to be able to do that it seems to be ruling out, I can't imagine anyone sticking with it for long. "Basic" implies that someone could actually use it permanently. ___ 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 2.6.1 with Advanced and Basic mode
On 2011-03-20, at 15:04, Da5id Kronfeld wrote: > I like "tourist", with maybe (eventually 3?) modes: "tourist", "resident", > and "creator" (or "resident-creator"). I don't think separating "creator" like that is a good idea. Everyone in SL is potentially a creator, at every moment, that's what makes it cool. ___ 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: Change to description for ShowNetStatus in debbug settings.
I agree with Boroondas. "Viewer and Network Usage" is wrong. Either "Packet Loss and Bandwidth" or simply "Network Performance". On 2011-04-05, at 16:55, Boroondas Gupte wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/251/ > > indra/newview/app_settings/settings.xml (Diff revision 1) > 9560 > Show the Search Bar in the Status Overlay > 9560 > Show the Status Indicators for the Viewer and Network Usage in > the Status Overlay > "Viewer Usage"? > > I think the indicators show packet loss and used network bandwidth. > > > - Boroondas > > > On April 5th, 2011, 9:31 a.m., Wolfpup Lowenhar wrote: > > Review request for Viewer. > By Wolfpup Lowenhar. > Updated April 5, 2011, 9:31 a.m. > > Description > > This is a change in the description for the ShowNetStatus debug setting. > Testing > > None needed as this is only a textual change. > Bugs: STORM-1098 > Diffs > > • indra/newview/app_settings/settings.xml (3fc9a496265c) > View Diff > > ___ > 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 "Welcome back, Anonymous, we're glad to see you again!" ___ 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] in-viewer translation is dead soon.
On 2011-05-28, at 22:52, a...@skyhighway.com wrote: > i don't know if i misunderstood or not, but are you really talking about > Google translation services particularly picking on SL access? All the > mail sounded to me like it was more of a policy decision at Google > affecting everyone everywhere? Indeed. Apparently there are over 600 apps using this API in the Android store. Changing the way SL uses the API isn't going to change Google's mind. The logical thing to do, it seems to me, is to see if LL can license access. ___ 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] in-viewer translation is dead soon.
On 2011-05-29, at 06:39, Daniel wrote: > You didn't read my previous comment apparently. They are NOT shutting > off all translations. > They are shutting the freestanding translation page in favor of embedded > translation web > elements within pages. That's not what I read. What I read is they're shutting off the API. http://code.google.com/apis/language/translate/overview.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] Review viewer -- draw distance slider
I think the icon should be a magnifying glass. ___ 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
On 2011-06-12, at 10:42, Hitomi Tiponi wrote: > Trouble with that is that LL already have that symbol [[magnifying glass]] > used for Search and also for Zoom on the World Map, and it isn't really a > 'zoom' feature. You're right. Suggestion withdrawn. ___ 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
How about a camera iris? ___ 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
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
Re: [opensource-dev] DD Philosophy
On 2011-06-17, at 11:41, Hitomi Tiponi wrote: > Please no automatic DD - there are two many variables and differing > circumstances for it ever to work. Much better to work on other ways of > improving fps e.g. selective updating of avatar movement. Me too. At the very least, make it a non-default option. I adjust DD based on network traffic and rez times more than FPS. Also, that "DD" logo someone suggested... isn't that TM Marvel or whoever owns Daredevil? :) ___ 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] Question about DD philosophy.
On 2011-06-18, at 13:00, Robert Martin wrote: > > one thing that i don't understand is why you can be at 4000 meters in > an untextured skybox and still within seconds get GROUND TEXTURES and > other objects on the sim before the contents of the skybox or > attachments on the client avatar (this even happens with a very short > draw distances). https://jira.secondlife.com/browse/SVC-2413? ___ 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 question/comment about the behavior of auto-pilot camera.
On 2011-06-25, at 10:58, Lee ponzu wrote: > Maybe we need to think through a more general solution. It occurs to me that > llRayCast() is going to make it easier to create scripted route/path finders > using simple AI. Some possible useful behaviors... > > • Go here. > • Go here and sit. > • Go wherever this avatar goes. > • Exactly trace the footsteps of this avatar. > • Try to stay just to the left of this avatar. > • Try to stay just to the right of this avatar. > • Try to get in front of and face this avatar. And the one I most want... follow these waypoints (here, and here, and HERE, and here...) ___ 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] Adding Neck and Root Attachment Points
Me Too ___ 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: Allow objects to have 99.99% max hollow for default hollow shape.
On 2011-07-11, at 23:05, Dahlia Trimble wrote: > One thing I noticed while coding collision geometry for OpenSimulator is as > hollow is increased and prims are twisted or otherwise manipulated such that > the hollow shape doesnt exactly follow the outer shape, the probability > increases that the surfaces formed by the triangles that make up the hollow > shape may actually protrude beyond those that make up the outer surface. I'm > not sure what SL sims do under these conditions but what ODE (Open Dynamics > Engine - most commonly used physics engine in OpenSimulator) is create a > condition where physical objects may become trapped between the resulting > surfaces. ODE uses trimesh colliders and surface normals for determining > collision surfaces and if prim hollow surfaces protrude outside of prim outer > surfaces, the surface normals for these surfaces point in the wrong > direction. This can be alleviated by increasing prim vertex count, but for > some of these prims vertex count may already be even greater than 4000 > vertices. Increasing it further would use excessive memory and likely > increase the cost of computing collisions dramatically. I've found that a > limit of 95% maximum hollow is a good compromise between prim complexity and > usability. > > > On Mon, Jul 11, 2011 at 7:34 PM, Wolfpup Lowenhar > wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/388/ > > Review request for Viewer. > By Wolfpup Lowenhar. Given the possible uses of this capability, it would be acceptable for the physics shape to pin at 95% while the rendered shape is allowed to be thinner. ___ 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: Allow objects to have 99.99% max hollow for default hollow shape.
On 2011-07-12, at 14:57, Boroondas Gupte wrote: > > I think by "ticket", Vadim meant the jira issue. I've already left a comment > there with a reference to this discussion. Ah, thank you, I added my comment there as well. ___ 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] FUI project just out - no more sidebar
On 2011-10-18, at 21:09, Geenz wrote: > I can't be the only one who thinks that window management needs to be > re-thought for FUI. As it stands, it seems as if that actually took a step > backwards. One thing that's an immediate show-stopper for me: chat as a separate floater. After all the debate over chat in 2.x, how could they even further marginalize 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
Re: [opensource-dev] FUI project just out - no more sidebar
On 2011-10-20, at 12:23, Kadah wrote: > To me local chat is the same since 2.0, except now the local chat log > and chat bar panels are in the same floater. I agree that it should be > a stopper, but I have thought since 2.0 beta. I don't use the local chat log, I use the chat overlay. ___ 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: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
How about reducing the vertical resolution of the packet by 4? ___ 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] View on Lion
> For that matter, what is the status of Lion, period. OS Xista? Or is it ok? OS X Vista. Definitely. ___ 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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity
On 2012-03-21, at 12:42, Geenz Spad wrote: > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" > looking specular model, as opposed to other platforms which try to go for > more physically accurate looking models, such as blinn-phong and similar. Could we see some examples of SL scenes using the two models, because there have been a number of changes to the SL renderer over the years... and the main effect of increasing the "realism" of the renderer has been to throw the deficiencies of the SL avatar mesh into sharp relief. The current specular model was a deliberate compromise. ___ 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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/565/#review1191 --- Could we see some examples of SL scenes using the two models, particularly with avatars in them, because there have been a number of changes to the SL renderer over the years... and the main effect of increasing the "realism" of the renderer has been to throw the deficiencies of the SL avatar mesh into sharp relief. The current specular model was a deliberate compromise between the older even-toonier renderer and a more "realistic" model that made avatars look horrible. - Argent Stonecutter On March 25, 2012, 2:07 p.m., Geenz Spad wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/565/ > --- > > (Updated March 25, 2012, 2:07 p.m.) > > > Review request for Viewer and David Parks. > > > Description > --- > > For a while now, Second Life's deferred renderer has had a somewhat "toonish" > looking specular model, as opposed to other platforms which try to go for > more physically accurate looking models, such as blinn-phong and similar. > > This feature changes the specular model to a technique called normalized > blinn-phong. The specular model applies the usual blinn-phong term (assume > NdotV to the power of n), multiplied by a normalization function of: > ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n)) > Where n is the specular exponent. > > Gamma correction is also applied to the result to bring the visual results > more in line with what you see in high end game engines such as Unreal Engine > 3 and Frostbite 2, and stored in a lookup texture. > > Test plan can be found in the JIRA. > Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp > > > This addresses bug STORM-1823. > http://jira.secondlife.com/browse/STORM-1823 > > > Diffs > - > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl > b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl > b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl > b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl > b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 > > Diff: http://codereview.secondlife.com/r/565/diff/diff > > > Testing > --- > > * Tested performance characteristics - both Normalized Blinn-Phong and the > previous model seem to have the same performance > * Checked the perceived "brightness" of the new highlights vs. the old ones - > new ones seem much brighter at higher shiny values than the old ones, and > seem much less "cartoonish" as such > * Checked the impact on different bumpiness values at the test rig at Hippo > Hollow - noticeable visual improvement across all objects (though low shiny > seems to have a much more subtle light reflectance term - this is expected > for normalized blinn-phong) > * Tested different LUT resolutions - best looking seems to be 512x128 with > seemingly no measurable decrease in performance > > You can find the latest build here: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html > > > Thanks, > > Geenz Spad > > ___ 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] Tutorial needed on TPV viewer-side AOs
The overhead of a conservative scripted AO is pretty low, and the ability to switch AOs by wearing an asset (attaching the AO HUD) means that I can have appropriate AOs for each of my avatars and outfits without having to tweak my client settings each time I jump from kangaroo to grasshopper to dolphin to ferret... ___ 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] Tutorial needed on TPV viewer-side AOs
On 2012-04-13, at 00:09, Adeon Writer wrote: > Wouldn't a new inventory item type make most sense? That way it could be put > in with any outfit folder or packaged with sold avatars. For a LL-provided feature, yes. I was still disappointed when TPVs didn't implement something like an "AO attachment point" that accepted a box containing a notecard and animations ___ 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] Tutorial needed on TPV viewer-side AOs
On 2012-04-13, at 12:17, Zi Ree wrote: > Am Freitag, 13. April 2012, 18:35:00 schrieb Adeon Writer: >> Alright, here's some features that, if missing, *someone* would complain: > > All of your requirements are present in the Firestorm viewer side AO. Only because he forgot to include the extremely important "it has to be an asset that can be worn with an outfit". That one's a complete dealbreaker for me. ___ 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] Tutorial needed on TPV viewer-side AOs
On 2012-04-13, at 18:05, Kadah wrote: > I believe FS's was designed to mimic the ZHAO II hud, it even uses its > config notecards. "Franimation Overrider" is a new one to me. Franimation is what ZHAO was originally based on. ___ 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] Tutorial needed on TPV viewer-side AOs
On 2012-04-13, at 20:28, Ziggy Puff wrote: > Agreed, for purely selfish reasons. I hope LL adds new LSL functions > that enable AO features / performance / scalability that is impossible > today. Then someone else will write the next ubiquitous AO, and I will > eventually stop getting the "Your walk sucks, I want my money back or > I'm reporting you to the Lindens" IMs. My only piece of advice to > whoever might pick up that baton - don't distribute it in a form that > allows someone to sell an object with your name as creator. Heh. I get all kinds of _interesting_ messages about "my" avatars or sex toys or what have you not working, because they use a version of one of my scripts. ___ 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] allowing client side AO's to swtich with outfits
On 2012-04-15, at 12:13, Erin Mallory wrote: > 1) Allow outfit folders and AO sets to be able to share a "hotkey" so that > pressing that hotkey will both equip the outfit and activate the AO > 2) Script in a right click menu option at the outfit folder level that asks > if you want to link an AO config to activate the ao when equipping the > outfit. IE: you right click the outfit folder and when the menu pops up it > has something like "Set outfit AO." Neither of these are acceptable, it _has to_ be something in the inventory that is managed with the inventory tools. Otherwise there's no reason not to keep using the existing scripted AOs. Ideally, it's just a box, like an existing AO, except instead of having a script in it it's attached to an "AO" attachment point or has a name like "#AO". Alternatively, a scripted object could run and llOwnerSay a series of magic strings containing the animation name and animation type, in on_rez() or attach(). ___ 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] allowing client side AO's to swtich with outfits
On 2012-04-16, at 00:50, Erin Mallory wrote: > Why would it need to be in the inventory taking up space when it would ONLY > do the same thing that either of these options do? I have over 300 outfits, each with their own set of AO choices... maybe 15 or 20 different sets of AOs depending on the shape of the base avatar in the outfit, attachments, and general style of the avatar. I change avatars radically, maybe a couple of times a minute when it makes sense. I already have an appropriate AO item in the inventory for each avatar... changing them gradually over to calling the item #AO or moving its attachment point and turning the scripts off or changing the script to one that chats the Notecard to the viewer on attach, that I am willing to do. Under your scheme I will first have to manually configure the AO into the viewer, then associate it with the inventory. Then I will no longer have any record in the inventory of what AOs are associated with each outfit. If I'm using SL from another computer, or I lose the profile directory on my computer, all of that's gone, forever. There's no way I'd ever be able to reconstruct it. And for what benefit? A barely measurable drop in my script time (which is already very low), a savings of 16k of script memory (and people are routinely walking around with megabytes of scripts), and possibly better behavior in laggy areas. It's simply not worth the effort and risk. ___ 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] allowing client side AO's to swtich with outfits
On 2012-04-16, at 09:34, Erin Mallory wrote: > I doubt it would be that hard to establish a way to ensure that the config > could be exported to an easy to read table that can have the option to save > to either a file on the computer (for easy reference) or as a single notecard > within the ao folder that other viewers can read and allow you to import > either manually or individually. An additional hot tip when you mouse over > the folder could tell you what AO is associated with the outfit. If the AO is not a single inventory item that I can copy from one folder to another, or link, or otherwise treat it as any other wearable, then I'm not going to use it because I can already do all that. > As someone that has to constantly pack and unpack things on my two oldest > accounts in order to even be able to get my inventory to fully load, the idea > of having to add another item to each outfit folder I make pretty much > destroys any advantage to having a system that could associate the ao with > the outfit. The item is _already in my folder_. There's nothing to add. > I use in client ao systems to reduce attachments, lag, and inventory > clutter. A system that relied on objects in each outfit folder would be a > huge step backward for me. If you don't need this feature there's no reason you can't keep doing whatever you're doing. ___ 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] Talk/shout circles on minimap, lost in the cracks?
On 2012-05-08, at 11:27, Oz Linden (Scott Lawrence) wrote: > No... the user experience folks decided that the minimap was confusing > enough and that the circles made it worse. o_O ___ 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] feature suggestion: make "doubleclick navigation" more "immersive"
User story: I would love to be able to set waypoints like in Everquest for mouse navigation. It's not too confusing, I don't know how many people played Everquest but they were all able to figure it out. ___ 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] Monospace ASCII-art font
Full Unicode, I would hope! On 2012-10-27, at 18:08, gistya gmail wrote: > I'd like to help work on a monospace font option with IBM PC ASCII box > drawing characters for use in notecards and settext. > > Notecards would get a simple checkbox at the bottom to toggle between > monospace and regular. Settext would get a new function, llSetTextMonospace. > Maybe there could even be llSetTextMonospaceTableFromList or -fromCSV, with a > box style and divider style flags. > > This would allow for much easier display of tables of information. It could > even allow for things like an in-world forum HUD :-D > > Thoughts? Should I post this as a JIRA instead? Thanks > > ___ > 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] Review Request: Put the viewer version into marker files, and report errors only when the version matches
On 2012-11-01, at 21:30, Ricky wrote: > Well, all I have is anecdotal evidence from my own family of four, everyone > an SL user: we all keep multiple versions of the SL viewer, and even a few > TPVs, on our machines. If one viewer crashes it's more often that the person > it crashes on will relog in another version or viewer - just to avoid the > perceived, if possibly inaccurate, cause of the crash. We may switch viewer > versions on the second or third crash, depending on the individual, but the > effect is the same. Different versions of the _same_ viewer can have incompatibilities in its config file, to the point where Firestorm recommends you do a clean install when upgrading, and you're running _different_ viewers on the same config? I suspect you will have fewer crashes if you give each viewer its own directory... and the crashes you're getting may not be statistically useful 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] Formal Animation Set Replacer
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
Re: [opensource-dev] Formal Animation Set Replacer
On 2012-11-03, at 22:39, Carlo Wood wrote: > LSL AO's have always failed majorly. I have used and written LSL AOs for 7 years now, and I haven't seen this "majorly" failing. Certainly nothing compared to the shortcomings of client-side AOs. Being able to load AOs from a wearable is kind of a key feature, in fact not having that is a deal-breaker, and none of them even attempt to implement it. Server-side AOs that can be loaded with wearables would be great, but they're out of scope for this list. ___ 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] Rebuilding Breakpad
Shouldn't builds be based on build rules, and not on tweaks in the application? On 2012-11-11, at 12:06, Nicky Perian wrote: > I saw some message list traffic on the cmake list about the newer cmake > versions having some lion behavior tweaks. > http://www.cmake.org/mailman/listinfo/cmake that is the subscribe link, You > should be able to find the archive from there. > > I don't have a mac so, I don't kn0w the details. ___ 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] BUG-1610: Current development source does not build with glibc 2.17
On 2013-02-09, at 15:40, Cinder Roxley wrote: > Here's a better fix than the other one I posted earlier… Don't use > extern "C". That... shouldn't work, unless it's generating C++ code in lex/yacc/bison/whatever. ___ 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] Cocoa Project Viewer
Where should I report bugs in the Cocoa Project Viewer? On a MBP running Snow Leopard with an 800 pixel high display, the window is taller than the screen and can't be shrunk, even by editing the NS window size settings in the .plist file. This makes it unusable on that laptop. Other than that, I hope some of the TPVs bring in that code base for their Mac versions, because it's wicked fast. ___ 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] Is the Cocoa project still alive ?
On 2013-05-11, at 12:15, Laurent Bechir wrote: > I haven't seen any new build of the Cocoa Project viewer since 02-28, and the > last one freezes on startup on my Macbook Air with Mountain Lion 10.8.3. I think replacing the arguments.txt file with the one from the original fixes the crash on startup. It did for me. ___ 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 2013-07-30, at 10:25, Carlo Wood wrote: > 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. Let's say we have avatar A and avatar B. Avatar A is throttled to 4% of the spare bandwidth of a sim, and avatar B has a nice fast pipe and us capable of using 40% of the spare bandwidth of the sim. Avatar A arrives, and slows everyone down by 4% for 10 minutes. Nobody notices. Even if half a dozen such avatars arrive, nobody cares. Avatar B arrives, and slows everyone down by 40% for 1 minute. If you have multiple such avatars arriving at the same time, you'll have a pretty sick sim. Avatar B is using a disproportional amount of the available bandwidth. ___ 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 Tools Upgrades - with a call for help
On 2015-02-07, at 16:24, Cinder Roxley wrote: > On February 7, 2015 at 3:13:31 PM, Oz Linden (Scott Lawrence) > (o...@lindenlab.com) wrote: >> On 2015-02-06 16:12 , Cinder Roxley wrote: >>> It would simply things greatly to remove lscript from the viewer >>> completely, thereby removing the dependency on flex/bison for building. >>> lscript is unused other than a few const values. Several tpvs have dropped >>> lscript from the build. (I’ve personally done that in two different tpv >>> projects.) >>> Is this something Linden Lab would be willing to consider? I’d be happy to >>> do the work to remove it if it is. >> What would the end user effect be? > The change would be transparent for the user other than saving them a small > amount of space on their hard drive. I have no idea what the final size of > lscript is when compiled, but it’s basically all dead and broken code and has > been for several years. Doesn't the script editor use it for syntax coloring? Or has it dropped back to using a more simplistic algorithm? ___ 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] Replacement for QuickTime media plugin - a straw man proposal
> • Ask for help from open source developer community to create a > version for Linux using LibVLC Since Linux currently doesn’t use Quicktime, why doe it need to be converted? ___ 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 scripting in Snowglobe
7. 8. 9. 10. ... I'm not going to run client-side scripts if I can't eyeball them. Creating a sandbox is a huge, complex, and difficult job, even in an application designed to run untrusted content from the ground up. Putting a blind scripting environment inside something like the SL client is risky. Putting one that isn't inherently secure in there is scary. Linden Lab does not trust the Mono sandbox on the server: you can't upload Mono bytecodes like you could LSL bytecodes. And they shouldn't. LSL bytecodes are run in an inherently secure environment... they can not perform any operation outside the capabilities of the LSL runtime: security and access controls are implemented outside the interpreter. Javascript and Activescript in Flash are in the same situation: they are languages that can (and usually do) run in an interpreter that does not even implement unsafe operations. Java and Mono/.NET intermediate language can do anything native code can, they are not inherently secure, and should not be treated the same way. * Even if the entire viewer was run in a provably secure virtual machine this would not seem like a safe option to me, since the viewer has full access to all my assets and account information in Second Life. Now there are situations where this kind of assembly would be acceptable, where it's treated and presented to the user as an application, where the user has to explicitly request that it be installed, where it is made clear that installing a plugin is the same kind of risk as installing and running an application. But not when it's something that can be pushed from an untrusted source with no more than a warning dialog between you and HonestImNotInThePN ThrowawayAlt. Even if they were using an inherently safe language, accepting unexaminable binary payloads from untrusted sources and running them in the SL client in anything like its current state would raise all kinds of warning flags with me. Doing this using an internally- sandboxed interpreter just isn't something I'm prepared to do. * No, I don't use Silverlight and I have Java disabled. ___ 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 scripting in Snowglobe
> and this is where languages like perl/python have a strength since the > files are plain text > so if you think that a script is doing something funky you can just > look at the script and see. Mono/dotnet code is compiled and very > easily could hide just about anything. I think using anything but Lua or Javascript (each of which has sandboxed implementations and a community of people already familiar with client-side scripting like this) for any kind of server-pushed client side scripting needs an exceptional justification. The only case I can se for using Mono here is to allow people to write client- side scripts that can not be easily eyeballed by the users. There is of course a community in SL which would consider this an important goal, but given the state of the client and the security model (and I'd be happy to discuss that offlist) I don't think that's a reasonable design goal. ___ 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 scripting in Snowglobe
On 2010-02-19, at 01:16, Ricky wrote: > I suspect that there are two things being discussed here without > distinction: Client scripting, and client extensions. Confusing the > two is easy. > > Client-side scripting SHOULD be sandboxed, and in a controlled set > of languages. For a close example think of javascript in web > browsers. > > Client extensions, or alternatively named as "plugins", would be > modules that can be plugged in and out of the client and run /as if/ > they were a part of the client. Think of browser add-ons/plugins/ > extensions. > > Client side scripts could (read might be, could possibly, needs > further thought, etc.) be given permission to be loaded in by worn > items automatically. Other objects would likely need to request > permission via a security warning. > > Client extensions would have to be downloaded and installed > externally; not delivered in-world. These would truly be programs > on your computer, and should be treated as such. > > Just my thoughts hoping for a clearer discussion. A very good summary. Thank you. ___ 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 scripting in Snowglobe
On 2010-02-19, at 12:53, Robin Cornelius wrote: > Well Morgaine's socket based idea could over come this very easily. If > the API was exposed via a socket, LL could provide a plugin loader > much as they do for the MediaAPI now, if they want, this pluginloader > could be CLR based and the default LL implementation of plugins could > be mono assemblies. So the plugin loader could be directly used by any > language that can produce CLR binaries. I suggested a socket based extension mechanism some years ago and was knocked down because you couldn't do things that required high performance access to textures, shaders, and so on. If that overhead is acceptable, then the socket mechanism would be completely language- agnostic, and it might even act as a legal firewall between the GPLed client and extensions. ___ 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 scripting in Snowglobe
On 2010-02-19, at 18:51, Rob Nelson wrote: > My main problem with Socket-based thing is that it opens up all > kinds of > problems, ranging from outside apps screwing with the socket and doing > stuff that the user has not authorized, If the socket is bound to 127.0.0.1 then only applications on the local machine can connect to and register with it. > to simple security concerns (I'm > sure as hell going to trust a readable > Lua/LSL/shell/anything-other-than-LISP script more than a binary > executable or shared library), This mechanism would allow your script to be written in Perl, Python, Seamonkey (standalone javascript), Lisp, VBscript, Applescript, Tcl, Lua, Icon, even shell. They would not need to be binaries. ___ 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 scripting in Snowglobe
On 2010-02-20, at 19:37, Morgaine wrote: > > It is interesting to hear that you also had this kind of > communications architecture in mind. I think perhaps it's an > applications model whose time has finally arrived, the age of > multicore. It's a fairly natural model. It was really first introduced around 1970 in UNIX... it's called the "pipe". Even on a single-core system it provides a significant performance improvement for a large class of problems where I/O and throughput matter. Of course as multi-CPU UNIX servers became common in the '80s and the norm in the '90s it just got better and better. ___ 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 scripting in Snowglobe
On 2010-02-22, at 03:13, Tigro Spottystripes wrote: > the other day i was reading about how the Unreal engine works, they > have > the client predicting the physics and sending control events tot he > server. During a lag spike the client continues to simulate the motion > by itself, and then whent he server starts talking again the server > sends the position, speed, rotation etc of stuff and the client > adjusts > it's local simulation to match That's pretty much what the SL client does, it just has a particularly simplistic physics (no collisions, no gravity, everything moves in straight lines). ___ 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 update
On 2010-02-24, at 02:26, Thomas Shikami wrote: > SOCKS5 is usually used by griefers to mask the IP address. SOCKS5 is the only way to connect if you are behind a reasonably secure corporate firewall. SL is completely out of the question for business use without SOCKS5 support, even for the kind of "3d corporate website" model that LL is pushing. ___ 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] Third party viewer policy
On 2010-02-23, at 15:43, Robin Cornelius wrote: > Also any one using mono with libomv has an issue as that cannot get > the adaptor mac address and passes a NULL mac address, in the past LL > have allowed a null mac address as they knew of this problem, clearly > now though thats a breach of 2c part i. Not to mention that any device using SLIP or PPP, (and probably other point-to-point protocols that don't require an address at the physical layer) may not have a MAC address or ANY analogous hardware layer address (even a PSTN). TCP/IP does not imply Ethernet. Admittedly this is not likely to be a common scenario, but the whole idea that a MAC address is a unique identifier for a device is based on a deep-seated confusion about the network stack. ___ 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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses
Gigs... I think what you're looking at is akin to Tivoization, and providing an external source for Tivoized content is compatible with GPL2 (and is one reason for the GPL3). ___ 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] TPV & opensim & physics prediction
On 2010-02-25, at 15:12, Dzonatas Sol wrote: > [Usenet] worked. It is still free and open. It used to be. It's getting harder and harder to get feeds these days. Everyone just reads through Google Groups rather than trying to find someone with a feed. SL and OpenSim started with the equivalent of "Google Groups" already live. It wasn't even vaguely real-time. It was *OK* that the stanford- munnari link was a daily airmailed magtape, nobody cared if their newsfeed was a day behind. ___ 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] "Second-Party" viewer policy (was: Third party viewer policy)
On 2010-02-26, at 05:27, David Simmons wrote: > The common sense rules apply. If you are not connecting to the LL > grid, Linden Lab can't make any policy regarding what you do. They > don't need a policy saying that they can't make a policy telling you > what to do on another grid. Is that a legal opinion? Words MEAN different things when lawyers are involved. ___ 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] FAQ posted for Third Party Viewer Policy
On 2010-02-27, at 20:24, Soft Linden wrote: > On Sat, Feb 27, 2010 at 10:32 AM, Fleep Tuque > wrote: >> >> The free content I create for education is intended to be fully >> free, fully >> permissioned, and fully exportable to other grids. Beyond the >> Second Life >> permissions, I keep hoping for checkboxes on the Edit menu with >> common >> licenses or a space to put a link to the user's specified license >> that is >> kept with the object info just like creator name. >> In any case, when I include Creative Commons licensing with my >> educational >> tools, and explicitly say users have my permission to explore the >> content to >> other grids, then I expect that to be respected by Linden Lab as >> well! > As someone else pointed out in this thread, you're able to host your > content outside of Second Life if you want to ensure people are able > to import it again. You're not restricted to using Second Life for > content distribution, and with an external site you can present your > full license, not just half a byte's worth of permission data. Regardless, http://jira.secondlife.com/browse/SVC-701 ___ 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] TPV & opensim & physics prediction
If you don't mind days round trip for each line of chat. On 2010-02-28, at 14:05, Dzonatas Sol wrote: > This is perfect then... > > If you are scheduled to meet in a sim later in the week, then why > worry if all the static objects take a day to download from that sim > through archaic usenet means. You would already have all the object > information needed for physics and to render in a local storage. > > By the time everybody meets, there would be no lag to suddenly > download all objects from a single host. > > Times that by 10,000 people... just for scalability concerns. > > Argent Stonecutter wrote: >> On 2010-02-25, at 15:12, Dzonatas Sol wrote: >>> [Usenet] worked. It is still free and open. >> >> It used to be. It's getting harder and harder to get feeds these >> days. Everyone just reads through Google Groups rather than trying >> to find someone with a feed. SL and OpenSim started with the >> equivalent of "Google Groups" already live. >> >> It wasn't even vaguely real-time. It was *OK* that the stanford- >> munnari link was a daily airmailed magtape, nobody cared if their >> newsfeed was a day behind. >> >> > "Welcome back, Anonymous, we're glad to see you again!" ___ 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] FAQ posted for Third Party Viewer Policy
On 2010-02-28, at 19:36, Joe Linden wrote: > TPV developers may choose to list their viewers in the Directory for > the value of receiving a wider awareness than they may be able to > create themselves, or not. That's entirely up to the developer. > All viewers that connect to the SL grids will need to abide by the > TPV Policy regardless of their choice to list in the Directory. > > And, since we're only talking about conditions that apply when a TPV > connects to Linden Lab's grid(s), we reserve the right to add, > subtract, or otherwise modify those conditions at any point in the > future. Then make the policy state that. Right now people are seeing it as ambiguous. ___ 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] FAQ posted for Third Party Viewer Policy
On 2010-02-28, at 21:30, Miro wrote: > You might wish to make time to read this (very long) thread, if you > have > not already: > > https://blogs.secondlife.com/thread/10467 > > Some research has been done into how the device works. Apparently it > exploits a vulnerability in QuickTime to access users' computers and > "mine" information about what software is, or was, installed on them. I think people are misunderstanding what's going on here. Quicktime doesn't listen on port 80. Parcel video depends on Quicktime. If you uninstall quicktime, parcel video doesn't work. This is almost certainly someone misinterpreting a parcel media request FROM the viewer to port 80 on an external server. ___ 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] FAQ posted for Third Party Viewer Policy
On 2010-02-28, at 21:49, Tigro Spottystripes wrote: > hm, i didn't thought he did collect IP addresses, but even if the > system > does catch IP addresses (which isn't such a big deal if you keep your > machine safe) an IP address wouldn't be of any help identifying > malicious clients, unless the malicious clients in question routed > stuff > thru a known proxy. If you read the thread they're talking about the ability of the system to identify alts. Which is precisely what a simple IP sniffer using parcel media would be good for. ___ 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] FAQ posted for Third Party Viewer Policy
On 2010-03-01, at 08:49, Lance Corrimal wrote: > Am Montag, 1. März 2010 15:42:00 schrieb Argent Stonecutter: >> On 2010-02-28, at 21:30, Miro wrote: >>> You might wish to make time to read this (very long) thread, if you >>> have >>> not already: >>> >>> https://blogs.secondlife.com/thread/10467 >>> >>> Some research has been done into how the device works. Apparently it >>> exploits a vulnerability in QuickTime to access users' computers and >>> "mine" information about what software is, or was, installed on >>> them. >> >> I think people are misunderstanding what's going on here. >> >> Quicktime doesn't listen on port 80. >> >> Parcel video depends on Quicktime. If you uninstall quicktime, parcel >> video doesn't work. >> >> This is almost certainly someone misinterpreting a parcel media >> request FROM the viewer to port 80 on an external server. > > so what? > set the media url to something that is not an url to a video, but > the url of a > script that exploits something in quicktime to gather data about the > client > requesting that url, and poof you have all kind of cans of worms > wide open. That's true, but the evidence so far provided is consistent with them doing no more than stripping IPs out. > ...and "flash on a prim" isn't going to make the whole grid more > stable and > secure either. No, I've been arguing that "web on a prim" was a bad idea for some years now. Yes, I'm enjoying the schadenfreude, thank you very much. ___ 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] FAQ posted for Third Party Viewer Policy
On 2010-03-01, at 16:13, Bryon Ruxton wrote: > I talked about banning every unknown or unidentified viewer that is > not in > the registry should I have a way to detect the viewer agent. Just > like I > have the right to restrict an unidentified web agent or telling an > Internet > Explorer 6.0 user than I do not support their obsolete browsers from > my > site. There are several sites where I have to lie about my browser, because their browser selection logic is screwed up. Like the ones that only work if I set the user agent to IE6 or IE5.5. Like the ones that insist I use Netscape Navigator 4 or better and don't work on Firefox. ___ 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] FAQ posted for Third Party Viewer Policy
On 2010-03-01, at 16:50, Bryon Ruxton wrote: > It's their problem and yours really. And not one that apply in this > environment. Yes, that was my point, The analogy doesn't apply. ___ 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] TPV & opensim & physics prediction
On 2010-03-01, at 20:38, Dzonatas Sol wrote: > Being able to distribute physic data about objects in a passive > manner has nothing to do with being able to network chat itself in a > non-passive manner. Oh, OK, so you're just talking about it taking days to rez a prim? ___ 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] TPV & opensim & physics prediction
On 2010-03-02, at 13:25, Dzonatas Sol wrote: > Argent Stonecutter wrote: >> On 2010-03-01, at 20:38, Dzonatas Sol wrote: >>> Being able to distribute physic data about objects in a passive >>> manner has nothing to do with being able to network chat itself in >>> a non-passive manner. >> Oh, OK, so you're just talking about it taking days to rez a prim? > If someone is scheduled to appear in a sim a week from now, then it > doesn’t matter if it takes 1 to 6 days to download, cache, and rez a > prim locally on the 7th day of the scheduled meeting. Given the way SL works, and the way people use it, this is an extremely unlikely scenario: * You're scheduling a meeting 7 days ahead. * There's not going to be any need to rez any prims that aren't already in the sim at any time during the meeting. ** Or less than 7 days before the meeting. ** Including attachments. ___ 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] TPV & opensim & physics prediction
On 2010-03-02, at 18:49, Dzonatas Sol wrote: > Let's add "burning man" event... so that is how many more sims! When I had a build in Burning Life, I was updating it all the way through the show, and I saw several people around me doing the same. That's just how SL gets used, in practice. If you want static builds that get uploaded and frozen into the sim, that's what Blue Mars is all about. ___ 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] Script Memory Limits UI
On 2010-03-06, at 14:49, Morgaine wrote: > It's been decades since computer users last had to specify the > memory requirements of their programs in advance of running them. About a decade. Mac OS required you to specify the partition size required by your program. This was also pretty common in real-time kernels. ___ 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] Script Memory Limits UI
On 2010-03-06, at 20:02, Frans wrote: > In response to the OP. I agree the UI will have to present that > information differently. As it is now people will merely make a > decision on memory usage and choose LSL scripts, and remove mono > scripts. Likely negatively impacting their own experience. Scripters > will be driven to compile scripts as LSL for marketing reasons, to > make a product report a lower value > Preventing LL from achieving it's goal of a full move towards MONO. This may not be a bad thing. LSL scripts require less work for instantiation and migration. For scripts that are not computationally intensive and are in attachments, it's unlikely that you'll ever get as good rezzing and sim crossing/teleporting experience with Mono scripts. They shouldn't be in any rush to eliminate LSL, and should allow LSL scripts to be compiled for smaller memory partitions as well. ___ 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] Script Memory Management Algorithm
On 2010-03-07, at 07:50, Carlo Wood wrote: > Lets assume that the *average* script uses > 8 to 16 kB of real memory. LL's design allocates > 64 kB regardless, leading to an overhead of > 400 to 800% (meaning they need to buy 5 to > 9 times the memory that is theoretically needed). This is not the case. Scripts use memory in smaller units than that. What I interpret the Lindens as saying is that they can not efficiently *measure* the amount of memory a script is using in real time with the kind of granularity required to make this useful. ___ 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] The Faces Of Client-Side Code
On 2010-03-07, at 08:20, Carlo Wood wrote: > On Sat, Mar 06, 2010 at 11:19:43PM -0800, Ricky wrote: >> Client Plugins > Ok, although I'd prefer if-- for example-- media plugins run in a > sandbox; > think about the recent mention of the quicktime exploit. The kind of sandbox you can usefully enforce for native code in an environment like this provides too little protection to justify the overhead it would require. Leaky sandboxes mostly provide a false sense of security. ___ 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] Question regarding llSetLinkPimitiveParamsFast() function in 1.38.0
On 2010-03-07, at 08:39, Obsidian Kindragon wrote: > I've a quick question regarding the new llSetLinkPimitiveParamsFast() > function in 1.38.0. Why did LL opt for a new function instead of just > removing the delay from the current llSetLinkPrimitiveParams() > function? Because code that currently depends on the implicit delay would break. This is similar to the reason many computers in the '80s had a "turbo" switch that throttled you down to 4.77 MHz so you could play games that depended on timing loops. > I can't conceive any case where removing the delay from the current > function would break any existing content. Code that wants to do something periodically and uses the delay as a timer. Yes, that's bad code. Doesn't change the fact that it exists. ___ 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 Plugin System Design
On 2010-03-08, at 10:06, Morgaine wrote: > Unfortunately, as you know from your own work, Rob, there is a big > difference between using an embedded language inline with its host > application's main or single thread of execution, and turning the > language into a concurrent execution environment that can run > multiple user scripts at the same time, which we need here. You could use the old fashioned real-time control system approach, make it event-driven (like LSL), and simply say that each script has to run to completion each time through the event loop... and outlaw long running event handlers. ___ 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] Script Memory Limits UI
On 2010-03-08, at 19:41, Lear Cale wrote: > Babbage has already said that LSO code will be "charged" 64K even > though it only uses 16K. Perhaps he's changed that decision -- is > that the case? I'd like some clarification there too, because I read that they'd backed down on that idea (which is good). If they've changed their minds again, I'd like to know. ___ 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] Script Memory Management Algorithm
On 2010-03-09, at 07:26, Carlo Wood wrote: > This is exactly the kind of reaction that drives me away from here. > > I propose a simple way get FOUR times the memory for all the > scripts, at > no other cost than adding some malloc code to your mono engine. I don't think you have established that. ___ 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
