Jump to content

Sasun Steinbeck

Resident
  • Posts

    254
  • Joined

  • Last visited

Everything posted by Sasun Steinbeck

  1. Yeah thanks! BTW for those interested I found this very helpful to understand the confusing name situation on various SL properties: http://wiki.secondlife.com/wiki/Category:LSL_Avatar/Name
  2. This would be critical functionality to impement. They HAVE to do this. Up until this minute legacy names were guaranteed to never change and always be unique. So let's say you have a list of subscribers to a list. Instead of exporting a list of UUIDs, you could export a list of legacy (or account!) names and be safe in the assumption that those were always useable, meaning, you could re-import them and in some way or another convert them to unique UUIDs. Now if that assumption is broken that is really going to screw up a lot of people that happen to have lists of avatars for whatever reason (sales logs, committee memebers, whatever) that are now broken. If you re-import them and half of them are completely unknown because the avatar changed their name... what a mess. Big problem. The only reasonable thing to do and not break a zillion tools and external lists that make those (previously perfectly safe) assumptions that legacy names will always be tied 1-to-1 to a UUID is to make ALL names, historical + current, be searchable/convertable to a unique UUID. Anything less will really screw over a lot of people.
  3. When you say "always use UUID values", yeah that's true when storing a list of avatars in some way. A database of legacy or account names only is indeed useless which I think is what you are getting at. For most APIs you need UUIDs so that's nothing new. For messages and whatnot to end-users, obvious I need to use something friendlier than a UUID, display names are useless as they can change on a whim, so I need to understand the details behind legacy names (and accout names, if they are changing too?) As a scripter I'll definitely need more specifics than general guidelines. Exactly how will the APIs change? Exactly how will llKey2Name() change? Under what conditions does it return a different name for the same UUID? What about llGetObjectDetails? What about llGetUsername? Will user names remain the same and never change or will they follow legacy name changes? Will legacy names still be called legacy names or will there be new terminology? llRequestAgentData? What about llDetectedName()? What about names passed into listen events? llSensor()? AGENT_BY_LEGACY_NAME? What about the q parameter for search.secondlife.com/web/search/? What about the q parameter for search.secondlife.com/client_search.php?s=people ? How will the results returned by those URLs change? What about the names shown for an avatar's web profile i.e. http://world.secondlife.com/resident/c3cf4c84-c31b-47ac-855c-3858375e0360 ? Do I need to store multiple names for every avatar UUID now? Will there be an API to get all (current + historical) legacy names from an avatar UUID? Or will all APIs like llKey2Name and llRequestAgentData only return one legacy name, the latest one? Can I look up a UUID from an old legacy name after it has been replaced? As you can see there are a lot of details that need to be known for scripters to fully understand what to do. I'm looking forward to the gory details.
  4. Just wondering if any detailed information exists yet on LSL API changes related to the upcoming avatar name changes. If not, where and when can we expect some details? I'm really hoping there are no breaking changes, but I need to know what is going to happen specifically to the APIs and any changed assumptions about avatar names before any changes roll out so I can get any necessary updates to my products out there.
  5. Yep that sounds like the best bet, thanks, just wanted to make sure I wasn't missing something about getting that retry header
  6. @Oz Linden one followup, how can I get the Retry-After header in the 503 response? The request is coming from an in-world script... llGetHttpHeader() in an http_response event doesn't work. I can't seem to get any of the usual expected response headers that way.
  7. I love how the second assumption in that bug report is that it's an evil conspiracy, lol.
  8. In my case the remote object sends a small request to my inworld server, then server replies with an "ok" response, then immediately makes an HTTP request back to the remote with some data. The only reason it does that instead of just sending the data back in the response is due to the response size limits. Sometimes the data can be a largeish payload so it has to turn around and make a fresh http request. Maybe a little pause between the response and the following request back would do the trick... but the actual number of responses + requests to the remote is just 2 or 3, there's no barrage of requests. Unless the quota somehow factors in the payload size. And in one case (and probably the second) where this happened the remote region was heavily populated and lagged, so it was probably an issue with other scripts in the remote region gobbling up all the quota... so that makes sense. Changing this quota to "same owner" would be great. At least I can watch for a 503 and the Retry-After header and know when it's hit. Thank you all for the info, that was very helpful.
  9. I am extremely familiar with all those limits and have delt with just about every single one (sometimes painfully, lol) at some point or another, but I'm asking specifically about the error I posted about. None of the documentation addresses what that error might actually mean. Any idea?
  10. Anyone have any clue at all what this error message might mean? "Cap invocation rate exceeded:" followed by a mysterious UUID. I'm seeing this from some HTTP based inworld servers that are getting a non-excessive number of requests. Some background... no, it's not http rate limiting, I detect and handle that. The servers in question have been stress tested to limits far above what they are at now (an order of magnitude larger) without ever seeing that message. I've seen it only once before, coming from an inworld server connected to a kiosk in an extremely laggy region (a very busy fashion store). The error came from the non-lagged server in a different region, not the lagged kiosk. I am wondering if the lag is causing the kiosk to be unresponsive to the server in some way... causing that error. What's weird is that it is most definitely not http rate limiting. We're talking a handful of http requests per minute. My guess is that the server is making an http request to the kiosk in the ultra lagged area and it gets that error. In this most recent case the server got a 503 error, so it looks like it's possibly an http request to an object in a laggy area. I can't find a darn thing about this error and it's extremely sporadic. It happens once... then never again. But now it's cropping up again on some very important servers and I need to get this resolved asap.
  11. Update: I tried a commercial long looped dance animation in my own object/script and it stopped immediately on llStopAnimation! So it must have been something with that other animation?I have no idea. Why would one animation stop and another refuse? Maybe this is not a real problem and most animations don't ignore llStopAnimation like that, I have no idea.
  12. Hm I just tested out a commercial dance ball in my inventory with a long looped dance. As soon as I jump off, the dance stops! The script must be stopping my looped dance. How??? It doesn't appear to be animating me with anything else.. the looped dance just stops immediately. What's the trick?
  13. Thanks much for the tips. I downloaded the bvh files, uploaded "avatar_stand" unlooped (yes it's a single frame) twice, once at pri 0 and once at pri 4. Neither one stopped the currently looping animation. The high priority one overrode it, but as soon as it ended, the dance resumed (which makes sense, since it was merely tempoarily "hidden" by the short high priority stand animation). So no luck so far at all. Contrary to what the documentation says, there appears to be NO way to really stop a looping animation immediately, period. You can only "hide" it temporarily with a high priority animation. I haven't tried that yet but a high-priority "stand" animation may be more confusing to the dancer than just letting the current loop finish. Plus I have no idea how long to play the "hider" animation since I don't know how long the current loop is going to take to finish. If anyone has any other ideas I'd love to hear. Or is this truly impossible? The only thing that actualy seems to work is the system Avatar/Avatar Health/Stop Avatar Animations in Firestorm (not sure if that's in the standard viewer). But this can't be done via script.
  14. I am trying to stop a looped animation immediately. Sample code below. From what I read the trick is this: "If the animation to be stopped is the only playing animation (as found via llGetAnimationList), it will continue to play to its end (if looped it will continue indefinitely). If you must stop a looped animation, playing a single frame non-looped one immediately after stopping it, at low priority, will clear the list." I'm testing with the only full perm looped animation I have, the ever popular "Chicken Dance (looped)" animation. The trick above is just not working, or, the "single frame non-looped" animations I'm trying are not the right kind. I was hoping that llStartAnimation("stand") or one of the built-in anims would immediately stop the dance loop, but nothing will stop it, for me or anyone else. Drop the script in a prim and click to start, again to (in theory) stop. What am I doing wrong? I have some other freebie single frame looped animations, and when I start one of those, chicken dance immediately stops and the new one starts. However if I try triggering then stopping that one (in place of "stand") then chicken dance resumes and finishes the current loop, then stops. Does anyone have this magical single frame non-looped animation I can have? I was really hoping one of the system anims would do the job since there is a big problem including any additional animation in the inventory of the product I'm building. I'd be glad to send you a test prim with this dance installed so you can fiddle with it. string curAnimation; getPerms(key id) { if (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION) { llStartAnimation(curAnimation); } else llRequestPermissions(id, PERMISSION_TRIGGER_ANIMATION); } default { run_time_permissions(integer perm) { if (PERMISSION_TRIGGER_ANIMATION & perm) { llStartAnimation(curAnimation); } } touch_start(integer total_number) { if (curAnimation != "") { llOwnerSay("stopping: " + curAnimation); llStopAnimation(curAnimation); llStartAnimation("stand"); curAnimation = ""; return; } curAnimation = "Chicken Dance (looped)"; getPerms(llDetectedKey(0)); } }
  15. I have 1.2 million names/keys in my database. Let's say for the sake of argument you are correct, that 99.9% of them will be easily found on the first page. You are probably right. So let's see, 1,200,00 * .001 is... 1,200. Yes, 1200 names, if that percentage guess is realistic, will not be found. Is that number acceptable to me? Maybe for you, but not for people that work with databases at this scale. My point here is not your specific numbers, but that "almost always" or "99.9%" is probably just fine for someone searching a few thousand or a few hundred thousand names. But when you get into the millions, "almost" is just not good enough. I really do not have a good idea of what percentage won't be found on the first page. But I will tell you that I was very surprised at how easy it was to find a few. I didn't write a program to search my database, I just looked at RANDOM at a list of names and started doing a few manual searches. I tried searching for a few dozen, then found Tila, and also found Secondary a short time later. By manually searching. So I'd be very curious what the real numbers are on how many residents won't show up on the first page. I'm glad to hear that you tested so many names and had no problems finding them on the first page. That's good news. After finding those two names I was pretty darn worried. Maybe I just got extremely, incredibly lucky finding those two examples of why assuming that your search result will be on the first page is a bad idea. Maybe. I may take some time to run some tests like you did to really find out. But if it takes me the same amount of time to just fix my search code to loop through all the search page results, I'd rather just make that work - then my search results will be better in the end. I must reiterate that all of this pain would be completely irrelevant if we had a decent and authoritative API to call to do this, instead of the complicated, messy kludge that we have now.
  16. It's not "better", it's either do or die. As if we have a choice at this point, right? THAT'S what sucks, that we all had to scramble to fix this. I had to convert or some key products would have continued to be non-functional like they were when vwrsearch first went down. And I'm sure you wouldn't argue against pusing for a simpler, more reliable web service, right?
  17. Where did I say vwrserach is perfect? And what does vwrsearch throttling have to do with the current discussion? Nobody in their right mind would assume that any LL service is perfect, lol. The fact that the old search isn't, and never was perfect, and that the new one isn't either, just proves my point that we DO NEED a reliable name2key service that doesn't make SL developers jump through hoops to parse the search results and returns useful error information.
  18. Yes, she does exist: https://my.secondlife.com/tula/#about_tab. Her legacy name is "Tula Resident". Your response proves my point exactly. If you don't know exactly how to parse the search results, you'll get bad data, as in "this person doesn't exist". Secondary Resident, however, does not exist. But you won't know that until you parse over 160 search results scattered over 20+ pages that you have to load. See what I'm saying? It's a mess! Do you have any authoritative information on exactly how search results are sorted? Can you share that information please? Don't assume that SL products can just assume that every name given to them to check is valid, current, and an existing avatar. I regularly get huge lists in the tens of thousands of avatar legacy names to import into my system, and almost always there is a good 5-10% accounts that no longer exist, are incorrectly capitalized, or just plain spelled wrong via manual copy and paste errors. If one of those lists includes the former Secondary Resident, I have no choice but to parse through that entire mess to figure out that that avatar doesn't actually exist. With any luck I'll get the actual avatar not on page 200 but on page 2, but I can't really count on that, can I? I have to keep parsing until 1) I find the verified name or 2) get to the end of the search results. So I must always be prepared to parse an unknown number of pages.
  19. Here's a good example. Let's say you're searching for an avatar with a legacy name of "Tula Resident". If you search on the account name, that is simply "tula" (parens are not part of an SL account name nor are parens always returned around account names in search results). So if you do http://search.secondlife.com/client_search.php?s=People&q=tula You'll notice that the first search result is not the correct avatar, so gotcha #1 is that you MUST search the entire result set. In fact, this search returns multiple pages! And the correct avatar with account name = tula is not even on the first page, so your web application needs to keep loading and parsing an undefined number of pages looking to confirm your search results. God forbid you search for an actual resident with an account name of "secondary" because you'll get 8 PAGES of search results, for every person with that word anywhere in their profile. This is simply not useable for real products that need to do a definitive name to key lookup without putting unnecessary and completely useless strain on the search servers, not to mention how tricky it is to do it right, which translates to lots of product bugs as you figure out all the crazy weird gotchas involved in search.secondlife.com (trust me, ugh) or incorrect keys. Someone testing this may never notice that it's possible to get multiple names in a search result, not to mention multiple PAGES, if every test name you ever test with only ever returns one search result. That's a bad assumption that I could easily see someone making, and now you've populating a database with BAD data, which is the worst possible situation.
  20. This turned out to be more complicated than I thought. If the returned avatar has a legacy last name of "Resident", then the account name is just a single word, so you need to distinguish account names that do and do no have a "." in them. For example Joe Resident with a username of "JOE" will return "JOE (Joe)", but an avatar Joe Bloe with username of "JOE" will return "JOE (Joe.Bloe)". Good luck to you guys trying to parse this mess, jeez.
  21. As of yesterday or the day before, http://vwrsearch.secondlife.com/client_search.php is failing to return search results. This is extremely bad and is no doubt breaking many many scripted objects in SL, mine included. Please note that http://search.secondlife.com/client_search.php is NOT a viable alternative for scripters. It DOES NOT return correct legacy names in the search results in all cases. If the avatar you are searching for has a custom name set, it will NOT return the legacy name, nor is it available on the world.secondlife.com search results if you try following those links. One vital function that vwrsearch is the only working option for is getting correctly spelled and capitalized LEGACY names, which every subscriber messaging system in the universe uses. Even more critical is that you can get search results that are NOT MATCHES of your search name, which is absolutely terrible. Misspelled names will result in search results for different or non-existant avatars that are spelled close to the searched for name and no easy way to confirm that you got the right key since the legacy name is not guaranteed to always be in the search results. This is a problem for anyone like me that maintains a huge database populated by names and keys from non-authoritative sources (such as hand-collected lists of misspelled avatar names that need to be confirmed and corrected on adding to the database). If you do get a search result for someone that happens to have a custom name, you get very different results - their username followed by their account name in parens, which could be used to confirm that you got the right person, but again, you don't get the account name in all cases. In that case, you get the legacy name. This is pretty bad, LSL developers REALLY need an authoritative avatar key/name lookup service that doesn't go down, ever, and returns sane search results that belong to the avatar you're actually searching for and don't require crazy complicated processing to figure out if your search results are even valid. For those scripters out there frantically converting to use search.secondlife.com like me to keep products working in the interim (sigh) here are a few tips. When parsing the search.secondlife.com results, which may or may not be multiple people, following the key in the <a> tag href, you get either 1) a legacy name or 2) a username followed by an account name in parens. Parse appropriately and you can do some level of confirmation of search results by comparing the original searched-for name with the account name, or if the name comes back with no parens, then it must be a legacy name. In both cases you can do a case insensitive comparsion and confirm that you've got the key to the person you're actually looking for. And don't for get to include a &s=people parameter in the search string to limit your results to just avatars. A few regular expressions to help: @"world\.secondlife\.com/resident/(.{36})""\s*>(.+)</a>" will extract the returned key and the avatar name, if any avatar search results come back. Use @" \((\w+)\.(\w+)\)" to test to see if the returned name is an account name and give you the first and last names (in lower case) that you can then compare separately to confirm. If that doesn't match, then you probably got a legacy name, not an account name. Just do a case insensitive comparison on the whole name from the first regex above and if it matches your search name, you're good, and the returned name has correct capitalization.
  22. This is making the assumption that all scripts in a region only affect avatars in that region, which is of course completely false. If I have a server farm on my private sim that requires bursts of responsive activity, so that when the literally hundreds of avatars clicking away at kiosks all over the grid at any given moment expect item delivery in a responsive manner, are my servers going to get bogged down just because no one is on my private sim where the server happens to be? Will they be just as responsive when an http request or an email event comes in? What if the server farm is so large that it is using a significant percentage of the sims script resources, are they all going to suffer? Do I need to log in an alt bot when I'm not around to stop this, because you can bet that's exactly what is going to happen if this affects actual script performance in any way, which not only defeates the purpose but makes things worse, because now you have at least one agent with all kinds of updates going on continuously for no real reason but to stop the idle. Is it possible to have an llStart/StopRegionIdle API that can only be called by estate managers, if this does in fact affect server performance in any way?
  23. Searching at https://secondlife.com/my/community/groups/ does not work for me. I get zero results every time. Instead, just use the search box on the upper right of any page anywhere on http://secondlife.com, click on Groups on the left if you need to narrow it down, click on the name of the group in the search results, click the green More Info button, then look down below the social media icons for "Link to this page:" and the group UUID is the last part following the last slash ('/'). For example if you see: Link to this page: http://world.secondlife.com/group/8aa64b67-bebf-f81a-cb76-45260601a58f The group UUID is: 8aa64b67-bebf-f81a-cb76-45260601a58f
  24. This migration really bit me in the butt. One of my listings reverted back to a very old description or was re-migrated again. I didn't delete anything. I was stupid not to save a backup of the lengthy product description I spent so much time doing, so it's my fault it was lost, but lost it was and all that hard work done the tubes. I am so pissed. Everything has been smooth up to this point but I'm very upset that my listing was essentially deleted and reverted to an old description that was chopped off halfway.
  25. Does this script fix problems ONLY from purchases in the last few weeks? I recently spoke to a customer that wants to change their rating but is unable to, from a purchase made more than 2 weeks ago, and I have items I purchased more than a few weeks ago that I'd like to review. Why are you only fixing the issue for the past two weeks only?? A related complaint, it's incredibly hard for people to figure out HOW to leave reviews, all the community reviews are one of the major strengths of the marketplace, that really needs to be MUCH easier to figure out how to do. Encouraging reviews is a good idea, having it so buried is NOT good for your merchants!
×
×
  • Create New...