RLVa 2.3 Release Notes

From Catznip
Revision as of 02:29, 10 December 2020 by Kitty Barnett (talk | contribs) (Windlight / EEP)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

New commands

  • @buy=<n|y> prevents buying an object which is set 'For Sale' or paying a scripted object (e.g. a vendor)
  • @pay=<n|y> prevents paying another avatar directly through the 'Pay' context menu
  • @versionnum:impl=<channel> allows you to query the active RLV implementation version as <major><minor:02><patch:02><implementation id:02>

Since new commands haven't been tied to a specific specification version for a while now it makes more sense to check the actual RLV implementation the user is using as opposed to the spec version (if you're interested in checking such things). As of this version RLVa returns 2030013.

Camera

  • @setcam_eyeoffsetscale:<multiplier>=<n|y> and @setcam_eyeoffsetscale:<multiplier>=force were added in line with the new Linden Lab camera presets feature (see the official viewer documentation for a description)
  • Taking ownership of the camera (through @setcam=<n|y>) will now leave the current camera offset, the camera offset scale and the focus offset in place and restore the user's preference on release
  • Releasing @setcam_eyeoffset, @setcam_eyeoffsetscale or @setcam_focusoffset (without releasing the others) will reset that modifier to the value it had when the first eye/focus restriction command was issued (so always set and release all three together; see also the notes below).
  • A number of camera commands have graduated and no longer have the experimental tag (which means they won't disappear or have their functionality altered randomly):
    • @setcam_eyeoffset (both versions)
    • @setcam_eyeoffsetscale (both versions)
    • @setcam_focusoffset (both versions)

NOTE: The camera presets feature now makes it more likely that users will have a non-default camera so always set @setcam_eyeoffset **and** @setcam_focusoffset (and the new @setcam_eyeoffsetscale).

Windlight / EEP

New Windlight settings that were added as part of EEP have each gotten their own command:

  • @setenv_asset:<day cycle/sky/water asset uuid>=force
  • @setenv_cloudtexture:<uuid>=force and @getenv_cloudtexture
  • @setenv_cloudvariance:<float>=force and @getenv_cloudvariance
  • @setenv_sunscale:<float>=force and @getenv_sunscale
  • @setenv_suntexture:<uuid>=force and @getenv_suntexture
  • @setenv_sunazimuth:<radians>=force and @getenv_sunazimuth
  • @setenv_sunelevation:<radians>=force and @getenv_sunelevation
  • @setenv_moonbrightness:<float>=force and @getenv_moonbrightness
  • @setenv_moonscale:<float>=force and @getenv_moonscale
  • @setenv_moontexture:<uuid>=force and @getenv_moontexture
  • @setenv_moonazimuth:<radians>=force and @getenv_moonazimuth
  • @setenv_moonelevation:<radians>=force and @getenv_moonelevatio
  • @setenv_dropletradius:<float>=force and @getenv_dropletradius
  • @setenv_icelevel:<float>=force and @getenv_icelevel
  • @setenv_moisturelevel:<float>=force and @getenv_moisturelevel

Moving forward @setcam_preset and @setcam_daycycle should be avoided if at all possible. The Windlight presets that used to ship with the viewer are now stored in the viewer's library inventory folder but users have the option to block the library and even when it's available it might not be (fully) fetched yet at the time you issue your command. Additionally if Linden Lab ever moves the folder, or decides to change which presets are offered by default your script will similarly start to malfunction. That said, it will continue to work as it did before, only now the command's option is any environment setting that appears under that specific library folder (you don't have to include the folder name, just the preset's name).

@setenv_asset:<asset uuid>=force will allow you to switch to any Windlight environment (and adds water as a side benefit) of your choice and has the major benefit of simplying your sequence of 40 RLV @setenv_XXX commands into a single one if you turn simply create a new Windlight environment and then use @setenv_asset:my_uuid_here=force instead.

@setenv_eastangle and @setenv_sunmoonpos have been replaced by @setenv_sunazimuth:<radians>=force and @setenv_sunelevation:<radians>=force (and @setenv_moonazimuth:<radians>=forceand @setenv_moonelevation:<radians>=force for the moon). Before EEP the sun's position was determined by two rotation angles with each a range of 360° which meant that the sun's position could actually always be expressed 2 ways: if eastangle was A and sunmoonpos was B then an eastangle of A - 0.25 (-90°) and a sunmoonpos of B - 0.50 (-180°) puts the sun in the same spot.

In EEP the sun's position is a quaternion so it's no longer always possible to get back the old eastangle and sunmoonpos, or setting them might put the sun at a different spot than you intended depending on the values you used. Moving forward the azimuth/elevation commands should be used instead and simply think of azimuth as an angle to put the sun/moon in the desired wind direction (NESW) and then the elevation will determine how high in the sky the sun/moon will appear (or flip the value to negative to put them below the horizon).

The legacy values will be correctly reported if sunmoonpos is in the range -PI/2 to PI/2 and incorrect when sunmoonpos > PI/2. Similarly when setting the sunmoonpos/eastangle:

  • sunmoonpos without eastangle (=0) => always correct
  • eastangle without sunmoonpos (=0) => always correct
  • eastangle before sunmoonpos => always correct
  • sunmoonpos before eastangle => correct for -0.25 <= sunmoonpos <= 0.25 and incorrect for 0.75 > sunmoonpos > 0.25

If any of this is unclear, please give me a poke in-world and I'll try to make it more clear. In the meanwhile: move the sun to where you'd like it to appear using the Windlight floaters and then issue @getenv_[sun|moon][azimuth|elevation] to get the values for your script.

Finally, in order to reduce the amount of commands needed to set colour and vector based values, the following shorthand sub-commands have been added:

  • @setenv_ambient:<vector>=force and @getenv_ambient
  • @setenv_bluedensity:<vector>=force and @getenv_bluedensity
  • @setenv_bluehorizon:<vector>=force and @getenv_bluehorizon
  • @setenv_cloudcolor:<vector>=force and @getenv_cloudcolor
  • @setenv_clouddensity:<vector>=force and @getenv_clouddensity (replaces cloud)
  • @setenv_clouddetail:<vector>=force and @getenv_clouddetail
  • @setenv_cloudscroll:<vector>=force and @getenv_cloudscroll
  • @setenv_sunlightcolor:<vector>=force and @getenv_sunlightcolor (replaces sunmooncolor)

Example: @setenv_bluedensityr:0.5=force,setenv_bluedensityg:0.75=force,setenv_bluedensityb:0.1=force can now be replaced by @setenv_bluedensity:0.5/0.75/0.1=force

Minor features

  • CATZ-576: Indicate user typing status with @redirchat=n with an optional toggle

In cases where a chat redirect is not due to a worn gag someone might still want to have their typing to show in world to be picked up by their AO (or a scripted item). This is off by default but can be toggled on from the RLVa menu.

Bugfixes

  • CATZ-553: Give-to-#RLV with nested subfolders
  • FIRE-24215: @sittp with a custom distance isn't being enforced (a similar issue existed with @tplocal)
  • Assertion failure warning when an object only issued unknown or invalid commands (e.g. @nohax=n by an OpenCollar)
  • Assertion failure warning when getting disconnected
  • RLVa shutdown crashes due to resources owned by left-over restrictions
  • Toolbar and menu items no longer disable when their matching restrictions are active