Jump to content

Whirly Fizzle

Advisor
  • Posts

    4,719
  • Joined

  • Last visited

Everything posted by Whirly Fizzle

  1. Heya Maestro, Main channel included this fix: Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent (mitigates BUG-1779[c]). I can still reproduce BUG-1779 when using the original repro with the Meeroos. The sliding of the Meeroos is no better on a main channel region. However the repro you gave on BUG-1779 using the coloured boxes does no longer reproduce. I have updated BUG-1779.
  2. Ferawri Enzo wrote: ...it caused the memory allocation to reach in upwards of 200 - 300 mb's which in turn caused many problems such as inventory issues, rezzing objects on the land were returned and error messages to follow, script errors, heavy lag and attchments not working propely. Ferawri. This bug is unfortunately not fixed yet and is especially bad on Homestead regions where the region will shut down attemps to rez when the memory allocation reaches ~ 230MB. Each time the region is rebaked, the memory allocation will creep up a little more (by approx 20-30 MB per rebake in my experience) and if you are doing a lot of terraforming, it does not take long to hit the memory allocation limit on a Homestead. This bug is being tracked under BUG-772 / MAINT-1957 (Simulator refusing to rez objects after 10 hour timeframe) so keep an eye out for a fix for this one in the deploy release notes.
  3. Perrie Juran wrote: I almost hate to ask this, but is that with the Official Viewer? Regardless, that is a huge snafu. Yeps. One alt was on the current Viewer 3 release and one was on the current Viewer 3 Beta. I also tested with Firestorm - same results.
  4. Hmm this does not seem to be working as it should. I have 2 alts logged in on different Magnum regions who are not friends. Neither alt hides its online status. Sending IM's between these 2 alts always produces the "User not online - message will be stored and delivered later." message.
  5. Cerise Sorbet wrote: I sort of expected that one to get annoying. This was a change on the Magnum regions this week -- Fix for 'IM does not respect "allow user to see my online status" flag in friends list' (VWR-786[c]) If a friend does not have 'See my online status' permission, they will now see "User is not online .." message following IM or inventory offer. No **bleep** lol I can see why they made that change but it's already irritating after one day on an RC :smileymad:
  6. If that does not work, another thing to try is disabling HTTP Textures. If your connection/router has problems with HTTP data, it can choke and disconnect you and the symptoms can be very similar to the DNS bug symptoms. On Viewer 3 or Firestorm: From the login screen, use CTRL+ALT+D to being up the Debug menu in the top menu bar then Debug -> Debug settings -> ImagePipelineUseHTTP -> set to FALSE Restart the viewer and login. If this does not help at all, set ImagePipelineUseHTTP back to TRUE again as it is best left enabled if not causing you any problems.
  7. It sounds like you have the "DNS bug". Symptoms of that include inability to upload any asset and disconnection on teleport. The workaround is to switch over to using Google public DNS . Queen Kellee has some nicely written info on this bug. For reference: VWR-26759 : Avatar does not appear to be fully connected to inworld grid / major loss of functionality VWR-25426 : Friendlist displays users as Unknown or (loading), teleports fail, assets will not save Hope that helps
  8. Heya Andrew et all, Bit sketchy on details I know, but incase useful... One of the Firestorm support teams partners was suffering from the Magnum issue. He could reproduce on both his main & alt account and on both his computers connected to the same home network - which was an ethernet openreach router. He switched ISP today back to BT fibre. He is using the same openreach router but in addition now has a new BT Homehub (http://www.productsandservices.bt.com/products/broadband/wireless-hub-router). He can no longer reproduce the Magnum bug using the same 2 computers & accounts. So, in his case it was connection related in some way, even though he had no issues at all on non Magnum regions.
  9. Shayne Hesten wrote: Suggestion... let us forget all this rubbish about packet loss, high bandwidth, poor internet connection and the whole range of technical things that has been put forward in this thread, let us see a hand raised in the air to say, Sorry, we got something wrong, version 13 is at fault, we will roll back and start over. This is not a viewer problem, it is not a user problem, it is clearly an LL problem that, it seems, can be resolved very simply, as already witnessed. You're missing the point here. They are trying to find what is triggering this bug for certain Residents and not for others. All those affected must have something in common - question is, what is it? Certain settings in their viewer, certain type of router? If we can find what that commonality is, it may help to point to the cause of the bug. For those affected by this problem on Magnum regions, it is not intermittant. They can reproduce it 100% on any Magnum region and only on Magnum regions. For those unaffected, as far as I know, no one has been able to find a way to reproduce it at their end yet. For those of you having this problem and have a laptop, if you take your laptop round to a RL friends and test on their connection, can you still reproduce it?
  10. Blake Burger wrote: I also wonder what the "Error fetching server release notes URL." is about as noted below..... . This has been broken on and off for a long time. See SVC-7598 - Error fetching server release notes URL
  11. Hi BlackMagi, That sounds like you may be seeing SVC-8130 - some neighboring regions are not visible
  12. More reports of problems on Magnum are on this thread
  13. Heya Guys, There is also discussion about the Magnum bug on the sever deploy thread Here
  14. Andrew Linden wrote: I wonder if Firestorm is using the a gradually increasing draw distance hack to help content get sorted near to far? I've heard rumors of this feature in TPV's but do not know if Firestorm is using it. Yes Firestorm has this Under Avatar -> Preferences -> Firestorm -> General -> Enable Progressive Draw Distance Stepping Code is here: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/f6b1dc9c6d32 Andrew Linden wrote: Whirly, I take it that the packetloss is primarily happening on TP arrival? Not as far as I can tell. Their packetloss appears to stay constantly high while on Magnum regions. I am at the Skybox from BUG-1460 currently and I am unable to reproduce the problems on Firestorm. I have tried with a 1024 draw distance, a 64m draw distance and with both progressive draw distance enabled and disabled. I have been sending people affected by this to test on Viewer 3 also and they have the same symptoms. I have been unable to find anything in common between the people affected by this issue and those that arnt. But those affected appear to be able to consistantly reproduce on any Magnum region and those of us who cant reproduce it have not been able to find a way to trigger it yet. Could it possibly be only affecting people with certain router hardware? I have seen a couple of reports now of internet connections cutting out when entering Magnum regions only.
  15. Just wanted to add that everyone we are seeing coming to Firestorm Support having the problems on Magnum have horrendous packetloss - 30-40% in some cases. They are only getting the high packetloss issues on Magnum regions.
  16. 16 wrote: does anyone know if there is a Debug Setting that deals with this warning. like a way to change the max of 5? 2013-01-22T09:27:46Z WARNING: LLVOVolume::sculpt: WARNING!!: Current discard of sculpty at 6 is more than than allowed max of 5 See VWR-29532 Viewer floods the log file with hundreds of exactly the same lines
  17. Maestro Linden wrote: Ah, I see what you mean, Dora. When I leave your parcel and cross the region border to the south, some of the objects in your parcel 'disappear'. Usually just disappear temporarily, but the set of objects which disappear and the duration of the disappearance varies a bit with each crossing. When I crank up my draw distance to 256m, I see the problem - when the objects are 'missing', they are appearing in the wrong region. For example, an object at 'Nautilus - Suniaton/25/8/23' is being rendered at the same coordinates in 'Nautilus - Sidobrim' when I cross into the latter region. It's a little hard to see your objects since they're somewhat small, but if you make an object such as a 64m tall red 'pole', you can see it clearly in the horizon when it disappears from your parcel. I'm fairly certain this is MAINT-1341 (internal Jira), which is a viewer bug against the 3.4.1 development viewer (the issue does not appear in your sim when using the 'Second Life 3.3.4 (262321)' viewer). Heya Maestro, This behaviour is not new. I am not sure if it is even a server bug because it does not appear to occur on Phoenix viewer, but does occur on Viewer 3 and Firestorm. I believe this behaviour is what was reported at BUG-621 What seems to happen is is that when crossing to a neighbouring region, some of the objects from the previous region "follow you over" for a couple of seconds until you move your avatar or cam. The objects you primarily see are objects that occupy the same coordinates as you although in the previous region. Is this a viewer or a server issue? Further reports of this are on the Firestorm JIRA: FIRE-8626 Sim build ghosting to next sim during border crossing FIRE-7586 Some objects disappear from regions (become invisible) while user crossing boundary of region (from the 13/Nov/12, 10:53 comment onwards)
  18. You are all describing textbook symptoms of the "DNS bug". See VWR-25426 for Windows and VWR-26759 for Mac. The workaround is the same, no matter what your operating system is - switch over to using Google Public DNS. See here or here for instructions.
  19. It's a recent viewer bug. You can see a publicly accessible paste of it here
  20. What is the name of the affected region? If you bring up the stats floater with CTRL+SHIFT+1 and look at the "Memory allocated" reading under "Physics details" what is the reading when the region is having this problem? If it is in the high 200's the region may have disabled rezzing until it is restarted. What is the exact message the tennants get when .. "the msg says the sim is not accepting them, it happens when i logon" ?
  21. Maestro Linden wrote: The only new feature new to Magnum is an increase in the allowed animation asset size. (The 60kB size limit on animation assets has been raised to 120kB.) Does this allow upload of animations longer then 30 secs?
  22. Do you have Apple's iCloud with the PhotoStream component installed? This will cause the symptoms you describe. The LL JIRA for this is a BUG so unfortunately is not public but you can see the same bug on the Firestorm JIRA HERE We have workaround for Firestorm (see Step #10 in that issue's description) but doing the same on Viewer 3 does not appear to work and just crashes the viewer.
  23. This is a known bug with MOAP and flash media Im afraid. See VWR-29397
  24. Benski Trenkins wrote: 1: does someone maybe know why my viewer is so laggy in build mode? (and only in build mode) and simply a joke compared to Firestorm (and any other 3rd party viewer I tested) 2: does someone know how to COMPLETELY shut off auto updates? No downloads in background, no nothing! only when mandatory on login screen? 1: Firestorm also had this problem but it was fixed. There were a few bugs causing performance hits when editing. To see whats causing your issue on Viewer 3, have a look at your Fast timers when editing to see what is taking up all the time. 2: No you can't unfortunately. They made it impossible to totally disable that :smileyfrustrated: EDIT: Forgot to say, the new Firestorm 4.3.1 release has full mesh upload capability and should behave the same as Viewer 3 in that respect. This was the first release using Havok for mesh uploads and full Pathfinding capabilities.
×
×
  • Create New...