Jump to content

Henri Beauchamp

Resident
  • Content Count

    130
  • Joined

  • Last visited

Community Reputation

104 Excellent

1 Follower

About Henri Beauchamp

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 s
  2. 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.
  3. 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 ?
  4. 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 befor
  5. 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.
  6. 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 totall
  7. 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 s
  8. 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
  9. 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 sug
  10. 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
  11. 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 bat
  12. 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...
  13. There is a basic misconception about what this rule actually means: it simply means that a TPV cannot implement a feature that would break the way things looks for *others*; in the past, there have been viewers implementing such features (e.g. non standard attachment points on your avatar, that then had the said attachments appearing in your avatar's center in other viewers) that other viewers (and especially LL's) could not render properly, which did break the ”shared experience” for all users of all viewers but that particular TPV. Now, what you display in *your* own viewer (as long as
  14. Can infirm: the Cool VL Viewer will keep both renderers (WL and EE, and switchable on the fly with the same viewer binary, i.e. no need for two different viewer versions) ”forever”, or at least until LL changes for a Vulkan renderer.
×
×
  • Create New...