[Feature request]: Save preferences! (all of them)
Gwyneth Llewelyn
First and foremost, congratulations, this is a simply amazing solution that you guys are providing — one assumes that most of the work is being handled by Amazon Luna's own infrastructure, but I
have
peeked at the JavaScript 'made by LL' and it looks like you really have done a great effort to solve a lot of issues already!That said, I'm aware that my request will be anything but easy to implement. It might even be impossible!
Here's the biggest catch with the Zero viewer: whatever
viewer preferences
are set in our 'main' viewers will be lost on Zero — which is obvious, since all viewer preferences are, well, stored on our viewer installed on our hardware. Zero presents a 'bare bones', pristine environment — how could it be otherwise, since we're basically streaming interactive videos from a (virtual) machine that is powered-up on demand? — which is more than fine for the casual user.But for us tinkerers, well, things are annoying. Buttons and our own shortcuts are, of course, gone; but so are things like camera settings (the most annoying thing for me), or, well, display graphics settings. Like most SL residents who have been around for a while, we profusely
hate
the weird 'view from above' that is the 'standard' camera position; and we have several settings for different environments — e.g., lowering settings on a region with way too much lag, or going to full Ultra Plus Extra Pro to take some amazing pictures. All of these required tinkering and tweaking over the years. And, since they are mostly configuration settings written to disk, they will survive viewer upgrades, and can even be used on different viewers as well (or copied to different computers, so that you have the exact same viewer experience on all
computers you use).Now, since, naturally enough, we will not have any disk-based access to the virtual machine running the remote Zero viewer, but are merely using a single application launched there, there is no way we can upload our favourite configurations to Zero — and that's really, really annoying.
I'm also aware that a naïve approach won't work. I thought about two possibilities. None are implementable in this specific scenario, but maybe they're worth being thought about. I'm posting them as comments due to space limitations here.
Log In
Gwyneth Llewelyn
The first solution is the more obvious and natural: have a way to 'dump to disk'
all
viewer configurations. Currently, there is a lot
of data that can be written to disk, individually and separately (even things like our avatar's current skeleton, for instance), sometimes with very easy interfaces (such as cameras and graphics), sometimes requiring using the Advanced or Developer tools.A much better approach would be a 'save all' button, which would dump
all
the configurations to a single
file, preferably one that is human-readable (and editable!), either in JSON, XML/LLSD, YAML, or whatever format you guys prefer. So long as it's a standard format, I'm sort of agnostic.This would also allow persisting information across versions. Suppose that the current 'bleeding edge' SL viewer (which I'm using) has several more configuration options beyond those provided by the regular, stable SL viewer. In that scenario, I would expect that the 'extra' features would simply be skipped over if the SL viewer reads them. Similarly, when upgrading viewers, deprecated functionality would be ignored, but not erased from the configuration file. The same concept could be extended by third-party viewers that offer options not available on the SL series of viewers: there might be additional configuration there which makes sense for a specific TPV viewer but not for the SL viewer, and vice-versa. For instance, the TPV crowd might add to the config file the configuration data for all the OpenSimulator grids — while the SL viewer obviously only needs two entries (main & preview grids) and doesn't need any other. Nevertheless, the configuration file might list
all
OpenSimulator grids — the official SL viewer would simply ignore them, but also not throw an error and/or deleting that configuration from the file.This sounds like it would solve all our issues, right?
Well, no, because you cannot really transfer any config files between Zero and an application physically residing on our own computers. And naturally enough you cannot upload them, either. So, this whole concept, although very useful overall, would
not
solve the issue we face right now
.Gwyneth Llewelyn
Plan B is also naïve and wouldn't work. As time passes, LL has been slowly pushing most configuration settings to in-world assets. The best-known examples are, of course, Environment Settings and, recently, Materials. It's conceivable that, over time, LL might do the same for other kinds of settings; for instance, we might be able to save our bookmarks as an asset in our inventory as well, or there might even be a simple way of saving camera settings or display settings. They would become commodity assets like Materials and Environment. And that means, in turn, that whatever viewer you use, and whatever grid you're logged in, you can retrieve that special "configuration asset", and apply it to the current session. Again, this preserves configuration settings across different platforms, viewers and versions, and so forth.
So, you would only need to change your
local
settings once, and replicate it anywhere by simply copying & activating the asset — across different viewers. And this would mean that you could
use them even on TPVs anywhere in the Multiverse — be it in any of the SL grids, or on OpenSimulator-based grids.This approach, however, also has a catch. Viewers are always being updated/improved/patched. As that inevitable progress continues, the configuration files need to be updated as well.
However,
assets
are immutable. To create a 'new' asset means deleting the old one(s) and creating a fresh asset. How would this process work? A certain degree of automation would need to be implemented, lest the inventory grows uncontrollably with 'old' (and now useless) configurations, possibly with obscure names, and a resident might have no clue about what was actually saved, so far.Gwyneth Llewelyn
Not to mention the difficulty of extracting all viewer preferences and storing them on the _remote_ asset servers. There might even be regulatory issues preventing that; but, in any case, currently at least, the viewer has not such a capability.
And even if you can somehow get all the configuration on a nice little file on disk, then what? You can't upload files to the streaming platform — or, at least, you can't with the _current_ version of the streaming platform, and, somehow, I have my doubts if it will work through what essentially is a video streaming service that can be interactively clicked upon.
(Note that to get snapshots out of the viewer, since "saving to disk" is impossible, the best choice is to send the image by email — which works fine! Probably you can also get a reasonable picture when saving to your my.secondlife.com profile feed — I haven't tested that yet.)
Some ideas come to mind, of course. The preferences
could
be serialised/encoded into an image, which would be uploaded like any other image (think how sculpties work!) as a special asset. This would allow us to create an asset for personal use only which could be 'activated' as the saved preferences, even on a device that has no way to 'save' or 'load' files. It would just be there in the inventory, waiting for us. And, of course, when on a 'normal' (non-web-based) viewer, that asset would have an option of 'saving to disk', and you'd get the deserialised configuration (in JSON/XML/YAML...) saved.Alternatively, it might be possible to load such configuration files remotely. It could be an option on the Preferences file: 'load viewer preferences remotely': you'd give it a URL and send back to the viewer either the serialised/encoded image, _or_ in JSON/XML/YAML. This would require users to have access to their own web server, or potentially using a third-party service (possibly provided by LL themselves!). It would also be reasonable to assume that such information might require some sort of encryption (to prevent _others_ from making copies of one's configuration!) and/or a PIN code to unlock.
Whatever the solution to be adopted, what matters is to have the ability to somehow save the viewer's setup (any viewer!) and restore it to any other viewer — no matter what constraints and limitations might apply to each.