#2 - Proposal for an extension to @notify to report successful wear/removal operations

[KittyBarnett]

This proposal would extend RLVa’s @notify command to provide notifications when a shared folder’s contents have been successfully worn or removed.

Currently, RLV allows scripted attachment and detachment of folders but does not confirm when these actions are completed. Adding built-in notifications would eliminate the need for unreliable polling and hopefully simplifies scripting logic.

[Wunder-Wulfe]

I second this, although I would also appreciate if the extension would reply under the two conditions:

1. The command is not fulfilled / is ignored, and as such, it will notify of failure of the command
2. The command is successful, and the items have been worn or removed (Proposed)

And I would also be pleased if there was some way to tag the response, or if it would reply with the specific command which was executed, as this would resolve any situations where multiple commands are being issued, and their completion may arrive out-of-order for various reasons, i.e. an outfit with pieces from several folders is worn with multiple commands at once

My main usage of RLVa is for scripting and designing outfit management interfaces, and the complexity scales depending on how many layers and folders I organize for mixing and matching outfits, adding accessories, and it is currently compounded when I cannot rely on RLV to execute the commands I provide it with successfully every time. I am required to continuously send RLV messages: polling to ensure the outfit and assets have fully arrived, and resubmitting commands that may have been dropped, as opposed to having a direct response or communication line with the system

[KittyBarnett]

1. The command is not fulfilled / is ignored, and as such, it will notify of failure of the command

I think with the way I proposed it, the only case that wouldn't result in a notification is a time-out: the folder contains clothing layers and the texture asset cannot be downloaded for whatever reason. Or the viewer requests an attachment to be worn, but it's never attached for whatever reason.

And there is the open question for this case: "Should the script be responsible for handling this with its own timeout? Or should RLVa send a timeout notification after a set period? If so, how long should that timeout be?"

I guess you're stating that RLVa should stay on top of this, but how long before it lets the script know then? If it's 5 minutes I assume that's too long... even if it's 30 seconds you might get quite a few false positives.

And I would also be pleased if there was some way to tag the response, or if it would reply with the specific command which was executed, as this would resolve any situations where multiple commands are being issued, and their completion may arrive out-of-order for various reasons, i.e. an outfit with pieces from several folders is worn with multiple commands at once

So if you issue:

@detach:Folder=force
@detach:Folder=force

which results in

/worn inv_folder Folder
/worn inv_folder Folder

You want to be able to distinguish between the two attach commands?

Do you need to be able to specify the tag yourself? Because it should be part of @Detach and RLV doesn't really allow tacking on extra parameters since older viewers wouldn't understand the command and not do anything so you'd have no backwards compatability.

The other option is either a random number, or an incrementing number?

/worn inv_folder Folder 23
/worn inv_folder Folder 24

My main usage of RLVa is for scripting and designing outfit management interfaces, and the complexity scales depending on how many layers and folders I organize for mixing and matching outfits, adding accessories, and it is currently compounded when I cannot rely on RLV to execute the commands I provide it with successfully every time. I am required to continuously send RLV messages: polling to ensure the outfit and assets have fully arrived, and resubmitting commands that may have been dropped, as opposed to having a direct response or communication line with the system

Thanks for adding that! You definitely seem to be the intended audience for this then 🙂.

Are the problems you're describing also a result of https://jira.firestormviewer.org/browse/FIRE-34084 ? Since that will just get fixed as well.

As an aside, I am planning some changes to how shared inventory commands are processed. The intent was always for people to batch commands together since that results in the most optimal behaviour.

E.g.

@detach:Folder=force
@detach:Folder=force

vs

@detach:FolderA=force,detach:FolderB=force

The first one is problematic and results in two appearance changes whereas the second results only in a combined appearance change. This gets particularly important when things are getting detached in one command and worn in the other.

Since people only seem to want to use the 'multiple attaches over multiple commands' instead of chaining them, there will need to be some delaying and batching them until the commands stop and only then executing them as a single batch (in addition to some revamping of how the outfit code works, but ideally that's in cooperation with LL as well).

[Wunder-Wulfe]

And there is the open question for this case: "Should the script be responsible for handling this with its own timeout? Or should RLVa send a timeout notification after a set period? If so, how long should that timeout be?"

I’m not entirely sure, I have ran into the case where sometimes just one command cannot be executed, and as such, I have to re-execute the command.

A great example is when I tell it to add items in the folder to my avatar. At times, the items will never be added, yet if I send the command multiple times, it gets added every time within a relatively short window.

Are the problems you're describing also a result of https://jira.firestormviewer.org/browse/FIRE-34084 ? Since that will just get fixed as well.

They are unrelated; I have been having these issues since I have designed my original menu code, and they still remain up to the current version. However, this has broken my menu beyond repair, as items will wear and immediately detach themselves upon the wearing of another item, and the circumstances that cause this appear to be random or out of my control, as I never issue a Wear or Detach command, and I believe they don’t share attachment points either, at least not in all cases

Since people only seem to want to use the 'multiple attaches over multiple commands' instead of chaining them, there will need to be some delaying and batching them until the commands stop and only then executing them as a single batch (in addition to some revamping of how the outfit code works, but ideally that's in cooperation with LL as well).

My implementation is handled as a queue as this is the only feasible and possible implementation due to the design of RLV with my system. My outfits are neatly organized in subfolder fashion, i.e.

Outfits
|_ Outfit Name
|__ Layer0
|___ objects……
|__ LayerN…

The system comes with a notecard where you can write down the structure/name of your outfits, which layers take up what categories (so tops can collide with tops to replace existing ones, and dresses can replace existing top and bottoms, so on), as well as culling values which are emitted from the script to handle body alphas and other details based on what is currently worn

Currently, no HUD to set up the outfits, it is all notecard. Waiting for Lua / client-side script support to move every bit of code into that, but until then, RLV is my only option and I have to be optimized and careful with my usage of memory and interface so I havent expanded the tool much beyond allowing users to manage the outfit via simple dialog boxes

However, the main crux with this system is I am unable to batch commands for a variety of reasons; here are the main ones:

1. You can wear and remove individual outfit pieces or the entire outfit at one time
2. Accessories are separate and can be worn and removed independently
3. I have to check against accessory count to ensure all assets can actually be worn onto the avatar at once, which is complicated with folders and batched commands
4. I am limited to 1024 characters, which will be reached if I attempt to batch too many commands
5. The queue system is very simple

The structure for the queue system I have is:

1. Send command
2. Send poll request to check how much of the folder is worn
3. If it is not worn upon response, re-issue command and poll again
4. After X time, timeout cancels the operations and state is not changed, send detach event for continuity
5. If only partially worn, continue polling but don’t re-issue command
6. If successful, move onto next item in queue and update culling values

There is some extra complexity involved in rotating listeners, as I have a set number which increments and wraps to remove and create new listeners for each poll, preventing cases where responses may overlap due to re-submissions or severe lag in the response (i.e. response to a poll from a previous outfit item)

If I were to implement command batching, the complexity would increase significantly, mostly due to having to check the status of several folders at the same time, as it may be the case that some of the items have not finished wearing yet

Overall, my frustration with RLV has been due to a lack of understanding between RLV and my code, as I have no feedback to determine whether my commands are dropped, have failed, or are in process by server, and there is no simpler way to communicate with RLV in a reliable manner. I only have the ability to get basic information about the avatar and inventory, and use it to inform my decisions with the script which wastes cycles on the server and creates many commands due to polling

In an ideal circumstance, the interaction would boil down to “add or remove all of these things” and a response that told me if it was successful or not, and if it failed somewhere down the line, it should be able to accept the command again as well as provide me with the reason why, i.e. attachment limit exceeded, failed to wear item for whatever reason, item doesnt exist, etc. This would give me way more opportunity to diagnose and work with RLV without all the guess-work and stick-poking to check if RLV died or not