Henri Beauchamp

Release notes for 2021-12-10.566713 are not accessible (access denied)... 🙄

You mean something like this ?... 😜 The textures in this test sim are not large enough to saturate the bandwidth... Note how fast the Cool VL Viewer rezzes it too (about 15 seconds, starting the timer at the ”Loading world” login step), here on a 9700K @ 5GHz with 1Gbps FTTH Internet link.

Same thing with Radegast: Login response failure: Notation LLSD parsing: Unknown type marker 'S'. I had a support chat with TJ who escalated the issue to the relevant team... Wait and see.

NFT = New Form of Theft ?... 🤣 EDIT: or (better ?): Nefarious Fake Trading

32 bits viewers are a thing of the past. Period. Even I, who is known for being very conservative with regards to ”novelties that are not so great”, ended up abandoning completely 32 bits platforms for the Cool VL Viewer. The reasons are many: A simple poll (and the subsequent abandon of the 32 bits compilation support which did not raise any protest) demonstrated that not a single user of my viewer (which is known for being used by many people with ”old” hardware, for it is easier on them) is missing it (i.e. no one was using a 32 bits Cool VL Viewer when I dropped support for 32 bits). All viewers need SSE2 support, and now (because of CEF v89+) SSE3: the latter is not available on any 32 bits CPU, and very few 32 bits CPUs offered SSE2. Even when running on a low memory system, and even though the 64 bits viewer binary does use more memory than the 32 bits binary one, the 64 bits binary is way stabler. Why ?... Because of virtual address space fragmentation. Keep in mind that, even on a 64 bits OS, the virtual address space is limited to 4GB for 32 bits binaries (and 3GB or even, horror, only 2 GB (for some 32 bits Windows systems) for programs running on a 32 bits OS: the rest is reserved for the kernel memory). Whenever the virtual address space gets too fragmented, some memory allocations will fail, because the memory manager will be unable to find a large enough contiguous *virtual* address space block. This got nothing to do with physical memory fragmentation (which is easily solved via MMU paging), but it affects all 32 bits programs (while the 64 bits address space being virtually illimited, it is never a problem for 64 bits programs). Over time and as the session lasts, your 32 bits viewer will end up crashing (or, in the case of the Cool VL Viewer and thanks to its memory safety checks and allocation failure fallback code, to notify you to please relog at once before it will crash !). The boost::fiber code now in use in all modern viewers (and which replaces a LL-brewed/forked boost::dcoroutine class) is totally bogus under Linux 32 bits and crashes immediately the viewer (so, I had to maintain a dual-path code just for 32 bits, with the use of an outdated boost library for it). Since, obviously, no other project is using boost::fiber in Linux 32 bits code, no one cares about that (or those) bugs... Don't take me wrong: 32 bits viewers were a better solution in the past (when there was no or few meshes, no materials, no Bento avatars, no animesh, etc, when having/buying 8GB or RAM was a luxury, and when some 64 bits CPUs were actually faster at running 32 bits code, which is no more the case), but now, they are simply deprecated. Conclusion: install a 64 bits OS and use a 64 bits viewer, even with only 4GB RAM: you will get a stabler SL experience, but of course, you will have to limit your texture memory to something reasonable (512 to 1024MB at most), and draw distances at 256m or less (depending on the complexity of the scene and the amount of neighbouring sims).

Memory allocations failures may happen if: You are using a 32 bits OS (time to upgrade, really...) or a 32 bits viewer on a 64 bits OS (this is totally silly: use the 64 bits viewer version !). If, while using a 64 bits OS and a 64 bits viewer, you do not have enough RAM+swap space and are demanding too much to the viewer; e.g. setting a very high VRAM texture amount (keep in mind that the viewer will use about 1.5 times of RAM for textures as you what set for the VRAM), or draw distances beyond 256m in sims with neighbouring sims all around (such as in main land). Not all viewers are created equal (mine is using less RAM and got many memory allocation failure checks and fallback code paths that prevent abrupt crashes), but all will fail at some point, when your system cannot cope with the amount of RAM they need due to the settings you are using. Nowadays, 8Gb or RAM is pretty much a minimum, especially in complex rendering situations. 16Gb or more is recommended, if you want to push the settings upwards (especially the draw distance and the texture memory).

I did add the ”sticking out tongue” smiley for a purpose... I'm quite the teaser, you know. Don't take it as an attack, for it is not ! 🙂 Err... On my calendar, the year counts 52 weeks, not 56... 🤣 As for the viewer branches, I do not always maintain three in parallel. The legacy branches only exist for a while whenever a breaking change happens in SL for ”old hardware”, such as the v1.19 branch (with 90 releases), which was the last up to date pre-Windlight viewer available to log into SL (many graphics cards could not do Windlight back in those days)... As for the experimental branches, they only exist when new features are introduced, that do need a lot of testing and debugging; the last such branch was for EEP (and the integration of the dual (WL+EE) renderer now available in my viewer). Finally, it also happens that I do not release a viewer on one particular week, whenever too few things happen on the coding front in SL. AFAIK, you and me are the only TPV coders/maintainers working alone on ”our” viewers, and our viewers are unique in the SL ecosystem, for they both provide unique features not seen in any other viewers. Believe me, I do respect you as a viewer developer, for I know first hand what it entails in term of dedication and perseverance ! But when I saw the breakdown of the years in days, hours, minutes and seconds, I laughed my ass out and just could not resist adding more (and bigger) numbers. 😜

Wow... Useless stats and shameless bragging !... I can do it too ! 😜 Let's see... Cool VL Viewer fact sheet: - First Linux TPV. First still maintained TPV (it was the third, fourth or fifth released TPV, since there was Nicholaz Beresford's and Dale Glass' Windows viewers, and perhaps a couple others, before I released publicly mine, but none of them survived). Only still maintained (and kept on par with LL's current viewer features) v1 UI viewer. - First (public) release on 2007-11-16: that's 14 years and a few days ago. I joined SL on 2006-10-06 and I made my own (private) viewer as soon as LL opened their viewer sources... - Number of releases: I lost the exact count because of the various branches (up to 3 branches maintained in parallel) and releases per branch to count before I opened my own forum to announce them. For the ”stable”, ”experimental” and ”legacy” releases starting from v1.19 (i.e forgetting probably a couple dozens in the various v1.18.* branches), here is the count I just made: v1.19.0/1/2: 90 v1.22.11: 11 v1.23.2/3/4: 18 v1.23.5: 37 v1.25.0: 41 v1.24/25: 42 v1.26.0: 32 v1.26.1: 9 v1.26.2: 26 v1.26.3: 9 v1.26.4: 99 v1.26.5: 22 v1.26.6: 21 v1.26.7: 21 v1.26.8: 94 v1.26.9: 37 v1.26.10: 21 v1.26.11: 21 v1.26.12: 50 v1.26.13: 19 v1.26.14: 14 v1.26.15: 13 v1.26.16: 16 v1.26.17: 14 v1.26.18: 36 v1.26.19: 38 v1.26.20: 50 v1.26.21: 17 v1.26.22: 67 v1.26.23: 19 v1.26.24: 24 v1.27.0: 4 v1.28.0: 20 v1.28.1: 10 v1.28.2: 48 and counting to date... That's over 1100 releases to date... So... What did I win ?... A cookie ? 🤣

No... That is why, for the past 14 years, you have had (and will keep having in the future) the good old (and totally productivity and screen estate geared), v1 UI in the Cool VL Viewer... 😛 Firestorm simply reimplemented (part of) the v1 UI floaters, among which the search one. It however lacks the ”All” search tab (it only implements it in its web flavour, not in the old search style). There are quite a few useful things that do not exist any more in v2+ viewers... Terrain-only tiles tab in the world map, chat input line, etc... Not to mention, on the renderer side, ”Classic clouds”, animated trees... All of which you still can enjoy in my viewer. As for the new-new web search (since this is actually the 3rd web search version), here is my take on it (posted as a comment to Inara Pey's related blog post) : Sadly, and unlike what LL did when they updated the first web search version to the second, they do not provide a way to use the old style search (for years, the Cool VL Viewer had a ”Use new search” check box in its web search tab, to allow switching between the two)... As a result, and for the next Cool VL Viewer release, I reworked the web search tab in the Search floater (it is now combo-less, search input line-less, with just the ”Back”, ”Forward” and ”Reload” buttons) and switched to the old v1 ”All” search for results when using the search input box in the status bar... Sadly and once more, LL opted to keep the new search secret till released, instead of communicating with viewer developers: the result is this total mess... Congrats, LL ! 😞

Or that is not a v1 UI viewer... :-P

The map server base URL is transmitted to the viewer in reply for the ”map-server-url” request parameter sent by the viewer on login; i.e. it can change over time. Some viewers (mine is one of them) log it in their log file (e.g. ”INFO: LLStartUp::idleStartup: Got map server URL: http://maps-cdn.agni.lindenlab.com/”).

As I described in my previous post, this is a viewer bug, that so far has not been addressed by LL and is present in TPVs using LL's code for the Marketplace. Try the Cool VL Viewer, which uses a modified (and fixed) code...

v495.x (x=any, so far, 44 included) got a lot of problems, such as performances issues, suspend/resume, sync, Vulkan, Wayland, dbus, etc... Just have a look at NVIDIA's forum. The latest is not always the greatest.

Under Linux, the current NVIDIA driver v495 (”new feature branch release” driver) got issues. Keep using v470 (”production branch release” driver) for now...

The reason for the ”small” size of the part is that the rest of the improvements (rigged matrix caching) were already implemented by me in the Cool VL Viewer months ago and with an even faster algorithm... 😛 The only improvement (three lines of code but it makes a very obvious difference) brought by LL's latest code over mine, and which I backported, is to avoid uploading repeatedly and uselessly the (cached) rigged matrix into the shaders... Which would happen hundreds of times per second for each avatar wearing a rigged mesh (depending on your frame rate).

SL's privacy agreement only rules out your privacy with regards to SL services, not what you can or must not do with other residents' private matters... The chapter 6 of the TOS (conduct by users of the service) makes it however very clear, in 6.1: Emphasis mine. The Community standards (which rule out how you shall behave and what you shall not do in-world) also make it very clear: Emphasis mine again. Now, giving the excuse that your relay warns the user ”after the very first message a user chats within it's range” is not enough: what about that first message (which, as I understand it, gets transmitted before the resident could see the warning) ?... What if the user wishes to chat freely (chat is not a group that you join after reviewing its charter and agreeing with it) and yet not gives their consent to see their prose transmitted outside SL ?... What if the user cannot see this warning (e.g. on a second visit) or forgot about it, because they muted you for having annoying objects that keep spamming them with object IMs ?... Information of the user and explicit consent given by the user are not the same things ! I am sorry, but the chat (*) relay you are using is against both the TOS and the Community standards. Period. ___________________________________________ (*) It might be OK for a group, as long as the information about the relaying is given in the group charter (by joining the group, the user gives their consent).

Ouch ! Discord and Second Life do not share the same rules about users privacy !!! Also, group chats do not have an history that anyone (including non-residents of SL) can see ! I am seeing this as a can of worms, with HUGE privacy concerns (not everyone wants to see their prose shared out of SL and visible by anyone on Internet !). As for any scripted relay, it would also cause privacy violations, especially if SLers in a group chat do not even know in the first place that their prose will be relayed to a discord group !

The Cool VL Viewer allows to limit the distance at which the ”point at” information is transmitted to the server (and thus avoid revealing what you are editing/inspecting beyond that distance). If you reduce this distance to 0, then you basically disable entirely the point at info and selection beam. The same is true for the ”look at” info, however my viewer does it in a different way than others, by ensuring equity/reciprocity. I.e. if you limit the look at info to a given distance, you will equally not be informed about the names of the avatars looking at the same distance and beyond. See the corresponding settings (and explanatory tool tips for them) in the ”Preferences” floater -> ”Input & camera” tab -> ”Input controls” sub-tab.

You do not seem to understand (or I don't express myself clearly enough)... Whatever the messaging protocol, this processing time (which is not dependent on the protocol implementation itself) will be the same. And there is no throttling for the HTTP textures fetcher, for example (and there, there's an awful lot of processing time involved on rezzing the textures, way more than on UDP objects data decoding), or for the mesh repository fetcher (HTTP too). For example, I can easily reach 150Mbps (with less than 1Mbps of UDP bandwidth: all the rest is HTTP) when rezzing a scene after a TP into an non-cached sim with the Cool VL Viewer: yes, the frame rate drops during rezzing, but it lasts only for a few seconds seeing how fast everything is decoded and rezzed. Again, the UDP bandwidth throttling has nothing to do with ”spreading out the load on multiple frames”.

The processing of the contents of the messages (i.e. updating objects data, or even decoding textures back when they were sent via UDP) got nothing to do with the messaging protocol itself that would have to be performed whatever the method (UDP or TCP). And whatever the protocol you use, you would see the same amount of time taken to process the messages contents. However the load for the UDP protocol itself, as it is implemented in SL, is negligible and certainly not the reason for the throttling.

No, not really... UDP messages processing is not at all taxing on the frame rate (when compared to the render pipeline load, it is negligible). The reason was most likely because, back in 2003 when SL was born, the Internet connectivity of the servers was much less beefy than what it is today. Back in that time, leased lines costed a small fortune, and a single sim server was likely (but it would be interesting to get this inference of mine confirmed by a knowledgeable Linden) very limited in available bandwidth to serve all users in sim (a few Mbps per sim server, at most), so you could not have those users sucking up UDP messages at more than 500Kbps or so (which was not even a big deal, since back in that time, ADSL down-links were limited to 512Kbps at best).

It does smell... I spotted this bug back in the time when I backported the Marketplace code to the Cool VL Viewer. Here is the culprit code and my comment about it. #if 0 // This is a bogus thing to do here (because updateCategory() would // change the modify masks and that change would have all risks to be // ignored, simply triggering the warning above), and should not be // needed any more now that I fixed the observer code for the // marketplace (by moving changes to the inventory structure out of // the observer event code and into an idle callback). HB if (LLMarketplace::contains(referent)) { LLMarketplace::updateCategory(referent, false); } #endif Note that since my backport is actually a partial re-implementation of LL's code, you'll need to do more than just commenting out the corresponding line in LL's viewer sources (see my comment about moving inv structure changes out of the observer code). The corresponding line in LL's viewer code for the recursive notifyObservers() call you observe is: update_marketplace_category(referent, false); Around line 1697 of newview/llinventorymodel.cpp.

Apparently, we do not share the same experience on these topics... I got HDDs that are over 10 years old and still spinning just fine (granted, they were not cheap HDDs either), even if others did die over time (I've had especially bad experience with the IBM ”Deathstar” in the distant past, and with a triplet of Seagate 7200.11 in a RAID5 more recently). I can't speak about my experience with cheap SSDs since I never bought any, but seeing how much data has been written already on my older (MLC) SSDs, the cheap ones would have long hit their max write cycles and exhausted their NAND provision, and faster than even the lame 7200.11s have died for me. As for second hand RAM modules, I bought quite a few over years, to upgrade old computers... From old SDRAM to DDR3 modules. Never got any issue with them. As long as they pass the memtest I always submit them to on arrival, there is no reason for them to suddenly die (and if they don't pass it, just return the module as faulty to the seller)...

I won't use a cheap SSD for caching purposes (and truth to be told and as far as I am concerned, for no purpose at all): they are especially fragile with a low endurance (low max write cycle counts), while a cache disk needs high endurance to writes. They are also slow (you will find QLC or non-V-NAND TLC drives in this ”cheap” category, and their write speed is abyssal). I'd rather use a RAM-disk, and if RAM is scarce on my system (less than 16GB), I'd rather consider adding more RAM (you can find 8GB DDR4 modules around 30-50 bucks, and you can even buy second-hand modules for RAM, while buying second-hand SSDs is quite unwise) so to be able to create a RAM-disk; the added RAM will also benefit all applications more than your cheap SSD would, the SL viewer included.

It has been several consecutive releases (i.e. quite a few weeks) that the server release notes are unavailable, always leading to an ”access denied” XML page. This week, yet again, I get for Second Life Server 2021-10-01.564394: <Error> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>K3YPNABE6YFTXY2H</RequestId> <HostId>hOSazNPaJ6eugcIdrcmr5Z24c/3CypGM2VLq+ds9nhkHtAqL/YK4FUd2wooCYW/QoTQetF81oMo=</HostId> </Error> Could you please, LL, get it right once and for all ? All it takes is to verify the release notes URL does work whenever you update your servers... What about adding this step on the check-list for server updates ?...