Jump to content

Oz Linden

Lindens
  • Content Count

    256
  • Joined

  • Days Won

    1

Posts posted by Oz Linden


  1. This is an optical illusion. The further away an object is, the less often the viewer runs its animations (to save trying to make what will be very small changes in distant objects). When animations loop, the updates can end up looking backwards for the same reason that a fan viewed with a strobe light will look like it's running in reverse at some strobe frequencies.

    • Thanks 5

  2. The "flat inventory" problem is very simple... if you have too many items in a single folder, especially the (invisible) top level folder of your inventory, it will slow down login. An 'item' for this purpose is either a folder or something else (an object, a notecard, anything). If you have enough of those very large folders, it can slow down login so much that it times out and you can't log in (if it doesn't happen every time, you're probably right on the edge of too many). It's only one level deep that counts; if folder A has 50 items, one of which is folder B, and B has 12,000 items, those 12,000 are not added to the count for A.

    We've cautioned people about this many times.

    Our support team does have a tool that "unflattens" your inventory by creating new subfolders and sorting the items into the too-large folders into those subfolders. They can apply that tool to your next login if you report a problem and it looks as though it might help.

    • Like 1
    • Thanks 2

  3. On 8/10/2019 at 5:09 PM, Chic Aeon said:

    I am using the not so new Firestorm ( Feb  9 2019 18:55:39 (64bit) (Firestorm-Releasex64) with Havok support)

    Testing the appearance with any viewer other than the EEP RC viewer is not very meaningful, since only that viewer has the shader changes that accompany the new settings and capabilities.

    We appreciate that the rendering in this overlap period before the TPVs all have the same rendering pipeline as our viewer is frustrating, and regret having gotten into this situation; we (specifically I) thought that this overlap period would be very short, but it hasn't worked out that way. My apologies.

    We're working as hard as possible to get the EEP viewer into shape to promote to default, after which we expect that it will be quickly available in most TPVs.

    • Thanks 3
    • Sad 2

  4. On 8/11/2019 at 1:09 AM, Prokofy Neva said:

    Why is it even needed? What, LL's servers can't themselves tell what version is logging on without having to put files on your computer to do this?

    It allows downloads for optional upgrades to happen in the background so that you don't get prompted about the upgrade until the file is ready to be installed.

    More importantly, it is a 32bit application so that it can check whether or not your system is compatible with the 64bit viewer (a test that's not as simple as whether or not it can run 64bit apps, since some video systems are not supported in the 64bit Windows). By doing that test, it can ensure that no matter which build of the viewer you start with you end up installing one that should work on your system.

    • Like 3

  5. When reporting a DNS problem, it is helpful if you describe what you were doing (opening a browser to the marketplace, logging in the viewer, ...), specifically where you are, if possible including what ISP you are connecting through.

    DNS is a global distributed system, with potentially many layers of caching between you and the systems that provide the information about our current names and addresses; some of those layers don't follow all the rules or are buggy enough that they are sometimes not in sync with us.

    Flushing your local cache may sometimes help, but won't help with the cache you probably have in your home router, the ones in your ISP, or any of the others that may be in the path. Debugging this can be very frustrating.

    There's a pretty good page on debugging DNS at https://www.a2hosting.com/kb/getting-started-guide/internet-and-networking/troubleshooting-dns-with-dig-and-nslookup

    As far as I can tell we didn't change anything last night involved with this, and right now I don't see major providers that have bad data.

    • Thanks 3

  6. 3 hours ago, Lucia Nightfire said:

    I don't consider using string literals to hold data outside of valid url format a hack.

    ... but note that Linden Lab does consider it a hack and not supported. We've already been through one round of data loss by users doing this when we improved the parameter validation; that could well happen again.

    The first law of software reliability: Use it the way the author intended.

     

    • Like 4
    • Thanks 4

  7. 25 minutes ago, KT Kingsley said:

    Is stuff like location at relog to last location, state of scripts and script-saved data useful or relevant?

    Bad effects on scripts may be relevant (or may be bugs in the scripts... hard to say), so it's fine to include it.

    Subsequent login attempts, regardless of where they are, are not part of the base problem we're most interested in right now.


  8. We are very interested in hearing about TP problems, but it will be far far more useful if you report all of the following:

    • When it happened; this doesn't have to be exact - within a few minutes is plenty accurate. Tell us what time zone you're using (SLT is easiest for us)
    • Where were you when you tried to TP?
    • Where were you trying to go?  (region names is all we normally need for start and end locations)
    • If you ended up somewhere else, where was it?
    • Were you disconnected or did you crash?  If the viewer window disappears with no message, you crashed; if not, you were disconnected.
    • What viewer were you using? (copy the information from Help > About Second Life)

    It's easiest for us if you report those in jira, but contrary to what some people think we do watch the forums.

    This issue is a very very high priority for us right now, so we really will use reports we get, but none of the above is enough for us to learn anything from. If what you want to do is just vent your frustration by all means go ahead, but if you'd like to contribute to solving the problem we need the information above.

    • Like 4

  9. 14 hours ago, iMeeky said:

    First and foremost, processing credit means you are taking your Linden Dollars and turning them into US Dollars.

    That is incorrect. The term 'process credit' means withdrawing your US Dollars (transferring them to PayPal, Skrill, or any other outside institution).

    Please see this thread for official clarifications.

    • Like 5
    • Thanks 7

  10. This is quite a bit more involved and expensive than it needs to be. You're essentially using the SHA1 value as an expensive index into a list; if both scripts have the same list of textures in the same order, just passing the index into the list is just as secure and much cheaper.

     

    • Like 1
    • Thanks 2

  11. On 6/30/2019 at 5:46 AM, Whirly Fizzle said:

    We are sorry, Linden Lab has discovered degraded performance on your connection to the region you are on. You will need to restart Second Life and log into a new region for the next 30 minutes to an hour. We apologize for the inconvenience. ?

    If that's the message, it's usually a problem with your inventory.

    What that message actually means is that the simulator has determined that messages from your viewer are frequently arriving out of order. Some out of order messages are expected and ok, but if it's happening too much it probably indicates a faulty network path between your viewer and the simulator. Because this can cause problems, certain messages are disabled when this is detected, which is why we suggest relogging somewhere else for a while.

    I have no idea why that would be related to landmarks or any other part of inventory, but it's possible ...

    • Thanks 5

  12. On 6/12/2019 at 7:11 AM, Astrid Kaufmat said:

    I found another kind of workaround too for thos of you who have installed it and want to wait for a fix.

    What I do is instead of X button to exit use the  Task manager so ctrl shift esc and manually terminate the prcess SL either it would crash the system.

    What you're doing is essentially manually crashing the viewer; that can result in problems such as corrupted caches and failure to save settings changes.

    There's no need to wait for a fix; the link Whirly posted is the fix, and that viewer has no other changes compared to the current default viewer - it's as specific as can be.

    • Like 2
    • Thanks 3

  13. On 5/29/2019 at 10:19 PM, Chic Aeon said:

    As of this afternoon, some (maybe all) of the people I have blocked are showing up as unblocked. I have REBLOCKED them and they are still showing up as unblocked. So something needs to get fixed.

    This would be far better to handle as a Support ticket or a Jira. In either of those, you could more comfortably have included the details we would need to investigate the problem (such as the names of the users that are not blocked but should be, and where you are seeing the incorrect status).


  14. 5 hours ago, martinmoun said:

    Most of us are member of 42 groups now. What happens at the day the change to 35 applies? Will 7 groups just randomly disappear? Or will we stay in 42 groups and and if we leave one we just can't add a new group until it's 35?

    The latter.  We will not delete any of your groups; you just won't be able to join new ones until you're under your limit.

    • Like 2
    • Thanks 2
    • Sad 1

  15. 6 minutes ago, Kilolo Jenkins said:

    Offline ims...why should they have been affected if the messages are being received offline via email? 

    IMs via email have never been limited, and are not affected by this change at all. If you have a verified address, we'll send the IMs you are sent as email.

    The limit is only the number of messages we'll store and deliver in a batch when you log in. If you have IM to email enabled, they'll all be old news by then...

    • Like 8
    • Thanks 6

  16. The documented limits are correct, but as others have pointed out even getting close to them can cause throttling events, and once throttled it will take quite a while for the condition to completely clear (twice the period that triggered the throttle initially, typically).

    Yesterday I posted an example script to show how to employ a fuzzy exponential backoff to deal with remote server failures; it would work equally well for throttling.

    http://wiki.secondlife.com/wiki/HTTP_Server_URL_Registration

    • Like 1
    • Thanks 2

  17. On 3/21/2019 at 3:18 PM, moirakathleen said:

    If, for someone reason you remove your payment info, or LL is not able to successfully bill it when your premium term expires, there could be a situation where you are not able to login inworld until you have brought your account back into good standing.  

    This is true only after a fairly long grace period (during which Billing will be reaching out to you to get it corrected). It does not happen automatically when a payment fails.

    • Like 1
    • Thanks 1

  18. In general, we won't be discussing dates or milestones for our migration to the cloud, only any user visible changes that result from that migration. Initially, we hope that there won't be many of those - it should be more or less invisible to you (digging into the hostnames or IP addresses may provide clues, but not always). We've moved a few things, and are finding and fixing a few problems that crop up with the changes. As noted above, we're also upgrading the OS version for simulators and other things; again, that should be mostly a no-op for users.

    It's also true that none of the above has anything to do with streaming viewers. We've been monitoring the cost/benefit of streaming viewers for years, and will continue to do so. If/when we think that the cost we can offer a streaming viewer is reasonable, we'll do it. There is https://brightcanopy.com/  now (not a LL product).

    • Like 3
    • Thanks 3

  19. It's sort of a problem with the installer.

    We went through a few changes in updater strategy over the last few months, partly to be able to protect users who still need 32bit viewers and partly for some other reasons. I think we've ended up at a good solution, but there were some problems with some of the intermediate steps.

    I think that if you'll delete any shortcuts that you've been using to launch the viewer, and then reinstall one more time, you'll be ok from now on. (The problem is that the shortcut you're using is still pointing to a leftover component from an earlier version)

    If that doesn't solve it, please zip up all the log files in your log directory and file a bug report on jira.

    My apologies for the inconvenience.

    • Like 3
×
×
  • Create New...