Rick Nightingale

Didn't know that, but I don't usually have tags shown. Prefer not to clutter the screen.

Well, I actually wore a transparent prim sphere on my head and it worked. Never thought of a hat... and I even have a hat folder in my inventory!

Bit of a necropost now I guess, but I was reminded of this thread today regarding the mod/no-mod thing. Earlier I was looking for hair. Good men's hair is a rare thing in SL IMO, but I finally found something close enough. Demo'd it fully, even checked that it had a script remove button. Yep. Bought it. Then I set it up and removed the scripts. Nope. Only one of the three scripts was removed. That means the hair still acts as if it is touchable to run the resizer (the only script that got removed). That means I cannot click on my head to move my avatar the way I always do (in Firestorm). Of course, the hair is no-mod. Arghh! Wish I had bought it on the MP,. not the in-world store, then at least I could have left an appropriate review. In contrast, I bought a rather nice full trench coat outfit - wonderfully made, and amazingly it is mod perms. The advert even encourages modding it and the texture HUD itself can be modified to create custom tints! Some people like to make others happy I guess, and like that their products can be further 'enhanced' by the purchaser. Even if in this case it's likely not needed because it's about perfect as it is. The seller is, I believe, a member of the furry lot. Now there are folks with the right sort of attitude to mod perms (and some cracking good avatars!) That purchase was on the MP and got a glowing review.

Thank you @Beq Janus for the super-quick work on the fix in Firestorm for this issue. Sounds like the viewer shutdown process is on the 'interesting times' side of things, as in the saying. Hopefully LL will take on board the suggestion of a more robust approach in the future. Those interested can read about it here: https://jira.secondlife.com/browse/BUG-232971 Looking forward to the next FS version

@Resi Pfeffer Funny you should say that about the anti LOD... I had that happen a week ago when I was making something. As my camera approached the object, it would vanish at the point it should be switching to highest LOD. Couldn't even select it; as if it really didn't exist. Did it persistently on several objects. No (for those going to point out the obvious) I hadn't messed up my LOD models. The models were fine. After swearing for half an hour, rerezzing and reuploading my model several times, I relogged and everything went back to normal. I can't help feeling all of these things are somehow linked to the new, 'improved' code.

Like other's said, I've not filed a Jira because I couldn't get any way to reliably reproduce it, and until today hadn't heard anyone else mention it (other than the usual things on a random group about "my beard fell off when I TP'd"). I tend to assume things are local issues (internet, or maybe my asset server) unless I hear others complain or can rule local things out otherwise. I think Lucia is correct that it's more frequent since the performance code update. More frequent, and more severe. In my case, moving the camera about only occasionally brings something back. I have other things going on like a statue (one of an identical group of them in a row, but linked to different things to combine LI) that insists on showing my the Lowest LOD almost every time I go into the room, or even just have it out of my view for a minute. Just that one, the others are fine. I should not even see Low LOD within 100m of it! It stays like that until I walk closer to it when the viewer switches to highest LOD.

Had this happening a lot recently (several weeks); far more than normal. Everything from my demon's attached horns to my entire house and half my garden, leaving some furniture floating in the air. Also shop buildings in skyboxes where the entire shop (apart from items for sale) is not there; feels like I need to start flying. Sometimes it's just the viewer that forgot to draw them and clicking makes them appear (like my horns and beard) but when it's a building or similar, it's just not there. Like you OP, no significant packet loss and no network issues apparent. Sometimes a double-click TP a few m away makes them appear, sometimes not. Zooming the camera out beyond draw distance and back does nothing to help. One shop I visit often, I'll TP there, and half the building is missing. TP out and back (but still in same region), it's all there. TP out and back again... it's gone again. I put it down initially to using a Firestorm beta, but doubt that's the case now (and no-one else mentioned anything wrong in the preview group). Something is certainly an issue at the moment.

@NiranV Dean The inventory cache files in question aren't shared; there is an individual cache file for each account so there's no clash there from multiple instances*. A quick relog of the same account, on the other hand... I'm 95% certain that I have had cache loss from quick relogs during all of this, but haven't been able to reproduce that over the last few days. From watching things, my theory is that my PC is, overall, just slow enough to take long enough to start the viewer up again and get to the point of logging in. That gives the cache writing from last time just enough time to finish on its fast SSD. I've watched the filesystem and seen the gzip file get finished just at the point of the (reloaded) viewer being ready to log in. I do sometimes have a lot running on that PC though, so perhaps something slowing filesystem access down a little while I'm relogging swaps that fortunate timing around. The next viewer logs in before the cache is written from last time and causes a problem as access to the (unfinished) file clashes. All that's just vague guessing though since I've never looked at the code. *Edit: I wonder what happens if I run a second viewer instance, and log in the same account on it... I know the first login is then auto-logged off by the server, but I wonder if the cache files in that case get messed up. Academic musings... I'm sure it will all come out in the wash now it's being looked into properly.

Thank you Whirly. I fully concur with the "this-app-is-preventing-shutdown" message (and actually do so while the cache is finished) that should be generated in this circumstance

I'm using 6.6.8.68355 (release candidate) here... I've used I think every beta since the last release which introduced the huge jump in framerate. This latest is performing just the same as the last few for me with high frame rates, quick enough texture loading, etc.. Everything seems good even in 'busy' places.

Yes, thank you Beq. Let me know if you need any more tests doing; I'm happy to help. I thought the end of the logs (I did look at them) seemed to end abruptly. I imagine this one will be tricky to investigate, given that it only seems to happen during a Windows shutdown or user logoff. I've tried but failed to get it to reproduce with quick relogs (no shutdown) this morning, even with multiple accounts relogging simultaneously to push the file system. That might be a red herring then, at least on my PC.

Yeah, that's logical. A bit like me watching the viewer's logoff process like a hawk for a week but never catching it 'in the act' of corrupting that file. I never would, until I stopped watching it and went back to behaving normally 🤣

I can confirm the same cache loss in the official LL viewer with a quick shutdown after the viewer apparently closes. Should have tested it before but I really dislike loading that viewer.

@Beq Janus I've done that. https://jira.firestormviewer.org/browse/FIRE-32453 I added several logfiles as I noted in the Jira. The results of the tests were exactly as before, with the addition of testing logging my Windows user out instead of shutting down the PC (quickly after closing Firestorm). Same result of cache loss. There are two logs after cache loss from a quick shutdown, and one log from the Windows log out. Probably more than you need but better to have it, and not need it... lol. Hope that helps.

I'll get on that later @Beq Janus - maybe tomorrow when I can concentrate better on what I'm doing. Your very compressed summary is correct. I concur regarding the 'truncated' gzip file being usable - being odd. I would have expected it to be simply unusable if truly truncated. I did look inside a truncated gzip and inside was the (shorter than it should be) .inv.llsd file. Yes, if the .t file writing is truncated by the start of Window's shutdown process, but then somehow the gzip process is still started on that truncated file... that would answer that but be quite 'interesting' as you say. Certainly it is related to Windows being shut down before the cache file is fully written, whatever the details of that are. I've run too many tests now without any deviation from what I have observed. Quick shutdown = 'truncated' cache file = missing inventory next time; 100% of the time. If I wait until I see the gzip file finish writing before shutting down... no problem.

Occasional frog: Or a greeny mer (not my usual triton): Sometimes a half-wulluf: Often a horny little demon: ...who grows up bigger: And sometime, just sometimes, a human:

I only use gmail for spammy, unimportant stuff that I don't really care about google indexing. Like general shops and forum registrations. I'm not into reading email on a web page at all. I've tried various PC email clients over the years, from free to expensive, but found MS Outlook to be the most reliable and versatile overall with numerous email accounts and types. That bugs me (being MS), but so be it. I also now use Mailbird, just for gmail, since they changed their authentication to prevent my version of Outlook loggin in. My accounts are a catch-all email account that I pay for at an ISP and have used since the Internet's very early days, and several on my own domains.

Yep - I was quite explicit as to the cause once I figured it out, as I have been in this thread. I basically got told I shouldn't be turning my PC off until it was ready (never mind about how should I know when that is? Or why a program isn't doing the obvious, simple thing of pausing shutdown while it saves its data) and it was my own fault (or I should talk to Microsoft about it, lol). End of story, lol. Good luck with yours - I've voted and watched it. I'm wary of commenting in case they just link yours to mine and close yours too.

My Jira got closed as 'intended behaviour' after jumping through the usual hoops. https://jira.firestormviewer.org/browse/SUP-27008

LOL - it's years since I've heard that one! But then it's years since I did serious (i.e. paid) programming.

Nope - usually a cloven-hooved demon. Occasionally a Triton who can shape-shift between tail and legs. If not that, it varies... but basic human probably accounts for <25%.

I have often done quick relogs too... I did wonder if that was also a cause since I noticed inventory loss issues on alts at times other than powering off/on the PC (but it could be that I had already had the loss on that alt and only just logged it in since it happened). I never put that to the test once I figured out the powering off issue but it seems likely. If the viewer is relogged on the same alt, trying to unpack and load a cache file before the previous viewer's thread has finished writing it... I can see that happening now I know the viewer's exit code is poor. In my case I usually relog like that because I've had several alts logged in together, testing something or other. Eventually the viewers can get a bit flaky when doing that, depending on what I'm up to and the graphics loads on them, so I'll log them all out and relog once they've all closed. I've not done recently because my work pattern is a bit different right now, and since making sure I don't power off for a few minutes (I watch the cache files being written if I'm just waiting) I haven't had any loss. On occasion though muscle-memory has kicked in and I've shut down after the viewer closes and, yep, sure-fire way to get cache loss every time. My annoyance with all of this is that it is, and should be, simply avoided in the exit code even with the pretended quick exit. Just use the same "No, Windows, you can't shut down just yet" response when Windows sends the shutdown query that a simple notepad application with an unsaved file uses. Likewise for the rapid relog issue, try restarting something like Firefox (the web browser, not a typo) quickly... "sorry, Firefox is still running" - and no doubt doing its housekeeping in the background, having only apparently closed. Instead, the response to it all seems to be "This is intended behaviour and it's a layer 8 problem".* * Edit: For those who aren't network nerds like me, layer 8 means the user is the problem

Sorry for the late reply. To be honest I'm happy going to the beta grid for physics testing. I would go there for most testing anyway, for texturing, optimising LODs and LI etc. I could always just add the physics model as another local mesh, to see it, if I need to. Thank you for your continued improvements of all of this type of stuff... it really makes a big difference to us!

Yep - no triangle messes - life is good. Have another star 🌟 I wouldn't say I enjoy making lower LOD models; it's just part of the process that I see it as essential for a good result. And I do enjoy the results. I've never seen an uploader-generated model of anything remotely complex that I couldn't both improve visually and reduce the LI of. I'm still learning... and have a long way to go. I always start mesh builds at medium and then copy that set to start off the high and low models. A few parts (more complex shapes/lots of faces usually) in that I'll start at the higher detail before copying because I find it easier to then reduce it in medium, than to add topology for the high. Quite often my high LOD will be almost identical to medium but with added bevel modifiers and hardened normals. I know there are automatic tools in Blender to increase/reduce triangle count, but I almost always prefer to do it manually for the sort of things I make. Like you say, it depends on the intended use, distance it's likely to be viewed from, etc.. I test builds at LOD 2 and try to get them so that there's indescernable changeover between the models at that. I shop at that setting too, even though I tend to run at LOD 4 on my land; I like a long view and not all of the stuff is mine with good LODs. The ridiculous number of triangles in some models is an ever-present annoyance, from a number of sellers old and new. As is the instruction from them to set one's LOD at 4 or higher because of their useless lower LODs. I bought a plate of food off the MP; took a chance without a demo - a rare thing but it wasn't too expensive and looked just what I wanted. It was beautiful (stood next to it) but had a ridiculous 70k+ triangles in high LOD, obviously uploader generated lower models and the thing turned to a mess just outside the small room (at LOD 4!). Rather critical review left on that. Conversley, I've bought a lot from What Next (which I discovered recently) and their stuff is a tenth of the triangles and stays looking good until it's so far away I can't see it anyway. I contacted the maker there to say how impressed I was with that and their use of imposters. I find imposters a great tool for some things. I made a hanging cage yesterday, and the lowest LOD is a photo of it. It's white, so can be tinted to match the colour of the bars. If anything, the issue was that the viewer showed the imposter better than I could see the low LOD before the switch. It was tricky getting the imposter not to pop out - did that by adjusting the mask value on the alpha. A bit too high and the viewer didn't bother to draw it at all, too low and the imposter was too 'much'. Got there in the end, lol. Making a functional gantry and winch for it now. Just wish we had PBR already - this would be perfect for it. Everything I make is for me, but I'll often make it with a view to also selling it. Some of those I'll make multiple LOD versions. The cage has two versions, one as above and the second with both the low and lowest as the imposter. That saves another 1.2 LI, and more if someone made it bigger. At LOD setting 2 in the viewer, the second version still works nicely and if it's in a room (even a large dungeon like mine) it's fine. Outdoors, while the lower LI version still works well at LOD 2 (and better than any I looked at to buy, which is why I made it), I prefer the look of the higher LI version. Similarly, a gazebo I made has two LOD versions so people can choose. I made some full perm bits a week ago and they were uploaded in three LOD versions, for optimising in LI and viewability depending on how big they are made. From cm to 20m+. All of them are 1 LI at 2m cube bounding box in size.

I like the Bandit 60 because it's closest to the sort I used to dream of sailing around the (real) world in. Getting the hang of sailing is quite easy in SL - with the benefit of not getting wet and trying to hang on to a line when the wind gets up and the boat heels over 45°. For pirating, I made my own top-sail Bermudan sloop with a much improved Tako-origin script.