Sassy Romano

Well on the other hand, your response is ill conceived and lacks technical merit. I've not looked at the data but there's no reason to prevent secure transport of messages from SL client to servers and onwards to clients. LL would still have MITM capability to intercept and log, just that there's no reason to NOT have clear text messages from the SL client on the local network or anywhere in between other than in the SL client to SL server environment. Is that something you don't understand because if it is, i'll be happy to explain further? I won't even begin to dispel the "nothing to hide" argument or "for the sake of the children/criminals/etc." that's a very VERY naive stance but lets just stick to how things *should* be... I do however agree with you though that there are other actors to be more concerned about than random 3rd parties, that said, governments have no right to invade privacy of law abiding citizens - EVER!

There are script functions that can interrogate objects so yes, don't know any off hand but if you just list your worn item, remove each in turn. You are clearly STILL wearing an attachment(s) that has scripts.

Indeed. They could rez prims in a coded layout for example.

Some TPV's used to have end to end encryption but LL banned it as the LL viewer didn't have it and thus it didn't meet the shared experience. I think LL understand "shared" to mean giving everyone everything, including governments who have no claim to it. (It might have been removed for a different reason, I forget but whatever, LL have NO interest or best practice approach to security with regard to their customers - period!) Create a JIRA for the feature request, they can't ignore it properly until you ask for it.

Something for LL to factor into their workstream

Ultra

Upload your original work for L$10 Sell it for L$11 = Profit

I don't agree that no customer service needed after a sale is the best. That just means that the product worked as described. There's plenty of opportunity for enhancements but feature requests should be entered into the JIRA system so that they can be triaged and ignored in favour of faffing around with other elements that aren't requested by those who should be the major stakeholders. Have you learned nothing yet about how this place works Magnet?

Ok CTL well you had my "general feedback" - I did a search and got results. No way to know if the result set was better or worse than it should have been but lets just look at the blog post for a moment and highlight something from that post:- "We are still working on an important feature, which will allow you to exclude keywords (such as “demo”) from your search - but want to get this into your hands now and get your feedback! " We shouldn't have to exclude demos from search results - EVER! If we have to rely on that sort of mechanism, just like keywords it will always be subject to abuse. Just giving us boolean NOT will not work. DEMO, D*E*M*O, D-Emo etc. let alone different languages. A demo product within MP ALWAYS has a relationship to a parent listing, you should be able to easily enough determine which listings have a linked parent and just exclude them from the result set. Done. No faffing about with requiring the user to figure out which magical method they need to use to not see something. I am curious about something though, same thing as before. Who are your stakeholders in this work and what are you looking to solve, from a business perspective? This work is aimed at:- Improving relevance - can't see much difference, I got a result set from search. You see "relevance" is just too fluffy, relevant to whom? based upon what? Maybe if I could weight my keywords based upon what I felt was more relevant and important then yes but if you're deciding what's relevant to me then you'll usually fail - per the other sentiments of this post! Improving scaling for more content and categories - are we seeing a problem with this at present? Fine if it's for future but we can't hope to test that today. So basically, given all the other things that have been brought up over and over again by merchants, who picked this stuff that isn't at the top of the list of really important things that are problems that need fixing? I get the impression that Linden Lab is just a big sandbox for a group of developers to mush code around in, under the guise of project work but without actually being required to focus on the main things that affect people.

Chinrey... Actually yes the Commerce Team do talk about the new things, the issue is that they don't really do anything new and haven't for a long time. VMM is just the final phase of Direct Delivery which was a self inflicted reason to do something in the first place. As for improvements to communications, the bar is so low, an improvement is achieved the moment a Linden says "Hi" Anyway, I have nothing else for this thread. It was pointless beyond the first post.

polysail wrote: That being said~ I'm still gravely concerned that this will be implemented ~ as I've voiced prior. But starting a flame riot on the forums is just going to lose the meaningful feedback in a soup of anger. The thing is, there's NO POINT trying this out because we don't know what has changed, what the objectives are or what the supposed outcome is intended to be. You search, you get results...that's all we can do. As for whether it will be implemented, we won't even know because stuff will just happen and whether it's right or wrong we can't easily determine.

Again, for the 3rd time, start at 20 and just go up in 20's. A 20ms yield may be enough, if it still runs hot, try more and just get to a point where you're happy. 100ms Yeild may be too much but it will run cool. There's no harm that will occur, it will just be a slower viewer experience the higher the number but the laptop will be cool. This is assuming that there's no problem with the fans and that this isn't attempting to address the wrong problem.

It might have been set to -1 yes? That just meant "don't yield processor time" Just use positive values, start at 20 and go up in 20's. This will make SL viewer more sluggish the higher you go but if your laptop fans are not obstructed and all else is normal, your choice is either a slightly slower SL or a cooked laptop. Your choice!

http://wiki.secondlife.com/wiki/Debug_Settings

Not an animation. Try looking for a particle script or particle generator.

Because SL drives it hard. To avoid cooking your laptop, go into the viewer debug settings and set YieldTime to something between 20 to 100. Try lower value first. Also, if the frame rate is high, use Firestorm viewer and limit the display frame rate. It's must likely the first solution.

and precisely what is it that we're supposed to be experiencing or testing here that would make any test or response actually have any value? What has changed, what does this beta offer? I see NO visual difference with regard to input filters, no expressions, certainly no ability to filter on any of the most obvious such as the MESH flag that we fill in in product listings, no filtering on "works with " avatar types or brands etc. I'm confused, this is a meaningless offer of something that is undocumented and undescribed. The JIRA has no value here because I cannot know what a bug is because I don't know what is supposed to work, don't know the functional specification... cannot flag exceptions to this specification! What are the test cases that you would expect us to be using here exactly? Let me ask it another way just in case my post isn't clear:- What business problem are you trying to solve here? Ok, i'll try to sound positive... "I entered a couple of keywords and got results back". Test passed - success! Another complete project. Yay.

Yes language is fluid but let's not resort to neologisms due to not knowing better or mimicking someone else who knows no better.

You could upload the texture and apply them. Local textures are transient by design.

Pick a tutorial, download matching versions of blender and Avastar. That might be a good starting point.

Not in Oxford English dictionary and I know it means a performer but it remains a made up misused word now touted inappropriately in tech circles because someone somewhere thought it sounded neat. I suspect the same person insured they got payed each month but wouldn't know why that was wrong either.

The object is not as the owner of the product wants it. It belongs to them, not you. You have the money thus that part of the transaction is complete. This false pride is worthless because at the point that they can not use it as they choose, it sits in inventory and NOBODY sees that glorious texture exhibited by this product owner. That aside, this was not about changing texture anyway so please, do list the many other reasons for making an item no mod, not including the couple of reasons already cited by Suki. Those reasons are valid. Not done yet.

Dear LL spokesperson... "performant " NO SUCH WORD! Stop using made up words or using words that someone else has also incorrectly made up and been passed along during sprint meetings.

An interesting exercise in comprehension. Nowhere in the original post did it say that the issue was with a purchased dress, it *could* have been an issue identified with a demo. However, that aside, the demo would not necessarily have elicited the same issue because some demos slap on a "DEMO" texture which does not reprepsent the actual texture at all. Moot point though really because... Back to Suki's point, "just make the stuff modify permission and grow up". Pretty fair really.

Applier's just send a texture to a mesh layer but what you're describing sounds like it would be a strange result. Wouldn't you rather just try to find a jacket that fits over everything, like how a jacket ought to look? I'm struggling to imagine how a jacket with sticking through painted boobs would look.