Command for feature checking

[Former user]

The RLV API defines already a feature that not every viewer implements, the blacklist. More features may come, like (hopefully) the outfit roles. Different viewers or different viewer versions may have different features implemented, so the scripts need to know if they can use special feature or not.

LSL has a nice command that checks if a particular feature is enabled in the sim or not: llGetEnv. To have something of that kind would be needed. I'd suggest to combine it with version checking while the version string is simply a feature to be responded:

@getfeatures:list=<channel_number>

The "list" is a coma-separated list of features. The viewer responds then with a coma-separated list of strings, each of them describes the feature and may not contain the coma.

When the result is binary (feature enabled or not) than instead of responding "yes" or "no" i would respond the feature name if the feature is enabled and nothing when not. This way the script could just ask if a special string is in the result or not.

Example: We want know the version of RLV API and if the blacklist feature is enabled by the viewer, than we issue this command:

@getfeatures:version,blacklist=2222

The response would be "2080000,blacklist" when the RLV API is on the version 2.8.0 with blacklist feature enabled and "2020000" when the API is on version 2.2.0 and the blacklist feature is disabled or not implemented.

The command could also help to avoid new version checking commands in the future that deliver additional informations like @versionnumbl.

LG Jenna

[Former user]

Perhaps the suggestion for binary features to respond the feature name in positive and nothing in negative case is not optimal but it depends on the final list of features and the implementation. Scripters can work with it each way. The implementation should be relatively simple, quite like the restrictions are implemented.

For valued features like the version, you maintain a key-value table with the feature name as key and the responded value as value in the table. For binary features you simply maintain a list of features that are activated. The table and the list you update on log-in or when a feature is activated/deactivated (if that goes without relog.) On request you look into the table and list if the feature is named there and build the response.

The most difficulty is probably to figure out the list of features that exist already. A feature is a special set of abilities that the viewer can or cannot offer. The feature can be specified in RLV API but the viewer can toggle it on and off. Or it is a part of RLVa and not in RLV. Or it is a part of RLV API but added on later point. The list of existing features must be defined already before the @getfeatures command is added to RLV API. So I suggest, when this proposal is accepted, to put here in comments what features should be on this list.

Version: When the response is not a fixed list but missing features are omitted in the response, then the version feature I would response now with "version <number>" instead of just number as suggested above.

Blacklist: The blacklist is definitely a feature.

Shared folders. As far I know you can toggle RLVa support on but using the #RLV folder off or you can not have the shared folder at all. Hence, shared folders is another feature.

A special case are Unofficial commands,

The existence of such commands that are not a part of RLV API but can be implemented by particular viewers is a feature as well. Say we call it extcom feature. Once the script detected with @getfeatures:...,extcom,... that the viewer implements unofficial commands, the script could request the list of the commands via @getextcom=222 to know which commands the script can issue and which not.