Michi Lumin

Just got hit by this one today. NO WAY for me to revoke the assailant's permissions, since permissions cannot be revoked on a worn object. It's unbelievable that this is STILL an issue, and is still being ignored. The JIRA has been open and acknowledged for *8 YEARS*. This is a MAJOR issue where someone can PERMANENTLY take control of another's avatar with ZERO recourse. This needs to be fixed. I've had my account for 12 years and now I may have to abandon it due to this issue.

Czari Zenovka wrote: Fourm life is such that I expect refutations/debates; however, let's keep it to topics I have actually addressed. Well, seeing as the original topic was about the "removal" of the "temporary texture" "feature", and that was a direct side effect of SSB/Sunshine, I think it's rather on topic. If your intent was to jog the discussion over to other features that you feel were unnecessary (yet feel took time from fixes), then that's an entire other ball of wax. The other thing is, LL is not monolithic. People will say things like, "Why are you adding shadows without fixing the marketplace!" for example. The group of (count em, two) people working on shadows (for example) have nothing to do with web coding or the marketplace. New features don't necessarily detract from long standing fixes. The same teams are not working on them (nor do they have universal expertise in them. A guy who does GL shaders isn't going to be the one to fix the inventory database I agree that there needs to be better QA and that a lot of needed fixes have been "lost", but that hasn't happened because new features were added.

Czari Zenovka wrote: I agree with you on LL constantly adding more annoying things features, most of which I could do without and the majority of which always have to then be debugged. Server side baking (aka 'project sunshine') isn't a "feature". It's a paradigm shift in how textures are composited. And it is better, and it is the right way to do it. Yes, *coincidentally* and as a *side effect* some old ways of doing things do not function. But they are ways of doing things that, once again, LL never had on the radar in the first place. The old way: 1.Retrieve all texture layers (skin, all separate clothing layers, tattoos, alphas, etc) - 2.send all of them separately and individually to the client (lots of redundant bandwidth), 3.have the client (viewer's - i.e., your) video card use its hardware to "bake" them into a single texture, (and if you have video errors such as bad memory, that WILL show up for others, (rainbow pixels) since it's using your hardware and video driver to composite) 4.then send the composited texture out to everyone else, (reupload) and the server. Lots of points of failure, much more bandwidth used, 'blurry' textures, corrupt textures if there's a problem with your video card or driver, etc. The new way: 1. Server sends an already assembled texture to everyone. It needed to happen. Badly. But yes, it broke some neat 'hax' that LL never intended to have in the system in the first place. If LL had to check with and get permission from every Tom, Dick and Harry who rolled a third party viewer before making any system changes (remember, the 'service' is still on their head) - nothing would ever get done. I know, I know, (insert big old percentages of who uses FS -- Firestorm, believe it or not, does not run the grid. LL does in fact still do that.) The overall benefits of server side baking far outweigh the convenience of temporary textures, especially when local textures already do 70% of the job. Believe me, I have my gripes with how LL functions - but SSB/Sunshine is not one of them.

LL didn't "take away temp uploads". It was an incidental loss of functionality that only existed in TPVs that was necessary to institute server side texture assemblage. Greater good, and all. Client side baking was a mess. Again for clarity: TPVs gave people temp uploads, as an unofficial feature, taking advantage of client side texture compositing. It was never meant to be supported, and was basically a hack-in involving the way the *client* (viewer) assembled textures. As Phil said above, the feature was never meant to be there in the first place. (Using TPVs' 'unofficial' features, it's something one is going to have to expect. LL cannot monitor, support, and maintain every hack and kludge that every TPV out there puts in.) The functionality went away with server side baking, because long story short, temp uploads can't work with server side baking. They depended on client side texture baking.

Knowing the current LL, probably the latter... I'm guessing that they saw that we noticed it, and expediently removed it. Historically, well -- at least in the 'later half' of SL's history so far - transparency (in LL's opinion) hasn't been a "good thing" to the Lab. Not something they want to foster. I'm not sure why this is, because it leaves the resident body to form a lot of opinions through pure conjecture, which can't help the customer-to-service climate. A little transparency would remove a lot of resident populace uneasiness, and bolster confidence. (Really, LL; A little tiny bit would go such a long, long way... Think - a real possible scenario: SL's popularity being spread by word of mouth again due to the residentia having more faith in the Lab again, and more pride and motivation in telling others to come to join SL -- It really could happen, with little measures like this -- 'letting the customer know they're being heard'.) That said, I'm glad to see some proof that at least abuse reports are still being acted on. That was a serious question for a while here -- whether or not ARs were even being processed in any way. (Most other residents I have talked to have taken it as truth that they simply were no longer even looked at, and that the AR function was little more than a dummy placebo remaining in the viewer.) It's good to finally have some evidence that this isn't the case. Even if this blotter was 'sanitized', I think if LL put it back, it'd go a long, long way towards getting a bit of morale stoked up out here in the community as far as LL showing interest in the state of the grid, and performing some degree of governance. I hope this is being read, actually - I hope it's not falling on deaf ears... Something like this reaassures the community, it really does. While "naming names" is a very gloves-off attitude and something I wouldn't neccessarily disapprove of, even if we just had date, region and classification -- being able to see this again would at least let people know that certain things were ongoing. To everyone else: Even back in the days of a regularly operating 'incident blotter' from LL (back when it was a normal and expected feature, until around the end of 2010) - not all incidents went into the blotter. So that had to be understood. The blotter was more for 'instant and temporary' actions; anything that required a lot of investigation generally didn't show up. Anyhow, LL: Please consider putting this back up in -some- form... It's amazing what little, seemingly light steps taken could really help get the community energized and more hopeful at large... Please do consider it. When residents saw this, I heard people reacting like this was the dawn of a new day. They were stoked, outright, (i'm actually borrowing that language from someone who saw the report while it was up.) - Again, maybe cull it a little, but please, consider putting this back up in SOME form.... I think it'd help way way more than some folks on the Lab side of the fence may think it would hurt; and certainly help more than (LL, collective) may expect.

Same happening to me for 7 months now... Does not seem that a fix is coming any time soon...

Ok, so I'm not the only one. We were told to file a JIRA by support, which was recently closed as a "duplicate", but the 'original' of the duplicate is marked as 'inactive' and hasn't been updated much since October of 2010. I'm a bit concerned about back-billing on this as well; at this point it would be L$41958, or around USD $170. I'm not sure if the listing enhancements are still active, though, as I've never seen the enhancements actually appear. It's just frustrating to me that LL can't at least give a small status update such as "Yes, we know, and we're still working on it" - instead of sending me in circles going to support, who tells me to open a JIRA, which gets closed, due to being a duplicate of one that's inactive; repeat repeat.

Since July, I've had "Charging, cannot edit right now" for 6 of our products with 'listing enhancements'. The forum post about this says to contact support, but when I do contact support, they say there is nothing they can do, and to file a JIRA. When I do file a JIRA, it gets closed as a duplicate of an existing JIRA that hasn't been touched for months. The last update on this was October 8... So these listings have been stuck in this state for 6 months now (half a year) and the last word I've seen was from October 8 (2 months ago.) Is anyone else still having this problem with listing enhancements? Or is it unique to our merchant account?

December 13. Here we are, 6 months in since this problem began in July. The last 'movement' on this issue was 2 months ago, October 8. I understand things taking a while but this is a bit ridiculous. And I understand that our merchant account may be an 'exception' but there is no way whatsoever to bring attention to this issue or have it manually resolved. Messages to Commerce Linden have gone ignored; JIRAs are getting closed and support tickets are closed. But this is still a very real continuing problem that probably would take a DBA a few minutes to fix; whether it's removing or changing some records. I can't understand this. Got told by support (again), to create a new JIRA on this issue (again), which will probably be closed due to duplicate (again) and not be addressed (again) due to the original JIRAs (and this thread) being ignored. It seems, that if at this point, your listing enhancements are stuck in "Charging right now, cannot edit" -- this is a permanent condition and will likely stay this way for the forseeable future. ... All I want is for these listings to be 'unstuck'.

This is getting just a -little- ridiculous at this point... Six listings, stuck in "Charging, cannot edit.." -- *two months* even after acknowledgement of the problem. Can somebody, anybody, on the LL side tell me if this is even still being actively worked on? Or are these listings just simply going to be stuck in this state forever? Do we need to remove, and remake the listings on our end? Would this even fix it? Support keeps telling me its a "dev issue that is known and being worked on." That's been -- a long time. It appears that some of our listings have been 'stuck' this way since late July/August. Support keeps saying "Support cannot help you with this issue". If they can't, and nothing's going on here - who can? Please, even just a status update, CommerceTeam Linden?

Just to clarify: I work with Eltee Statosky (Luskwood Creatures) who previously mentioned that as of Nov. 5 (and now Nov. 6) - that yes we still have 6 "stuck listings" and this means "Charging, cannot edit.." I did try contacting Support, and they said they couldn't do anything abut the issue. (I'm *not* trying to be cynical, but outright, it seems that Support's task is only to tell residents where the knowledge base is, or to say no. It appears that there's very little if anything they can actually resolve -- mostly by policy.) It's a little tough to swallow.. When a group or online entity depends on their sales (marketplace, etc) pays upwards of the 'high three digits, almost four' per month for sims, land, listing and other LL services, and has no real "support" avenue, it does become a little bit "frustrating", yes. The six stuck items of ours happen to be some of our top sellers. So we're at a bit of a disadvantage here. I'm sure that they could be manually reset, but i'm also sure that "policy" doesn't permit that to happen. (Because 'if they did it for one, that'd set precedent and they'd have to do it for everyone'.) -- I get that on some level (and things like this seem to be mired in 'policy' lately) - but really, even if it took a while, what's so wrong with resetting these manually, so that customers (real, paying ones; these listings are not free after all) can continue about their business and then the dev team can work on the problem that caused it without interference? I suppose the frustrating facets of this are: -The issue has gone unchanged for a number of months -Support can't provide a resolution or assistance. -The JIRA about it has been marked 'inactive' and cannot be commented on, nor is status being updated there. -Don't get me wrong, I DO appreciate the update and communication here but, "watch the release notes, it'll be fixed at some point" could mean another several months. ...Even if it took, I don't know, a week or two to get to -- just, a side note and suggestion to Commerce Linden here: Couldn't you guys set up a way that we could file a ticket for this and have them manually reset when you guys can get to it? It just seems there has to be some way to implement a short term amelioration versus waiting for this to bubble to the top of the priority list (which may take a very long time)... It just seems like the best way forward for everyone? Of course I'm not on that side of the fence -- but it's likely pretty different from inside-of-LL preception on the 'rezi' side of things, too. Anyways, in short: The response is appreciated, it's good to know that this is still 'actively' being worked on (I was under the impression it had been resolved) - but, as paying customers, could we may be get thrown a bone and get some sort of short term help, even if it takes manual intervention, as it has been -quite- a long time? Respectfully (but frustrated) Michi Lumin / Luskwood Creatures

They were defaulted to be unchecked in some builds... I know it's gone back and forth. I know some folks in the render department prefer masking vs blending because it simplifies lighting. Personally I'm not a fan of it because it does break content; so whether that's going to land on enabled or disabled by default is still up in the air. I do know on some previous builds the default has been to -disable- the auto masks and use blending. It seems to me that now, after some other bug fixes with lighting, even with deferred (Shadows) enabled, lighting falloff matches on alpha objects, so it's mostly a moot point and probably could go back to being defaulted to alpha blending vs masking. I suppose the issue would come back into play if they decided to ever re-implement Global Illumination again, but as far as I know that's shelved for the time being, so defaulting these auto-mask options to off probably wouldn't hurt.I'll see what I can suggest; or if LL is listening - a tip of my hat on this notion.

Aha! Auto Alpha masks. You can change this back to the old behavior To get this looking back how it did: Turn on the Advanced menu with Ctrl-Alt-D Turn on the Develop menu with Ctrl-Alt-Q Develop -> Rendering; UNCHECK "Automatic Alpha Masks (deferred)" and "Automatic Alpha Masks (non-deferred)". (Make sure both are unchecked.)

Agreed- the JIRA has essentially become a knowledge base over the years. Getting rid of that functionality is absolutely removing a resource from SL. Additionally, due to the fact that bug regression seems to be somewhat common in SL viewer builds (there is after all a lot of disparate merging going on - i'm not faulting LL for that; regression happens in most dev environments from time to time), referring to previously fixed issues really has in the past, short circuited the need to start from scratch. It's another form of duplicated effort, but a duplicate nonetheless. Innula Zenovka wrote: Latif traces the way it started as a question about uploading, got identified as a problem with Microsoft Skydrive, then Latif posted a registry fix for it, and then Whirly Fizzle identified the root cause,which LL have apparently fixed (thus fixing several other issues in the process) and we should see the benefits of all this in a viewer release soon. As Latif says, that will not now be possible. Wow. I didn't even think of that -- That, in fact, is EXACTLY how I solved my "can't upload " problem. I did in fact have SkyDrive installed, and Latif's fix on the JIRA got me up and running again. Threre is *no way* I would have divined that myself without the JIRA. SL and SkyDrive? Too disparate for me to presume that they were interacting badly. I'd still probably be pulling my system apart to this day if it wasn't for Latif's JIRA post on that one, and it being searchable and available.

To me it's not even the publicity and searchability that kills it. It's the inability to have a dialogue with the dev team and work towards an outcome. You know, "mutually beneficial". As in "Here's what I'm seeing" / "Can you clarify?" / "Yeah, here" / "Ok I see it now, try this fix" / "That worked for the most part but there's just this one thing that's still not working" / "Ok, try this one." / "Yup, that did it" (jira closed). Versus "My second-lifes doesnt work it is broek plz fix plox"... (spend next month praying for a release note.) But maybe that's just me. However you're right, the only way that not being able to look at previously reported problems would reduce workload is if they're not looking at the bug reports at all. That, or LL hired a person to triage all incoming bug reports and pair up / consolidate them as they come in. But, come on. There's no way that happened.

The inability to reply when a repro fails is absolutely crazy. Sometimes there's a communication (or comprehension) failure in a bug report from resident -> LL employee. This means, basically, that if that occurs, it's shot dead. I cannot count how many times I've gone back and forth until even a Linden got an "Aha!" on the repro, and then the bug was fixed. But it took some ~communication~ for that to happen. Now, we can't do that. "Blame the customer and close the issue". I think that's what we'll see.

Over the past ... 6-7? or so years that SL Jira has existed, we have reversed SO many bugs, ferreted out SO many hard-to-triage, hard-to-find items, and collected SO much information on issues that just would have been completely detrimental to let go in SL. The Lindens do not "live" in world and find so few of these issues on their own. They don't build, create, interact -- their development (From what I can tell) seems to consist of going to an empty Linden sim and getting a "yup, it works, ship it" response. This means, LL does what it wishes - the product (server and viewer) is 'as is' and we just have to deal with whatever issues are foisted on us. If this was done due to the idea that 'game companies don't have public bug trackers': SL is a lot more complex and involves a lot more systems (and user self-extensibility) than your average game. The very aspect that content creation exists in SL changes this paradigm. Forget the notion of SEC jiras. Not being able to categorize, not being able to have several people doing tests/trials, and no interactivity between LL and the userbase of "Here try this" / "nope that didn't fix it" means that bugs are going to remain and fester for, well, perhaps forever in some cases when LL devs don't feel that they are interesting enough to address. Community impact on an issue can no longer be gauged; LL will only work on assumptions and presumptions since they do not operate "on the ground" with the residents. I'm sure this is a cost cutting measure in some sense, and somewhere it makes "good business sense", but it of course calls into question the intended longevity of their product. LL is going to "cost cut themselves" out of the userbase. Major producers and players will continue to leave, and the only folks who will be around are the fickle fly-by-night consumers; and as soon as new content runs out, they'll leave too. I feel that if LL is working on 'spinning down' SL, they should give notice so that people can make other arrangements. I've spent a decade of my life, paying LL money - thousands of dollars a year - and putting in thousands of hours of work to build community and create content in SL. Every year that goes by, I feel that LL finds new and creative ways to kick sand in my face for the effort and expense. Doing it for 'pocket change profit' has long since become a thing of the past; I do it now because I believe in the communit and the people on SL - Linden Lab continues to gain, on that, while making it harder and harder and harder for me to do so, for seemingly little to no rationale. (I understand that folks at LL do not like their legacy userbase. I do not understand why. We bring in new people - I see it every day. We drive conversions - I see it every day. We engender longevity and give people to log on - I see it every day. We bring in revenue for LL - I see it every day. So please, LL? Answer me - even in private: Why are we your enemy?) I wish that someone at LL would see this, what i'm typing here. Morale among the userbase could use a slight boost, guys. Lindens: you know how to reach me. But I know I won't hear a thing. Separation and firewalls are the name of the game here, I get that. I don't think that's wise. But what do I know, i've only been doing this for almost 10 years of my life, running both a community and a large content creation business, without stop. I obviously am completely clueless when it comes to any aspects of SL.

"I suspect that's the next thing on their list right after making sure all the Magic Boxes are disabled." ^^^ this. Have not heard a word directly from LL as far as ANS goes. LL: A lot of us depend on ANS, not just for record keeping but for external functionality. Support kiosks. Databases. Updates. Accessory vendors. All sorts of things. We all have different customer service models, many of them which depend on ANS. Saying we have to rely only on 'transaction history' and manual downloads or manual views is going to crash the party for a lot of people. Please. ANS. Soon. (As in, before magic boxes are disabled.) -- As soon as you guys have ANS working, my Magic Boxes will be gone *THAT DAY*. Promise. 

Darrius, Don't suppose you (or anyone else) has heard any news on ANS? This thread here seems to be my only link to the Linden Reality Distortion Field -- Linden Lab: I'd really love to convert to DD. The day ANS is working, i'll be doing it. I sure hope the decision on this isn't changing, or ANS isn't changing into something else.

YMMV, but I try to keep our announcements to our opt-in announcements group. I've run a business here for a long time. (check that - really, a very long time.) To date I've got about 39,000 past customers. Of those, about 1,000 have opted in to our updates and announcements group. This shows me that 'spam and announcements' simply isn't the way most people want to function. When they're looking for something, most folks will search on the marketplace for it specifically. If they like your products in particular, they'll sign up for annoumcements if you offer it. There's no need for you to do it for them. Anything but 'opt-in' is shady. Anything else actually drives customers away from your store. If they didn't ask for the newsletter, you shouldn't be sending it to them. Historically, SL's culture is not one that likes to be "advertised at". I'd bet that opt-out lists cause every business that uses them to shed more possible sales than they gain. I have several 'newsletters' I get now, and I don't really have the time to track down where they're coming from. They'll likely not stop coming until these shops close down. I sure won't buy from them again though, on the chance that somehow that will "re-up" my "opt-out" situation with them. So it goes: as is email, is Second Life. And as far as I know, nobody enjoys UCE in their inbox. Treat your customers with respect and they'll remain loyal.

Ok, very interesting... So ANS is going to be transactional, you're saying? Or that it will exist in different states (delivery started, delivery confirmed)? In any case I'm glad I'm not one of the only ones who's waiting. And, really, thanks for the heads up; the more information on this, the better.

Same here. No ANS, no go. Everything else seems to work great, but, we absolutely need ANS. Our support terminals and external database, updates, etc depends on it. Hopefully also no fields will be removed from ANS. But, before nitpicking that, I want to see ANS happen at all. Really, this is a must. Some of us have too many tie ins and move too much inventory to rely on the marketplace's sales history alone.

So, from what I can tell, support for ANS is up in the air. We keep our own database of purchases, and have for eight years. Relying on the marketplace's purchase history is not a way we can go. This is a very serious issue. With 3 weeks to convert, and ANS not being released for another (undetermined) few weeks, this is seriously going to put a crunch on us with ~300 listings.

We've heard nothing from Lindens since the initial posting here. My original concerns were posted one month ago -- and that's only two or so posts up. No replies from LL. If a Project Viewer is meant for feedback, then, here is feedback. Here, above, and in the JIRA i have created. I believe I am taking the proper path here as far as responding to LL on this project. So, we have given feedback, and we have questions. So, can we please know: Will the 'Switch to hierarchy view' be going away? (The writing is probably on the wall, here.) If so, WHEN and WHY will hierarchy view be going away? (Why can't we retain this option?) If HV is going away, Will ALL functions we had in Hierarchy View be implemented in SINV/Folder View? For example, when we make an avatar, often we will have, say, 17 varieties in one release. Each avatar has 30 parts or so. I CANNOT see using SINV for sorting all of those items into their proper folders to get ready for packaging. The problem is, people are viewing this from an "I've already got all my stuff" perspective. That's FINE for users who are mainling buying/wearing/using stuff in SL. For folks who make things, and have ot keep large inventories and manipulate a lot of items, SINV is a non-starter, since you really can act on only one item at a time without even being able to see what is above and below it. As a more detailed example, I may have a (2012 MESH UPDATED AVATARS) folder, and then beneath that, (CAT UPDATES), (LION UPDATES), etc, and in each one of those, (ARMS, HEADS, WINGS, SKINS, SCRIPTS). Some of these scripts may be used across many avs. Others are specific. When packaging an avatar for sale I have to pull from a lot of these different areas into cleanly pacakged folders such as (2012 BLACK CAT MESH UPDATE) which then goes into a box, the marketplace, or a vendor. "Walking" each single item into place with SINV is going to multiply the amount of time it takes to complete this task several times. Another example would be, sometimes I have to multi-select a bunch of things several 'hierarchy levels' in, say, all of the parts for the (Purple Female Fox) avatar and move them into another location, to be updated/worked on/packaged/permissioned/whatever. And I have a lot of nested folders for 'production' and 'distribution' such as (2012 AVATARS) -> (PERMISSIONED) (NOT PERMISSIONED) ---under each--> (CATS)(FOXES)(DOGS)(DRAGONS) ---under each--->(MALE)(FEMALE)---under each-->(SCRIPTED PARTS)(UNSCRIPTED PARTS)(SCRIPTS). With SINV, this all becomes useless, and VERY hard to navigate. .... Now, if Hierarchy View remains intact, all of this becomes moot, and we have a viewer that is A) more newbie friendly and B) still useable for content creators and power users. So, LL: The userbase has given feedback after using the project viewer. Can LL PLEASE give us the verdict on whether or not this will be REPLACING Hierarchy View? Or simply supplementing it? A lot of us are pretty concerned here. Note, I have created a JIRA, SINV-11, Here, about the 'optionality' of this, so hopefully we can get answers and get concerns voiced while the "Switch to Hierarchy View" option still exists. (https://jira.secondlife.com/browse/SINV-11) Thanks Michi Lumin / Luskwood Creatures

Okay. I see where you guys are going with this, (LL) But: I know Rhett said otherwise, but I am really concerned that this will be the only view available down the road (as historically - and I've seen a LOT of LL history - LL does **NOT** like to support 'options'; the stated end goal seems to be "One Size Fits All".) I'm also rather concerned that it will be foisted upon the population "as is". Without functionality like property inspection and -- well, everything I use inventory for besides "wearing a thing" (which, as a content creator and vendor and sim operator is a whole lot of stuff ) - this would be the 'final straw' that pushed me to a TPV if it was indeed "forced on us" as the "only option" in the official viewer. (I have my own reasons -- including security and lack of accountability -- as to why I don't use TPVs.) HOWEVER: If What Rhett says is true, that this is only for user feedback, AND if the existing inventory view remains an option (Which Rhett did *NOT* mention, but, really, I know this may go in one ear and out the other but - PLEASE consider maintaining the existing inventory view!!!) - then I COULD see this as being an advantage for new users who DO get confused by inventory. So, AS USUAL, this is a potentially good idea by Linden Lab, but, has its biggest risk in "the implementation" versus the idea. Please, LL, -- Historically I know when pleas from the userbase like this happen, *the opposite* happens but, please, by all means follow through on this view, but do not remove the existing hierarchical view unless somehow the new view is made feature complete in comparison to the existing hierarchical view. I know everyone gets antsy when a new 'project' like this shows up because there's apprehension that "this is how it's going to be, like it or not". I have a large inventory (out of neccessity; 8+ years of projects and extant products; not out of pack-rat-ism) and need to perform a whole lot of manipulation on those items. (Which, by the way, if I ever had to pay something nominal to maintain such a large inventory on LL's servers -- i'd understand..) I do NOT want to move to a TPV. And I am NOT in any way saying this view is bad in all ways -- I help a LOT of newbies and I can see where this would be a great simplification for them. Just please don't make it a forced, only-option. I do hope this feedback is heard and considered.... -Michi Lumin / Luskwood Creatures