-> historically RLVa always had the concept of "local teleports" by tieing double-click teleports to @sittp rather than being subject to @tploc
-> location teleports were tied to @tploc regardless of the distance
=> this change divides position-based teleports in "local" and "remote" with different sets of rules (@sittp and @tploc respectively)
=> added @tplocal=n to restrict local teleport without impacting sit distance (@sittp still implies @tplocal)
--HG--
branch : RLVa
-> @accepttprequest will auto-accept all incoming teleport requests (allows exceptions - see @accepttp)
-> @allowidle (stays experimental - subject to change)
-> @getcommand:<filter> can be used to discover which commands are part of the user's RLVa implementation (with user-defined separator)
-> @findfolders:<filter> works like @findfolder but will return all matches (with user-defined separator)
-> @getdebug:<setting> can be used to query (but not set) the "RestrainedLoveforbidGiveToRLV", "RestrainedLoveNoSetEnv" and "WindLightUseAtmosShaders" debug settings
-> @interact will block world interaction but allows drag-drop, the camera tool, mouse steering and access to the "self" context menu
-> @sharedwear is the counterpart of @unsharedwear and wear locks the shared #RLV folder
-> @sharedunwear is the counterpart of @unsharedunwear and remove locks the shared #RLV folder
-> @touchhud will prevent the user from touching/clicking on their HUD attachments (allows exceptions)
-> @tprequest will prevent the user from requesting teleports (allows exceptions - see @tplure)
-> force wear commands will activate/deactivate gestures as well
-> force wear commands will collect from folder links as well
-> [FIXED] Location on incoming teleport requests isn't censored when @showloc restricted
-> [FIXED] Message on outgoing teleport offers isn't censored when @startim restricted
-> [FIXED] Message on outgoing teleport requests isn't censored when @sendim or @startim restricted
--HG--
branch : RLVa
The problem was that class-static LLUrlEntryParcel::sRegionHost was being
initialized by copying class-static LLHost::invalid. Naturally, these two
statics are initialized in different source files. Since C++ makes no promises
about the relative order in which objects in different object files are
initialized, it seems we hit a case in which we were trying to initialize
sRegionHost by copying a completely uninitialized LLHost::invalid.
In general we might attempt to address such cross-translation-unit issues by
introducing an LLSingleton. But in this particular case, the punch line is
that LLHost::invalid is explicitly constructed identically to a
default-constructed LLHost! In other words, LLHost::invalid provides nothing
we couldn't get from LLHost(). All it gives us is an opportunity for glitches
such as the above.
Remove LLHost::invalid and all references, replacing with LLHost().
Kitty Barnett