i will keep var browser workable. but not put into too much time. so if there is some function is needed and not cost too much time,i will handle it.
I totally understand when an older work product is lower on one's priority list. As it is currently, Var Browser is indispensable and very useable for me. Actually, it is so essential for me to have VAM running that if it were less "useable" I would still use it. But for your consideration, here are a few things I would love to see implemented. Of course I have no idea of the work that could be involved. The following are quality of life requests and should not be interpreted as bugs which need fixing.
1. VR features. I pretty much use VAM in VR most of the time.
-1a. Launching Var Browser:
Along the lines of what JayJayWon did with BrowserAssist, it would be great if one of these two buttons were used to launch VAR browser UI (vs using the keyboard hotkey OR navigating to session plugins, scrolling down to Var Browser and then Open Custom UI). I would suggest the top button since I always open the main UI in Edit mode by default. Others may have a different use case. Or perhaps users who only have Play Mode access may have an issue.
-1b. Var Browser window location in VR:
Once a button is clicked, the Var Browser browser window is currently opened in a fixed location (I think it is anchored in the default viewing direction of the VR headset). For me, it would be great if the window were floating just like the main VAM UI. Or if not floating as part of the VAM UI, it would be great if the window were opened directly in front of where the VR Headset is currently pointing. Again, this is a quality of life issue - so that I would not have to expend precious energy turning my head. Just kidding.
2. VAR management
- 2a. Speed.
In my experience clicking on "Install in Background" has no discernible difference than clicking on "Auto Install". Both actions freeze up VAM until the VAR file is migrated from AllPackages. It would be fantastic if "Install in Background" is an action that takes place in the background while we do other tasks.
- 2b. Gear icon is too small.
The action icon associated with each VAR panel is too small. Because VAM is so slow AND the opening of a scene is atomic, there is a significant time penalty for clicking outside the active area of the action icon. For example, if I want favorite a VAR, if my mouse overshoots the gear icon and I accidently click outside of the icon, VAM proceeds to spend the next few minutes opening that scene. I have no choice but to go get a coffee, go to the bathroom, or watch some porn while VAM does its thing. Ideally, the active areas for opening a scene vs opening the action screen would be inverted. Or at least 50-50.
- 2c. Batch operations.
It would be great if there is a way to select multiple VARs and perform a single operation for the batch (e.g. change Auto-Install or Favorite status). Perhaps using an action similar to File Explorer with a Ctrl-click.
- 2d. Uninstall individual VAR.
There is a batch "Uninstall All". It would be fantastic to have the option to uninstall individual VARs - preferably as a background operation. Currently as you know, VAR Browser moves VARs into AddonPackages so it can be opened by VAM. The use case for the individual uninstall would be for when checking out a newly downloaded VAR. If the VAR turns out to be something that I will not likely open up again, I would like it moved back to the AllPackages (instead of doing an "Uninstall All"). BTW, if you implement a batch function suggested in 2c, it would be great if it were extended to this requested feature as well.
- 2d.1. Script based mass action.
If implementing 2d would take too much effort, perhaps if you could tell us how Var Browser's internal DB is organized. I looked at the JSONs in Cache\AllPackagesJSON. It did not seem to me that the JSONs contain information about a VAR's Var Browser status. My thought would be to act on the DB to operate on multiple VAR files (such as in a collection) quickly.
- 2e. Flag for deletion.
I know that giving users a means to delete VARs is dangerous. (Another tool which I will not name, enabled me to accidently delete all my custom scenes). So instead of deleting files, I propose that VAR browser allow us to "flag" a file for deletion (e.g. a red X). This will provide us a note to remember which var files to delete manually. Of course, once a file is removed by the user, VAR browser would no longer present the VAR.
sfishere, I know this list is long. But I assure you that if you do nothing from this list, I will still be a huge fan of Var Browser. As I said before, these are just quality of life issues for me. Thanks again for your invaluable tool.