Henri Beauchamp

In NVIDIA's GPUs case (with NVIDIA's proprietary drivers), it runs better (about +5 to +20% fps rates, depending on the rendered scenes) because Linux (the kernel itself) got less overhead and (way) more efficient I/O (much less frame rate ”hiccups” while moving around and crossing sim borders, for example). In AMD's GPUs case, this is both because of the above and because of AMD's deficient OpenGL implementation in their own drivers, where they are replaced with Mesa under Linux.

The problem might be that with a middle-range, aging PC, you are using a high resolution monitor: your snapshot is 3840x1961 pixels wide, meaning that unless you took a ”high res snapshot” (which doubles the native resolution), you got a high DPI screen... If this is the case, then on a ”standard” (full HD) screen, you'd get much better frame rates... And yes, with a high res monitor, an RTX 3070 would far better, but not that much either (I'd say you'd get twice the fps or so in this spot), because the CPU single core performances would become the bottleneck. With a 1920x1200 screen (i.e. slightly over full HD which is 1920x1080), a 9700K @ 5.0GHz (locked on all cores), an RTX 3070 (2025MHz graphics clock, 16000MT/s VRAM clock), running the Cool VL Viewer under Linux, with all graphics settings maxed out, including shadows on, I get 60fps, for a draw distance set to 256m. And 150fps with shadows off (not much of a difference in this spot, visually, so I could not tell if you had shadows on or off from your screen shot): As for the CPU and GPU usage, with shadows on, it was 36% CPU (~ 2.9 cores loaded), and 42% GPU.

I come back to this thread and... Wow ! I never thought such a minor ”issue” could inflame people like that ! 🤣 But, please:

What is already worn at the same spot, of course... Maybe ”Wear/replace” then...

Rename it ”Replace”, perhaps ? Or ”Wear & replace” ?

Maybe, depending on what is the root cause for the crashes (if it's a bug in the graphics driver, it won't solve it)... Always worth a try, anyway.

No, the full contents of the About floater. Without any info about your system (especially GPU brand/model, RAM, GPU drivers version etc), we cannot even start making hypothesis...

Using LL's official viewer, what happens when you right-click and ”Edit” the unresponsive HUDs ?... If you can edit them, they are ”touchable” but their script(s) is(are) ”simply” stuck (or maybe crashed). If, when right-clicking, another (invisible) HUD object is selected (outlined), then just ”Detach” it with the context/pie menu... Oh, also... You are in a parcel/land allowing scripts, are you ?...

There might be two issues at play: Your viewer has registered a RLV touch-restriction and is simply reapplying it on login. The scripts don't restart, or restart too late (i.e. you loose patience before they do ), and the said restriction can therefore not be refreshed/reevaluated. Your viewer should have a RestrainedLove log/restriction floater of sorts, where you would be able to see what are the current restrictions in force. Otherwise, and as suggested above log in with RLV disabled or a RLV-less viewer (such as LL's official viewer), and see if it solves your issue...

This issue got strictly nothing to do with RLV or the viewer in use. It is a scripts deserialization (*) issue, server-side. ------------ (*) When your avatar changes region, a handover is done between the departing and the arrival sims. That handover involves pausing the scripts and serializing them (kind of ”zipping” their data/state), the serialized data being then deserialized (”unzipped”) on the arrival sim. Once the scripts ready, they are un-paused to continue their execution where it was suspended. This process normally takes a second or two (the more scripts, the longer it takes, of course), while here it can take a full minute.

I have noticed this issue happening from time to time for the past two weeks or so, especially after far TPs. This is ”just” a long delay (several seconds to almost one full minute) between the arrival in a sim and the scripts states restoring; just be patient and wait for the scripts states to be deserialized... I will mention this issue at the next SUG though, since it might be related with a recent server-side change.

This specific bug is a race condition between the interest list data sent by the server and the rebuilding of spatial groups in the viewer render pipeline; it is normally ”seen” (no pun intended) happening after login, a TP, or a sim border crossing. Some viewers (TPVs, not LL) got workaround(s) for it (usually ”manual” ones, involving selecting a ”Refresh visibility of objects” or equivalent item in a menu); the Cool VL Viewer implements an auto-refresh of objects visibility for the three cases when such an issue might happen (login, TP, sim border crossing). For viewers not implementing any specific workaround, the most reliable way to make such ”invisible” objects pop into existence, is to toggle the wire-frame render mode on/off. As Animats wrote, there are other possible issues that can lead to ”invisible” objects, but the one you described is only due to what I just explained.

Most viewers do not even bother distributing MSVC runtimes (or they distribute it with missing DLLs, or without repeated copies in llplugin/ sub-folder, because yes, Windoze sucks big time and SLPlugin.exe won't find the runtimes if not placed in its own ”home” folder), resulting in such errors when the runtimes are not installed system-wide (and one viewer I tested and I will not name by pure charity, is, on the other extreme, installing unconditionally system-wide runtimes while there are already present on the system). There are also Micro$oft bugs in their own runtimes, e.g. with vc143 (VS2022) runtimes that complain about missing ”api-ms-win-core-com-l1-1-0.dll” on Win7, because the corresponding runtime DLLs (*140.dll) reference that (Win10+ only) library (which is not part of the re-distributable VS2022 runtimes), while they do not even make any use of it (I can tell this for sure, because the viewer would nonetheless start and run just fine, after ignoring the missing DLL Windoze error dialog)... 🤪 This is why, for the Cool VL Viewer, I always test my installer on a VS-runtime-free Win7 VM, to ensure no such problem will ever occur.

This is called EU regulations ! 😛

I never saw any UDP packet loss due to to high a UDP traffic (and I have my limit set to 16Mbps in my viewer) ! This is an urban legend that needs to cease. UDP messages processing takes very little time when compared to the rest of the ”ancillary” tasks the viewers must deal with. One of the most heavy such task is by far textures prioritization, now that almost all the rest got pushed to threads.

You might be (alas), a tad bit optimistic on the release date for a Vulkan viewer... Vulkan-capable GPUs That's a pretty big list, and most (i)GPUs released in the past 8 years or so can do it... Plus, there will likely be a transition time with OpenGL viewers still maintained for some time. I'm afraid that the bar will be raised much sooner however, with the future PBR viewer (which, at least for now, got rid of the less demanding forward rendering mode)...

Running Win7 in a VM won't allow you to run OpenGL applications such as the viewer... Beside, the whole point of keeping Win7 (against Win 10/11) is because it runs most applications faster (this is true of the viewer), so running it in a VM (even if you could for that particular app) on a slower system makes no sense whatsoever. 😜 The main problem is to find proper drivers to go with modern hardware, especially modern CPUs with built-in USB controllers, for which the motherboards rarely ever implement alternate/supplementary USB ports that would be recognized natively by Win7... I managed to install a Win7 partition on an i7-9700K and a Zen2, using hacked drivers, but I'm not sure it would be possible any more with newer CPUs. +1 And you do not even need Windows at all ! I can run most Windows programming software (e.g. Xgpro for a TL866 II+ programmer) under Linux, via Wine !... But it runs as well via a Windows VirtualBox VM running under Linux. Also, MCU makers often provide native Linux tool chains (e.g. Microchip's MPLAB IDE+IPE)...

The ”preferred language” changes with the situation, so I personally prefer a free form text field (mine contains ”French (never used for role-plays) and English”, meaning I prefer English for RPs, and French for the rest, with people speaking it). As for scripts, there is already a setting to ”share language with objects”, meaning the scripts can already use that setting, when enabled, via llGetAgentLanguage().

If I were the implementer for an achievements feature, I'd use smaller icons than yours, however... 🤣

Ah, sorry... This is not what I understood... I thought he was trying to save a preset and failing to do so (because the said preset would be overwritten in the installation app_settings folder sub-directory)... The reason behind this misinterpretation of mine is that it rang a bell in my mind, with an issue I had in the past (I would have to re-check, but I rarely ever boot under Windoze, so...), where Firestorm failed to remember an override for the Rear camera preset (I hate the ”look at the ground” default, and always change the Z offset to 0.0 so that my camera looks straight instead), and I had to change it manually by editing the corresponding preset file in the app_settings/ installation sub-folder... Not trying anything else than to help and diagnose issues... Honi soit qui mal y pense !

@Coffee Pancake Err... Thanks, but no thanks ! I can already foresee dramas caused by such a ”feature”, and frankly I do think LL did the right thing™ when they removed ratings, back in... 2007, IIRC ? On the other hand, I would be all for an ”achievements” system, to help newbies mastering the viewer and world features and improving their SLing skills. In my view, the rewarding in such a system won't be money, however, but just an achievement score in the profile; perhaps even with check boxes so that everyone can see what achievements have been fulfilled... In the recently (and stupidly) removed ”Interests” tab, for example ? 😜

I depends whether you are careful not to cross two borders in less than 3 seconds or not. If you cross a lot around sim corners, you risk disconnections... Same thing if you perform a U-turn crossing a border. Using the mini-map to visualize the sim border (when your viewer got that feature) helps avoiding such ”dangerous” situations.

To avoid such a problem, settings overrides (whatever the settings type, i.e. including presets), should go to the user_settings directory (%AppData%/Firestorm/user_settings under Windows)... I.e. Firestorm code needs fixing for this. 😛

Your opinion, not mine, neither the one of, I would bet, many thousands of SLers... Again, please do a proposal to replace it (and I am eagerly waiting for what could be improved and be made ”better”). But asking or applauding for its removal is just showing disrespect and condescendence towards people who, like me, find it incredibly useful and valuable. Oh, also, I'm not a dreamer... Dreams rarely ever become true !

To avoid a ”robot-like” avatar, I implemented the look-at limiting in a smarter way for the Cool VL Viewer: you set a distance under which the viewer keeps broadcasting your mouse focus, and your avatar therefore keeps moving its head, as long as you do not focus your mouse on an object beyond that distance. I have that distance set to 20m, for my own avatar, which also corresponds to the ”say” distance and thus does not impair role-playing or OOC chat interactions (when within chat range, people are less ”surprised” and less likely to be ”upset” by your interest for their avatar). I also implemented a reciprocity algorithm (because I find it unfair to allow ”spying” others' focus while preventing them to see your own): when you limit the look-at focus, you cannot see the names of the avatars on their own focus crosshair when the latter is farther from their own avatar than your own configured distance limit... Finally, to try and get a better usefulness for that ”look-at” info (and better than being interpreted as ”spying”), I implemented a (configurable) timer: when someones looks at your avatar (i.e. with their camera actually focused on it) for a continuous period of time (30s by default), the viewer notifies you (via a notify tip) that they are showing interest in your avatar. This is something which, I think, helps increasing the opportunities for role-play and socialization...