Henri Beauchamp

The Cool VL Viewer v1.32.0.17 got a workaround for this and will actually log you in the same flying/non-flying state as when you logged out (also, this is a per-account setting in this viewer, unlike others which use a global setting: I fixed that silliness a little while ago).

Dullahan/CEF is using the OS' installed CODECs: Win11's ones are likely more up to date...

In fact, those spurious ObjectUpdate's messages have mainly been an issue with agent attachments, for C++ viewers. Gory details here (in paragraph 1). So yes, most TPVs do have code to ignore those bogus ”kill attachment” messages, in one form or another... However, the agent stays rooted to the region it arrived in, even if the departure sim says otherwise via a bogus ObjectUpdate: the agent only changes region on ”AgentMovementComplete” (which callback is process_agent_movement_complete() in llviewermessage.cpp), and therefore any position received from another region is ignored. You could do the same thing with Sharpview...

The ”no fly” parcel restriction is only ”enforced” viewer-side, and can actually be bypassed by enabling the ”Admin” mode (CTRL ALT V with most viewers). So, if you are flying before a TP, you will keep flying on arrival: the server won't have any say in ”flying” matters and follows what the viewer tells it via the ”agent flags”. Thus why this ”flying on login” issue is a bug, and why the viewer does not ”reflect” the flying status with its UI in this particular case.

Well, you can convert a prim-based builds to the LI system, and it is usually very worth it in term of parcel prims usage: once converted to a ”convex hull”, a non-tortured prim land impact is reduced to 0.5; convert it to ”none” (child prims only, not the root prim), and you might even reduce the total LI of the object further (though, it usually only affects the Physics cost, which is still a good thing for the sim health, reducing the Physics engine lag). The only caveat is that you must do the conversion in a place where you have plenty of unused LI (a sandbox is the ideal place for this), or you risk to see your object returned to your inventory should the LI algorithm go wild (it does happen, especially if the converted prim is a tortured prim) and suddenly causes the object LI to skyrocket (I have seen 30 prims objects exploding to a 200+ LI); for best results, ensure you start the conversion with the root object (changing its type from ”Prim” to ”Convex hull”), then continue with children, and as a rule of thumb (but there are exceptions too, depending on the prim actual usage/function/torture level) do not attempt to turn tortured prims to ”Convex hull” (but you may convert them to ”None” with many benefits, as long as you do not need them to collide with avatars). Sculpty prims, however, should not be converted (even as a child with ”None” type, they will always account for 1 LI and most of the time 2 LI or more). Once the conversion done, you can see very nice benefits in term of LI (sometimes 50%). Also, the LI is rounded in a 5/5 way (i.e. a an object with a 1.49 LI will account of 1 LI/prim in the parcel allotment, while an object with a 1.50 LI accounts for 2 LI/prims): by cleverly linking objects together (or on the contrary splitting some), you can lower your land prim usage, using this rounding to your advantage (i.e. maximizing the number of objects with a xx.49 LI)... 😜

The feature in question already existed ! Before this bug, when you were flying at logout, the viewer remembered it in its settings, and made you fly on next login... LOL, yes, good point !... Well, fixed (worked around) already in the Cool VL Viewer v1.32.0.17 I just released... 😜

Wild guess: a playful Linden's April fool ? 🥳

Workaround already implemented in the Cool VL Viewer for next Saturday's release. 😜

I have one novelty I noticed, but that I don't think will be listed in the release notes: On login (with any viewer), the avatars now always fly (*) Annoying... 🤪 (*) Until you click with the mouse in-world, at which point the viewer will update the flying state; normally, the avatars should never be flying on login, and it is the viewer which sets the flying flag (if needed) and informs the server of this, based on a saved setting (the flying state is saved on logout in ”FlyingAtExit”)...

Most likely a race condition. I did not investigate, since I would expect from LL that they fix their own mess... Sadly, they currently seem busier pushing new features (which will of course introduce even more bugs), rather that fixing all the outstanding PBR bugs (moires on water with SSR and non-working water reflections, blue hue on shiny objects unless you hack EE settings beyond repair, broken shadows, broken alpha with shadows on, broken semi-transparent faces on legacy contents, etc, etc, etc...). 🫣

Precisely no... This is a new bug that only happens in PBR rendering mode (the fact I can switch between all three forward, ALM and PBR modes in the Cool VL Viewer allows me to be 100% affirmative on this): the old bug does have a workaround (that has been implemented for years too, in my viewer, including with an ”auto” mode, on login, TP and sim border crossing), but this new one does not have any other work around I could find, beside the OP's one (i.e. zoom out beyond draw distance, wait a few seconds, then restore camera to normal view). This is not to say that you got that bug in Sharpview: on the contrary, I do believe this bug is specific to LL's PBR renderer code (C++, shaders, or a combination of both, and most likely a race condition too).

The PBR renderer is especially sensitive to this... Probably a race condition in the occlusion code. Even with the Cool VL Viewer (which got a workaround for such cases, workaround which always work for its ALM and forward rendering modes), when in PBR rendering, I sometimes observe this phenomenon (and the ”Refresh visibility of objects” workaround is helpless in this case: only the zooming out of draw distance can fix it)... 😢

I don't have the sources, to start with...

It would likely compile just fine on a Linux aarch64 SBC (Orange Pi5B, Rock Pi5B, Raspberry Pi5, etc), and might run fine on them too, though at low FPS rates. With the sources (apparently not yet available), I could give it a try on my Orange Pi5B...

It will work fine (CPU and GPU are plenty powerful enough), but you might want to verify if you can expand the RAM (are there free slots left, or are all the motherboard slots already populated, because then it would mean buying 32GB (2x16) of DDR4 instead of an additional pair of 16GB (2x8) DIMMs if/when you want to update). 16GB is really a minimum for SL, nowadays, and you would be much more at ease with 32GB of RAM (the viewer alone can easily consume up to 24GB of memory in heavy environments such as scenic sims with a gazillion of meshes and textures, or very populated places with dozens of avatars wearing complex attachments).