Jump to content

Michi Lumin

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Michi Lumin

  • Rank
    Advanced Member
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Same happening to me for 7 months now... Does not seem that a fix is coming any time soon...
  7. 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.
  8. 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?
  9. 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'.
  10. 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?
  11. 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
  12. 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.
  13. 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.)
  14. 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.
  15. 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.
  • Create New...