Jump to content
Sign in to follow this  
Pamela Galli

Thoughts on the new proposal?

Recommended Posts

Thanks for keeping us in the loop.  It's nice someone can be bothered doing the job the Commerce Team are paid to do.

 

The proposal is a significant improvement.  I see no reason why IMs about returned items should be forced on us if something is returned to us. There is no reason other than laxness for LL to not make this an optional setting in the viewer.

 

Share this post


Link to post
Share on other sites

A significant improvement. However I'd like the option of being able to drop things in world from Recievedr.  It would be a lot more convient to open boxes first before sorting to other folders.

The IM's should be something you can set in preferences if poosible as I can see where some may like the feature while others don't.

Share this post


Link to post
Share on other sites


Anaiya Arnold wrote:

Thanks for keeping us in the loop.  It's nice someone can be bothered doing the job the Commerce Team are paid to do.

:matte-motes-big-grin-squint:

I don't see the advantage of getting all and everything in my received items folder. I don't see the problem with the current system where notecards come in the notecard folder, scripts in the scripts, textures in the textures and so on.

Why mess up the current system, for what purpose? What problem does it solve? None, for me, it will only give me extra work. Why must I drag all received things by hand to the folder where they belong?

My most important question is: will I be able to answer a notecard that is in the received items folder? Or must every single customer request for support be dragged into my notecard folder first to be able to answer it? I fear the latest will be the case.

Share this post


Link to post
Share on other sites

That was my thinking, Maddie -- wanted to know if I was missing something.

 

Bottom line: Do not give me any more chores. My inventory is enough work as it is.

 

My guess: they can't figure out a way for only Marketplace items to go to the folder.

Share this post


Link to post
Share on other sites

It's an improvement (modest) - objects rezzed or built going to their original files or object folder (as they do now). I'm disappointed that notecards, landmarks, etc are still headed into the Received Items folder. It does seem that there is some kind of difficulty coding just MP purchases to go to this folder as was originally discussed.

 

ETA - the more I think about it, I'd rather the current system just be kept. Deliveries from MP going to Objects folder, and everything else just going where it's always gone. I just don't see what advantage this new folder is providing.

Share this post


Link to post
Share on other sites

 


Madeliefste Oh wrote:

My most important question is: will I be able to answer a notecard that is in the received items folder? Or must every single customer request for support be dragged into my notecard folder first to be able to answer it? I fear the latest will be the case.

OH I didn't think of that. 


Yeah that too

Share this post


Link to post
Share on other sites

My guess is it has to do with some sort of technology with servers. I think they are trying to make the system lighter, and for that the way how, (or the place where), the inventories in are stored must change somehow.

I don't know much about technology, so for me it is hard to understand how the inventory works now anyway. I know it works with the asset server, but what this actually means, no idea. Now cloud computing seems to be hot. So maybe they are working on that, put all inventory items in a cloud. And it is probably too much demand from the system to let this cloud split up items again in different folders in everybodies inventory. Or maybe it is just cheaper to deliver all at the same folder, and let the residents do the hard work of sorting it out again.

Share this post


Link to post
Share on other sites


Pamela Galli wrote:

That was my thinking, Maddie -- wanted to know if I was missing something.

 

Bottom line:
Do not give me any more chores. My inventory is enough work as it is.

 

My guess: they can't figure out a way for only Marketplace items to go to the folder.

I got the notecard with the links also and when I read through it and discovered that I would have to move everything to their proper places before I could rez them, read them, whatever...this was my first thought too.  I filled out the survey again and told them that notecards, textures, scripts, etc. all need to go to the correct folders and bypass the received items folder all together.

But, reading through others responses in this thread, I'm starting to think the same thing.  There's something in the coding that's preventing that from happening.  

I'm glad that they are fixing the problem with objects not arriving if your messages are capped!  That's a plus fer sure!

Share this post


Link to post
Share on other sites

My sleepy response:

 

As a concept it has merit.  Resolving capping on object send is something that should have been done years ago anyway. 

The issue that I have is that it vastly increases the workload just to shuffle inventory.


With reference to being sent an IM for items returned to lost and found, we already get a message.  Will this proposed *new* IM be per object?  That would be horrible when a lot of content is returned and then immediately causes IM capping for those who don't send to email and for those who DO send to email, I do NOT want 15,000 emails when a sim is returned!


Where does "buy object content" go to when it's a prim with content for sale?


Does the "Resident to resident" proposed cap include "Object owned by Resident"?  I presume that it does but it's not explicitly defined.


I'd like filters that automatically redirect


I still don't see why this is a dumping ground for everything?  Why not put notecards into notecards, snapshots into snapshots and so on? Why is every login to be turned into an inventory management chore?


The question STILL remains, WHO asked for this, it's not the fee paying customer!

Share this post


Link to post
Share on other sites

It is great that things will be automatically received but the special drop space is clunky imo.  Items should just fall into objects folder (best) or a inventory received folder (fallback) and not require multiple steps.  I have same issue with the LL viewer, while the new beta is certainly better, everything takes more clicks to do or get to, more hunting or work.

Share this post


Link to post
Share on other sites


Sassy Romano wrote:

Where does "buy object content" go to when it's a prim with content for sale?

 

I just logged into Aditi to test this.  I put a bunch of items (including textures) into a box and set it for sale.  Then, purchased it.  The system created a folder in my regular inventory (not my received items) named what the box was named and put everything inside that. 

It was a separate folder in the inventory though.  Not a sub-folder and it was not in the Objects folder. 

Share this post


Link to post
Share on other sites


Pamela Galli wrote:

They do get points for inquiring, tho.

(But those points can be taken back!)

I agree!  But, if my suspicions are correct...this is the final production model they are proposing.  I doubt they will postpone Direct Delivery until they can satisfy all of us with this received items folder (which I'm not sure they can do).  They have expended too much time and effort getting it ready.  So...I suspect this is how it will roll out.  Whether we like the received items folder or not.  

I hope I'm wrong.  But I doubt I am.

Share this post


Link to post
Share on other sites

    * NO CHANGE FROM CURRENT BEHAVIOR: Take or take copy will go to the folder it came from. If the folder does not exist in the current user’s inventory, the item will go the Objects folder

Take copy does NOT currently go to folder it came from - is this changing or not?


    * MINOR CHANGE FROM CURRENT BEHAVIOR: Items returned to a user’s inventory will go to the user’s Lost and Found folder AND an IM will be sent to alert the user (the IM is new)

We already get an IM about this - is this a change or not?


    * In order to make it harder to end up with a really big Received Items folder (and easier to move things out of the folder), the following changes are proposed:
          * The Received Items pane will become a new floater which supports search (and possibly sort)


Unless it can sort by newest first it will be a nightmare


          * Objects cannot be rezzed from the Received Items folder (will require users to move objects to inventory to use them)


This seems awfully clunky - wouldn't be so bad if just for MP deliveries - but messy if everything else is going there. Does the size of the folder really matter?

And what about notecards, for example - can they be opened? I get tons of NCs/textures from group notices/scripted deliveries - currently they open automatically on acceptance - i can glance over them then decide to keep or not. If this changes I either won't read most of what i'm sent, or i have to go and move the thing then click to open it - very time consuming.


          * Drag and drop OUT of the Received Items folder is allowed but not INTO the Received Items folder


Why?? Who'd want  to add stuff there anyway?


    * In order to prevent griefing, we are proposing a Resident to Resident limit of N deliveries per hour. Feel free to provide feedback on what this value should be.

There's no number you can safely pick . There are instances where someone would actually want 100+ items sent in a short time, yet for most ppl that's a griefer level of spam. And btw resident to resident is not your major concern.

 

Saving offline deliveries is good.

Using this folder for everything else, then adding impractical limitations to it is bad.

Confusion re current inworld inventory processes is disconcerting.

Share this post


Link to post
Share on other sites


Marcus Hancroft wrote:


Pamela Galli wrote:

They do get points for inquiring, tho.

(But those points can be taken back!)

I agree!  But, if my suspicions are correct...this is the final production model they are proposing.  I doubt they will postpone Direct Delivery until they can satisfy all of us with this received items folder (which I'm not sure they can do).  They have expended too much time and effort getting it ready.  So...I suspect this is how it will roll out.  Whether we like the received items folder or not.  

I hope I'm wrong.  But I doubt I am.

I agree that this is likely what we will be given even though yet again, NOBODY asked for this.  Show us the results of the study group that asked for this please...

Yet again, Received Items is for some stuff but not all stuff and that inconsistency with regard to "something someone buys" will cause confusion.

Share this post


Link to post
Share on other sites

All excellent points and questions, Miss Zanara.  I wish I knew all the answers.  I'll bet you money though that this is exactly how Direct Delivery and the Received Items folder roll out.

Share this post


Link to post
Share on other sites

Madeliefste Oh wrote:
:matte-motes-big-grin-squint:

I don't see the advantage of getting all and everything in my received items folder. I don't see the problem with the current system where notecards come in the notecard folder, scripts in the scripts, textures in the textures and so on.

Why mess up the current system, for what purpose? What problem does it solve? None, for me, it will only give me extra work. Why must I drag all received things by hand to the folder where they belong?

My most important question is: will I be able to answer a notecard that is in the received items folder? Or must every single customer request for support be dragged into my notecard folder first to be able to answer it? I fear the latest will be the case.


Good  post...that's the way i feel about it. I want my notecards to automatically go to my Notecards folder. I set filters on my "Recent Items" tab.....so that it effectively becomes my "To do " list. I don't want everything hitting the "Received" folder.....for many it will just end up like an over-bloated "Objects" folder over time!

Share this post


Link to post
Share on other sites

LL .. STOP... GO AWAY... IN THE PRESENT FORM YOU BREAK RLV SCRIPTED ITEMS THAT GIVE INVENTORY TO THE #RLV FOLDER.

Nobody asked for these changes, don't continue with this relentless program recently of breaking things without thinking it through, better than this, please STOP thinking because your thinking IS dysfunctional.

You don't use your own platform, WE, the paying customer does.  WE are the major stakeholder, we know what we want but we don't get even the simple little things, you do NOT know what we want, that much is clear.

Seriously, this is dysfunctional project management behaviour and should cease.

I'll ask again, please present the study results that show clear and compelling demand from users for all these features that so far people have expressed push back on.

Share this post


Link to post
Share on other sites

Sassy,

The existing script functions llGiveInventory and llGiveInventoryList cannot designate the destination folder for any items given. It is a function of the Viewer (either an RLV-only or a TPV with RLV enabled) to detect an incoming item and place it into the existing #RLV folder. Thus my bet is that, at most, it will take a tiny bit of coding in the viewer side to look in the Received Items folder and move the new item itself.

Even if llGiveInventoryList is used with a folder name of "#RLV" designated, the Asset Server will create a new folder with that name rather than put inbound items into an existing folder.

(Caveat: I am not 100% clear on the inside workings of an RLV-enabled viewer, but I am very positive you cannot designate an existing folder as the destination for an inbound object.)

Share this post


Link to post
Share on other sites


Darrius Gothly wrote:

Sassy,

The existing script functions llGiveInventory and llGiveInventoryList cannot designate the destination folder for any items given. It is a function of the Viewer (either an RLV-only or a TPV with RLV enabled) to detect an incoming item and place it into the existing #RLV folder. Thus my bet is that, at most, it will take a tiny bit of coding in the viewer side to look in the Received Items folder and move the new item itself.

Even if llGiveInventoryList is used with a folder name of "#RLV" designated, the Asset Server will create a new folder with that name rather than put inbound items into an existing folder.

(Caveat: I am not 100% clear on the inside workings of an RLV-enabled viewer, but I am very positive you cannot designate an existing folder as the destination for an in
bound
object.)

They have already broken this on Bluesteel and LeTigre where this now appears to be live.

Kitty Barnett (RLVa developer) and I tried this on the first round when it was on Aditi, she hasn't done the JIRA yet but plans to.  I don't know the internal details either, Kitty is far better positioned than I to know what the issue will be but the impact is huge as right now, yet again, I and other RLV object creators have broken content, solely due to LL's meddling.

Any change WILL require that everyone who uses RLV must change viewer and that's only after they've all been updated which isn't an instant task.

Thanks LL, this was highlighted by me before, didn't listen... again.

Also, just to add to this, if it's simply that people need to update their viewer, they first of all need to KNOW that they need to update their viewer.

What is more likely is that they buy an RLV enabled product which has instructions as to expected behaviour, after all this has worked for years.  Now that behaviour is different, it doesn't work at all.  In the case of all my prime products, their set up will fail 100%.

At best, the customer will contact us for support, we then have to repeat over and over "Sorry, LL broke it for you" and deal with it.  Equally likely is the customer bins it and leaves a negative review on MP "Product does not work" and as we know, empirical evidence demonstrates that it's far beyond the skill set of LL to send an email notification when a review is left.

Simply put, it's a massive content breaker that has a huge impact on creators and merchants and their customers.  LL sits and shrugs while delivering something that nobody asked for.

Update:

Kitty's detailed response https://jira.secondlife.com/browse/SVC-7748

Share this post


Link to post
Share on other sites

LL get your heads out of your asses. NOT ONCE have you asked US the consumers what you should do. You implented these changes to STOP people from using TPV. Its stupid. You are supposed to be the forefront and you guys are so behind that you have to come up with this stupidity to MAKE everyone choose V2.X

Well guess what if those grid wide, I hope you realize that you will loose  A LOT oF PAYING CUSTOMERS!

So much for your bottomline. For even most of your premium accounts use a thrid party viewer. Why? Becasues yours Sucks donkey balls. Quit jacking with **bleep** that is already working just fine. You goof nuggets.

 

 

Share this post


Link to post
Share on other sites

Sassy, as I suspected, the Viewer itself is responsible for moving the objects / folder received into the proper #RLV folder when it detects the arrival of a specially tagged inventory offer. Because the Received Items folder functionality will be active for online users as well as offline, this is guaranteed to break any special functionality in the viewer of this nature. Thank you for supplying the JIRA link. As I mention in my comment on that JIRA, I believe the Received Items folder functionality should be used only for Marketplace purchases (as originally intended) and when the user is offline.

The main issue they are trying to solve is the loss of items delivered while the user is offline. Making Received Items the destination even when the user is online goes way beyond fixing the real problem ... and as the JIRA points out, breaks many other things that don't need breaking.

Again, thank you for pointing me to the JIRA.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...