EnCore Mayne

it doesn't seem to be that bigga deal with our overwhelmed shipmates working for the man. they DID trepidatiously announce that v1.0 has been "released". no notice about requiring a new application in that post but i thought i'd seen on one of my random browses that a new application was not necessary. one might want to prompt someone somewhere somehow for the official word tho.

i asked FS support about my own certificate warnings: found these warnings in the Firestorm.log WARNING #SECAPI# newview/llsecapi.cpp(186) LLCertException::LLCertException : Certificate Error: CertExpired WARNING #SECAPI# newview/llsecapi.cpp(186) LLCertException::LLCertException : Certificate Error: CertExpired WARNING #SECAPI# newview/llsecapi.cpp(186) LLCertException::LLCertException : Certificate Error: CertExpired WARNING #SECAPI# newview/llsecapi.cpp(186) LLCertException::LLCertException : Certificate Error: CertExpired WARNING #SECAPI# newview/llsecapi.cpp(186) LLCertException::LLCertException : Certificate Error: CertExpired any cause for concern? the FS dev's answer was: "Nope. And it would be LL's job anyway." i'm one version back from their newest so maybe they're caught up. who knows. the log indicated the "Certificate store" CA.pem wasn't in my user settings and since it wasn't isn't there it reverted to the FS root's ca-bundle.crt where the warnings above came back. INFO from llsechandler_basic.cpp(637) says: loaded 129 good certificates (rejected 5) from C:\Program Files\Firestorm-Releasex64\ca-bundle.crt. that's a pretty good average : ) everything runs fine (as far as i know) without having those 5 rejects.

probably shouldn't be looking in on those log files anywho. seems like all the WARNINGs don't amount to anything but embarrassing the devs. felt their download without my explicit approval was a little hackish so i removed it. one less log file to grok.

thanks Jerom, i just recently noticed where the download was poking about the system. and, going further i noticed in the user_settings folder there's an SLVersionChecker.log file. when i looked inside i found these: DEBUG: update_manager.py(508) : onNo64Windows: Windows version 10.0.19045 should not be okay DEBUG: update_manager.py(530) : isUnsupported: power shell graphics card info: 'NVIDIA GeForce RTX 3060\n' so far as i know my OS is functioning okay (aside from a few anomolies) and the graphics card seems to be working. from these log responses should i begin to worry?

is this true? has it been downloaded? even when i choose skip or not now?

well... there's hardly any time to breath. just got notice in the latest use of the official viewer, which i hardly ever use, that 7.1.1.7039128750 is ready for installing. that didn't take long. 3 days? i never looked at the "Resolved Issues" list from the release notes page for 7.0.1.689.... i count 490! that there's a ton of bug fixes. and who ever said the Linden's aren't working hard enough?

nice theory but i believe their build numbers have something to do with automated numbering generated by GitHub (a hornet's nest of confusion).

well, you don't have to tell me things are easy to find in SL's documentary madness: found this here from the ReleaseNotes subdomain https://releasenotes.secondlife.com ================= Version Numbering Systems Second Life uses two slightly different version numbering systems for viewer and server Second Life Viewer Versioning The Second Life Viewer uses a four-place version convention that is common to the software industry. The four places in the w.x.y.z version string correspond to Major.Minor.Patch.Revision, and combine to indicate the nature of each release. Note: Individual Second Life viewer versions may be formatted as either “w.x.y.z” or “w.x.y (z)”. In ‘Help > About Second Life’, as well as in the release notes, we have standardized on the “w.x.y.z” format, but either version format is acceptable. W.x.y.z - Major Revision The first place, or Major version, in each version number effectively represents the “generation” of Second Life. Changes in the Major revision are reserved for comprehensive changes in the way Second Life looks and/or functions. This is usually incremented only for changes that introduce significant incompatibilities (if you are not up to date, something important in Second Life will not work correctly for you). w.X.y.z - Minor Revision The second place is incremented when the version has added significant but essentially compatible new features and enhancements, or releases in which very important bugs are fixed. w.x.Y.z - Patch Revision The third place, or Patch version, is incremented for releases whose changes are relatively minor. w.x.y.Z - Build The final place in the viewer version contains a Build number unique to each release (produced by our internal build system). Updates (rebuilds) to a particular viewer project will usually differ only in this last number. that seems to suggest this new version's a WOWZA version. sheesh, who'da thunk.

can anyone explain this: Second Life Release 7.0.1.6894459864 i mean really. what is with the extraordinary magnitude of this version count? i've never been knowledgeable about anyone's versioning methods or standards (if their are any). i'd appreciate any knowledgeable people's coles notes. nonetheless, there has to be some sane reasoning associating such a voluminous digit to what i believe should be a valuable designation of the interim processes. like, i know "major" updates increments one of the dot's number. first or second, im not sure. but the closer you get to the initial number the greater significance the upgrade had. so, 7.0.1's next major upgrade might be 7.0.2, or 7.1.0. i should read more about this, or i'm can learn. which gets back to the initial reason. how did this version ...6894459864 get so high? what does it all mean?

seeing lots of first tier LaraX designs now @ Cosmopolitan

the current way of SL: one vendor purchase delivers one folder (containing box(s) or other object types) vendor inventories (or any object) do not allow for organized folder contents outfits may consist of multiple items good designers design for multiple bodies providing for a choice of scripted body unpacking HUD is the current solution alleviating the users' problem of sorting/deleting all bodies and all outfits with whatever naming convention the individual designers may come up with. having a wearable HUD sure is better than the old way of finding land to unbox. next phase will surely be to detach and delete the vendor HUD (and folder) on choice so the user doesn't have to find it and manually remove it from their inventory after unpacking's been done. at present, that's impossible, but i've seen mention of this function in the JIRA.

i had a strange observation. when i looked up LaraX from the marketplace a day or more after she came out, the items that came up were mostly from second or even third rate designers. whoever it is that's currently rigging for LaraX, they may not be using Onyx's weighting files.

methinks Steeltoe Rigney fills the bill.

i've been looking around to unwravel the mystery surrounding the personnel on whose shoulders rest the continued functionality of our little world. even tho it contains Ebbe as the head it still seems to have a good number of organizational positions hitherto unknown. as far as i've researched, the phenom of SL's code was admired and revered world wide back in the day. seems passing bits and bytes down the wires of the internet is an awe inspiring thing to those involved in the struggle of developing asyncronous data flow. let's just say my admiration for their skills for keeping the boat afloat while adding more sails to the rigging has been quite substantially improved. even tho i can hardly understand most of their chatter when they do supply it, i've noticed a few more explanatory notes from the GitHub posts. it's always a bonus to know what's going on under the hood.

exactly the root of my concerns Kathrine. i'm subscribed to their updates and don't see a lot of diversity or significant amount of inputs. i suppose i'm looking for more "chatter". it's always nice when one developer comments on some particular process instead of just putting out the code for some nonsensical reason.

as a curiosity, does anyone know just how many actual active developers are hacking away at the platform (viewer, server, website) on a daily basis? of course, as i see it (total speculation) some unknown unnamed individual within the corporate structure of LL has the ultimate responsibility for associating teams, tasks, projects, etc to present and future plans. this individual would most likely work for and along with corporate administrators who may or may not have the slightest inkling about code in general or SL's humongous spagetti code nightmare specifically. as i've read, the scene at the Lab was, and may still be, one that could be construed as rather laid back. there were even historical reports of individual coders "choosing" their own projects. shock, aghast! just making note of the working environment here. it may give some relevant perspective as to how rigourous ongoing demand-based tasks may or may not be achieved in a timely basis. (if anyone looked at the JIRA one might get a hint as to the "timeliness" some reports are addressed.) not to be overly critical of the Lab's process but it is after all all quite subdued in comparison with their Silicon Valley compatriots. nonetheless, it's all about the code.... whether the "director's" pool of coders works from home or is indentured to perform within the confines of a geocentric culture is another matter. do our fearless leaders come bounding into the Battery Street building clutching their brown paper lunchbags eager to craft logical complexities of unheard and unknown solutions to longstanding conundrums to be lauded by their peers and corporate masters or are their days spent alone staring at a daunting screen of gibberish until someone notices they're not awake? is there a vibrant and energized corporate culture, or are the cubicles populated with hangers on and dead weight waiting to be fired or something better to come in? are the remote workers a "part of the team" or are they like temporary contractors begrudgingly happy to do some work never knowing the comaraderie of sharing space with your common thinking cohorts. i hope i've left you with some things to think about. i know how my opinions have elicited controversial responses in the past and i'm okay with that, you've set me apart from the rest of you. but, in this instance, can we not think about how our common world is being bolstered essentially by nameless faceless individuals who have no bearing on how we live our lives? i ask you, is there not a common goal to improve it, preserve it, and know its foundations? what ever happened to SLCon?

Philip Rosedale

that's funny, it's working for me now too. gremlins working in the dark without telling me?

unfortunately the undo option is disabled using that mode. https://jira.firestormviewer.org/browse/FIRE-33219

we are all very very smart....

hmmm. it's been a few weeks since Patch Linden announced the dev kits were going out. and, distilling the general consensus of opinions on the license agreement it seemed their weighty legal terms were a bit skewed towards draconian. could that be a reason for the lack of input for this post? i must admit, were you to wade through the disappointing comments promoting the sdk one might come away with the feeling the Lab's NUX project administration is just another abysmal failure to enhance the platform's future viability. i know from eventually (and that has due emphasis i might relate later) getting the kit i'm far from pleased with what was included. hence the question. has no one any comments on their package?

works like a charm Wulfie! m'excuse, madame, your wet nose shoulda given it away.

any word from anyone receiving the sdk for Senra?

and what might this extension be dear sir? good for Firefox?

best would be to connect to the LeLutka Discord server. the team's seen it all and can fix any problem you're having. there's a link to their help server on their web site's main page.