-> RlvHandler should only deal with the actual RLV API syntax
-> RlvActions should handle all interpretation of the stored behaviour
=> the end result will make it significantly easier to finally switch over to a new syntax with the option of remaining compatible
--HG--
branch : RLVa
-> see FIRE-20266 - problem when group name contains a comma (or colon?)
-> an exact match has precedence over a partial match; in case of multiple partial matches the last match wins (group ordering isn't guaranteed so essentially 'random')
-> @setgroup:<uuid>=force is still preferred
--HG--
branch : RLVa
Firestorm fires a custom "update grouptitle list" event which will also cause
RlvHandler::handleEvent() being invoked even though we only registered for the
"new group" event, screwing up the logic there. So make sure we really only
handle the event we expect here.
-> thankies Ansariel - they're not used as-is in RLVa (or Catznip) but Firestorm hooks into them for various UI enabling/disabling hooks
--HG--
branch : RLVa
-> bundle all permission checks in a predictable single function (see RlvActions::canChangeActiveGroup)
-> properly handle the case where a user is ejected from a group
-> provide feedback to the user after we force the previous group back when joining a new group
--HG--
branch : RLVa
-> TPVs implementing dynamic viewer data should call RlvSettings::initCompatibilityMode() with the setting
-> End-users also have manual control over the list through the "RLVaCompatibilityModeList" debug setting
-> Format: (;-separated)
* creator:<uuid>
* name:<perl-regex>
--HG--
branch : RLVa
* Change RlvCommandOptionHelper::parseOption<RlvCommandOptionGeneric>(rlvCmd.getOption()) to RlvCommandOptionHelper::parseOption<RlvCommandOptionGeneric>(rlvCmd.getOption(), rlvCmdOption ) as otherwise a wrong template go picked wich resulted in linker errors.
=> we don't (need to) check the return type in those cases since it can't ever fail to convert so we just end up with less nice looking code
* Rearrange RlvBehaviourDictionary to be above the classes that need the defintion (RlvBehaviourDictionary::instance call)
* Change '(".("RLV_FOLDER_FLAG_NOSTRIP")"' to '(".(" RLV_FOLDER_FLAG_NOSTRIP ")"'. The GCC preprecessor does not like it w/o spaces.
* Add template<> to those specialization that missed it
* Change template<> template<> to just template<>
=> GCC seems to hate the templated std::enable_if (try boost::enable_if in the future); meanwhile try to #define a solution
=> Nicky changed a function parameter name matching a template parameter name so start differentiating between the two
--HG--
branch : RLVa
-> Examples:
* @recvim:0,20=n - user can only receive IMs from people within chat-range (20m)
* @sendim:256=n - user can only send IMs to people who are at least a region away (256m)
* @startim:0,256=n - user can only start IMs to people who are on the same region they are (between 0moh oh and 256m)
-> Note that you generally can't rely on having location information for avatars beyond the current region (and maybe 1-3 surrounding neighbours) so large values are of limited use
-> On an isolated region using 4096m as the upper value will guarantee that you can only IM avatars on the same region regardless of elevation but none anywhere else on the grid
--HG--
branch : RLVa
-> [FIXED] "Pay" isn't disabled on the avatar context menu when @shownames restricted
-> [CHANGED] Show a notification when the user can't offer a teleport due to an RLV restriction
--HG--
branch : RLVa
-> Example: issue @tplocal:50=n
-> gRlvHandler.hasBehaviour(RLV_BHVR_TPLOCAL) will return true but gRlvHandler.hasBehaviourExcept(RLV_BHVR_TPLOCAL, LLUUID::null) will return FALSE
=> since it's a modifier command it will be reference counted but that fact is lost on manual matching (tplocal=n != tplocal:<option>=n) so we keep track of reference counting in the command
--HG--
branch : RLVa
Kitty Barnett