Jump to content

Whirly Fizzle

Advisor
  • Posts

    4,632
  • Joined

  • Last visited

Everything posted by Whirly Fizzle

  1. Do you happen to be using the Vintage skin in Firestorm? This skin actually causes a slower login time then the other skins, especially when you have a large flat inventory - I think it's because of the different layout of the inventory window. If you are using Vintage skin, switch to the Latency skin which looks 99% the same but doesn't have the same problem. If you are fine after switching to a different skin then Vintage, you'll still need your inventory deflattened though because you'll be very close to having the same problem with other Firestorm skins or with other viewers too.
  2. If clearing cache lets you login that session, the problem is most likely to be a large flat inventory structure causing the "Creating in inventory views" part of the login process to take so long the login times out. If this is a flat inventory issue with a certain account, you'll also be able to log your alts in without any problems even with a fully cached inventory. Best thing to do is to contact LL support & ask them to check if your inventory needs de-flattened. LL support can run a script on your inventory to "de-flatten" it, which will fix the problem. If you are a premium member, use Live Chat & they will most likely fix you right away if it just needs the de-flatten script run. If you are a basic member, file a support ticket: https://lindenlab.freshdesk.com/support/solutions/articles/31000131009-contact-support A "flat" inventory is one which has a large number of items in the inventory root folder &/or one or more inventory folders contain a large number of items - where an item is a loose inventory asset or a folder. The more nested your inventory is the better - you can never have too many sub-folders within sub-folders. The de-flatten script LL support run will automatically create sub-folders within any folder that is too flat - ie contains too many items.
  3. Nice breakdown of the problems here: https://blog.cloudflare.com/analysis-of-todays-centurylink-level-3-outage/
  4. This is a LL feature, not something nefarious the person who banned you did. When a banned agent attempts to enter the region, any agents that share the same IP address as the banned account will also be banned for a limited time.
  5. Still makes more sense then the server release notes...
  6. Maintenance-RC viewers have been named after alcoholic drinks for a while now, we've already been through the alphabet once & they are back to A again.
  7. Open Phototools with ALT+P Go to the Light tab. Click the D buttons next to all the shadow & AO settings. Does that fix the crash? Setting shadow res above default is the most usual cause of crashing when taking snapshots with shadows enabled. You need a really powerful graphics card to handle setting shadow resolution at 3 or 4.
  8. Web search blocks the N-word. it returns "Whoops! Your Everything search for "bad word" did not return any matches. Legacy search doesn't block it though & returns some very nasty results under groups.
  9. Hiya @Mystical Loon Ok, so it's a viewer crash or disconnect. I found some viewer crashes from you in Bugsplat - thanks for enabling crash reporting! There are 5 viewer crashes from you between 06-08-2020 and 07-26-2020. 3 of the crashes were in the 64bit Intel graphics driver ig9icd64. The other 2 were known crashes, Firestorm_Releasex64!`anonymous namespace'::makeMap and Firestorm_Releasex64!LLMeshRepoThread::fetchMeshLOD. However all these crashes appear to be on a different system because it has Intel graphics and the CPU is Intel(R) Core(TM) i5-7200U What happens when Firestorm crashes on the new computer? A) You get a notification saying you have been disconnected from Second Life or that the region is experiencing trouble, with the option to view IM/Quit B) The viewer freezes & never recovers & you have to force quit. C) The viewer closes to desktop with no error message. D) The viewer closes to desktop with an error message from Firestorm - if so, what's the error message. E) The viewer closes & you get an error saying "Firestorm has stopped working" from Windows. F) Something else. Please can you check that you have enabled crash reporting for Firestorm on your new computer. Go to Preferences -> Crash Reports. Make sure that "Send crash reports.." is ticked. Also make sure that "Include Second Life name" is ticked so I can find your crashes in Bugsplat. After changing these settings, relog - if you crash before relogging after changing these settings, the crash won't be sent. Thanks
  10. Oh this will be fun. I love ̶g̶r̶i̶e̶f̶i̶n̶g̶ testing bots. I'm going to quiz Boxy on its knowledge of JIRA
  11. Create a test account. Write an automated action web script thingy to upload the desired image to the test accounts web profile image, which is free. Grab the profile image UUID. The rest is easy.
  12. Objects or mesh or avatars with complex geometry. Or objects with rapid object updates.
  13. Why don't you file this feature request on the Linden Lab JIRA & see what the Lindens have to say about it?
  14. I filed a JIRA BUG-229235 - [ADITI] Multiple problems on Aditi
  15. There is no way to allow more then 512MB texture memory on the LL viewer. Some TPV viewers allow the texture memory to be set higher. For example, for Firestorm Viewer: Viewer Texture Memory Buffer (MB😞 This is the amount of graphics memory the viewer will use. By default, it is set to the size of your graphics card's memory. 32bit versions only. This setting is hard limited to a maximum of 512MB. Lowering this value may resolve certain texture corruption and performance issues, but under normal circumstances you should not need to alter this setting. 64bit versions only. This setting is hard limited based on the VRAM available with your graphics card. It is recommended you increase the slider to use the maximum available to prevent texture thrashing. GPU 1GB = up to 768MB GPU 2GB+ = up to 1024MB GPU 4GB+ = up to 2048MB
  16. I filed this bug a while ago on the LL JIRA: BUG-228974 - [EEP] EEP settings do not respect texture permissions The bug isn't public because it's a permission issue. To be honest, I'm not actually sure if this is technically a bug, because creating skin assets using no copy to you or no transfer to you textures behaves in the same way - the resulting skins are full perm. The same behaviour happens with eye, hairbase & system clothing assets you create with non-full perm textures you are not the creator of & as far as I can tell, it's always behaved this way. When it comes to textures, permissions are pretty meaningless to be honest.
×
×
  • Create New...