Anna Salyx

I saw that behavior noted somewhere else and I believe it's recognized as a proper bug. I tried a quick search in my usual places for seeing things like that but came up blank. if I find it I'll update.

Had my testing alt create the same NC and give it to me with M/C/NT perms. Tested for the existence by name. Tried to get the UUID (failed because it's not full perm, but interestingly I did not get the expected shout on the debug channel) Still failed on the first Sync read before I did the async dataserver nudge.

Yes, I can/will confirm that in my testing, adding an uncached notecard to item inventory does NOT cause it to become cached. It takes direct call to a the dataserver version for it to be loaded into the cache. That was very consistent in my testing. The same with editing in place and creating a distinct change. and yes, my testing was fairly blind. Now, I could to some extra sanity checks into my test code to verify the existence of non blank NC and see if that makes a difference.

More testing. the code touch_start(integer total_number) { lineNo = 0; llOwnerSay((string)llGetUnixTime() + ": starting read of 1000 lines"); integer DO_LOOP = TRUE; while(DO_LOOP) { string result = llGetNotecardLineSync(ncName, lineNo); if (result == NAK) { llOwnerSay("notecard not ready at line: " + (string)lineNo ); llGetNotecardLine(ncName, lineNo); llSleep(1.0); } else if (result == EOF) { llOwnerSay((string)llGetUnixTime() + ": all NC lines Read"); DO_LOOP = FALSE; } else { ++lineNo; } } } The test card: Notecard consisted of 1000 lines. Each line reads: "Notecard test line 0000", and the number incremented to 999. The output: [18:05] Notecard Sync tester: 1706493914: starting read of 1000 lines [18:05] Notecard Sync tester: notecard not ready at line: 0 [18:05] Notecard Sync tester: 1706493916: all NC lines Read Second output with card firmly in the cache: [18:09] Notecard Sync tester: 1706494162: starting read of 1000 lines [18:09] Notecard Sync tester: 1706494163: all NC lines Read All this was with no parsing of the data. So, I did a final test so simulate processing the lines. So I took the result and edited the final else to do some work of storing the result into the LSD store. llStringTrim(result, STRING_TRIM); string lsDP = llGetSubString(result, -3, -1); llLinksetDataWrite(lsDP, result); ++lineNo; [18:16] Notecard Sync tester: 1706494612: starting read of 1000 lines [18:16] Notecard Sync tester: 1706494614: all NC lines Read [18:16] Notecard Sync tester: linkset records stored: 1000 The record count came from "llLinksetDataFoundCount(".*") to verify that I actually counted the records. this is going to be nice.

it's fairly new (as of late Sept, 23), and I'm not sure how much press it got. I believe you can also set individual prims in a linkset to ignore, and not just the whole thing.

side note, Wireframe mode is explicitly disallowed when anything is locked on. I believe that is the only place where Wireframe and RLV intersect.

72 minute later. at some point when I I wasn't looking the test box was returned to be via auto-return rule/timeout. I re-rezed from lost+found. touched, no error, nc was still cached.

This was my test for the new function. touch_start(integer total_number) { string result = llGetNotecardLineSync(ncName, lineNo); if (result == NAK) { llOwnerSay("notecard not ready"); llGetNotecardLine(ncName, lineNo); } else if (result == EOF) { llOwnerSay("No more lines, restting"); lineNo = 0; } else { llOwnerSay(result); ++lineNo; } } Granted this is in a manual read mode, once per touch, but the fall back did work. I never used or defined the dataserver event itself. Just called a function that would invoke it. then a retry to the Sync command on the next touch_start. I do know that on a looping read function I might should drop a simple pause in place to give the faux dataserver call a chance to do it's thing. and lastly I also know that I should have a try counter in place and if 2 or 3 calls to the Sync version after a dataserver nudge all return NAK to fail on out and let whomever know, or to wait and try again later. === and one point: I crashed out of the beta server (my fault, not SL), but when I decided to get back in (it was a bit but I'm sure it was less than 30 minutes), the notecard had fallen out of the cache. Another wait and after 15 minutes it fell out of cache, but then 45 minutes later the NC was still available on first try, so de-caching through time is....??? Additional tests: I tried editing the NC and tried and got the "not ready error". I edited again (added a space, removed the space) saved. No error I edited again and added a line - got the error I edited again, added a space. - got the error edited again, removed a space, no error. removed another space, got the error. Editing the card does appear to have an effect on it's caching maybe, but it also appears to be inconsistent. As is just time since it was cached. So, test for success do a blind data server nudge it if needed.

This one is somewhat tricky and misleading, too, due to how the script are handled server-side. Most all modern script will share byte code when there are multiple instances of the same script on the region simulator. So if you have a person on the parcel wearing a given body and associated HUD it takes up a certain amount of memory. Now if 2 more people come onto the region with the same body and HUD combo, the script load/count does not get tripled. Instead, it stays the same with a little additional overhead take up to account for the extra people's individual variable environment. The region just goes "oh, that script is already running, no need to load in others copies, I just need to track these few little things". But your script counter boards can't account for that so they are often very inaccurate in terms of how much resources are being used by each individual. A better metric is how much script time each person is using, not how many script, how much memory the supposedly are using. I mean yes, it's good to be aware of how many scripts we are hauling around and how much space they potentially can take up, but in terms of finding balance and optimization, it's probably one of the lower priority things to be factored in to your decision tree.

since nothing i wear natively typically uses these spots, I'll park things on them that I wear often or all the time so that they'll be out of the way and not be stacked with other things: Right Wing Left Wing Tail Base Tail Tip and sometimes maybe Right Ring Finger Left Ring Finger.

I'm assuming this is for a rigged worn item but don't know what since you didn't specify. With that base assumption though, did you change the attach point? that can cause some root anchor (not mesh) prims to move around unexpectedly and suddenly appear where once they were tucked away inside the body space.

Coupled with that, new users just buying into the Maitreya verse with LaraX also get the 5.3 (OG) Lara as a free add in. This is a functional backward compatibility with an extensive catalog of existing clothes and accessories with minimal effort and zero cost (for the body) involved. This can be a tremendous lure for new customers to the line, now and in the future.

Currently working my way through the Muderbot Diaries by Martha Wells. An excellent diversion for the holiday season (edit to add: about halfway through Exit Strategy as of this post)

I know this is a couple of weeks out if but if you want a secondary location to list as a back up, my go to for a no-script sandbox is: http://maps.secondlife.com/secondlife/Alethia Island/128/25/24 straight out from the landing area are several clearly marked parcels. some are simple privacy enabled for unpacking boxes, changing clothes, and having private conversations, some are set to no script. the privacy enabled ones clearly mark if they are occupied or not too which is nice. when I get something potentially sketchy this is where I go to rez to check it out. (also good for logging into to disable an errant/misbehaving RLV object w/out fully turning off RLV.)

Someone please tell my bank this. They are still requiring me to change on a schedule, every 6 months, don't reuse any of the last 10 you've used. that's 3 years before I can start recycling. and heaven forbid if I forget it cause after 3 fails, they lock the account and you have to call a CSA during normal hours. which, the last part I get, it's my money after all, but the constant, "you must change now" cycle is highly annoying.

I don't disagree with the last statement. and I think much further down the line Wulfie R mentioned that at first the MFA was compartmentalized to key parts of the dashboard, then expanded from there. Even with the blocking now in place, Linden Lab still does not require that TPV makes incorporate MFA tech. I do think that Linden Lab should have been much more forthcoming in the fact that the security hole was there, but there is also a philosophy of security through obscurity (which yes, I know doesn't means this specifically but it can be applied). No, you can use G-Authenticator w/out a Google account, and even using it with one, it was opt in to cloud store/sync the token database. I opted not to. Instead I, simply, manually sync my accounts between my phone and my tablet. so if the phone ever gets broke or (touch wood) lost/stolen, I'm not suddenly locked out of a a lot of account. Once I opted out of cloud storage, I can't later decide to turn it on. I've not tried uninstalling and reinstalling to see if that gives me the option again however, mainly because I have zero interest in that. At least one (Authy) has a desktop version for Win, Mac, and Linux. so you don't need a smart device if you don't have or want one. Standard is not synonymous with secure. Yes, it can be argued that they are better than nothing, but not by much. If your banking details includes your main e-mail and your e-mail account get compromised it's a simple matter to have your bank send out reset data. There have been more than a few cases of phone SIM hijacking through weak link CS Agent at the phone company and your SMS messages get redirected. (last one is probably less likely in most cases I'll agree). it's one reason I have a secure e-mail account that only has one use: bank. no it's never given out, it's never used to send mail. it's not installed on my phone. since my bank doesn't use MFA it's my way to adding a layer of security. I'd say less than stupid. The advice is use a strong unique password that is 8+ characters long, mixed case, numbers and special symbols, etc and even multiple words, etc, on every site, and change them every 6 months or so. Now, I've got easily 100+ accounts: that advice is not going to happen. Either I use a password vault service, or I reuse passwords. (I tried password vaults, but never found one that was convenient enough to stick with for any number of reasons). it's not stupidity, it's not even laziness, it's convenience (which okay might be synonymous with those two thing). I have a strong unique password for each of my banks. I have a strong unique password for my credit card services. I have a strong unique password for my e-mail accounts. I use separate obscure e-mail accounts for my banks and for the credit card services, and then have a couple of general use accounts. I have MFA on about 30 of what I'd consider sensitive accounts but the bulk reuse passwords to some extent or another. It's just a fact of life. We are drowning in passwords, and something has to give. I'll take the added step of MFA on the important things as it does add an additional layer and very little effort. A thing you know and a thing you have. I'm a product, and I have no illusions otherwise. I carry a phone so I'm tracked. All my activity is tracked to varying degrees on line. My viewing habits are reported back by either my cable provider or by the streaming services I use. What I buy is tracked either because I order online or pay by plastic, I rarely if ever use cash anymore. My eating habits are tracked because I use a grocery store loyalty card. I could go on, but this, really, is just one small drop in an otherwise huge pond. I don't have to like it, but I can accept it and accept the benefits that some of that that gives me for being a data point product. Edge case but even so, when I worked in IT we had a software vendor that sometimes needed to log into our systems to troubleshoot problems, but we didn't want to give them free access. So when we contacted them for support, we had to provide them with the MFA token from an RSA fob for them to log in. They had the password but could not access the system without us being explicitly onboard with it and giving them the final one time key. This was 20 years ago and long before MFA was really gaining traction as a consumer product, so it does have a history of being very useful tech. MFA is not pure snake oil. it is a valid technology that has its place. and in the sea of passwords, it has its place now IMO. If you have just a few accounts and practice good safety practices it might be redundant, but for a lot of modern society it's the band-aid that is sorely needed. One final thought: There are a lot of authenticators on the iOS store that try to trick to using them instead of the main one by looking like the main ones. Goggle Authenticaor was a big one for copying and so they recently changed their icon to stand out. the others haven't followed yet but I'm sure they will in time. So you do still need to be diligent on vetting who you decided to use and that the app you chose is the one you think it is.

The long and the short is that Linden Lab provides a viewer to access the service and the MFA routines were implemented there. TPVs are just that, third party, and no matter how widely they are used or how much they are sanctioned by the company, using them is always "at your own risk". While I personally think the window of MFA support adoption for TPVs has been overly generous, I don't think LL did anything fundamentally wrong by releasing a feature that was fully incorporated and supported by the official product but maybe not by the TPV community. Most of the main TPV vendors have come on board, and did so quite readily too I might add, and this just closes the door finally on the few hold outs that for whatever reason won't or can't. And even now they are not "making" or "requiring" TPV makers to include this feature. Rather they are saying, if you (the user) wish to avail yourself of this added security protocol, then the viewer you choose much support this. I don't have a problem with that either.

Basically yes. Allowing an account setup for MFA to be logged into sans MFA by a viewer that does not support that feature is a gaping security hole. I am glad they have finally plugged that up. It should have been plugged sometime ago IMO. It's like locking the front door and leaving a window open next to it. I'm not sure what you are trying to say here. I've been using Google Authenticaor (iOS) for SL ever since MFA was first enabled. Early adopter. It works just fine. And setup was easy: scan the QR and then supply two generated numbers (tokens) (if I recall correctly). So I'm not grokking at what step it's failing for you. That said, they did have some outbound internet issues earlier that might have been interfering with the sign up process. But at last check (as of this post) that's been fixed, so.... try again?