cinderblocks
small RLV problem with @getinv for folder list from path to folder with no subfolders in it
I noticed a small issue with Rad 2.38 and newer (tested 2.38 and 2.41), with the RLV command getinv. This command is
getinv:path=channel
I stuck the full definition from https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI#Clothing_and_Attachments_.28Shared_Folders.29 below.
So the problem is - when path points to a folder with no subfolders, most RLV-enabled viewers (e.g., Firestorm) return an empty string. Older Rads did this. But somewhere around 2.38 Rad started not returning ANYTHING on channel in such a situation. This causes many collars and other RLV gadgets to malfunction. I guess it should be an easy fix!
Get the list of shared folders in the avatar's inventory : @getinv[:folder1/.../folderN]=<channel_number> Implemented in v1.11, added sub-folders in v1.13
Makes the viewer automatically answer the list of folders contained into the folder named "#RLV" (if it exists), immediately on the chat channel number <channel_number> that the script can listen to. If folders are specified, it will give the list of sub-folders contained into the folder located at that path instead of the shared root (example : "@getinv:Restraints/Leather cuffs/Arms=2222"). Always use a non-zero integer. Remember that regular viewers do not answer anything at all so remove the listener after a timeout.
The answer is a list of names, separated by commas (","). Folders which names begin with a dot (".") will be ignored.
Further tests reveal that the RLV command findfolders:foldername=channel_number has exactly the same problem, when there is a perfect single match there is no path returned. This is in discord with the behavior of other RLVs as for getinv. Thanks!
I think that is a bit harsh! I have found that quite a lot of the RLV stuff works very well. For example in Rad 2.25 OpenCollars worked without any trouble (not the case now). I suspect this small bug in the folder data return I mentioned (nothing returned when the targeted folder contains no subfolders) is something that can be easily fixed (it used to work, back in 2.25 or so). Probably a one-liner down in the code! I wish I were cogen with the relevant language (C++ in a windows environment I guess...). Fingers crossed for a fix!