|
|
|
[
Permlink
| « Hide
]
Wrestling Hulka added a comment - 08/Nov/07 11:21 PM
This issue arose after the Nov 8th Server upgrades. Thank you Funk for posting this - it's very critical to anyone who takes multiple vendor boxes into their inventory.
yes, this is definately reproducable and also seems to affect object groups which were picked up before the Nov 9th updates.
This is absolutely critiacal for multiple object setups like store setups consisting of vendors and single boxed items set for sale. I'd not say it's a showstopper but definately a critical issue since if you do not pay attention your items are all set to sale for L$0 or at least a price you did not intend. THANK YOU for an excellent repro; I've changed priority to Critical, will import this, and ping our devs about this right now. I can definitely see how this could result in unpleasant, messy surprises due to the instances BlckCobra mentioned.
I know it's an obvious question but I need confirmation from anyone who knows: you remember this functionality working CORRECTLY before and this is a NEW bug as of yesterday, right? As in, you could take a whole bunch of objects with different prices into inventory, then rez them, and the price on each would be correct?
And if anyone remembers, what happened if you took a coalesced (combined) object, and tried to set the price in Properties? Did it overwrite them for all? I'm asking for dev, QA (Quality Assurance), and Rx (Resident Experience) assistance in helping us figure this out and fix it soon is appreciated. Torley- this definitely did work prior to the upgrade, when you took a coalesced object into inventory and re-rezzed it in world, each prim would maintain its original price.
As for the second question, if I recall correctly, setting the price in the edit menu for multiple selected objects would only set the price of the last prim selected, though I actually would prefer it overwrote the price for all. I was taking coalesced objects the day before the update and it was working fine (correct prices remained on the right prims). This is definitely new. Setting a price would only effect the last selected prim, but I also wish it would apply to all of them!
This problem has been occuring for me since the rolling restart yesterday. I have 100 plus prim displays - every box linked has a different price - upon rezzing my display and unlinking every box is not marked for sale. This is a HUGE issue for merchants who set up many stores - indivudually pricing 100 or more boxes each time you set up is impossible. Please resolve this issue quickly! This is effecting many many merchants due to the fact they use linked displays. ty
This is a new issue that started right after the restart of each region. It isn't only changing the prize it is also changing the permissions, the root prim changes all objects in the link (if linked) or the group. My vendor boxes are linked to a backdrop, i have noticed pretty late that all my boxes been not for sale anymore! However, it is certainly new, unfortunately unpleasant doesn't describe it in entirety in fact this has a major impact on the sellers guild. Contact me In World and i demonstrate it to you! Mall renting is kinda standing still right now coz everyone is waiting for it to change back to normal!
Yes I have to agree with Alyssa and Steph, as a merchant with many stores this is a major major issue! Please hurry and fix this!
Yes sales are lacking terrible from this  Hope we see a fix ASAP! This issue became a problem for me yesturday after the rolling restart. And it was not so prior to the update. This has brought gridwide new shop aquisition and maintainence to a grinding halt for many. BIG BIG issue. Would appreciate a swift repair. Thanks.
At risk of making a shameless plug, I should point out rez-faux might help with rezzing your displays, Alyssa:
http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=65607 Yeah I have had same problems I have a crapload of shops like Alyssa Steph and Nosha and always get more and get rid..this totally bites it.. sure if i used a vendor but alot of places dont like vendors.. keep it simple keep it easy keep it working..
now all my sets are broke ;/ The root prim in a link group of prims will change ALL permissions + FOR SALE SETTINGS for EACH prim in the link... The last selected prim in a group of prims will change ALL permissions + FOR SALE SETTINGS for EACH prim in the group ...when you rezz it from your inventory ACK, i have enough trouble with little fubars like tihs!
I also noticed when i rezzed a single prim it didn't give me permissions to my own things, nor would it let me set the price, so this is a watch out too girls, and Dark. <winks> I just reproduced both parts of this; permissions resetting as well as the pricing resetting too.
Torley, Linden Labs, please please please post a status report. This is certainly a show stopper and not just critical, it needs to be fixed immediately. I am sure it isn't easy to realize the importance of such an issue and in a case like that there will only be a few complaints because there are simply less merchants in comparison to people loosing their prim boot bases during teleports and mostly because the most merchants rezzing their displays without even knowing. An official blog announcement has to be published and we merchants need to be informed when this bug is gonna be fixed.
An ESSENTIAL FEATURE was taken from SL, it shouldn't take longer than 24 hours to acknowledge the bug and get rid off it. I know the amounts of L$ i have lost already + rental time + wrong rezzed displays and selling my stuff too cheap, you don't need to be Einstein to realize that this bug causes a multi million L$ damage in only a couple of days! So please please please lets work on this together for once and let us know what we can do to fix this. Thanx Sorry, I bumped this up to showstopper; merchants who use vendor boxes are completely unable to do anything right now. It's beyond cumbersome, it's dangerous for anyone selling any content unless they're incredibly diligent. And given that so many people are unaware of it there's really no telling what mistakes can happen with prices set incorrectly or permissions being reset. I have completely given up working on content right now until this is fixed. This is definitely something that needs to be looked at right away.
I support the escalation to showstopper.
This is a huge problem that's affecting a lot of people. It's conceivable that this bug will cause people to sell things they didn't mean to sell, at prices they didn't mean to sell them at, and/or at permissions they didn't mean to sell them at. This could cause a heck of a lot of damage to unsuspecting vendors in SL. Worse yet, this will catch people unaware; it's a bug in functionality that apparently a lot of people use. It needs to be fixed ASAP. I'd like to see LL make a blog post about this, and possibly even an MOTD pointing to it. Eeee gads! We can't set up any of our stores without manually setting, checking and correcting each prim price and permissions. Are you kidding me? I've got enough grey hairs.... AAHH!! Please fix this as soon as possible! This is certainly a Showstopper. Thanks Linden Lab!
please Please Please Fix this ASAP!!! Prims should never have there permissions or pricing changed automatically by the system.
As a merchant with many shops i also find this very troubling and makes it imposable to set up multiple prim shop in a timely manner. i also like to note that this happens for linked and unlinked sets of items changing the prices and perms This Bug Changes the permissions and pricing on every prim to the root prims perms and price for EVERY RESIDENT of Second Life regardless if they are a merchant or not. Permissions pricing should NEVER be changed automatically for any reason
I second Crucials statement. Auto changing permissions leads to a worst case scenario for content developers as well as sellers. This is hosing alot of people and needs to be repaired now.
Please please post a status report on this problem. I just had out 4 different items for sale, all vendors were grouped and taken back into my inventory and then rerezzed. 3 groups of vendors objects all took on 0L and the other group took on the highest price. Not sure if its the last selected object or not? I think it's vital everyone is made aware of this problem especially for merchants. Also, I have older grouped vendors in my inventory, when rezzed they are all effected, so it's not just happening on recently created objects.
Thanks everyone who came on here to express how important this is to you, I'm both going to advocate to Support (re: blog post) and Devs (re: fix) about how needed it is to get this fixed ASAP.
I have been aware of this issue for some time. Yes it is annoying and can be costly. Permissions on one prim do not transfer to another once linked. So far I've been careful to link my vendor prim last.
Posted to our Official Linden Blog:
» http://blog.secondlife.com/2007/11/12/a-word-of-warning/ We'll update you as progress is made. I was hoping someone could clarify, does this only affect prims set to sale, or would it affect prims that use a script with a money event? Thanks.
I can confirm that linking does change object permissions on top of price and selling permissions. Once reserved, even after unlinking, all the items still retain the selling price/perms of the root object. Tried it a few days ago and noticed it but could not remember if it had always been this way.
I also tried selecting a basic prim last (not set for sale, just a plain plywood cube) with a bunch of for sale items. Thought maybe that could prevent the change in price since it is not set for sale. Nope! Once the grouping (unlinked – just taken as a bunch of selected individual items) is taken out of inventory, the NOT FOR SALE prims, were now SET for sale and had taken on the price and selling perms of the last "for sale" item selected in the bunch redardless of being selected first, in the middle or last. So, the last item for sale selected (even if you select other not for sale prims after the "set for sale" prims) dictates the prices and selling perms of all the other items as well as make "not for sale" items "for sale". Also tried "take a copy" instead of take to inventory. Same results. Linking, as mentionned, will change all perms, selling settings, price AND whether or not it is "for sale" based on the last item selected (the root prim). Thank you Torley, blog should probably mention that linked objects are affected as well!
Darien, scripted vendors aren't affected as long the script handles the pricing and the way of delivering the product (original/copy/content) Your multi product vendor is certainly not affected by this! The blog entry should also point out this affects permissions as well, not just sale price.
Ofcourse comments were off on the entry preventing any of us from alerting anyone to that oversight, which is pretty asinine. taking coalesced objects doesnt seem to change permissions for me. What are you guys doing? Can you give the exact steps required like I did for the original entry?
If on the other hand you are LINKING the prims, then yes, all those prims will take on the same perms. It has always been like this from what I can remember. Lets say I make 100 prim object (not that I would), the default perms on rezzed prims are nocopy/nomod/trans. If I link them and set the object to mod/copy/no trans, I dont want the perms changing back to nocopy/nomod/trans if someone unlinks! I agree with you Funk but what i am seeing is something a little different . what you are talking about is you personally and physically changing the perms of a linked set of prims. that kind of change should effect all the prims in that linked set. This is true.
But what I am others are seeing is if you have 100 prims all that are transferable and one thats no trans and you link them making the One that is no trans the root all the other 100 prims will then be no transfer. The difference is in the first case the object owner changed the perms in the second case which i think is new the system changes the perms upon linking of the prims. Perms should stay with the individual prims/scripts/sounds/animations/textures that made up the object before linking them. If you set the object, once complete, to no modify, then you can't unlink it. And both "bulk perms settings" and "indicate nested perms with double parenthesis to indicate only part of an object is ((no modify)) or ((no copy))" have both been suggested in the new features section of the Jira.
Our developers are working on this and I will confirm:
There was also design discussion about related issues happening today and other subtleties are being investigated, more than I can sum up neatly, but be assured we take this extremely seriously and hope to fix it soon – earnestly, thanks for your continued patience. Aimee: OK I see. I still think it might have always worked that way though (I could be wrong). Others would know better since I always made sure to set perms on an entire linked object anyway.
I think it makes sense to set all perms to the root prim's perms though. Lets say I make some hair. 20 prims all linked and set to the perms I want (mod/copy/no trans). What If I decide I need an extra strand, but forget to set perms on that strand before linking to the main object. Someone could unlink it, and do something I didnt want with that strand (like transfer it) . That would mean I would always have to check perms of every single prim in every item I make. Actually I just confirmed that with Stumbelina who makes hair. She uses a standard root prim for all her hair (which sits inside the head). That is set up with the perms she wants for the whole hair. When she links her hair strands to that root prim, they take on the perms set up on that root prim.
Just to make it 100% clear. From what I remember and what Stumbelina tells me about the way she makes her hair, this "permission change" on linked items has always worked that way. It's not a "new bug".
If someone knows for a fact that it didn't work this way, I think it would be better to start a new jira bug and link it as related. I just don't want the devs trying to fix something that isn't broken. I don't want to wake up tomorrow and find my items now have multiple permissions because I forgot to set them on the final linked object! O.o Ok. I never noticed that linking changed perms on all items as I also, like Funk, always set the final perms after everything is linked and when I made the odd "link the whole store to a prim vendor" mistake, I never took those things to inventory, so that wouldn't change the settings. Crazy how many little details there are to learn, even after being here a while!
I really don't remember linking changing each individual object sale settings though. Thank goodness for having a messy inventory, I found a really old display that was linked, which I used a lot in my early days, and I don't recall ever having to change the individual prices when setting it up in a new store or the display wall and signs being set for sale. Unless my memory is seriously failing me. does this bug enabels people to sell no-transfer itens or change perms on no-mod itens?
Sorry, all. I should have made my comment clearer. The root affecting all internal prims/scripts/etc. is the disired behavior. It's the other direction that has borked my for sale items. If I use a script that's set to "no mod", or even a notecard set to "no mod" in a build, the entire build takes on the perms of embedded objects and I can no longer change it before sale despite the fact I have resell perms on all components. Tp whit, I have a multilanguage notecard dispensor that is full of "no mod / copy / trans" notecards. I made the script, prim and texture on the device. When I take it into inventory, the prim is intended to remain "mod" so that new notecards can be added by others at a later date. Yet, the dispensors properties in inventory have the "Next Owner May: Mod" button greyed out. Not a good thing. It happens to all objects I create. It used to be that this apparent nomod of objects taken back into inventory doesn't apply for the next owner and the embedded components retained their proper perms. Now, the whole is set to disallow all perms from all internal components if rezzed and taken back into inventory. This needs to be checked, yesterday.
I cannot believe that it is now the 15th no fix and NO blog update-
For an issue this serious that effects so many people I'd think it be more important then filling the blogs with fluff..who cares what the sky looks like if we can't continue to expand our business? PLEASE update the blog and give us a status on where you are at with this fix. The folks it effects the most are the ones who are paying the tier around here. I can not believe it either. .. seriously .. people!! ...a bug that takes over 5 days to fix tells me there is something unfixabel wrong . HELLO!!! IT'S A SHOW STOPPER!!! .. I rented several mall places that are EMPTY right now because i can not set them up since it would take me HOURS to so if i have to do it prim by prim. I pay money to have empty mall spaces AND I wont rent anymore till this SHOW STOPPER is resolved!!
I can not believe that QA did not check a simple thing like this BEFORE ALL OF THE SL SIMS got screwed. How can rezing inventory items NOT be on the list of things to test on an global update like this? I think it'd be best if we limit comments on this issue to further information about the bug rather than complaining. We all know that we're all upset by this bug and that it's hurting businesses in SL. Just saying that again in this JIRA thread only serves to increase the amount of cruft that LL devs need to wade through to get the useful information about reproducing the bug that people have posted. Also, LL devs have hearts, and they probably don't feel so great reading all of this vitriol directed toward them. This encourages LL devs NOT to read JIRA, which is exactly the opposite of what we want.
So just assume it's known that you HATE this bug, because it's been said a lot. If you have new technical information about the bug, post a comment. If you just want to register your dissatisfaction, vote this issue up and get all of your friends to do so. LL pays attention to votes. Yeah Lex nice Words Of Wisdom there, i know for a fact that people offered direct help to fix this bug, that isn't the point here, the point is that something that worked the last 3 years isn't working anymore and like someone mentioned already it is probably the desired behavior that LL was trying to achieve by not seeing the complexity of this behavior in entirety. I guess the more committed merchants have already made alternative setups and are able to do business as usual, it is sad enough we have to go through this and it is sad enough that somehow there is a bandwidth limit and regions rez slower (i am on 15 mbit) this all isn't thought through and this all is hurting our sales, the reason to be upset is because they have the solution already, remember it worked for 3 years, there simply won't be made a rolling restart just for this, lets not upset the mob, let's upset the little group...and again it isn't thought through coz our shop rentals keep sim owners in the game and once they haven't enough income they can't pay the tier, the sim closes and LL doesn't sell land! I have never experienced a week like this where merchants were so uninterested in having 1st dibs in new malls! Some people doing this for a living and every cent one is loosing over this is upsetting!
However... this new "feature" isn't affecting content items like mesh wear or note cards, it is a prim 2 prim problem only! Is there any update or an ETA on when the fix for this will be rolled out ?
This NEW bug causes a huge waste of time for retailers who set up at multiple locations having to reprice any where from 25 - 200 prims with every new set up not to mention the utter frustration that comes with every store set up knowing this was never an issue in the past and we can't count on the prices being set to what we expected them to be set at. PLEASE PLEASE PRETTY PLEASE CAN YOU FIX THIS! I am not yelling i am begging PLEASE. I do hope this gets fixed soon, although... I am personally loving this bug, I hope once the bug is fixed, we can have a new future to "bulk" click for sell. It makes it much easier having 20 prims of the same thing and being able to set the price one time instead of 20 times.
This issue was FIXED INTERNALLY on 2007-11-14, a week ago, and currently is in an internal maintenance branch awaiting inclusion in a public release. Like you, I hope it happens soon. Watch http://blog.secondlife.com
 for when, because it'll be listed in release notes.
I deeply apologize this issue wasn't updated earlier to reflect actual status; I wish our public and internal Issue Tracker were auto-synced, but as they aren't, developers manually check back-and-forth. It's time-consuming, but better than having no Issue Tracker (remember how things were before?). But I did notice this was amiss, and wanted to assure & confirm on behalf of LL that we do give such a damn about speedily fixing horrible bugs like this. So....... this was INTERNALLY FIXED exactly 2 weeks ago! Today was a rolling restart and the bug fix wasn't deployed to the servers. Thank you so much for taking this so serious!!!
How about posting an estimated time window and pushing this SHOWSTOPPER on top of the to do lists? With all due respect Torley, by not updating this today LL kicked us straight in the face, i think thats so rude to let us deal with your bs for nearly a month. This bug is listed as resolved, don't you think too that this is a bad joke?? QUOTE: "and wanted to assure & confirm on behalf of LL that we do give such a damn about speedily fixing horrible bugs like this." ROFL! A rolling restart without a patch for this critical fix is rather poor form.
Donovan was remarking earlier, that things are taking a long time to get through QA these days . Perhaps that should be speeded up. I am extremely disappointed this issue was not included in this latest update.
I do have a question - why is this issue logged in this manner: Status: Resolved 1. It has not been resolved - why would someone mark it resolved when its not??? If LL is having problems addressing this issue please let us know - just don't leave is in the dark I logged in to see there was an update viewer and was very hopeful that this issue was fixed. I log in and test out to find that nothing has changed. So why does this issue say its resolved??? Its not resolved and we need some answers. Tell us why this issue hasnt being fixed. Ignoring us wont make the problem go away. I have quit renting shops for the time being. This triples or more the time it takes to set one up. Not to mention the sales I lost for having incorrect prices in the beginning and the new paranoia over pricing and perms that I with many others are experiencing. PLEASE UPDATE US WHAT IS GOING ON?????
This issue is NOT resolved!!!!
It is resolved when it is updated in world and not when someone cleans the plates before dinner! I kinda feel sad for Torley ho has been sent to the frontline getting shot at for other peoples WRONG DECISSION MAKING and strange policy. However if you people still haven't realized what this bug is causing and if you really care so less that people invest their RL savings into land and malls and go broke over this bug then i am really sorry. If this bug is really resolved internally why wasn't it updated, why wouldn't you inform us? Excuse me for being blunt but we deserve a propper treatment, vendors posting in this topic generating billions of L$ a year! Shakes head in utter disappointment. This bug is just as important as any exploit. it should of been treated as such. i have seen serious bugs fixed in days this apparently was not serious enough in the minds of some. and the "SHOWSTOPER" title is completely meaningless. Linden Lab makes me regret my decision to go full time SL nearly every day.
Setting this back to the correct resolution.
NOTE: Resolved / "Fixed Internal" means the item has been fixed in an internal development branch of SL. The code is pending QA testing and when deployed to the grid the status of this JIRA will be changed to Resolved / "Fixed" Shame on you, Linden Labs. Is there a hall of shame meta issue anywhere?
You got to be kidding Thraxis. Like anybody thrust LL QA anymore after this SHOWSTOPPER bug got introduced with that rolling restart back then. Seriously, If they where not able to test to re-rez a bunch of prims in a sim to see if the prices on them are still correct back then how do you think they do now?
I still can not believe this is taking soooooo long to fix. It clearly shows me that LL doesn't care. Especially considering the silence around this issue. I am very disappointed. I'm going to find out what happened here and post an update AS SOON as I hear back...
Point taken. Apologies
There are quite some Fixed Internally issues there. Maybe if QA is working on something that a developer thinks is resolved this should not be marked as Fixed Internally. It just upsets people. I don't know, maybe it creates additional overhead with the updates of issues, but ... even if so, might be worth it. Maybe an additional state would also help. Yeah, I know, more bureaucracy, I hate it too. Though, many of those maybe just need to have the state moved to Fixed. Here I would definitely not insist on submitters to close, but on the other hand, they could be the ones that could help by doing so. Email notifications might help with that, by the way... I'm anxious and I don't want to leave you guys hanging over the weekend and I wish I had more info right now but I don't – I've already contacted several Lindens more knowledgeable re: what happened to this, and let them know to comment here ASAP if they find out before I do.
Here's what I know right now: the fix is in an internal maintenance branch and waiting to be deployed. I don't have an ETA. @ZigZag: Rob Linden, I, and some other Lindens have been discussing exactly that (specifically, a "pending" state). Related, see @Torley - My cryptic comment was to ping you guys on
I DEEPLY apologize
We made a mistake, so again, I'm sorry, and will endeavor that mistakes like these are minimized in the future, and I'll personally continue to work on improving Resident< @ZigZag: I'm not familiar with what you describe offhand; it sounds like it should be easier. And, I should add that Alexa and I spent a lot of time recently changing older issues which are indeed publicly fixed from "Fixed Internally" to "Fixed" – any Resi help doing this for stuff you're sure is publicly fixed is really welcome. Okay, so when is it going to be fixed. It's been a month now.
Can we get a date? Version revision? After Havok 6? sorry lindens but this issue isnt resolved!!!!
@Joshua: I or another Linden will post a date here when it's available – in any case it will be announced on the Official Linden Blog @ http://blog.secondlife.com
, so please keep looking there for release announcements.
@gepaecknetz: It isn't fixed publicly yet but was resolved internally. The difference is explained at the bottom of the "Add Comment" form: "NOTE: The "Fixed Internally" resolution status means that the fix has been applied to a Linden Lab internal version, but is NOT in a public release of Second Life yet. "Fixed" means that the fix is confirmed public. Please do not reopen an issue unless you are sure what you are doing." Thank you Torley, I appreciate you are still on it and trying to get involved more for a better communication.
The majority understands it isn't your fault, that it is a management problem. People are better in complaining as giving a pad on the shoulder and even when I totally understand that things are developed at different branches, if it helps the communication process, please inform the management that the people would rather see a problem fixed before something else is released for beta. Like I said i understand the different branches issue and that the left hand doesn't know what the right hand is doing but thats what the management is for that ties these things together. Probably just crazy talk but here is an idea to avoid a rolling restart, how about the maintenance branch uploads the fixed code on the servers and sim owners can initiate the restart by themselves? Is that too out of the box? this is not6 fixed. so leave it open till it is fixed. you mislead people by closing massive incredible defects before the fix is deployed.
if you mistakenly think you rolled out a fix you are sadly mistaken. by the way, judging from admissions above, there seems to be no software engineering management at LL. this is a programming 101 error and to allow code branches to be plopped in without any serious SQA is unacceptable. hire a development manager. i used to be one. and i fired the showstopper that caused most of the problems. the one primadonna that swore he could not be fired or the entire project would fail. we shipped in 2 weeks. corncob removal is a beautiful thing. sorry about that. but fixed internally is not a good status for this type of issue since there are so many "fixed internally" defects that are forgotten and never deployed.
i set it back to fixed internally. someone of authority needs to micromanage this into a release immediately as many merchants are unknowingly losing money. in addition someone of authority needs to step away from shinies and show up in here and explain exactly how this was allowed to happen and exactly what code review and source version management systems and policies, including mandatory termination for disregarding said policies, have been implemented to prevent future recurrences of mismanaged source code. many of us have long made comments regarding the defects that get fixed and then show back up. this source code version control issue is not new. Ann, and others. It has been identified that the "Fixed Internally" in combination with "Resolved" is not good because people misunderstand it. This is being addressed in
As for managing those issues, there is definitely room for improvement. I don't know what LL will do internally to address this, but I doubt we will be informed in details. The public jira can take a certain part in it. A good definition (short, clear, easily accessible) of what a showstopper is would be a start (and definitions for other levels would be just a link from there!). This would make it easier for all of us to lower the level of the issues that do not deserve it. On the other hand, an issue like this one does deserve a showstopper priority. My definition of a showstopper is not that every Linden employee needs to stop doing what he/she is doing because of that, but it does mean that the next viewer or server should not (to the best of everyone's effort) be deployed without fixing AND merging such an issue. The other part is keeping the "pending" list accurate. The right thing would be to move all the issues with fixes included in a released version to a "Verification" state, which either submitters or the community would close once it is clear that the issue is indeed resolved (giving it a couple of days). As part of this, I thought that it would be easier for the submitters to help here if they would receive email notifications. That is why I was mentioning Let's keep this issue "Fixed Internally" to accurately reflect internal status.
I agree "Fixed Internally" is confusing and think it should be an "intermediate" stage rather than a perceived final one. From my perspective, it's wasteful to have to reopen a "Fixed Internally" issue and then set it to "Fixed" when it IS fixed publicly. (Context in http://wiki.secondlife.com/wiki/User:Torley_Linden/New_release_checklist @Istephanija: Thanks; I'll reassure you that it isn't so much a "management" problem as a "miscommunication" problem where Release Team didn't know in advance about how important this was, and it could've made it into 1.18.6. No one in particular's to blame; I (this is my opinion and not all of LL's) feel we need more Lindens responsible for keeping an eye on things (related, WEB-401). Seraph Linden, who's been working the onboarding process for developers, has also improved our internal documentation about checking in critical bugs directly into release (not maintenance). If I had known this was going to be delayed, I would've blown the whistle, as I'm sure any Linden would've. Also re: "maintenance branch uploads the fixed code on the servers", unfortunately not possible this time because the specific maintenance branch w/other fixes involves a viewer update too (hence why I mentioned 1.18.6 earlier), and was "locked" pending Quality Assurance testing (someone from Release Team could explain better as to why & how). In the past for some server-side-only Showstoppers, we have deployed code live that required a rolling restart – of course, estate owners are able to delay that for an hour with a button in Region/Estate tools > Debug tab. This pressing issue is currently in Quality Assurance phase. I know how many of you (and myself) are anxious, and for the curious, this is the test plan we're using to verify that this is fixed: SALE INFO UPDATE ON MULTIPLE OBJECTS SALE INFO UPDATE ON SINGLE OBJECT On an additional note, we do have a lot of details about our release process here: http://wiki.secondlife.com/wiki/Source_branches Thanx for keeping us posted Torley
the 3 test plans are correct just in case you wanted to be reassured It seems the inventory/properties/change multiple items has caused the bug, well.. if it works both ways it's gonna be pretty neat. It also would be neat if we could batch rename, do batch descriptions that would help to optimize for the search engine! Torley: regarding "SALE INFO UPDATE ON MULTIPLE OBJECTS".
Is it REALLY a good idea to be able to make bulk changes on coalesced objects like that? What other changes on multiple coalesced objects are now implemented? In the past I have changed the name of these objects and only changed the name of the object the coalesced object's name was taken from... and I thought even changing that much was a bit dodgy. Was this the change that caused this problem to pop up? I think it would be much simpler and safer to treat coalesced objects as an opaque object, and not allow any changes on the underlying objects. It's just too hard to tell what's going on otherwise. Hi Torley, did you miss my comments already? lol
We have learned from you that things at Linden Labs have to run over a couple of desktops before the get released. These test you were talking about can be executed in approximately 1 minute if one isn't too experienced in world approx. 2 minutes! You have acknowledged that it this was a VERY SERIOUS BUG! You have told us that there is some sort of miscommunication between the different branches, you have been kind enough to show us how things in SL work.... but you know life is a bitch and all that counts are results and bottom line nothing has changed for us! Torley it is NOT fair that Linden Labs lets use loose money big time, it is not fair to the mall owners that renting has become a pain in the a** and we all cut back on new spots. I predicted 6 weeks ago what will happen and at least 8 malls that I know have closed because they couldn't pay the tier anymore! It has started to affect peoples RL incomes, 4 mall owners i know are broke now in RL and all that because some people can't do their job right! When this bug appeared the first time I honestly believed it would be fixed within a couple of days, thank got i didn't place a bet. It is 6 weeks now, and someone in charge is avoiding to deal with it! It is frigging Christmas Seasons and we are supposed to be out there and sell, the point is that we can't like we want to and we are all loosing money. Maybe you want to join me for Christmas Dinner and explain to my son why he didn't get the gift which he was begging Santa for in his cute little letter. Use your turtle powers and get the people to move their butts, it is totally unacceptable and you know that as good as we do! This possibly needs to be reopened.
I just had some stuff I rezzed multiple become set not only for sale at the same price, but all set to "sell contents" including the stuff that had been "sell copy". The tests Torley just listed wouldn't check that case. Has this aspect of the bug also been fixed? @Argent: Lindens earlier got into a LOT of internal design discussion about "coalesced objects" and their un-intuitiveness. There are related features/bugs-to-fix that would improve usability, but some of them are non-trivial to do and would take a lot of work. Also, I don't know if this
@Sera: I share your sadness. @Istephanija: I didn't forget your comments, and I sympathize. I don't think it's accurate to say "we are all loosing money" and can you please shed more light on why renting has become so difficult? The relationship between that and this bug isn't clear to me. What I would recommend here is letting friends and fellow mall owners know to check their transaction logs, inspect their content, and not to set prices in a way that would result in this bug – proactive education is VERY important until it can be fixed. Torley: the biggest problem I have is that when a mall gets reorganized or when you need to move a display the natural way to do it is to take it and re-rez it. In one case the sim was completely redone so there wasn't the option of using any combination of edit moves to get my stuff from one part to another.
The other thing is that I did check and update the prices, I didn't check what was for sale... I had no reason to. Hi Torley,
i am taking the liberty to quote you and answer underneath: please read it carefully coz it has been explained already 10+ times in this thread. It is important that you as our interface to the gods in the background REALLY understands whats going on. Torley Linden: Answer: My average rentals are between 40 to 75 prims, let's assume for a moment the average prim count is 50. The most of us in this thread would head out and rent at all 10 to 15 malls for 2 weeks and sees how it goes. That brings a lot of followers, for once we share our LMs with our friends andy they share it with their friends etc.. usually a mall fills up within a couple of hours! THE PROBLEM NOW is that I simply don't have the time to rezz 50 prims and put in the prizes individually, we all have optimized our businesses before, "rezz and go" most shops are similar so it was easy to just rezz a copy of what i have setup an hour ago somewhere else. NOT NOW, we have to do everything from the scratch, I am watching people rezzing prims individually. However before i needed 5 to 10 minutes to rezz my shops including backdrops and decorations and now i need 20 minutes. Take this times 15 and you got 300 minutes a day which equals 5 hours. 5 Hours of my time where i cant design something new take care of my land, work on my marketing, my displays and especially update my older shops (i have 162 shops) BOTTOMLINE is that ANYONE is not renting as much as before which means we all loosing potential income, i don't share my LMs when I don't rent and the mall owner doesn't get his mall filled within a few hours, it usually stays empty and closes after a few weeks. It is just a natural reaction on the situation and more and more people started caring about their main stores, stopped renting entirely and started using the the saved up rental money on classified ads. I recently moved my mainstore which means i had to change my landmarks in all my boxes and landmark givers, it would have been easier to re rezz all my shops instead of deleting old LMs and replacing them with new ones from 6000 boards. It would be way easier to re rezz my shops to make them all search engine compatible instead of entering descriptions and enabling "show in search" on each prim i ever rezzed. It is a major pain in the ass to setup each prim individually. From 15 invites i probably rent at 2 or 3 a day which means i am loosing out on 12 business opportunities a day, today it is the 37th day my business is affected from that bug which means i have lost 444 opportunities to make a revenue. I think it is fair to assume i am loosing money and it is even easier to see how 400+ Mall owners have lost business over that bug. "Torley Linden:
I don't think it's accurate to say "we are all loosing money" " Excuse me? What hubris. I have been waiting to launch three simultaneous storefronts since this happened and I haven't been able to because between all three I would have several hundred boxes to price and set sale accordingly, instead of taking a copy to inventory and rezzing it where I want, three times. I'm happy that this is of no consequence to you, though. Six weeks now. Absolutely amazing. "I don't think it's accurate to say "we are all loosing money" and can you please shed more light on why renting has become so difficult? The relationship between that and this bug isn't clear to me. "
Torley: Any one who sets up shops using individual prims is loosing money from this bug. I get several mall invites a day and I used to jump on them when they came in. now I don't jump on them as fast because I have a back log of shops to set up that I have rented but have not set up because setting up a shop takes so long. So not only have I been slowed down but I have shops I have rented that are empty which equals lost money. You check for your self how long would it take you to price 50 - 100 prims then multiply that by 4-5 a day and you see our problem. Now I can see an argument to my problem above and that is to work harder. The problem here is this bug was reported as soon as it was detected and it was labeled a show stopper and it has gotten tons of attention here in the Jira. SO I am many others have been holding out from setting up shops and not being as aggressive as we normally would be if this bug had not happened. We all hoped that this bug will be fixed publicly fairly fast since it was an update that broke it in the first place. So not to be totally negative here in my comments, I have to give props to Linden Lab there are few if any software companies that would act as fast as Linden Lab has on this and many other issues. Even though it's not publicly fixed yet "the bug" is fixed internally and will be implemented publicly in time. If this same type of thing happened in any other type of program or software it would be many months before a fix was put in place. Thanks for the continued feedback and explanations to clarify – this is also important to remember in the future, because we (and I personally) certainly don't want this happening again. :\
I'll continue to let you know what I hear back. Merry Xmas everyone, here a little poem for you all
I cheated on a test today, And now I'm in detention! This issue has been bulk changed to fix pending.
dot dot dot...still waiting to:
Reorganize my 1500 boxes and store Update more than 30 mall shops Clean up my work area of all new creations since this bug Its impossible to do these jobs and NOT make pricing errors. This bug has thrown off my entire process of packing and selling items. Its the worst inconvenience and has cost me so much $. Im not renting mall shops, Im not updating mall shops very much because it takes like 1-2 hours for each shop to be done prim by prim, and Ive missed price errored boxes only to find out after selling the packs at single prices...Its ridiculous, its been weeks and weeks!! Please fix this. I understand it takes time, but not weeks..months...This BUG Severely impacts mine and hundreds to thousands of content creators. ... still waiting... I use boxes like many others and I have just lost all incentive to open new stores. My stores run usually between 100-200 prim and I just don't have the time to reprice. I found a whole wall priced at 0 yesterday due to an IM from a customer. My own fault as I should have remembered to check.. Being in a hurry all the time has its downside.
Thanks to everyone who has been pushing this with the Lindens. Hope it gets solved soon. There needs to be greater awareness of this issue for vendors, and I hope it can be fixed soon.
I agree there should be more awareness for all involved. I hope it is fixed soon also
There are some server side fixes planned for Jan 2nd. Will this be included? If not, we will be close to 2 MONTHS without a fix for this issue.
2 months! Having it "fixed internally" really doesnt help us With January 2nd being my birthday, the bug being fixed, would be an awesome day!!
Another Bug, thats a shock tick tock said the clock a fix before week eight though its late would really be great! A little Humor through my tear stained cheeks, please LL Fix this externally so we may all clean up the mess it's created and move onward!! And, BTW, can we change the priority from "SHOWSTOPPER" to "Pointless" ? since that is what it is.
seriously. Also having Torley in here apologizing and promising more information falls into the same category. .. since there has been NO new information provided yet. at all. And just to make sure the above information was passed on correctly. THE TEST PLAN SHOULD INCLUDE OBJECTS THAT HAVE NOT BEEN FOR SALE BEFORE! Like, not only: create Object A for 10L and Object B for 100 .. select both .. take to inventory and re rez and both have the price of the last selected object. No. More like: create Object A for 10L and Object B for 100L and Object C NOT FOR SALE AT ALL .. select all objects and make sure that object A is selected last .. take to inventory and re rez and tadaa . Object C is now for sale at10L! :O Same goes for if you select object C last .. then all of a sudden NO OBJECTS ARE FOR SALE !! This can make a mall shop setup look really silly. Yes, this has been posted already .. I just try to make sure it has been noted. .. I mean .. if any linden is still reading this. What? me? .. bitter? .. nooo! ... why? It looks as though when we log in on Jan 2 we will find out if it is fixed since nobody will give us an answer.
Does LL just want us to have to work harder for the $ we make? Are they sitting back and laughing at us? I feel spit on, stepped on, and oh ya crapped on. Good or bad they should give us the courtesy of a reply. Id rather just know even if it is bad. Happy Birthday Julia, sending you lots of virtual Sugar Pops
 In the meantime i find this issue hysterical, the way it wasn't understood the way it is "handled" and the way we get misle## with cute Linden Lingo (show stopper, internally fixed, fixed pending, WE CARE) and patronizing .....and when there was no way left to patronize us they stay in silent mode! It is their game and their rules, they are god and we are ants, there has been made a schedule once and now they working it off and when all this stuff is done then someone will take care of this! You could travel back with a time machine and tell them a day before they deploy the bug what it will cause, they wouldn't stop the train from crashing into the wall. All you can do is to accept THEIR RULES and not waste your precious energy and don't loose your spirit over that crap. I'm sorry this has dragged on – I was waiting for news to update you, and this fix will be in Second Life 1.19. Our Release Team will post about it on http://blog.secondlife.com
when there's a committed date, as they have for previous versions. Thanks for your continued patience. Thank you Istephanija, No more time to waste waiting... Happy New Year Everyone!!
[UPDATE] http://blog.secondlife.com/2008/01/28/second-life-server-code-upgrade-tue-jan-29/
On Tuesday, January 29, (10:30 AM - 12:00 PM) we will be upgrading the code running on our central second life servers. This will mainly add stability fixes and set the stage for upcoming new features. It will also include fixes for the following issues:
SVC-1039: llResetScript() from a state without a touch_start handler does not re-enable touch in default state We do not expect any service interruption during the upgrade, and we will be following it up with a rolling restart of most Second Life regions on Wednesday, January 30th. Restarts are expected to begin around 2:30 PM and take approximately 5 hours. Watch this space for progress reports Hello seems to have not been fixed yesterday was there a delay? please update.
Still broken...
Still waiting. I can't say I've been more concerned about any other Jira issue more than this one. What's up? It's been nearly three months. Tested with 3 prims, 1 set for sale at 0, the others at 10. Choosing the 0 as the last in the coalesced object sets all to 0. Tested with 3 prims, 1 not for sale, the others for sale at 10. Choosing the not for sale as the last in the coalesced object sets all to not for sale. I really give up.
It's been three months for a fix on something that should have been corrected immediately. Which still hasn't been. I expect to log in one day six months from now and discover it's fixed, and replaced with a bug that does something horrible like dispense what's sold with full permissions. Keep us on our toes. When I read the blog message on this I read:
"We do not expect any service interruption during the upgrade, and we will be following it up with a rolling restart of most Second Life regions on Wednesday, January 30th. Restarts are expected to begin around 2:30 PM and take approximately 5 hours." Means: The new server code with the fixes was rolled out yesterday and we can expect the rolling restart for today (01/30/2008) starting at 2:30pm. The restart will take about 5 hours. This means: you can not expect it to be fixed before 7:30pm on 01/30/2008 - correct? ==> read the announcements completely, read them again, try to understand them ... stop whining and relax Then maybe they should be more clear regarding things like this. If it won't take effect until the restarts are done, then that's fine, but it shouldn't be difficult to just say that clearly without us needing to read between the lines. A great many of us are artists, not server techs.
""""""stop whining and relax "When I read the blog message on this I read:
"We do not expect any service interruption during the upgrade, and we will be following it up with a rolling restart of most Second Life regions on Wednesday, January 30th. Restarts are expected to begin around 2:30 PM and take approximately 5 hours." Means: The new server code with the fixes was rolled out yesterday and we can expect the rolling restart for today (01/30/2008) starting at 2:30pm. The restart will take about 5 hours. This means: you can not expect it to be fixed before 7:30pm on 01/30/2008 - correct? ==> read the announcements completely, read them again, try to understand them ... stop whining and relax Actually no, that isn't what it means, so your interpretation is meaningless and your attitude unnecessary. This has been an issue for three months now, every business person affected by it is very much entitled to be as upset as we are, which is something to be commended given how patient we've all been. Just tested this a region that has had its rolling restart. Turns out BlckCobra's interpretation was correct, after a region gets it rolling restart and is on server version 1.19.0.78817 this is indeed fixed.
Changing back to Fix Pending since 1.19 is being rolled back.
3 months to fix this bug and reinstalling it with a new one!
Now the SHOW IN SEARCH function is broken rezz a box, click show in search, leave edit mode and return to edit mode and see that making changes on the show in search function can't be modified anymore! THAT'S JUST SURREAL! Well, we all knew that something had to give, didn't we?
And yes, she is right. It's broken. Yea totally awesome new bug huh!!! We "WERE" getting ready to reopen a new store.. but can't now or we will be NO where on searching redoing all our items for sale .. ( no search) HOW NICE!!!!!!!!
yes SURREAL! Hey thats name one our tats Steph! hahahha Has someone created a new Jira issue for the new bug? If so can it be linked so those of us who haven't voted on it yet can do so?
Nor more troubles for 2 monthes. I close.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Showstopper
Prims set for sale - prices are incorrectly set when multiple prims taken to inventory and rezzed
