Beq Janus

I would check that your Anti virus whitelisting is still correctly in place. I don't see a reason why the LL viewer would interfere in that regard but what you are describing sounds like one of the many ways that AV and anit-malware systems can interfere with the viewer

With less than 8GB RAM and very limited VRAM you are unlikely to be able to use this machine for very much longer for SecondLife. The sad reality of life is that things are getting more demanding on hardware and this machine is significantly underpowered for second life use. There are a few things that you might want to try. 1) As @Gwin LeShelle pointed out, making sure that you have the latest stable driver for you system (this is not always the newest, and with older laptops newer drivers can cause more problems than they solve) 2) Minimise the memory demands as much as possible. Set you graphics to Low, everything will look awful, but put up with it and see if it stabiliseand does not flicker. You can help yourself a lot by restricting the texture size. (paste this into chat and click secondlife:///app/openfloater/preferences?search=restrict ) you'll see this preferences window like this make sure that the restrict max texture resolution is ticked. You'll need to restart. If you get it stable and not flickering then you can start to increase some of thew quality settings again. Please note though, that machine is significantly underpowered for modern SL and it is only going to get worse soon, there's nothing we can do about that really.

@Island Granville, firstly welcome to Firestorm; I am very pleased to hear that you are enjoying our viewer. I would advise you to follow Gavin's suggestions and do whatever you can to enable 10.13 updates. Gavin is very knowledgable (far more than I will ever be) on Mac stuff. Our (Firestorm) next release will also be moving to 10.13, the simple reason for this is that none of the build servers we have access to support anything below 10.13, and as such, we have had to move our minimum level up too. We will (as usual) have a 3-release policy where we will not block the current release until we have 3 newer ones. so you have probably a year or so left. In the past, we have also left a specific build available if it was "the last working build" for some given platform, but of course, with that accommodation, you do give up any hope of new features. I'm not sure whether we'll do that in this case (that decision comes from elsewhere) There are a lot of changes coming to SL, not least of which is improved graphical realism (known in the annoying techno-jargon that people seem determined to bamboozle users with as PBR - Physically based rendering); this is going to put a lot more demands on hardware and may well see the death of many older, less capable machines. If this does apply in your case, then, as noted in my previous paragraph, you'll get extended support in FS to a point, but there is a cut-off, so the more that people are aware and prepared less distressing this will be.

Henri, in Cool VL Viewer do you get many complaints about this from the entitled users that we all tend to have at least a few of? I'm curious because I've been planning on making discrete caches and logs for a while, but I keep holding back, wondering whether I end up with another 50/50 situation where half the people think it's good and half the people complain that now their caches are eating all their disk space. The plan would be to have a per-user cache, which would, therefore also avoid the read-only cache issues that we have today for second and subsequent instances.

Can you let me know (private message if you prefer) the name of the alt that was logged in as the second instance when you crashed and submitted the bugsplat(s)? I can sift through them and see if there is an answer. Can you check if the same issue happens when running the default (LL) viewer. If it does not then I'll probably be asking you to raise a JIRA (jira.firestormviewer.org) so that I can track this. At the very least I need to know more about the system how much RAM, VRAM, what are your graphics settings etc. Thanks Beq

Ahh Cool VL Viewer, I shall try to keep that clear in future. What I meant about 512 is the resolution limits. When FS is run using the 32-bit build, we force the resolution limit of 512x512, forcing all 1024 textures to 512 max. This makes it a lot less memory intensive to visit texture-heavy places. In the 64-bit version we also have that option as a preference but it is not enforced.

As Henri says, you might be able to get online with that just barely, but it won't run any sense at all. These days I would say 8GB is the minimum viable DRAM for basic operation, and increasingly I would be pushing people towards 12 and 16 as the realistic minimum. You can improve things a little by running the 32-bit viewer. Firestorm (and possibly other TPVs such as CoolVL) allow you to limit the maximum texture size to 512 (in FS, it is enforced in the 32-bit viewer and optional in the 64-bit). This will greatly reduce the memory demands but not enough to make 4GB viable for anything but the barest minimum.

How it got enabled is almost certainly "you clicked it", probably not intentionally, maybe you were trying to click history or something, if there was no muted text on screen then you'd have seen no change except the subtle highlight and forgotten all about it. As for differentiation, for muted avatars it will be different. See preferences->colours->muted. But in this case, the fact it is an object supercedes the fact it is muted. For all I know there was a previous JIRA a decade ago asking for that. As to why it is a button at all? I have no idea, I never even knew it was one. It has been there for a long time, though, and this is the first I have ever heard of it causing an issue, so I am going to have trouble arguing that it is a problem 🙂 However, I have made it so that it will not persist, that way the worst case is you'll be confused until you relog. The other option is to add yet another colour and I don't think that is worth the hassle And, of course, thank you for helping get to the bottom of it. Today we all learned something new 🙂

OK problem has been located. You will kick yourselves when you see it. The blocks are working entirely as designed. You have enabled the "show muted chat" button. In the example below, GreenSpammer is blocked, YellowSpammer is not. It is remarkably obvious in hindsight, but I've never clicked the button, so learned something new today, too LOL

I have a custom build, but as don't know if you are able to repro like Tessa can it doesn't move us forward

Not necessarily. I've had another person test the same scenario as @Quistess Alpha and I, and like me they block normally and as expected. I am currently building a viewer with some extra logging in it that might help us identify at what point the viewer gives up and says screw it, let it through. There are a lot of checks and conditions for whether a message is allowed through, RLV, friends only, mutelist, etc etc, so now I am wondering if you have some magic combination of settings that is doing this (or I have the magic ones that make it work)

Thanks Henri, Yeah, I was expecting to see at least a processMuteListUpdate() for the initial response though. I've not had a chance to walk it through and see where it goes. It might just write to file then load the cache, which would explain what I see, or don't see.

Ty, my test script is essentially the same (I didn't bother with the state_entry completeness). default { state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llInstantMessage("c7d8bc3e-3b7d-45a8-94f6-080913a47999", "spam!"); } } The only thing I see that strikes me as odd is that you don't get any update from the remote server when the viewer requests the mute list. It seems to only use the cached version. I need to do some digging to see if that is "expected". In the meantime if you have the opportunity to test the same cube setup on a completely different region that'll help remove that variable too.

If anyone has information that is anything other than anecdotal please add the logs and any step-by-steps to the JIRA, it may be the hint we need to determine what this missing detail is.

Thanks, it still begs the question of how that evades the user block; we're missing something here, just no idea what yet 🙂

There's definitely some truth in that. In the end an object is an object and the viewer has to iterate over them all, all those segmented bodies out there, while now far more heavily optimised in the viewer than was the case a year or so back, are still hundreds of separate parts all of which have to be properly marshalled. Imposters are "more efficient" mostly by virtue of rendering less frequently but still require everything to have been fetched in order to render them. I went to see my favourite SL musician (Tally Mercury) singing at SL20B and after fiddling was getting around 20fps (3070Ti 8GB VRAM) with Max avatars at around 26, draw distance 288. I was getting about 9 FPS (IIRC) before I reduced the max avatars, so it made "a difference" but not perhaps what we'd expected. As you can see it was "good enough" to get a reasonably smooth flycam, though obviously the imposters switching in and out is not the best. https://i.gyazo.com/ead815a44353ff8cae7b0a77d75bb0cc.mp4

As per LL (and FS) policy we will not add features until they have been considered mature enough for a full release by LL (otherwise we end up with a lot more regressions). It'll be interesting to see how this scales to large inventories, it is definitely a long-awaited feature and assuming it works well will be in great demand.

I cannot reproduce this problem (Using the current release Firestorm 6.6.8, I have no recollection of a prior issue that would have affected 6.6.3 though TBH ) Here is a 90-second video showing an alt clicking coloured spam cubes. https://i.gyazo.com/0a6927db782c04c2543c926e4511631b.mp4 (you might want to click off the audio, which I recorded by mistake, just lots of background) Each cube has the same basic script in it. As we see, clicking on each cube in turn yields a "spam" message. The centre cube is then blocked. We see it appear in the block list. The centre cube no longer posts "spam", it has been blocked. both the others continue as expected. I then block the owner (me). We see that appear in the block list and further evidenced by the attractive grey monstrosity that I become. clicks now fail, no more spam and all is right with the world I unblock, and things return as expected too. (I'll add this to the Jira, at the moment, I have nothing more to go on, it seems fine, suggesting we're missing some subtle detail). If you can add captures (to the JIRA) that show your block list and the object and the owner in question on it then that might yield more info, perhaps (worth a look) Note: I have also relogged, and confirmed that things remain blocked after relog.

Hi all, I'd just like to add another option that once setup, is far simpler and more reliable than any of the relog variants. @Dakota Linden's option should apply to any viewer while my suggestion is specific to FS (and possibly other TPVs that may have adopted the reload folder capability). You can, of course, choose which method suits you best; both will work. It is worth noting that in many cases the first step that our own support team will suggest is to confirm whether an issue replicates on the default viewer as that allows us a good frame of reference when looking for the cause. There are a couple of reasons why I am not a fan of the suggestion to create a separate folder however; firstly, this is a workaround that only really makes sense in the LL viewer because the "received" folder is hidden by design and cannot be unhidden. In FS (and maybe in other TPVs?), we allow you to unhide it (see below), negating this need. Making separate folders and moving them adds yet another set of folders to the already cluttered inventory space. Nine times out of Ten, the delivery folders will probably only have an unpacker object, which will create another folder in the main object space with the real goodies in it. If you are as lazy about your inventory as I am "cluttered" is an understatement; it is good practice to delete the received item once you've unpacked it; cleaning up as you go. As you can see from my video clip, I do not practice what I preach here, don't be like me; clean your inventory!! While we're on the subject, there are a couple of outdated suggestions in this thread that we see time and again and ought to have been retired by now, old habits die hard though ; Dakota and others have already addressed the "busy"/"unavailable" myth, ye olde marketplace was a far less robust thing, that is no longer true. I would also strongly urge you not to clear inventory as a first step; if you are struggling to pull in inventory due to some external issue, clearing a cache and pulling everything down again may make matters worse. Partial reload (see below) is thus our current recommendation. On occasion, a complete refresh will be suggested by our Support team, but normally, this will be after we've established that there are no other issues at play. Note: Dakota's guidance was also in part about establishing whether the LL viewer had the issue as well, and if not, was offering a workaround. @HayleyTurner has since confirmed that the behaviour also occurs when using LL viewer, and of course, if they are not appearing in your viewer (any viewer) then you cannot move them; in this case a simple relog to any (or the same) viewer, appears to be working to restore them. But, ideally, we should not have to relog at all; that's a very disruptive user experience. "So Beq, what's the 'better' method?"...In FS, we have preference options (of course we do, it wouldn't be FS if we didn't have a billion and one options, right?). In this case, I think one of those options will help you out by indirectly enabling you to force a reload without a relog. The TL;DR quick summary: Enable received items folder visibility through preferences, then right-click "reload". Job done. Long form... Go to preferences (avatar->preferences or Ctrl-P on Windows) in the "preferences search" box, type "received" and then click "User Interface", In there you will see two highlighted options. I would suggest that you tick both of those. The first makes the received items folder just like any other. The second option also restores the separate panel behaviour: have your cake and eat it. The following shortcut link will Open Firestorm Preferences with the search already in place, as shown in the video clip secondlife:///app/openfloater/preferences?search=received (sadly it won't allow me to embed it, type it in a new tab or simply into local chat then click it). https://i.gyazo.com/6ed11f21d43d84912a5bafe6607fbf85.mp4 These items remove the "default" behaviour of treating the received items as "speshal". Once you have these, you can treat the received items folder as if it were any other, including the "reload folder" option. This is Firestorm's main defence against lost folder contents these days; right-click on the folder name and select "reload folder". This should force a refresh of that specific folder, and assuming that the items are simply missing due to corruption or mis-delivery, they should then appear. Of course, we may have a different issue at play here, so if this does not help, please do ask in the Firestorm Support group (secondlife:///app/group/3a1be8d4-01f3-bc1a-2703-442f0cc8f2dd/about), inworld; where our support experts will apply their accumulated wisdom to help get to the bottom of this (I'm just a developer, they know far more about the day to day issues people face than I do). This discussion made me wonder why we don't expose the refresh folder button directly on the Received items pane when shown; this would further increase the usability. We will look into the feasibility of that.

Ahh, I see; that's a different scenario, but as you say, expiring stuff can be as much work. Though ideally, that wouldn't affect the fps, so there's stuff that could be done there. It is, of course, one of those wonderful features of SL that what we consider "30 avatars" may be 1000s of objects and 100s of textures.

How peculiar, there's a bug/feature/behaviour that we've been puzzling over for a while where the viewer's framerate tanks and does not recover. We've had a few reports, but nothing is consistent enough to reproduce it under observation. While "3 hours in a parcel with a crowd, then move to a shielded parcel" is not going to be an easy test to reliably reproduce, but it is at least a well-defined scenario.It might be worth looking at your logs after it tanks to see if there is anything looping or behaving in a clearly different fashion.

Interesting, this is repeatable?

V-Sync works exactly as designed (it is just the OpenGL Vsync; we do nothing else) it is just that that design is a very very very poor choice in SL, so I would very rarely suggest anyone use it. You are far better off simply using the viewer "limit FPS" to cap the FPS to a defined value. As for the design of V-Sync, you are correct; it is more acceptable in a game where you are not subject to the effects of user-generated content, where FPS can be predictable and more stable. V-Sync works by waiting for the next full draw to complete before switching the screen; as a result, if your monitor is 60Hz (60 refreshes per second - or one refresh every 16.7 milliseconds), but you are getting 58fps (one frame takes 17.3milliseconds). You will miss the screen refresh every time by a millisecond, the GPU/driver will then wait until the next refresh to complete that frame, so you only get 30FPS effectively because you are waiting for every other frame. Like I say, don't use it; it's a dumb mechanism for our use case. There was/is an issue with the default value of V-Sync somehow being restored when you installed a new version. I think that was fixed in the latest release, or if not it is in the current beta round. That is a bug, for sure, but not a bug in how V-Sync works, just that it enables it when you don't expect it to. With regards the Jira etc., sorry for the lack of response; Jira responses are often slow (there are so few of us) and for my part, I've not been pulling my weight as I've been barely able to spend time on Viewer dev for months now due mostly to being too busy in RL (work and family, nothing bad, just lots of it 🙂 ). As a result, I've not been able to look at a number of things that were on my to-do list. There are several things like missing meshes, area search weirdness, and other things screaming for attention, so I hope RL will give me a break in the coming months. We are also balancing the fact that we have a massive update in the form of PBR coming soon, so attention is also being directed there.

@arton Rotaruis likely right, use the scale control on the uploader to make the import larger, or scale it in your mesh editor before export. There are problems doing this because you cannot always easily scale it back down. It "might" be helpful to see the debug output of the log tab of the mesh uploader (though it might not shed further light) Mesh Asset Validation failures are ALWAYS because some part of the upload preparation has resulted in an invalid mesh. My guess (and that is all it is) is that in the case of the tiny parts you are using, the likelihood is that the quantising of the mesh coordinates has resulted in a zero-size object that fails to match when searching for LODs.

In blender, make sure that you are in object mode, then ctrl-A and select scale from the popup menu. saves all the faff later.