Henri Beauchamp

You know, searching for any of these acronyms, with any web search engine or with this very forum search feature, would give you the answer... CEF = Chromium Embedded Framework (an embedded version of Chromium, used by the viewer to display web pages). VM = Virtual Machine TOS = Term Of Service FS = Firestorm PBR = Physically Based Rendering (the new rendering engine in LL's latest official viewer). In this case (Windows 7), this won't help, like I explain in my post above, unless you build the viewer yourself from sources (but you'd have to do it from a Windows 10 or 11 VM, since the required compiler, Visual Studio 2022, won't run either under Windows 7).

This could be caused by quite a few different things... In things that you were not told about, I would mention: A bug in the new driver that would cause some fault on the PCIe bus (thus the reboot). Solution: wait for next version and keep the last working version installed in the mean time. A more optimized driver (yup !) that would cause the GPU to heat up more than with the old driver and end up crashing. Solutions: check that you did not overclock/over-voltage your GPU, and that it is properly cooled down (careful with accumulated dust between the heat sink fins). Use the viewer frame rate limiter to lower the heating in light rendering scenes (it may seem counter-intuitive, but when the viewer is left ”free running”, rendering in a sky box at 400+ fps will cause your GPU to hit its maximum power draw while it would run cooler in a complex render scene, for which the fps bottleneck will be at the CPU level). CPU and/or DDR overclocking issue that would creep up, due to added stress (sharper/more frequent P-states/C-states/frequency transitions) caused by better optimized drivers (more threads used, for example). AMD Zen CPUs can easily be the cause of such sudden reboots when using too aggressive a PBO (meaning not enough voltage fed to the core during a frequency or C/P state transition), or too high a FCLK (DDR4/5 overclocking/EXPO tweaks). Solutions: try without OC, at stock CPU/DDR speed and see if you still crash; if not, then be more reasonable on OC settings, and try disabling C/P states entirely when pushing the CPU closer to its limits (less transitory states = less voltages dropouts and overshoots = better stability). There are also settings in the BIOS to prevent automatic reboots in case a core would crash (”Sync flood” related settings): by disabling the automatic reboots, you could get more info from the WIndows logs.

Because it is still using the old (and security-holes riddled) CEF91 plugin... Won't work any more with viewers that have updated to a newer CEF version (last Windows 7 compatible version of Chromium/CEF was v109, and current version in use by LL and most TPVs for their Windows builds is v118).

Not a viewer issue. It's a Windows 7 vs ”recent” (post February 2023) CEF issue. See this post.

Windows 7 is the problem: the new versions of CEF cannot run under it any more, meaning that to be able to see web pages displayed via the web plugin, you would need an old version of a viewer (Cool VL Viewer included: current versions cannot run CEF under Windows 7). It should also be possible to replace all the CEF & Dullahan plugin files from a newer viewer installation with the ones from an older version of the same viewer using CEF91... Also, you could build the Cool VL Viewer with the old CEF91 plugin, by changing ”USE_OLD_CEF” to ”ON” in the linden/indra/cmake/00-BuildOptions.cmake source file, but to build it, you also need Visual Studio 2022, which cannot run on anything older than Windows 10... Doh ! If you are stubborn enough, I suppose you could install a Windows 10 virtual machine (using VirtualBox) on your Windows 7 PC, then install VS2022 in that VM, compile the viewer with the old CEF, and then install it on your Windows 7 PC... But frankly, that's a lot of troubles, when it became rather obvious that Windows 7 is a thing of the past (it does not even receive any security update any more) and that it is time to install a new OS... or to migrate to Linux ! 😛

The Cool VL Viewer has no problem at all: it simply displays what the script is printing, without hiding the URL... And you are totally right on the second point: this ”feature” (Wiki-like URL links) was introduced in v2+ viewers, and I indeed chose not to backport it to my viewer, thinking it would be a bad service to the end user, who would be faced with a link without any way to see what the URL it points to actually is... This is unlike in-viewer URLs (such as for resident names which link to their in-viewer profile) or SLURLs (which are strictly verified and also have security features, such as for ”trusted”, ”non-trusted”, ”click-only” sources, etc). Call me a paranoid old fart 👴, but before I click on a link, I want first to know where it would lead me...

I just did in my above post...

Sadly, Radegast is getting quite a bit outdated... For me, the ”last known good” version is Latif's v2.18.1466, and I have no trouble with inventory or 3D scenes, so far.

I do not see any stuttering in your video... Just FPS rates variations depending on the camera FOV and the amount of objects to render in it, which is perfectly normal. Watch the texture console (CTRL SHIFT 3) and look at the VRAM usage. It is likely that, when a lot of textures are around and you move or cam around, LL's viewer fails to keep everything in the VRAM (the console will then report 0MB free in VRAM), forcing the driver to start and spill GL textures and vertex buffers into the RAM, causing stutters, freezes, etc... Sadly, your only option is to switch to a TPV, since LL removed from their PBR viewer the possibility to adjust yourself the VRAM usage. Also, most TPVs offer a frame rate limiter, which you might want to use, to avoid FPS yo-yo and useless heating (and fan noise) of your GPU when it renders way above your monitor native Vsync rate (which is perfectly useless). If you are not adverse to the v1 UI, have a try at the Cool VL Viewer: I spent a lot of time (both programming and testing) to optimize it and prevent VRAM usage overshoots; it also got a ”smart” frame rate limiter which uses the ”free time” between frames to rez meshes and textures faster.

Stupid question, but did you check Windows' sound mixer while the media are playing ? Depending on your system audio devices, it might happen that the viewer cannot ”catch” the audio level properly for your audio output device, and then it must be done from the audio mixer of Windows, or even from some mixer your audio device vendor is providing with their drivers...

To be honest, and for being myself spending 95% of my SL online time in adult regions, I do not think any significant number of child avatars are roaming them (I could likely count them all on the fingers of a single hand in one year worth of SLing): also, most of the times I witnessed such a rare occurrence, they were either politely asked to change their look or leave, or were ejected by the region owner/moderators. I personally have no problem at all with the principle of adult region = child avatars forbidden. The only problem I have is to determine what a ”child avatar” is exactly... A change in the current policy, even if not more restrictive than the above principle could lead to another period of paranoid, knee-jerk reactions from land owners/moderators (or even any resident using them), with many non-child avatars being considered as ”too childish” to be accepted. I already experienced such an issue, back when the first child porn hammer struck, while my own avatar, even if young (and rather effeminate-looking), is/was definitely not a child (as tall as myself in RL, clearly identified as adult in the profile, never wearing childish attire, never playing childish anims (AO & Co), and always role-played as a young adult, never as a child, not even as a teen): I then had to leave a few regions I used to RP in, because of such knee-jerk reactions, which never happened again ever since, in the past 15+ years or so... But I guess I might be faced with the same occurrences again, now... 🫤

It happens that the parcel info arrives late (especially after login). Like many things in SL, you just need to be patient enough...😉 But when it happens, moving to another parcel will help to kick the server's ass and make it spit out the parcel info...

Since you are not adverse to the v1 UI (Singularity, Genesis), give a try at the Cool VL Viewer: it got better VRAM and RAM management algorithms that might help you to keep things in line (for VRAM do have look to the Preferences floater, Graphics tab, GPU/GL features sub-tab, and do read the tool tips for the settings there: they are worth a user manual).

What OS ?... For Linux, the main CEF library is in the lib/ sub-directory of the installation folder as libcef.so. For Windows it is in llplugin/ as libcef.dll. There are also other CEF files (IIRC, for FS, they keep them in bin/ for Linux, which is not very ”clean” a layout: my viewer got everything in lib/, but this involves telling Dullahan/CEF where those files reside), a couple *.bin files, *.pak files with most of them in a locales/ sub-directory, some other lib*.so (Linux), *.dll (Windows) libraries for GL/EGL/GLES/VK/v8/chrome...

The libremetaverse project is a library, not a full client: it is used to connect to SL or OpenSim servers, and got a simplified renderer too, as well as simple GUI building blocks (inventory, chat, etc), but you need to implement your own UI and logic around it. RLV is one such ”logic”, where you restrict things the user can do or see, at the client level. Radegast, which is using libremetaverse, does have RLV support implemented...

The Linux SLVoice client is deprecated and won't connect properly any more with the Vivox servers in SL. You need to install Wine and let the viewer use it and the SLVoice.exe Windows client to connect.

Please see this message of mine about the parcel ”no fly” flag... Yes, you would be flying, even in a no-fly parcel (since the latter only disables the UI to start flying, and only when not in ”Admin” mode).

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. 😜