Uploaded image for project: 'Firestorm'
  1. Firestorm
  2. FIRE-8842

[BUG-1626] [MAINT-2347] Mesh transfer is limited to 30 seconds per transfer. Should only time out from lack of updates.

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Phoenix Firestorm 4.3.1
    • Fix Version/s: Phoenix Firestorm 4.6.1
    • Component/s: None
    • Labels:
    • Environment:
    • SL Avatar Name:
      Danny Nolan
    • Reported In:
      Firestorm 4.3.1.31155 Havok Release

      Description

      The Problem

      There seems to be a hard-capped limit of 30 seconds per mesh transfer. If the transfer hasn't finished by 30 seconds, it just stops completely, and starts over.

      What happens is there will be multiple transfers open, but since my bandwidth is relatively low, it simply can't finish 10-15 transfers in 30 seconds. So, it will terminate the transfer, and start over - where it will once again fail, and start over - basically perpetually maxing out my connection until I relog and try again.

      On a slower connection, this is unacceptable. Teleporting anywhere with 2-3 avatars with 5,6,15 mesh attachments WILL max out a slower connection, and not be able to finish transfers within 30 seconds.

      Solution

      This time limit should be reset each time data is received. That way, the transfer will only time out if there hasn't been any data over a substantial amount of time. Simple.

        Issue Links

          Activity

          Hide
          martinus Martin Taylor added a comment -

          just for info, I seem to have reported the same issue (or a superset thereof) under http://jira.phoenixviewer.com/browse/SUP-11577 . For some reason it got classified as support request.

          I would like to add, resetting the timer when data is received is one aspect of the solution. Another part of the solution is effective bandwidth control for UDP and HTTP traffic combined. This is essential for users sharing a connection with limited bandwidth. Can you add this to the development backlog?

          Show
          martinus Martin Taylor added a comment - just for info, I seem to have reported the same issue (or a superset thereof) under http://jira.phoenixviewer.com/browse/SUP-11577 . For some reason it got classified as support request. I would like to add, resetting the timer when data is received is one aspect of the solution. Another part of the solution is effective bandwidth control for UDP and HTTP traffic combined. This is essential for users sharing a connection with limited bandwidth. Can you add this to the development backlog?
          Hide
          martinus Martin Taylor added a comment -
          Show
          martinus Martin Taylor added a comment - fwiw, another report: http://phoenixviewer.com:8080/browse/FIRE-9310
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          There is a post you may be interested in here: http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2013-04-01/td-p/1954059/page/4

          tristangarrard wrote:

          Something I noticed tonight, and this seems to happen on multiple sims, is that the textures will complete loading and the viewer stats will show a bandwidth of circa 10kb/s as normal, but my firewall (Little Snitch) still shows data constantly downloading from the sim IP address at a rate of about 150kb/s. This does cause some inevitable lagging as well as hammering my bandwidth, I think I saw about 215MB come down in total from the sim before I relogged. Relogging seems to clear it for a bit but then it restarts.

          Anyone else seeing this?

          Reply from Monty Linden:
          The Texture Console speaks truth for texture fetches, either http or udp. If that is quiet while this transport is going on, it's something else. Little Snitch can tell you more and here are some rules that will determine the traffic:

          Port 12046 but textures are quiet => mesh fetches
          Port 12042 => other HTTP services ("Capabilities")
          UDP port 12035, 13000-130XX => simulator communications

          Show
          whirly.fizzle Whirly Fizzle added a comment - There is a post you may be interested in here: http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2013-04-01/td-p/1954059/page/4 tristangarrard wrote: Something I noticed tonight, and this seems to happen on multiple sims, is that the textures will complete loading and the viewer stats will show a bandwidth of circa 10kb/s as normal, but my firewall (Little Snitch) still shows data constantly downloading from the sim IP address at a rate of about 150kb/s. This does cause some inevitable lagging as well as hammering my bandwidth, I think I saw about 215MB come down in total from the sim before I relogged. Relogging seems to clear it for a bit but then it restarts. Anyone else seeing this? Reply from Monty Linden: The Texture Console speaks truth for texture fetches, either http or udp. If that is quiet while this transport is going on, it's something else. Little Snitch can tell you more and here are some rules that will determine the traffic: Port 12046 but textures are quiet => mesh fetches Port 12042 => other HTTP services ("Capabilities") UDP port 12035, 13000-130XX => simulator communications
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          i'm seeing it too SHould reducing max medh concurrent help this?

          Firestorm 4.4.0 (33720) Apr 22 2013 01:30:08 (Firestorm-Release)

          Show
          skua sarrasine Skua Sarrasine added a comment - i'm seeing it too SHould reducing max medh concurrent help this? Firestorm 4.4.0 (33720) Apr 22 2013 01:30:08 (Firestorm-Release)
          Hide
          ansariel.hiller Ansariel Hiller added a comment -

          Reducing the max mesh concurrency (MeshMaxConcurrentRequests) would indeed be a way to reduce the likelihood of timed out mesh requests, as each mesh request will have more bandwidth and can transfer more data within the 30 seconds timeframe.

          Indeed the hardcoded limit of 30 seconds is really short. Even with high bandwith you can be victim of dangling mesh requests that never finish, for instance if the connection to the server is bad. Unfortunately changing the timeout is nothing trivial, as it's hardcoded at a very deep level in the viewer. And that an effective fallback mechanism only exists in form of a ToDo-comment by LL doesn't make it better...

          Show
          ansariel.hiller Ansariel Hiller added a comment - Reducing the max mesh concurrency (MeshMaxConcurrentRequests) would indeed be a way to reduce the likelihood of timed out mesh requests, as each mesh request will have more bandwidth and can transfer more data within the 30 seconds timeframe. Indeed the hardcoded limit of 30 seconds is really short. Even with high bandwith you can be victim of dangling mesh requests that never finish, for instance if the connection to the server is bad. Unfortunately changing the timeout is nothing trivial, as it's hardcoded at a very deep level in the viewer. And that an effective fallback mechanism only exists in form of a ToDo-comment by LL doesn't make it better...
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          cut mine to 16 and still pegged out i wonder if theres a way to break out of this inworld. i welcome inworld messages on the subject

          Show
          skua sarrasine Skua Sarrasine added a comment - cut mine to 16 and still pegged out i wonder if theres a way to break out of this inworld. i welcome inworld messages on the subject
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          AT 16 it seems to have enough breathing room for worst case scenarios. Didnt they say mesh would be MORE efficient? its obviously beasting the connections. at 16 regular textures FLY in and loads happen more quickly besides the people with sideways mesh pants

          Show
          skua sarrasine Skua Sarrasine added a comment - AT 16 it seems to have enough breathing room for worst case scenarios. Didnt they say mesh would be MORE efficient? its obviously beasting the connections. at 16 regular textures FLY in and loads happen more quickly besides the people with sideways mesh pants
          Hide
          hilaryquerrien Hilary Querrien added a comment -

          I have my Concurrent setting down at six. Going much higher than that seems to have problems on my connection

          Show
          hilaryquerrien Hilary Querrien added a comment - I have my Concurrent setting down at six. Going much higher than that seems to have problems on my connection
          Hide
          ansariel.hiller Ansariel Hiller added a comment -

          Made the timeout for mesh requests customizable via FSMeshRequestTimeout debug setting in 33986 (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/1765aceeba59). Also increased the default timeout from 30 seconds to 60 seconds for mesh requests. Let's see if that helps anything.

          Show
          ansariel.hiller Ansariel Hiller added a comment - Made the timeout for mesh requests customizable via FSMeshRequestTimeout debug setting in 33986 ( http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/1765aceeba59 ). Also increased the default timeout from 30 seconds to 60 seconds for mesh requests. Let's see if that helps anything.
          Hide
          danny nolan Danny Nolan added a comment -

          Looking forward to hearing from your results Ansariel. I thought this problem was only going to be fixed from server-side code. But, hopefully that hearsay was wrong haha.

          Show
          danny nolan Danny Nolan added a comment - Looking forward to hearing from your results Ansariel. I thought this problem was only going to be fixed from server-side code. But, hopefully that hearsay was wrong haha.
          Hide
          martinus Martin Taylor added a comment -

          I have word from a Singularity developer that the network code in the viewer (as inherited from the LL viewer) is responsible for this mess, but difficult to get right. They are looking at replacing it. That and the availability of a linux 64 bit client makes it almost worth checking out, although I still prefer the usability and stability of firestorm.

          Show
          martinus Martin Taylor added a comment - I have word from a Singularity developer that the network code in the viewer (as inherited from the LL viewer) is responsible for this mess, but difficult to get right. They are looking at replacing it. That and the availability of a linux 64 bit client makes it almost worth checking out, although I still prefer the usability and stability of firestorm.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          If anyone would like a test build containing Ansariel's customizable FSMeshRequestTimeout debug setting, please let me know here and I'll send you a private message with a download link.

          Please state your operating system when requesting a build.
          It would be great to get some early feedback from people having this problem.
          Thanks!

          Show
          whirly.fizzle Whirly Fizzle added a comment - If anyone would like a test build containing Ansariel's customizable FSMeshRequestTimeout debug setting, please let me know here and I'll send you a private message with a download link. Please state your operating system when requesting a build. It would be great to get some early feedback from people having this problem. Thanks!
          Hide
          danny nolan Danny Nolan added a comment -

          Yeah definitely hit me up with one.

          Windows 7 64 bit.

          Show
          danny nolan Danny Nolan added a comment - Yeah definitely hit me up with one. Windows 7 64 bit.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          @Danny
          Link sent by private message from JIRA

          Show
          whirly.fizzle Whirly Fizzle added a comment - @Danny Link sent by private message from JIRA
          Hide
          danny nolan Danny Nolan added a comment -

          So far it's working perfectly as intended. Ended up setting my limit to 6 minutes instead (cause my connection literally is that bad). Even brought up the meshmaxconcurrentthreads to 128 to purposely try and overload it. All http requests continued to operate nominally, and not time out.

          No buggy behavior that I can see as of yet. Will continue to test.

          Show
          danny nolan Danny Nolan added a comment - So far it's working perfectly as intended. Ended up setting my limit to 6 minutes instead (cause my connection literally is that bad). Even brought up the meshmaxconcurrentthreads to 128 to purposely try and overload it. All http requests continued to operate nominally, and not time out. No buggy behavior that I can see as of yet. Will continue to test.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Excellent. Thanks for the feedback Danny!

          Show
          whirly.fizzle Whirly Fizzle added a comment - Excellent. Thanks for the feedback Danny!
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Adding some info from dev chat discussion about this problem:

          • Increase timeout and decrease mesh concurrency if you have a bad connection and mesh fails to load regularly
          • Does FSMeshRequestTimeout need a relog when changed?
            No. It works instantly for new mesh requests
          • Is the oft given advice to set a higher value for MeshMaxConcurrentRequests good or bad?

          The problem with setting a high concurrency is: if you have a slow connection and at the same time the viewer tries to download several mesh assets that are quite big, they will not finish within the timeout and the viewer tries again. if you have 32 requests that are in this state, no new mesh will load. Increasing the concurrency will indeed load mesh again, but the situation will get worse since you are now trying to squeeze even more data through the line. So actually it's better to use a smaller concurrency in that case so requests have a chance to finish within the timeout. (Thanks to Ansariel for this explanation)

          It is even a bit worse, when you're on a bad connection and you choke your download like that, there's a high change you choke your upload too, Eg lag our everything you send (like chat, movement) (Thanks to Nicky)

          Show
          whirly.fizzle Whirly Fizzle added a comment - Adding some info from dev chat discussion about this problem: Increase timeout and decrease mesh concurrency if you have a bad connection and mesh fails to load regularly Does FSMeshRequestTimeout need a relog when changed? No. It works instantly for new mesh requests Is the oft given advice to set a higher value for MeshMaxConcurrentRequests good or bad? The problem with setting a high concurrency is: if you have a slow connection and at the same time the viewer tries to download several mesh assets that are quite big, they will not finish within the timeout and the viewer tries again. if you have 32 requests that are in this state, no new mesh will load. Increasing the concurrency will indeed load mesh again, but the situation will get worse since you are now trying to squeeze even more data through the line. So actually it's better to use a smaller concurrency in that case so requests have a chance to finish within the timeout. (Thanks to Ansariel for this explanation) It is even a bit worse, when you're on a bad connection and you choke your download like that, there's a high change you choke your upload too, Eg lag our everything you send (like chat, movement) (Thanks to Nicky)
          Hide
          ansariel.hiller Ansariel Hiller added a comment -

          Some additional info:

          • "It works instantly for new mesh requests" means if a new request is issued. That are new downloads as well as downloads that are being retried.
          • A single mesh asset can issue several download requests. Hairs for instance often tend to cause several downloads. Each of those requests for a single asset count against the concurrency limit. So if the viewer downloads a mesh asset that causes for instance 20 requests, 20 download slots of the 32 slots by default are already used up. If those downloads never finish because they are aborted by reaching the timeout limit, and then end in a loop of constantly being retried, it leaves 12 slots open for other mesh downloads. Now add more meshes downloads - especially also fairly large ones - and the chance they will be even less, eventually resulting in all download slots being occupied by download requests that never finish because each one using up bandwith others requests would need to complete.
          Show
          ansariel.hiller Ansariel Hiller added a comment - Some additional info: "It works instantly for new mesh requests" means if a new request is issued. That are new downloads as well as downloads that are being retried. A single mesh asset can issue several download requests. Hairs for instance often tend to cause several downloads. Each of those requests for a single asset count against the concurrency limit. So if the viewer downloads a mesh asset that causes for instance 20 requests, 20 download slots of the 32 slots by default are already used up. If those downloads never finish because they are aborted by reaching the timeout limit, and then end in a loop of constantly being retried, it leaves 12 slots open for other mesh downloads. Now add more meshes downloads - especially also fairly large ones - and the chance they will be even less, eventually resulting in all download slots being occupied by download requests that never finish because each one using up bandwith others requests would need to complete.
          Hide
          martinus Martin Taylor added a comment - - edited

          i'd like to beta test, too Linux 64 bit (running 32 bit version of Firestorm now as there is no 64 bit version, unfortunately)

          currently i'm on Firestorm 4.4.0 (33720) with MeshMaxConcurrentRequests = 4, using a massive caching proxy behind the viewer.

          Show
          martinus Martin Taylor added a comment - - edited i'd like to beta test, too Linux 64 bit (running 32 bit version of Firestorm now as there is no 64 bit version, unfortunately) currently i'm on Firestorm 4.4.0 (33720) with MeshMaxConcurrentRequests = 4, using a massive caching proxy behind the viewer.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          @Martin
          Test build link sent in private message to your JIRA email.

          Show
          whirly.fizzle Whirly Fizzle added a comment - @Martin Test build link sent in private message to your JIRA email.
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          i want!! windows 7 64!

          Show
          skua sarrasine Skua Sarrasine added a comment - i want!! windows 7 64!
          Hide
          martinus Martin Taylor added a comment -

          I've packaged and installed the test build and I've given it a whirl - pun intended .

          Hint for all other testers: copy the file settings_firestorm-release_v4.xml to settings_firestorm-nightly_v4.xml if you want to keep your settings.

          My impression is very positive. Obviously, my underlying bandwidth problem is still there, but everything loads faster and I don't get broken mesh objects and textures anymore. Everything seems to load eventually. The bandwidth might peak, but it tends to come back down after a while.

          For reference, I used MeshMaxConcurrentRequests = 12 and FSMeshRequestTimeout = 300. I also use UseHTTPBakedTextureFetch = FALSE and an UDP max. bandwidth of 300 kbit/s. The caching HTTP proxy restricts HTTP traffic to 320 kbit/s.

          Show
          martinus Martin Taylor added a comment - I've packaged and installed the test build and I've given it a whirl - pun intended . Hint for all other testers: copy the file settings_firestorm-release_v4.xml to settings_firestorm-nightly_v4.xml if you want to keep your settings. My impression is very positive. Obviously, my underlying bandwidth problem is still there, but everything loads faster and I don't get broken mesh objects and textures anymore. Everything seems to load eventually. The bandwidth might peak, but it tends to come back down after a while. For reference, I used MeshMaxConcurrentRequests = 12 and FSMeshRequestTimeout = 300. I also use UseHTTPBakedTextureFetch = FALSE and an UDP max. bandwidth of 300 kbit/s. The caching HTTP proxy restricts HTTP traffic to 320 kbit/s.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          @Skua
          Private message sent with download link

          @Martin
          Glad to hear and thanks for banging on this

          Show
          whirly.fizzle Whirly Fizzle added a comment - @Skua Private message sent with download link @Martin Glad to hear and thanks for banging on this
          Hide
          ichbins Felicia Serenity added a comment -

          I'd like to give Whirlys test build a try as well! Win7/64bit

          Show
          ichbins Felicia Serenity added a comment - I'd like to give Whirlys test build a try as well! Win7/64bit
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          @Felicia
          Test build sent.

          Show
          whirly.fizzle Whirly Fizzle added a comment - @Felicia Test build sent.
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          i downloaded bitmeter2 and keep it running as a floater so if i get pegged out i know why and can relog without wondering why. about to install the test version

          Show
          skua sarrasine Skua Sarrasine added a comment - i downloaded bitmeter2 and keep it running as a floater so if i get pegged out i know why and can relog without wondering why. about to install the test version
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          TextureFetchConcurrency set to 8, meshmaxconcurrent to 16 and fs FSMeshRequestTimeout set to 300 let ya know

          Show
          skua sarrasine Skua Sarrasine added a comment - TextureFetchConcurrency set to 8, meshmaxconcurrent to 16 and fs FSMeshRequestTimeout set to 300 let ya know
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          been using it including a trip to 2 mesh stores. bitmeter shows normal up and down activity.. no sign of peggin out. Packet loss is hovering around .5 percent which is good for my connection 3Meg U-verse and i am running it at 500 hardwired

          Show
          skua sarrasine Skua Sarrasine added a comment - been using it including a trip to 2 mesh stores. bitmeter shows normal up and down activity.. no sign of peggin out. Packet loss is hovering around .5 percent which is good for my connection 3Meg U-verse and i am running it at 500 hardwired
          Hide
          martinus Martin Taylor added a comment -

          One further observation: I've noticed that sometimes certain textures (I think they are always mesh objects) will not load properly and remain grey for the entire session, even when bandwidth consumption goes down to almost zero. Explicit texture refresh will not help. Almost as if the client does not recognize that a mesh transfer or texture fetch has failed or timed out or whatever. I realize this is not a very good error description but I don't have more information at this point in time.

          Show
          martinus Martin Taylor added a comment - One further observation: I've noticed that sometimes certain textures (I think they are always mesh objects) will not load properly and remain grey for the entire session, even when bandwidth consumption goes down to almost zero. Explicit texture refresh will not help. Almost as if the client does not recognize that a mesh transfer or texture fetch has failed or timed out or whatever. I realize this is not a very good error description but I don't have more information at this point in time.
          Hide
          greatfox snowpaw Futashy added a comment -

          Beta tester looking to test. I'll take that fix if you're still offering it Whirls. Windows 7 x64.

          Show
          greatfox snowpaw Futashy added a comment - Beta tester looking to test. I'll take that fix if you're still offering it Whirls. Windows 7 x64.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          @Greatfox
          Build sent

          Show
          whirly.fizzle Whirly Fizzle added a comment - @Greatfox Build sent
          Hide
          hilaryquerrien Hilary Querrien added a comment -

          Can I try - um - test - too please? I had a bad day today on a hunt with lots of mesh places. Windows 7 64 bit

          Love

          Hil xxx

          Show
          hilaryquerrien Hilary Querrien added a comment - Can I try - um - test - too please? I had a bad day today on a hunt with lots of mesh places. Windows 7 64 bit Love Hil xxx
          Hide
          whirly.fizzle Whirly Fizzle added a comment - - edited

          @Greatfox
          The new beta just sent to beta testers has this commit included

          @Hilary
          Sending you download link now...

          Show
          whirly.fizzle Whirly Fizzle added a comment - - edited @Greatfox The new beta just sent to beta testers has this commit included @Hilary Sending you download link now...
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          Spent the weekend hemmering this fix.. i was stable at the home and garden expo with my friends dropping like flies muahahahahaha

          Show
          skua sarrasine Skua Sarrasine added a comment - Spent the weekend hemmering this fix.. i was stable at the home and garden expo with my friends dropping like flies muahahahahaha
          Hide
          hilaryquerrien Hilary Querrien added a comment -

          Thank you so much. things seem to be recovering a lot better now when I move into a meshy region.

          Show
          hilaryquerrien Hilary Querrien added a comment - Thank you so much. things seem to be recovering a lot better now when I move into a meshy region.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Great! Thnaks for the feedback guys

          Show
          whirly.fizzle Whirly Fizzle added a comment - Great! Thnaks for the feedback guys
          Hide
          martinus Martin Taylor added a comment -

          some additional feedback: after tweaking my router settings with regards to TCP session timeouts I can now report everything working as expected. Since the download does no longer stall I have been able to remove bandwidth control from my HTTP proxy. This has given me the best viewing experience in a loooooooooong time. ^^
          Whirly, I am still using the nightly build 33991. If there is any good reason to move to another one, or if I can beta test 4.4.1, please let me know.

          Show
          martinus Martin Taylor added a comment - some additional feedback: after tweaking my router settings with regards to TCP session timeouts I can now report everything working as expected. Since the download does no longer stall I have been able to remove bandwidth control from my HTTP proxy. This has given me the best viewing experience in a loooooooooong time. ^^ Whirly, I am still using the nightly build 33991. If there is any good reason to move to another one, or if I can beta test 4.4.1, please let me know.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          @Martin

          If you are interested in joining the beta testers team, please contact Takoda (lassie.resident) directly.
          Thanks!

          Show
          whirly.fizzle Whirly Fizzle added a comment - @Martin If you are interested in joining the beta testers team, please contact Takoda (lassie.resident) directly. Thanks!
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          i dont know where i am supposed to report a problem with the test version but

          http://wiki.phoenixviewer.com/fs_mouselook

          the bit about being able to click in-world doesn't work or just doing it wrong

          Firestorm 4.4.1 (34154) Jun 11 2013 01:34:48 (Firestorm-Release) with Havok support

          hit me up inworld if this is the wrong way to report this

          Show
          skua sarrasine Skua Sarrasine added a comment - i dont know where i am supposed to report a problem with the test version but http://wiki.phoenixviewer.com/fs_mouselook the bit about being able to click in-world doesn't work or just doing it wrong Firestorm 4.4.1 (34154) Jun 11 2013 01:34:48 (Firestorm-Release) with Havok support hit me up inworld if this is the wrong way to report this
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Heya Skua,

          When in mouselook, to click a touchable object rezzed inworld, you just left click it as normal.
          To click on HUDs you need to hold ALT and then left click.

          Also see...
          Preferences -> Firestorm -> Move & View for extra mouselook options:

          • Enable mouselook functionality
          • Show Avatar in mouselook
          • Show user interface in mouselook
          • Enable context menus in mouselook
          • Leave mouselook after regaining focus
          • Show mouselook instructions
          • Show mouselook crosshairs
          • Mouselook mode sensitivity.

          The wiki help pages are left hidden for pre release builds until the release actually goes live, then the wiki pages are all updated en masse with the versions that include any changed functionality.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Heya Skua, When in mouselook, to click a touchable object rezzed inworld, you just left click it as normal. To click on HUDs you need to hold ALT and then left click. Also see... Preferences -> Firestorm -> Move & View for extra mouselook options: Enable mouselook functionality Show Avatar in mouselook Show user interface in mouselook Enable context menus in mouselook Leave mouselook after regaining focus Show mouselook instructions Show mouselook crosshairs Mouselook mode sensitivity. The wiki help pages are left hidden for pre release builds until the release actually goes live, then the wiki pages are all updated en masse with the versions that include any changed functionality.
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          None of the above works for me whirly i can move the mouse independently of the camera by pressing alt while in mouse-look and the cursor becomes the pointer hand but when i click it just recenters the mouse cursor to the center of the screen

          Show
          skua sarrasine Skua Sarrasine added a comment - None of the above works for me whirly i can move the mouse independently of the camera by pressing alt while in mouse-look and the cursor becomes the pointer hand but when i click it just recenters the mouse cursor to the center of the screen
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Skua, can you file a support issue for that then please: http://wiki.phoenixviewer.com/file_a_jira


          Linden Lab have a fix for MAINT-2347[c] Feature Request - Mesh transfer is limited to 30 seconds per transfer. Should only time out from lack of updates, which was Danny's clone of this issue on the LL JIRA.

          Details and download links for the Beta maintenance viewer here: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Maintenance/3.5.4

          I have no idea how they implemented this fix because the code isnt public yet, but you guys may be interested in testing if things are improved for you on that Viewer 3 build.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Skua, can you file a support issue for that then please: http://wiki.phoenixviewer.com/file_a_jira Linden Lab have a fix for MAINT-2347 [c] Feature Request - Mesh transfer is limited to 30 seconds per transfer. Should only time out from lack of updates, which was Danny's clone of this issue on the LL JIRA. Details and download links for the Beta maintenance viewer here: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Maintenance/3.5.4 I have no idea how they implemented this fix because the code isnt public yet, but you guys may be interested in testing if things are improved for you on that Viewer 3 build.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          SEtting this for 4.4.6 for now, seeing as there is a LL fix in the pipeline.

          Show
          whirly.fizzle Whirly Fizzle added a comment - SEtting this for 4.4.6 for now, seeing as there is a LL fix in the pipeline.
          Hide
          martinus Martin Taylor added a comment -

          Whirly, just to clarify, does that mean the fix we have all been testing over the last few weeks will not be shipped with the next firestorm release?

          I also don't get why MAINT-2347 is classified as a feature request and why the LL fix has taken so long. Don't they realize, this is not a minor inconvenience (like the fact I have to press CTRL-SHIFT-R twice after teleporting, pffft), but but a core issue for some users, making or breaking the entire SL user experience?

          Show
          martinus Martin Taylor added a comment - Whirly, just to clarify, does that mean the fix we have all been testing over the last few weeks will not be shipped with the next firestorm release? I also don't get why MAINT-2347 is classified as a feature request and why the LL fix has taken so long. Don't they realize, this is not a minor inconvenience (like the fact I have to press CTRL-SHIFT-R twice after teleporting, pffft), but but a core issue for some users, making or breaking the entire SL user experience?
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Heya Martin,

          The fix you have been testing (which more extra options given to workaround this problem then a fix) will be in the next release yes.

          Well, Firestorm users also have not got this fix yet in a release. You guys are using internal builds. Linden Lab testers will have been QAing their own fix too. Now there is the public Viewer 3 build ready for Residents to test.

          We have no idea yet how LL have dealt with fixing this issue. We wont know this until the code is public. We cant see the MAINT-2347 JIRA issue to see any details on this.

          Monty may be able to answer the question of how LL approched fixing this issue

          Show
          whirly.fizzle Whirly Fizzle added a comment - Heya Martin, The fix you have been testing (which more extra options given to workaround this problem then a fix) will be in the next release yes. Well, Firestorm users also have not got this fix yet in a release. You guys are using internal builds. Linden Lab testers will have been QAing their own fix too. Now there is the public Viewer 3 build ready for Residents to test. We have no idea yet how LL have dealt with fixing this issue. We wont know this until the code is public. We cant see the MAINT-2347 JIRA issue to see any details on this. Monty may be able to answer the question of how LL approched fixing this issue
          Hide
          martinus Martin Taylor added a comment -

          great, thanks for the clarification. we can see the light now.

          Show
          martinus Martin Taylor added a comment - great, thanks for the clarification. we can see the light now.
          Hide
          vola Vola Le added a comment -

          hi to all
          I have made the following change:
          FSMeshRequestTimeout 30.000 to 300.000
          I entered a club full of avatars, heavily loaded mesh objects
          the result is O:O wow!!!!!
          earlier in this sim was impossible to survive in this place, my bandwidth 100% collapsed
          now without any problem, all perfect
          I'll continue testing but I think already this is a final solution for me
          thank a lot
          Vola Le

          Show
          vola Vola Le added a comment - hi to all I have made the following change: FSMeshRequestTimeout 30.000 to 300.000 I entered a club full of avatars, heavily loaded mesh objects the result is O:O wow!!!!! earlier in this sim was impossible to survive in this place, my bandwidth 100% collapsed now without any problem, all perfect I'll continue testing but I think already this is a final solution for me thank a lot Vola Le
          Hide
          vola Vola Le added a comment - - edited

          I noticed that the settings 300,000 affects mesh load so I reduced to 150,000, and the result is still as good
          my actual bandwidth is 2.5 M.

          Show
          vola Vola Le added a comment - - edited I noticed that the settings 300,000 affects mesh load so I reduced to 150,000, and the result is still as good my actual bandwidth is 2.5 M.
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          just want to say the new version is GOLDEN

          Show
          skua sarrasine Skua Sarrasine added a comment - just want to say the new version is GOLDEN
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Great! Thanks for all the feedback guys

          Show
          whirly.fizzle Whirly Fizzle added a comment - Great! Thanks for all the feedback guys
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Discussion about this problem on: http://community.secondlife.com/t5/Second-Life-Viewer/avi-dosn-t-load-correctly/td-p/2137193

          Some useful info from Monty Linden on that thread.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Discussion about this problem on: http://community.secondlife.com/t5/Second-Life-Viewer/avi-dosn-t-load-correctly/td-p/2137193 Some useful info from Monty Linden on that thread.
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          raising mesh max is incorrect solution pfft

          Show
          skua sarrasine Skua Sarrasine added a comment - raising mesh max is incorrect solution pfft
          Hide
          whirly.fizzle Whirly Fizzle added a comment - - edited

          A discussion of the new GetMesh2 capability which may be of interest: http://rcds.nfshost.com/ques_view_chatLog.php?queOwner=llsl%3ARex+Cronon&queName=chatLog&pg=1

          (https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/13#13.09.04.280593)

          (Relevant snippets on pastebin incase above log gets refreshed next week: http://pastebin.com/aEz3LQrq)

          Show
          whirly.fizzle Whirly Fizzle added a comment - - edited A discussion of the new GetMesh2 capability which may be of interest: http://rcds.nfshost.com/ques_view_chatLog.php?queOwner=llsl%3ARex+Cronon&queName=chatLog&pg=1 ( https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/13#13.09.04.280593 ) (Relevant snippets on pastebin incase above log gets refreshed next week: http://pastebin.com/aEz3LQrq )
          Hide
          skua sarrasine Skua Sarrasine added a comment -

          are there guidelines for less experienced people to dick around with the new settings say if they live in FRANCE and have crappy internet??

          Show
          skua sarrasine Skua Sarrasine added a comment - are there guidelines for less experienced people to dick around with the new settings say if they live in FRANCE and have crappy internet??
          Hide
          ansariel.hiller Ansariel Hiller added a comment -

          Closing this issue as it should be fixed with the HTTP update in 4.6.1. If there are still issues, please create a new JIRA.

          Show
          ansariel.hiller Ansariel Hiller added a comment - Closing this issue as it should be fixed with the HTTP update in 4.6.1. If there are still issues, please create a new JIRA.

            People

            • Assignee:
              shouldbeworkingonit.linden ShouldBeWorkingOnIt Linden
              Reporter:
              danny nolan Danny Nolan
            • Votes:
              5 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: