Cain Maven

Having had a few hours to digest this, I've decided to postpone panic. It is perhaps mildly surprising -- at least the timing is -- as it seemed like Linden Research had ambitions for Tilia. On the other hand, maybe this was the exit strategy all along. On the third hand, maybe priorities no longer are what they were under the late Mr. Altberg. I suspect we will never know. Based on what little we do know, I don't see much reason for immediate concern. I think we can safely assume that Thunes know what they are getting into, including the adult contents. They are probably also aware that the Lindens have been more than hinting at embracing adult, er, experiences in The Near Future. I bet this side of SL is safe. That said, I do think it's odd that the Lab did not announce this themselves; only Thunes did. In cases like this, both parties usually send out press releases. Why the (pointless) silence?

This is excellent -- thank you very much!

I would prefer that they not request sensitive information via email. For very obvious reasons. They have a secure (one assumes and hopes) web form, which they could have directed me to in the first place, although they would have had to do some actual work first. And yes -- I have always reported all my SL income on my tax returns.

At the risk of flogging a deceased equine: Whether it's issued a K or a MISC or both is not really the root of my concern. The fact that Tilia requests sensitive information via email is -- and I personally think we should demand better from a company that touches so many of our livelihoods.

In fairness, the form under the Process Credit tab appears to be secure, and that's where I eventually submitted the information. But that's not what Tilia asked me to do.

Right -- having done this for a while now, I'm somewhat familiar with the various tax forms My issue is not with he issuance of the form but with the fact that Tilia requested sensitive information over email, which is a huge no-no.

Yes, I did contact support and they confirmed that the email was legitimate -- in the sense that it was actually sent by Tilia. Which never should have happened.

Today, I received an email from Linden Lab's payment processing company, Tilia. It said that I was "eligible" for a 1099-K form, but they did not have a Social Security Number on file. (For those of you outside the US, a 1099-K is a tax form issued when someone pays you more than a certain amount. The SSN is your personal identification number and therefore sensitive.) The message then went on to say: So that we may issue you your 1099-k form, please reply to this email with your full social security number. Yes. They actually requested that I send my SSN over email, security risk be damned. I examined the email headers, which looked fine (famous last words, I know) but I am obviously not prepared to email my SSN under any circumstances, so I replied to that effect. I also tried calling them, but there is no way of reaching an actual person. Tilia's response: For your security and to fulfill this request, we have reset your Know Your Customer application and ask that you re-submit your Identity Verification once more. This form is cleverly hidden on the Process Credit dashboard page, so I had to contact SL support to find it. Now that I have resubmitted the information -- and I'm positive I had provided it earlier -- Tilia seems to be content. However, I am not impressed. A company that deals with sensitive personal information such as real names, addresses and SSNs needs to have its security act together. Asking people to provide sensitive information via email is not good enough. Not by a long shot.

Looking good, sir

Maybe it just sounds better than "Purchase and Teleport"?

Free in the sense that there is no monetary fee to enter. As a builder and merchant, you knew that.

Can? Yes. Should? That's an open question, I think.

Which may not be seen as a Good Thing if you're a smaller resident-run event... or Leon Trotsky.

All fair and valid points -- although I do disagree with the notion that "residents are terrible at organizing"

Shop & Hop is free for creators (assuming you are selected to participate.) This gives the event a competitive advantage, since resident-run events typically charge a fee to cover cost and/or turn a profit. Linden Lab can also reach a large number of customers easily and cheaply.

RFL and its events aside, perhaps a bigger question is whether Linden Lab should run events at all? They are obviously competing directly with all resident-run events.

We can all speculate. My rule of thumb is that it's better that complexity is handled once on the back end than thousand of times in the client -- with varying degrees of success. But reasonable people can disagree.

Understood -- but in those rare cases an error (say NAK, heh) could be returned. This would be no different from other synchronous functions, and handling that edge case would probably not be any harder or more complex than the timout and error reporting you suggest; it may even be simpler.

I must be missing something here. If we call llGetNotecardLine(), the back end has to a) check if the notecard is in the cache, b) if not, fetch and cache it, and c) retrieve and return the requested line. Why can't llGetNotecardLineSync() do the same thing? If the notecard already is in the cache, great -- we get the speed advantage. If not, we're not going to be worse off than with the async flavor.

Sadly, I can imagine it... but it would be great to get clarity on this. I would also like a clear answer on which functions actually force the notecard to be cached.

Imagine that 😊

It seems like there's pretty much a consensus here: Yes, the speed gain is great, but it does need a lot of hand holding. It makes you wonder if this could have been approached differently -- although without knowing the internals of the caching system it's fairly pointless to speculate. Besides, there are a few other things that perhaps should have higher priority for the Lab

The new and wonderful llGetNotecardLineSync() function requires that the notecard is in the region's asset cache. Is there a way of ensuring this? For example, will calling llGetNumberOfNotecardLines() immediately before reading lines as in the published example do this? Also, is it possible that the notecard is removed from the cache while it is being read? Depending on how this all works, using this function may require a lot of checks and hand holding. The speed improvements are of course very welcome

Probably not in the cases that I've seen -- which don't seem to have anything in common, be it size, tri count, complexity, etc. Then again, I have no idea what really is driving this bug

Good point. I don't have an answer, except this behavior is not consistent. I have linksets where *most* objects return to their assigned shape type after motion ends, but not all. The issue has apparently already been reported; it would be great if LL could take a look at this.