Re: [opensource-dev] Linux build without the pausing behaviour
Il giorno 28/mar/2011, alle ore 16:41, Mike Chase mike.ch...@alternatemetaverse.com ha scritto: Is there a Linux build of V2 of any version that doesnt exhibit the annoying multi-second pauses that freeze the UI? I find myself without any useable V2 viewer at present. I've tried 2.5.2 and 2.6.3 and both still have this issue. How in the world did this every get past QA? It really renders the viewer unusable. I've been using Imprudence the last few days which is nice but a huge shift in UI and I've actually gotten both used to and productive with the V2 paradigm. Can you explain better the kind of pause? I don't notice sort of... -- Sent by iPhone ___ Policies 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] Log file names (was: Request for feedback - Preferences Cleanup)
Maybe is the right time to implement in LSL sort of llKey2Name, save logs and other using the UUID and cache the display name (at least 1 change per week us allowed, caching username and display name should solve ??? Problem, falling back on cached if trouble) -- Sent by iPhone Il giorno 09/nov/2010, alle ore 16:39, Kent Quirk (Q Linden) q...@lindenlab.com ha scritto: I think the filename needs to be based on the unique account name, with any periods (.) replaced by underscore (_). The display names can change weekly, and as you note it would be much more difficult to track based on display name. Q On Nov 8, 2010, at 11:45 AM, Oz Linden (Scott Lawrence) wrote: On 2010-11-08 11:10, Sarah (Esbee) Kuehnle wrote: Thanks again for all your feedback. I've made some updates to the design deck (see attached). I'm going to create subtasks underneath STORM-31https://jira.secondlife.com/browse/STORM-31for the new preferences and get these updates rolling with the team! :) Cheers, Esbee PS - Please feel free to keep feedback coming On the Privacy tab, you ask Is this a timestamp in the log or in the filename?... I think that once we've integrated STORM-102 (a final test build for that is running now), we'll actually have two checkboxes there. A new test build for that is available now (fresh off the server) at [1]. - Add timestamp - Add datestamp to log file name The first one controls whether or not lines in the log file have timestamps on them, and the second appends a datestamp: For person-to-person chat, the datestamp is -MM (year and month) For local chat, the datestamp is -MM-DD (year month and day) One issue on STORM-102 that probably needs discussing... the present person-to-person chat log file name is First Last[-datestamp].txt where First and Last are the real account names. If a person has a Display Name set, that name is not used when constructing the file name: instead the real first and last names for the account are used for the log file name. The Display name does appear (followed by the userid first.last in parens) in the log text content. This seems potentially confusing to me, especially if the only name I ever use for someone is the Display Name. It seems to me that either: 1. the Display Name should be used (if I remember talking to Joe Somebody, that's the log file name I'd be most likely to look for), which would mean that each DN value would produce a separate log even if I had conversations with the same user with different DNs, 2. or the userid (first.last) should always be used for the log file name. [1] http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-storm-102/rev/214097/index.html ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies 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] USER STORY for not so far future
Not understand sorry... This isn't a LL problem. You can already use iMouse to use your iPad, iPhone or iPod as a multi-touch trackpad and via control panel you can bind multi-touch gesture to keyboard shortcut... -- Sent by iPhone Il giorno 21/ott/2010, alle ore 15:52, Ponzu lee.po...@gmail.com ha scritto: As a user, I want to use a multi-touch device (iPad, Android, etc) to control Second Life. The simple technical issue is getting the tablet to talk to the viewer. Of course, the hard issue is creating the insanely great multi-touch interface. For example, touching tablet could re-aim camera. making little walking motions with your fingers could make you walk. two-finger movement could enter mouselook and move. I thought of this because I saw a Mac paint program (on the big screen) where the controls such as palette, color, brush, are on an iPad. Looked really cool. Ponzu ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies 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
I think Carlo mean something else... In place to create another viewer join an existing team and contribute code for building and SIM managements -- Sent by iPhone Il giorno 18/ott/2010, alle ore 03:02, Arthur Fermi arthur_fe...@fermisandbox.org ha scritto: Well LLs base is a decent start point. We have looked at the other viewers and think we have some good ideas. I find that most of the other viewers are not focused on building or sim management. -Original Message- From: Carlo Wood [mailto:ca...@alinoe.com] Sent: Sunday, October 17, 2010 7:59 PM To: Arthur Fermi Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Fermi Viewer Imho, it is not a good idea to start yet-another-viewer. The number of open source coders are limited, they should be working on one viewer - not twenty. We already have more than 10 different viewers based on LL's code. How is it possible we need another? On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: Fermi Sandbox is looking to put together a team to develop the Fermi Viewer. Please send inquires to arthur_fe...@fermisandbox.org or in world. Mission The Fermi Viewer projects goals are to create the best viewers for Second Life that works with all OS Grids. The Fermi Viewer will be open for all to review and look at, and all in house code will be generated and provided to the community. Project Overview The Fermi Viewer project will generate 2 separate viewers, one will be a full featured viewer along the lines of emerald, this will be a general viewer with a focus on building and sim management. The second view will be as light weight and fast as can be made, it will have building and sim management as its only focus with as many non-essential items moved out. Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. A Version 2 viewer will come later in the project when time and resources are available to dedicate to a redesign of the interface. Open Source All work coming from the Fermi Viewer project will be returned to the community, this is a 100% open source project. Code Review All code other than the Linden Labs provide source code will be reviewed by a peer review committee to ensure that it complies with privacy standards. Once code is has been reviewed it will not need further review unless it has changed. Viewer Privacy Policy The Fermi Viewer will contain no code that will gather any information other than is required for interoperation with the grid it is connected to. No information will be stored off the client computer, no anonymous tracking data will be collected. Any violation of this policy will result in the instant removal from the project. Arthur Fermi ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood ca...@alinoe.com ___ Policies 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] Problem with displaying Arabic menu text in SL client
U+200F Reverse direction Notes: - Microsoft have a bug, this char don't work sometimes (msoffice 2011 for Mac affected too) - parser work left2right put the char on left side of each entry in all XML files -- Sent by iPhone Il giorno 05/ott/2010, alle ore 12:19, Boroondas Gupte slli...@boroon.dasgupta.ch ha scritto: Hi Izze On 10/05/2010 10:31 AM, izze euler wrote: I have been looking to get Arabic text working on the SL client, but so far with no luck. I am only looking to display Arabic for menus and text on the client. What I have found is that the Arabic text is being displayed left-to-right, rather than right-to-left. I have added a language to SL, so I have the Arabic translations in UTF8 format in XML files, as with the other languages such as Chinese. I used Notepad++ to copy the translations to the XML files, and they are displayed right-to-left correctly. However, when loaded into the SL client, the text is being reversed so that it reads left-to-right. Unicode has special control characters to switch between left-to-right and right-to-left in mixed language documents. Additionally, I think some programs switch direction automatically when they encounter characters they know belong to a right-to-left written script. So if the translations are displayed correctly, Notepad++ is capable of at least one of those, probably the former (interpreting the control characters). I have tried reversing the text, so that it displays left-to-right in the XML file, in the hope that it will then be reversed and display right-to-left in the client. I cannot read or write Arabic, but I have been told that the characters are displayed disjoint, most likely due to the wrong ordering of the characters breaking associations between them in the XML file. Arabic script relies heavily on ligatures. Ligatures are glyphs that represent multiple characters. Other than the ligatures used for latin script (fl, fi ffi, etc.) which merely make the rendered text look nicer, ligatures in scripts like Arabic, Devanagari (a script used for Sanskrit, Hindi and other Indian languages), Bengali (another Indian language and script) and probably many others look very distinct from the characters they represent http://en.wikipedia.org/wiki/Devanagari#Conjunctsand aren't optional. (Typographs and typesetters might argue that Latin ligatures aren't optional either. But omitting ligatures in these other scripts will not only look typographically wrong but, well, just wrong. (I don't know whether it'd be considered an orthographic error in the respective cultures.)) Has anyone looked into this problem, or have any ideas to what I could try? We've discussed the problem this summer, see here: http://wiki.secondlife.com/wiki/Open_Source_Meeting/2010-07-13 The issue is that while the SL client has support for displaying Unicode characters, it lacks the ability to use Unicode's script direction markers and the feature of converting specific character sequences to the matching ligatures. For pre-set strings (e.g. your UI translation), the first problem can be worked around by writing stuff backwards, as you already tried. To work around the second problem, you'd have to directly write the ligature characters (so you have only one character per wanted glyph). I don't know Unicode well enough to tell whether characters for all possible glyphs exist. It might well be that some ligatures always have to be created on-the-fly from a sequence of single-character characters. Of course, both of these workarounds aren't feasible for chat and other run-time user input, because users will be used to write sequences of single characters in reading order rather than ligature characters in left-to-right order. Also, entering these ligature characters (if they even exist) might be complicated and time consuming, because their usual keyboard layout might not give direct access to them. Does anyone have this working? Adding these features to Linden Lab's homebrewn text rendering system would be a major effort that probably none of us is capable of. Alissa Sabre once adapted the Viewer to use Pango for text rendering. ( See http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer) Pango can handle bidirectional text and ligatures just fine, so this solved the problems. However, these changes haven't been integrated in the official viewer and her patches are now out of date. For chat, using Dzonatas' Icesphere (allows for IM and chat in separate GTK+ windows, thus also using Pango) has been recommended to some Arabic users, and that seems to work alright. Both, the sender and receiver, will have to use it to be able to chat in Arabic script. Cheers, Boroondas ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
Sorry for top quoting... There Are already a lot if monoscript based on a single script for whole item, but lazyness of creator is high and is more easy say is a LL fault the lag, But this is about OT here. ;) -- Sent by iPhone Il giorno 28/set/2010, alle ore 11:27, Marine Kelley marinekel...@gmail.com ha scritto: On 28 September 2010 11:20, Ann Otoole missannoto...@yahoo.com wrote: this isn't the place for that and LL needs to weigh in on things like this. It isn't the only one and one person LL openly promotes also sells over scripted shoes. If we are going after one we have to go after the ones LL promotes as well. Better for LL to step up first. I think I know who you are talking about, Ann. I remember having sent a very detailed notecard with script time, snapshots and explanations, proving that the lag came from their shoes and that they really should do something to lighten the load on the sims. One resizer and texturer script per prim on a 250-prim shoe (and you got two feet), some of the prims never even showing because you have to actually buy an option to see them, is unacceptable. No response from them whatsoever, and no change in their products. My message totally fell in deaf ears. So I gave up on them and went to the competition, who does listen to their customers. And I made a point in telling everyone I know to do the same. End of story. I just wish everyone was aware of how much resources they take, and that means having the right tools for it. The upcoming script limits project were aimed at doing that, but I guess it is suspended for the moment. ___ Policies 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] item autodecline on crash at login
Is already working in this way, if i crash without accept neither decline something at next login i found them in my inventory (and if i open past notifications and click decline item is deleted) -- Sent by iPhone Il giorno 27/set/2010, alle ore 12:51, Erin Mallory angel_of_crim...@hotmail.com ha scritto: As a user, I would like my inventory offers to be auto-accepted instead of auto-declined in the event of a crash on login. Currently if I crash on login with viewer two, I can kiss anything that was given to me while offline goodbye.. ___ Policies 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] J2C fast decoder
Would it be a huge problem, for example, to transfer HTTP textures as TGA or PNG and use one of the rather well-optimized decoder TGA have lossless RLE compression anyway transport is format-indipendent, you can send on HTTP voice too (like skype) or anything you want. To increase bandwith and rendering performance we need a client side routine (viewer must ask to asset server only vievable textures) and servers should send the right order from closer object to farest. Scaling/resizing should be done by viewer after render engine calc the size of the surface where texture is. Receive a already undersampled image mean each movement of avatar/camera a re-trasmission of same image each time bigger, in medium-long time terms is better receive the fullres texture and let the viewer resize and render using discarding to the right level based on local viewer side settings (resolution, monitor DPI, CPU power) But as always we are talking with only our hardware in our hands,all about this can be discussed better if somewhere are avaiable some statistic data about residents' hardware. If LL (better if others viewers team too) can collect anonymous data all decision about decoding, pipeline, shadow or shader and all other can taken more easy, a approx list of usefull data can be (if a statistical collector is or will enabled) to probe each XX minutes: - CPU mips/bogomips - CPU calc cores (not physical, just grand total) - avarage load of cores - cpu load of viewer executable - number and avarage load of plugins (voice included) - Amount of RAM (how much free) - Amount of swap (how much used) - Brand and model of graphic card - Graphic settings - number of agent in visible area - avarage of rendering cost of agents in visible area - FPS collected only when viewer isn't in icon - inboundoutbound bandwith - bandwith used by viewer - bandwith used by plugins, voice too - % of packetloss - uptime of connection to be sure no double data collected and no personal data used to collect them i suggest to use serial number of CPU (linux /proc/cpuinfo, mac same, windows dunno how) or sort of unique UUID based on hardware configuration (if somebody increase ram or CPU a new ID should be used) -- Sent by iPhone Il giorno 13/set/2010, alle ore 07:40, Tateru Nino tat...@taterunino.net ha scritto: If we're using HTTP textures, is there actually any need for the JPEG 2000 format? Since the transfer time of individual textures is vastly reduced (from the first byte to the last byte) the intermediate quality levels supported by jpg2k would seem to be redundant. Indeed, you could argue that transferring the textures in jpg2k format imposes a now-redundant workload on the texture-pipeline, and that providing HTTP textures in a simpler format that is more tractable to high-speed, low-cost decoding would save a whole lot of problems. Would it be a huge problem, for example, to transfer HTTP textures as TGA or PNG and use one of the rather well-optimized decoder libraries for those instead? It seems to me that it would be more efficient both on the network and on the system - though at the expense of conversion of all the textures at the store. Just thinking out loud. On 13/09/2010 1:58 PM, Sheet Spotter wrote: Some comments on SNOW-361 (Upgrade to OpenJPEG v2) suggested that changing to version 2 of OpenJPEG might improve performance, while other comments suggested it might not support progressive decoding. http://jira.secondlife.com/browse/SNOW-361 Is an upgrade to OpenJPEG v2 under active development? Sheet Spotter -- *From:* opensource-dev-boun...@lists.secondlife.com [ mailto:opensource-dev-boun...@lists.secondlife.comopensource-dev-boun...@lists.secondlife.comopensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Philippe (Merov) Bossut *Sent:* September 9, 2010 10:35 PM *To:* Nicky Fullton *Cc:* opensource-dev@lists.secondlife.com *Subject:* Re: [opensource-dev] J2C fast decoder Hi Nicky, As it happens, I've been working on instrumenting the code to add metric gathering for image decompression as part of the Snowstorm sprint. You may want to use my branch ( https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and create a baseline for openjpeg then run a test for Jasper. You'll have to sort out the failing cases certainly and just throw them so we compare what gets truly decompressed (though, clearly, working in all cases is pretty critical if we look at Jasper as an alternative). Here's what I got comparing KDU and OpenJpeg: Label Metric KDU(B) OJ2C(T) Diff(T-B) Percentage(100*T/B) ImageCompressionTester-1 TotalBytesInDecompression50486435003370-4527399.1 TotalBytesOutDecompression 40415336 465928966177560115.29 TimeTimeDecompression3.74 17.04 13.3 455.39 ImageCompressionTester-2 TotalBytesInDecompression
Re: [opensource-dev] before opena Jira, APR
Il giorno 01/set/2010, alle ore 15:36, Tateru Nino tateru.n...@gmail.com ha scritto: On 1/09/2010 11:24 PM, Oz Linden (Scott Lawrence) wrote: On 2010-09-01 7:12, Tateru Nino wrote: Hmm. It might not be an actual leak per-se... I've noticed in busy areas that the viewer will often hit a **lot** of parallel HTTP texture fetches. That's not very good http behavior, but I doubt that we can get it changed until the servers are properly supporting persistent connections. Indeed. It's not exactly best-practice. Creating a priority list of textures and a configurable concurrent requests cap (default: 16?) would probably be the way to go. No, this is a client side problem in file handling, not an HTTP problem... You can parallelize billions of download, the fail (you can see in my logs) is in local filesystem file handling. Maybe there are more locks than suitable, the file/decoder handler must detect the limits and adapt the pipes. As seen in logs i suppose when a cached texture fail (timeout, bad crc for packet loss) the automatic clean try a clear_while_run wasting all openable files. If a http timeout or corrupted cached texture found the SINGLE download or the single fileust be deleted or dropped, not whole cache. If a running viewer have 600 opened tectures and got a timeout now re-open all to clean them, exceding the default 1024 limit I've noticed some grey textures too, i begin to think about the old (patched) bug about decoding fail without retry, the pipe hold the channell opened wasting resources -- Sent by iPhone ___ Policies 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] before opena Jira, APR
Il giorno 01/set/2010, alle ore 16:47, Oz Linden (Scott Lawrence) o...@lindenlab.com ha scritto: Correct, but that's also something we should improve anyway - doing a better job of prioritizing which textures are loaded and in what order could make things _seem_ faster, even if the total time was the same. Doing both that and the connection handling together would be a big win (file under Faster). May be usefull do something like old windlight... The area visible by avatar (cam or mouselook) should be splitted in slices and textures should be downloaded starting from closest slice 16 textures each 512Kbps of inbound network speed (client setup). A system for fallback on single texture if corrupted or timed out will be great... -- Sent by iPhone ___ Policies 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] Anti-Aliasing
Enabling FBO broke hires snapshot -- Sent by iPhone Il giorno 27/ago/2010, alle ore 12:36, Aimee Linden ai...@lindenlab.com ha scritto: On 27 Aug 2010, at 02:06, Trilo Byte wrote: Is it just me, or is anti-aliasing broken in the last couple builds? Do you arms and legs look lumpier than normal? If so then it's you ;) Quite a large amount of rendering work dropped in one of the latest updates. You're on a Mac right? It seems to be broken on my Mac also :( To get AA working on my Linux box I had to turn _on_ Framebuffer Objects in the DevelopRendering menu (same as setting the RenderUseFBO debug option to True) but that just freezes rendering on my Mac. So yup, it's not you, looks like we broke it at the moment. Aimee. ___ Policies 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] Removal of the MultipleAttachments debug settings ?
Maybe i not understand well, now if i want i can wear a collar from a creator on a shirt made by somebody else, if viewer lock me on a fixed wearing strutture imho is a pain IF a user want create fast combination of clothes and attachments without waste time clicking one per time each item can use outfits folders, without overload viewers with code than limit residents creativity in outfit composing. If i want wear me undie ON my jeans i must be free to do it :) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 14:48, Aleric Inglewood aleric.inglew...@gmail.com ha scritto: I fail to see how your example could undermine the bits-proposal. For a start, the bits *only* add possibilities (254 per object!). Currently the ONLY existing behavior is as if my bits are already in place, but set to when you 'wear' something, and to when you 'add' something. Adding the bits will just open up a whole scala of control over how your attachments replace other attachments (and clothing?). On Fri, Aug 27, 2010 at 2:20 PM, Francesco Rabbi syt...@gmail.com wrote: You lost quite all good taste of this feature Ppl should be free to add everything in funny/weird way, and creators cannot be limited matching which bit another creator use... The possibilities only increase, as I just explained. You can still add anything in every way possible. I specifically said that each user should be able to change the bits of objects even if those objects are no modify. You can always just set all bits to 0, then you can wear anything and everything at the same time. The solution is resident side: outfits folders, may be interesting mark boxes or vendors to create automatically outfit folders maybe Lets look at your example. I added comment on the right. Example: -outfit naked Hair --- Head attachament SHAPE NO bits (or all 0) Skin NO bits (or all 0) Genitalia --- Pelvis attachment -outfit sport All above but genitalia Jeans--- covers genitalia Shirt Shirt collar --- Chest attachment Necklace --- Chest attachment Shoes --- Feet attachments Ok, so a user could set the same bit on the Genitalia object as on the pants. Then they would become mutual exclusive, which is what you want apparently (and which makes sense since pants cover genitalia. Pants that don't should just NOT set that bit). Assuming that it looks good if you wear the necklace and the shirt collar at the same time: put them in different classes so they won't replace each other when worn. replace outfit should revert from to other, without got creators crazy replace outfit is an entirely different thing than wear attachment/clothing. The usual meaning is that EVERYTHING is removed and then things in the folder are added. If a vendor or box can be enganced with outfit (over buy content and buy copy) I think daily outfit management by the users is more important than the urge to control how and what the users wear by vendors. If things bought by users don't work out of the box, then they will have to manually remove a few things, just like now. But at least they'll be able to automate that and not have to worry about having the add and remove attachments/clothing EVERY time, when wearing stuff from inventory. Any change to wearing a new outfit that is in a just-bought box is orthogonal to my proposal. ( all this marked with a giant IMHO) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 14:11, Aleric Inglewood aleric.inglew...@gmail.com ha scritto: The following has been proposed before: * Add new bits to each object (all existing objects should act as if all bits are set). * Give the bits a default meaning (read: human readable word, which can be different per attachment point), but allow each user to override those descriptions locally. * Allow users to change the bits for each of their objects, even no-modify ones. * If a user 'wears' (or adds, which becomes redundant) a new attachment, then remove those attachments that have one or more of the same bits set. In other words, at any time one can only have one object attached at a given position with any given bit set. Suppose you think that 8 bits are enough, then the following holds: * = old 'wear' behavior: replaces everything else. * = 'add' behavior: is added, replaces nothing. * 0001 = (for example): assign default meaning 'jacket' for chest attachments (jacket collars and hoodies). * 0010 = (for example): assign default meaning 'shirt' for chest attachments (shirt collars). * 0100 = (for example): assign default meaning 'necklace' for chest attachments. and so on. This allows users to make groups of attachments that are mutually exclusive, but having up till 8 classes that can be worn at the same time on the same attachment point
[opensource-dev] Kdu
I see in latest 2.1.2 builds kdu libs, but in about second life i see openjpeg is used, is a bug or a feature? -- Sent by iPhone ___ Policies 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] Removal of the MultipleAttachments debug settings ?
I think may be more usefull add all you asked in the jira opened about multiattachments double worn :) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 00:50, Brian McGroarty s...@lindenlab.com ha scritto: There were some fixes in 1.42 that dealt with a related MultipleAttachments issue, and should have addressed the more general case. If anyone encounters this while logging in with an account where you've crashed or logged out today or later, would you please follow up with me in direct email? If you include the time and location at which you logged in, as well as what the item names were, and which attachment point they were on, it will help tremendously. Also, let me know if you flipped between 2.x and 1.x viewers in those sessions - anything out of the ordinary could be relevant. On Thu, Aug 26, 2010 at 2:37 PM, Marine Kelley marinekel...@gmail.comwrote: I'd like to chime in and say that this happens to me often as well. Attachments are worn twice on relog, approx. once a day. Since the attachments I'm wearing usually say things with llOwnerSay and I see them say their messages twice, I do know this is not only a viewer-side problem. I have never observed this with 1.23, only with 2.1. Soft is aware of this issue, and confirmed seeing the double-rezzing in the logs of my sim at the time I indicated. On 26 August 2010 22:30, Altair Sythos syt...@gmail.com wrote: On Thu, 26 Aug 2010 16:24:08 -0400 Nyx Linden n...@lindenlab.com wrote: Let me know if this clarifies things. yeah i'm on Second Life 2.1.2 (208569) Aug 26 2010 05:22:24 (Second Life Development) now, it work as you said, just noticed something weird and tryiong to reproduce: if i crash when relog all attachments are weared double time, like the dirty logoff don't detach items. I dunno how logoff/login work, i *SUPPOSE* debug warn during logoff acvatar destructor take current outfit and store somewhere on asset, during login last saved current outfit is worn. maybe is better if saved current outfit replace what worn during login, so if crashed nothing boudle is worn... somebody who know better and deeper the code can hint me 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 -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler ___ Policies 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] Temporary textures
Why using beta grid you can test it for free without overload the viewer with code used by few ones i suppose... -- Sent by iPhone Il giorno 25/ago/2010, alle ore 19:47, Laurent Rathle laurent.bec...@madonie.org ha scritto: Hello, Is it possible to have temporary textures available on Snowglobe or on Second Life viewer ? It seems to be a quite requested feature since it allows people to test easily their creation without spending too much money. If not, why ? 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 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
