Jump to content

Henri Beauchamp

  • Posts

  • Joined

  • Last visited

Everything posted by Henri Beauchamp

  1. If you are using the Cool VL Viewer, you do not need to worry at all about cache locations and file names when logging in in different grids... File names that do risk to collide (such as for the regions objects cache, the inventory caches, etc) have a grid suffix appended for non-SL grids (also, the Cool VL Viewer uses a different cache location or cache file names than any other viewer, where appropriate, so you may use it along other TPVs without any risk). Assets and textures caches are shared, but the collision risk (i.e. encountering two different assets or textures with the same UUID on two different grids) is totally negligible (just as probable as getting a duplicate UUID generated for a new asset/texture uploaded in SL). The only exception is fo UI sounds (which have a fixed UUID but different actual sounds in SL and OpenSim), but even for those, the Cool VL Viewer offers a way to cache UI sounds and make them ”static”, to avoid mix-up when you log in both SL and OpenSim grids...
  2. Well known issue, usually caused by a badly designed product causing a low texture LOD to be used. To work around it, I implemented (years ago) a ”Boost attachment textures LOD” in the Cool VL Viewer... While it works for all rezzed avatars, it of course only works (on their screen) for people using this viewer.
  3. I find it rather funny (and quite silly) that LL did not even properly change the code of their own viewer to prevent UDP fetching of textures after they shut down the service... Got a ”mCanUseNET = !gIsInSecondLife && mUrl.empty();” line in my viewer to implement this trivial limitation (which would translate to ”mCanUseNET = false;” for LL's viewer, since it won't log in OpenSim grids)...
  4. Strange, really... Perhaps the UDP service got accidentally re-enabled in the sim servers during the AWS migration... As for viewers, the Cool VL Viewer is still able to fetch textures via UDP (as a fallback to HTTP), but, after LL shut down UDP texture serving (which happened quite some time ago) only on OpenSim grids (i.e. the UDP fetch retry code is disabled while logged in SL). However, if someone found a really old release of my viewer, they might be able to try and fetch textures with UDP (there was even a switch to disable HTTP fetching in even older releases, dating back from the time when HTTP fetching was still experimental). The same is true of other TPVs that do not have a kill-switch (no forced update & Co), so I suppose it is possible to still find a viewer nowadays that could do that (but at the cost of a sh*tload of missing features, of course).
  5. Mindful scripters will limit the usable memory for their scripts to what those scripts do need: this will also prevent those scripts from appearing as always using the max allotment memory (64KB) when they actually only use a fraction of that allotment. But as noted in above posts, nowadays, and given the amount of equipped memory per server, I very much doubt memory usage is a problem any more... Regarding the server-side load, the one and only relevant info for scripts is the amount of time they consume per frame (which is the OBJECT_SCRIPT_TIME figure as returned for each object by llGetObjectDetails()), i.e. how much time the server consumes to process events in the script at each server-side ”frame” (loop). And even then, you must account for the fact that this number is averaged over 30 minutes or so: it is maximal when you arrive in a region (because the script state de-serializing and resuming time is taken into account), and that's why you sometimes see a ”lag spike” when a heavily scripted avatar enters the region where your avatar is present). So, the micro-seconds per frame figure is only getting truly relevant 30 minutes or so after the avatar arrived in the region. As a conclusion: that floater is of little to no use (a scripted load monitor can do the exact same job) and rather irrelevant most of the time anyway... That's why I never bothered implementing it in the Cool VL Viewer.
  6. There could be, and very easily: the viewers derive an unique computer ID out of your computer hardware. This ID is used during login and allows LL to track griefers, for example. It would be dead easy to add some code to the viewer in order to transfer that ID together with the avatar name to a third party website so to register them into a database and then find out what avatars pertain to the same person (or, at least, are used on the same computer, since a family could be using several accounts on it, with several avatars). My advice is to never trust any viewer build that is not provided by the developer/team maintaining that viewer, together with the sources (and only via their official web site or channel). This is true of any Open Source software !
  7. Either you report properly, on the support forum, or I will not even bother trying to understand your issue. Beware: I won't take abuse from stubborn people... I share my work on my viewer as a free service for other like-minded people; don't make me regret it ! This is my last message here, on this topic.
  8. It's in no way ”broken”, and the script does report to you what it finds missing on your system... Here, it will complain about a missing binfmt_misc module and ask you to fix that issue before retrying. Yes, please, this forum is not the place for this... The call to ”wine” shall be done by the kernel, via binfmt_misc... That's how all modern distros I tested (and I tested many, believe me) do work. That's also what TPVs allowing to run SLVoice.exe from Linux (e.g. Firestorm) expect to happen: they never launch ”wine” (or wine32, or wine64, or whatever it is called in your distribution, which the viewer cannot guess) directly, but delegate to the Linux kernel the care to find the right launcher for the SLVoice.exe binary (which is the binfmt_misc module's very task and only purpose)... I could of course arrange something else for exotic or badly configured Linux systems (via a wrapper script to launch SLVoice.exe, for example)... Post all the gory details about your system configuration and what messages you get from the installer script on the viewer support forum and I will see what can be done...
  9. /proc/sys/fs/binfmt_misc/* files are checked by the script to verify that the binfmt module (which is responsible for launching non-ELF binaries, such as Windows ones) is indeed installed and active on your system, and that a proper Wine entry is configured (so that binfmt knows that it needs to use 'wine' to launch binaries matching Windows' executable format). This should pose no problem whatsoever, unless your distribution is using non-standard kernels patched with a different /proc layout... If this is the case, please provide details on the Cool VL Viewer support forum.
  10. Well, it should... Please, report any issue you find when using the Cool VL Viewer on its support forum. Give all relevant details (at the minimum, what Linux distribution and version you are using); 'which wine' output would help there, or the list of the files (especially, the wine executable) in your Linux distro's package.
  11. The Cool VL Viewer does: type ”./linux-build.sh --usesystemlibs” in the linden/ source directory, wait 3 to 10 minutes (depending on your hardware), and enjoy your home-built viewer. Of course, some SL-specific libraries (patched ones, or things such as GLOD) are still pre-built ones, but who cares ? Oz created ”autobuild”, which basically made rebuilding libraries a nightmare, under all OSes. Oz stopped Linux support (and actually killed it) by his actions and inaction. I've been developing the Cool VL Viewer (which is primarily a Linux viewer) for the past 14 years. Nicky Dasmijn also provided a working Linux branch of LL's own viewer, but Oz did nothing with it (inaction, again)... What more do you want (or more exactly what Oz wanted, if not killing Linux support) ? It does, at a HUGE frame rate loss (and frame rate ugly stuttering) cost: why do you want to run a Windows viewer under Wine when there are Linux viewers that run 20% faster natively under Linux than their Windows versions under Windows (and that's not even counting on people with AMD GPUs, who will find out how lame the AMD OpenGL driver is under Windows, after trying the Linux version of their viewer under Linux). Vivox' fault: they hate Linux and stopped providing Linux clients years ago... This said, their Windows client can be used (via Wine) from a Linux viewer. The Cool VL Viewer is now provided with a script I wrote that will install a SLVoice.exe client in a Wine ”prefix” (separate prefix, i.e. it won't touch your existing Wine install) and setup everything for you. Wayland SUCKS (there are things you just cannot do, or cannot do right with Wayland). The viewer (like 90% of graphics software) is an X application. Use it under X, and you will see it fly ! NVIDIA proprietary Linux drivers are excellent: nothing can beat them in OpenGL. Just use them. They also added support for Wayland in v470 (and Wayland recently got an update to use it). But I still highly recommend using native X, which is the true thing !
  12. Try CEF 90 or 91: they (finally) fixed the GPU process crash on shutdown that plagued CEF 77 to CEF 89 inclusive and made the Dullahan plugin crash on exit (almost systematically under Linux, and no so rarely under Windows). This fixed such plugin crashes on exit for the Cool VL Viewer, at least. For reference, here is the bug report I made to the CEF devels about these crashes.
  13. 64 bits viewers (at least the Cool VL Viewer and LL's viewer) run fine (albeit of course a bit slower) for me under Linux + Wine 6.6... I'm using this trick for quick tests of my viewer Windows builds, and for LL's viewer when I want to test some new feature before backporting it (since LL is not providing a Linux viewer any more). Teleports do work fine. Linux viewers also do run (but 10 times slower than natively) in a Linux VirtualBox VM on a Linux host. With Linux, you could also run Linux viewer under a virtualized kernel (e.g. with the Xen hypervisor) and almost at the native speed, with some tweaks for the GPU drivers... This said, I won't recommend any of these solutions for everyday's SLing.
  14. There is no OpenGL driver for VirtualBox and macOS guests: the viewer won't run at all on such a VM. Sound is missing too.
  15. Excellent ! While you are at it, why not giving this LSL function a name that is unambiguous (OpenFloater is terrible, since almost everything happens in a floater in SL): llWebUserGuide(), for example ?
  16. In my latest build (for Linux and macOS, used in last Cool VL Viewer release), I used ”zlib threads no-idea”, so nasm is enabled. ”zlib” could probably be dispensed with, and is not used at all for textures (which need to be downloaded via range requests, since a J2C file does not need to be entirely downloaded when you only need its lower LODs, and the viewer does use this property), neither for meshes (which data is already gzipped anyway: it's a llsd+gz encoding). You are right about SSL (3 and 2), as well as for weak cyphers, but not sure which cyphers are in use by LL, so before disabling a bunch of them, better letting LL do it; plus, as long as LL is not using any such weak protocol or algorithm, it does not hurt (it just makes the libraries a bit larger)... IPv6 could also be disabled (both at OpenSSL and Curl levels), since SL (and the viewers) only knows about IPv4 and having IPv6 enabled could slow down DNS resolution in some configurations; I am currently testing OpenSSL and Curl builds without IPv6 and they will be used for the next Cool VL Viewer release (at least Linux and macOS ones, if I do not have the time or patience to build them for Windoze).
  17. It depends if the DNS you are using uses the Anycast protocol (which allows to select a server on the basis of the lowest number of 'hops') or not... I would assume Google's uses it, and you won't see a difference in name resolutions for their CDN server with a local DNS not using Anycast. One thing is certain, I could convince SL to use different CDN pools (AKA ”PoP”: point of presence) for me by changing DNS, but I never use ”big DNS” servers, and even most often use DNScrypt servers.
  18. Maybe if you are using a cheap router (usually seen with WiFi so-called ”routers”) that support only a limited amount of simultaneously opened ports (viewers can use dozens of them, depending on their configuration): you might manage to work around it by reducing the configured numbers of max requests for textures and meshes (see your viewer network preferences or debug settings), but the definitive solution is to replace that cheap router with a true one, that can keep all 65535 ports opened simultaneously ! Maybe, if configured with a local proxy for HTTP connections: it would totally ruin textures fetching, don't do that ! However, such proxies are usually configured only for standard web ports (80, 443, typically) and won't affect SL's HTTP traffic that happens on non-standard ports. Yes, if your computer is behind a firewall using its own proxy for HTTP connections (same as above). Different CDN pools = different administrators. You cannot rule-out local ”optimizations” (that might be great to serve standard web pages but would break SL's usage of HTTP for assets serving, including textures). It won't surprise me the least if some admins, in some countries/regions would have had a ”great idea” that ruins it for SL. It's easy to verify whether you are in this case or not, by configuring a different DNS (from a different country).
  19. I agree with Lucia's opinion on the ways to abuse such a feature and the need for a kill-switch for it, viewer side... I'll also add that if you ever implement that feature, you must make sure it will be compatible with all viewers (TPVs often got/implement different floaters, have some non-existing floaters (e.g. for v1 UI TPVs), or on the contrary additional floaters not available in LL's viewer). Granted, a mapping of floater names/keys could be implemented by each TPV developer, but what about scripters making use of TPV floaters that do not exist in LL's viewer ? At least make sure that if a viewer refuses to open a given floater (be it because it does not have an equivalent, or because of a kill-switch), it will not break the script asking for it. EDIT: by the way I see that llOpenFloater() is already implemented for URLs in the RC server version to be deployed; where is the code implementing the viewer side of things ? I cannot find it anywhere on LL's public code repository !
  20. 1.- The interest list has been implemented (so the project viewer itself has been adopted). It got nothing to do with textures loading, however it changed how objects get rezzed and there have been changes in how objects are cached too, which may cause objects not rezzing after a TP or login: they are ”there” but you need to right-click at their (empty) position to see them pop up into view. The Cool VL Viewer got a workaround for this issue (it refreshes the visibility of all objects in the object list when it receives the parcel info, which happens a few seconds after TP/login; you may also refresh them manually with ALT SHIFT R, a bit like an objects ”rebake”). 2.- The texture fetcher and the texture prioritization algorithm are suboptimal and would deserve a rewrite, from the ground up. In the Cool VL Viewer I recently added a textures fetching boost feature (which also benefits from its new multi-threaded image decoder), which basically forces the refresh of the textures priority way more often (more textures have their fetching priority updated at each frame), causing partly loaded textures in close view to get loaded MUCH faster; the drawback is an impact on the frame rate while the boosting happens. This feature kicks in after login and TP (duration of the boost is configurable), and on demand (CTRL B), with also an optional ”camera speed proportional boost” feature (the faster the camera moves, the higher the boost factor: great when using a vehicle at high speed). 3.- I do not see the issue described here (i.e. the textures network traffic slowing down to a trickle), but it might depend on the CDN serving your region/country. If you are unlucky enough to hit a badly configured CDN, you may change your DNS address for one in a neighboring region/country, which will cause another (pool of) CDN to be used. 4.- The viewers are still using a curl version with HTTP/1.1 (pipelining) enabled. I recently updated the curl version for my viewer (for Linux and macOS ) to a patched v7.64.1 which got HTTP/1.1 re-enabled (via a one-liner patch), so that OpenSSL v1.1 could be used as well (instead of the deprecated v1.0) and suggested to LL to use that combination: they are working on it.
  21. For what it is worth, I had a login issue with my main avatar in my home region (a couple of alts could still log in just fine there) a couple of days ago. I could not go past the ”logging in” or ”connecting to region” steps. Got a live support chat and the nice Linden suggested I'd try in another region (which I did not think about, since my alts could log in just fine in my home region), and I indeed could log in in that other region. I then retried to log in my home region with my main Av and it failed again, at which point the Linden restarted the region, which solved the issue. I suggested LL would look into the last server update, since that's the first time I encounter such an issue (i.e. not able to log in with just one avatar in a specific region). To see if you have the same issue, try and log in in another region than the one you logged out from...
  22. I hate to contradict you, but the day time sliders (you can find one in the Local environment Editor, and another in preferences for the time of day at login) in my viewer are indeed genuine ”time of day” ones, that use a ”track blender” (the new, complicated way to set the time of day in EE settings), on settings with a day cycle (I'm not using any more the ”fixed sky settings” for the 4 fixed time of day presets, but instead WL-translated settings with a full day cycle); they do not drive the Sun azimuth or elevation directly. Before affirming something about other viewers, do check in their code (see LLEnvironment::setFixedTimeOfDay() in mine) 😜
  23. You won't have any issue with my viewer... It automatically translates EE settings to WL settings and vice-versa to render them. Sure, you do not have fancy Moon and Sun orbits, changeable Moon and Sun diameter and other such EE-only settings in WL rendering mode, but it displays EE settings fine nonetheless in WL rendering mode (and vice versa) ! If, like me, you spend most of your time in indoor scenes, you won't even notice a difference, but for your fps rate (usually significantly higher in WL mode, with the exception of scenes with lots of alpha textures which the EE renderer can batch, unlike WL). I believe in freedom of choice. Why would I suffer lower performances when I do not care for EE fancy settings ?... On the other hand, it seems natural that I can see the effect of those fancy settings in EE mode whenever I want or need it. Thus my choice of a dual-renderer for my viewer. It can do both, so there's no loss for its users ! 😛
  24. Wrong ! I implemented the day light time slider for the EE local environment editor in the Cool VL Viewer (as well a another slider for the time of day at login). It works just fine, but did involve changes to the default settings (using WL translated defaults that do include a day cycle, instead of the ”fixed” midday/midnight/sunset/sunrise EE defaults). This could be backported into any other EE viewer as well...
  • Create New...