Re: [opensource-dev] Anyone playing with Android and Second Life?
Ponzu wrote: > /me imagines a viewer that uses various ascii characters to render the > graphics... *COULD* someone be insane enough to hook up AAlib or libcaca to the viewer? What a scary thought! ___ Policies 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-829 Viewer 2 does not parse /me in object Instant Messages
Joshua Linden wrote: > I believe Aleric's comment is accurate. Logic testing for a prefix > should be removed from the patch, and the flag should simply always > be specified in this case. > It is notable that the flag does trigger exactly the same test that > is present in the patch (i.e. it's not case sensitive, it replicates > prefix testing in several other places in the code base, etc). A more > general fix might be to refactor all of the places that do prefix > testing, but that wouldn't affect this specific issue. Again, the > patch should be reduced to one line that simply adds the desired > flag. I'm... wondering why not test *ONCE* when the input is accepted, do the appropriate replacement and set the flag so it gets sent as an action instead of a statement, and be done with it? The IM input, chatbar inputs, and local history tab inputs all need pretty much the same validation, don't they? ___ Policies 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
Tateru Nino wrote: > Which is a shame. It's significantly less versatile that way. > On 13/01/2011 12:06 AM, Nexii Malthus wrote: >> "/me " is a *post-process*. I'm missing what versatility we're wanting in /me - I've always seen it as a rather straight-forward substitution. ___ Policies 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.
Boroondas Gupte wrote: > On 06/25/2011 05:58 PM, Lee ponzu wrote: >> # Go wherever this avatar goes. > A long time back, the viewer had a 'Follow' option in the context menu > on other avatars. If I remember correctly, it was removed due to abuse > considerations. (Which I could never quite follow (sic), as this merely > facilitated something for everyone that a skilled human keyboard or > joystick-navigator could do manually anyway.) > That feature was quite useful when showing SL to a friend who had just > signed up and wasn't used to its navigation, yet. Having them follow you > as you showed them around much more natural than teleporting everywhere, > even for short distances. (Which might not have been possible back then, > anyway. I don't remember whether this was before or after point-to-point > teleports were introduced.) The follow feature would allow someone to set their AV following another, and then chat-spam the hell out of them. As it stands, it's nearly impossible to keep moving while chatting to someone. Of course, it would be nearly nothing to build a vehicle that would do it, or to modify a client to do 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] How to upload a mesh on v-d rev 20205 ?
Marine Kelley wrote: > Thanks... I wouldn't have guessed that all by myself. lol. > I see on that JIRA entry that I'm not the only one who is confused one > about this issue. I'll give a try to the open source version when > able, it seems promising. You might want to look at what Kirsten has done - his client claims upload capability compatible with the sandboxes as of LL version 2.8.2, but apparently there have been some changes since then, as Henri's post mentioned, so you'll likely need to adjust it a bit, as Kirsten will most likely need to once he gets back from vacation. ___ Policies 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-58 Allow objects to have 99.99% max hollow for default hollow shape.
Lance Corrimal wrote: > under certain conditions the hollow value"snaps back" to 95.0: > * stretching a hollowed prim > * entering a"wrong number" manually, e.g. 99.999 I believe all prim size/parameter restraints are clamped on the server, due to the Megaprims debacle. I think there was some testing of hollows greater than 95%, and some issues were run into with the physics engine. As the physics engine has changed twice, at least, since then I think, it may be possible to increase it to 99%. ___ Policies 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-58 Allow objects to have 99.99% max hollow for default hollow shape.
Zabb65 wrote: > The clamp for primitive parameters was in place long before the > megaprim "debacle", unless you are referring to the one in early 2006, > possibly even earlier than that. >> From what I know, doing this will require that the server be updated > to relax this restriction. That is the one I'm talking about - the one that resulted in a large part of the grid having objects created by Gene Replacement. Somewhere prior to time frame, the server did not clamp the prim dimensions - it was done client side. However, reverse-engineering of the protocol resulted in libsecondlife, which was used to create the most infamous of the "copybots", as well the megaprims labeled as created by Gene Replacement. These prims were made full-permission and handed out quite widely - the 20x20x0.5 cube prim is still one of the mainstays of building. However, due to some of the other prims created, including a 65535x65535x0.01 "infinite prim", which when rezzed often required Linden intervention to remove, Megaprims got the reputation for being laggy and bad for the system. Linden Labs refused to support them, but also did not take action to remove them from the grid, unless they were specifically involved in a griefing action, such as the above prim. For a long time, there were camps both within Linden Labs, and among the users, over whether or not to increase the limits. Claims and counter-claims got pretty heated at times. Finally, Andrew Linden, one of the anti-megaprim camp, proposed a series of checkpoints that if fulfilled, would lead him to supported "Megaprim Liberation Day". The biggest thing was some way that users could remove megaprims from encroaching on their land, even if the center of the megaprim was not on their land. The suggested fix at the time (and I suspect the one finally implemented) involved having parcels as a special object type in the physics engine, and checking for collision. With the implementation of Mesh, though, we have something near full Megaprim liberation - we can create prims up to 64x64x64. There will be times when even larger prims will be useful - and the Gene Replacement megaprims, as well as the second-wave ones created when the servers had clamping turned off by mistake a couple of years ago, are still in inventories and available. But for the most part, the current maximum size is a very nice one, and I've already started using it to reduce my prim count. Now, I just need to figure out why v3 won't run for me, so I can check into the "not involved in collisions" flag, which, but one reading of the announcement, means that prims flagged that way don't count against your parcel prim limit (though I suspect physics-enabled vehicle prim limit was what was meant). ___ Policies 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
Cinder Roxley wrote: > An advantage to scripted AO's as has already been stated is that > bundling the config, AO, and animations into one object that can be worn > and added to specific Outfits is simpiler and conserves Inventory count. > AFAIK, any client-side AO relies on animations being unpacked and in the > user's inventory, sometimes creating additional object links. AFAIK, the > only client-side AO implientation that doesn't do that relied on an > external xml config saved to hard disk and was abused by users plugging > UUID's of animations in which they did not own. It was subsequently > replaced with another implementation. One of my friends has different AOs for different outfits - she goes to great trouble to select animations so that while sitting in a skirt, the hands don't go through the skirt during the animation, and similar issues. I'm not certain just how many AO sets she has, but it's significant. ___ Policies 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] Viewers in the directory are being impersonated already
Robert Martin wrote: > Dusting off an old statement > The 3PVp will be a semi joke until LL decides to put up a compile farm > and begin creating "signed builds". Even not using proxies and other > cloaking all somebody has to do is get the source for a listed viewer > and then hack and recompile. > Oh and They can't wait until you can create plugins for the base viewer. Signed builds won't do any good unless you sign your entire computer over to the Trusted Computing Platform, at which point, be prepared for files to disappear whenever one of your software suppliers decides you shouldn't have that particular file. Say, for example, that competitor's software, that MP3 file you paid for 3 years ago, but a new company bought the rights to it, and decided your previously perpetual license is no longer valid, or that article you're typing up in their cloud/browser based word processing program that explains how they deleted files you had a perfect right to own. Meanwhile, those few allowed to create and distribute content will be bemoaning the pirates who have hacked around the TPM module in their computers, wanting a tax on everyone to cover monies lost to these alleged pirates. Anyone creating *FREE* content, and trying to distribute it to who-ever wants it, will find that they're charged by the byte they type, and someone else will be charging by the byte for their readers to read it. It's kind of amazing how people keep making the same suggestions for how to prevent piracy of some kind, despite said methods being previously discussed and found wanting in similar contexts for 20 or 30 years now. Anyone remember dark burgundy sheets of paper with odd codes on it to prevent copying of games? Just how well did *THOSE* 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] impending lawsuit?
Lance Corrimal wrote: > ... is that guy out of his mind? Yes. See notes below. > You are reading this because you were listed in a lawsuit by Belial > Foulsbane and Scarlett Vielle. Somehow you are a victim of his False > DMCA claims, and his ongoing effort to manipulate LL into killing off > his competition for the "Emerald Speed Rez". There was discussion of this "Emerald Speed Rez" at one of the previous Emerald Office Hours - as the same effect can be implemented with a short series of chats (short enough, quite a few don't bother putting it in as a gesture), it's highly unlikely he's actually doing anything of note. I believe the Emerald Devs said they weren't going to include a feature of that nature to automatically take effect after teleports, as it actually increases the load on the server by a fair amount. > If you would like to join the defendants against this > paperwork-greifer in a counter lawsuit please contact me with your SL > name and anything else at prime...@gmail.com > Do not be scared This is certainly true enough. > 1) Scarlett Vielle claimed that they automaticly had a protected > copyright from the moment they made anything. (The US copyright > office is not aware of every creation in SL, does not issue free > copyrights, and does not issue anything without a proper filing) > 2) There is no copyright registered in the united states: > http://cocatalog.loc.gov/cgi-bin/Pwebrecon.cgi?DB=local&PAGE=First In fact, copyright of a work does take place at creation, and does not require filing with the Library of Congress. However, to be awarded punitive damages in a lawsuit, said filing must take place - but actual damages may still be asked for. Just that actual damages is far harder to prove. IANAL, but this has been hashed out in the broader computer community for some time. > 3) Linden Labs cannot be sued. Yet he filed against them. Linden Labs can in fact be sued. Nothing stops that. Only governments can claim sovereign immunity from courts that are under their authority. Ergo, the US Government must consent to be sued in federal, state or local courts, states may be sued in the Federal Courts, but must consent to being sued in their state courts, or in subsidiary local courts. And so forth. Again, IANAL, if it's really important, contact your own legal advisor. > 4) The judges signature on his legal papers he faxed to LL is blank. This may simply be that these are copies of his copies - the controlling paperwork would be the original copies actually on file with the appropriate court. However, it does sound rather bogus. > 5) He cannot copyright the word "Emerald" for the same reason he > cannot copyright the word "SecondLife" or "Microsoft". Correct - copyright does not apply to single words. Trademarks *can*, however, the Emerald Devs would have a much better claim. It would be rather funny, if he did in fact get a trademark on Emerald, since the Emerald viewer would need to get a new name, which would lead to his "Emerald Speed Rez" not having an Emerald viewer to work in! > He is a paperwork bully filing false DMCA claims as you know. At least he learned it from the Big Guys, like the MPAA and the RIAA. This is why the DMCA is so bogus. > If you have any ideas to stop this madman, do please share them. Lets > create a group and fight him off shall we? I'd say just ignore it - the bogosity is so strong, it'll collapse into a black bogosphere from which no sanity can escape. ___ Policies 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] Severe water flicker in recent development build
Tateru Nino wrote: > Another aspect to the numbers there is that (quite often) users will > crank up visual features until frame-rates become just short of > intolerable or unusable. That tends to make the results trend downwards. > They *could* be higher for the same hardware, but many of us will crank > up our quality and distance settings until the viewer is on the edge of > shuddering -- and increase our crash-rates in the process. One possibility is if the Lindens set up an island, with an agent limit of *1*. Region forces AV to face a particular direction. Avatar drops in, and waits 5 mins. During that time, the system records frame rates, CPU, and vid card. AV reports graphics settings (unless that can be pulled from the client automatically). AVs do it with client set to the absolute defaults for low, mid, high, and ultra, turning off anistropic filtering and antialiasing. A few weeks of that, and we should have some good data - would have to be the stock client, too, though - but could record stock 1.23 and stock 2.1, and get good data on whether the changes to the rendering engine helped. ___ Policies 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] 2.0 Absolute Dealbreaker - script count feature request
Zi Ree wrote: >> Do you want an incomplete yet helpful solution doable now, to be >> improved/completed later on, >> or do you prefer to wait another 6-12+ month with nothing at all? > Since improvised and incomplete solutions tend to become the final one after a > while, and since I have no issues with script memory whatsoever, I rather wait > for a fully functional, complete implementation than seeing a temporary and > useless "solution" in place. I gotta agree here. Sculpties were a quick hack, and we were supposed to get support for in-world editing, but they wanted to get it on out there so people could get started using it - and guess what - 3 years later, no in-world sculptie editing support yet. Just a bunch of hacked-together prim tools. Windlight was supposed to be this awesome way to be able to share wonderful and amazing environmental settings, allowing the creation of regions with alien atmospheres and odd psychological effects. Oh, well, let's hope the Lindens decide to adopt the Lightshare system already implemented by the OpenSIM people. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] O.O Display name code DROP!
WolfPup Lowenhar wrote: > Well folks my night is going to be interesting as now I have to hard > merge my logging code to the new code as there are changes to the way > logs are EVEN saved .llsd instead of .txt which is going to make things > interesting for me as now I have to change my history look up code for > the new file extension and maybe even the name formatting itself! Is that the crash & console logs, or the chat logs 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] O.O Display name code DROP!
WolfPup Lowenhar wrote: > Actualy the file extension change is only to chat and IM logs. And I > have already found a bug in the code! > https://jira.secondlife.com/browse/VWR-23437 > the above jira is the bug and it is not being cause be my file name > modification as the mod is working fine for group IM’s. Ok - so instead of just opening wordpad/nano/vi/emacs/religious editor of choice, and reading with eyeballs mark I, we're going to have to have a specialized decoder/converter, to read something that as far as I can tell, is going to take up a hell of a lot more storage for ... what purpose? Is there actually a *reason* for this change, or is it just to screw around in the code to do provide an opportunity for new bugs, such as the one you found already? Goddess knows, all of the bugs in the current code are *completely* eradicated. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] O.O Display name code DROP!
Marc Adored wrote: > Download a stylesheet? The file would contain a link directly to the > stylesheet and would be automatically loaded. Also I'm not sure about > your operating system but I'm pretty sure the file extension already > opens in your default browser and once the stylesheet is specified it > will look just like a plain text log file just loaded in your browser > through the same process and opening a text file. The only fear here > is change and the unknown. It's not going to be any harder to read the > logs just different. Sorry like Ricky said its more future proof and > thats all there is too it the only mistake was not setting this up > earlier so the change didn't frighten so many people Let's see... Future Proof. Program to read and process a text file - anywhere from a few hundred bytes, to a small OS-wannabe like emacs. Program to process LLSD and display it - several hundred K minimum, oh, and *REQUIRED* network connection live so the referenced DTD can be retrieved - more like a program that is ALREADY being considered an OS-replacement, such as Internet Explorer, Mozilla, Safari, or Chrome, each several dozen megabytes. Ok, so let's look at a project that's *GOT* a nice long history already (some 30+ years) and is *VERY* interested in future-proofing. Minor project, really, called Project Gutenberg. Here's what *they* have to say on the subject: http://www.gutenberg.org/wiki/Gutenberg:General_FAQ#G.17._Why_is_Project_Gutenberg_so_set_on_using_Plain_Vanilla_ASCII.3F When you really, really, *REALLY* want it to be readable - ASCII plaintext is the way to go. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Fermi Viewer
Marc Adored wrote: > Yes that could be awesome like The Fermi Builders Mod for Phoenix or Imprudence? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
