locally (offline) stored / persistent variables

[alexderpyfox]

Is your feature request related to a problem? Please describe.

no limit to how many and creation and deletion is instant also local is good if you want different values on different pcs for the same avatar

Describe the solution you'd like

local cloud variables so values can be different across different pcs because it would get the value from local

Describe alternatives you've considered

mods

Additional Context

persistent avatar toggles

Requesters

No response

[paradoxical-autumn]

I've actually talked about this to some friends actually! Having a way to save data w/o the cloud would be very useful.

However, this would still need rate limits to prevent read/write spam (but a solution similar to cloud variables would work - keeping the values cached in the RAM until they're written once every so often.)

and

How can we prevent users from tampering with another user's local variable setup? Example:

• User A creates a local variable: U-A.Cool_App.Enabled
• User B makes uses protoflux/components to delete the variable definition for U-A.Cool_App.Enabled or edit the path to break existing content

How can we securely get the defining user, I'd guess a component similar to Simple Avatar Protection (SAP) where it has a defining user set and if anyone tries to tamper with it, it either rejects the requests or self destructs.

A layout like this would be feasible: LocalValueVariable\<int>

• Defining User\<str>: "U-1PsFEG1qoqm"
• Variable Path\<str>: "CoolApp.Material_Index"
• Write permissions\<enum>: variable_owner
• Update definition\<bool>: False
• Value\<int>: 2
• Is Linked To Definition\<bool>: True ---BUTTONS--- Create variable definition Delete variable definition

Anyone can remove the component but if the path is edited by anyone but the defining user, it reverts the change and only the defining user can click the buttons on the component (like SAP)

The reason why we need a defining user in this is also so that user A and user B can each have their own definitions with identical paths:

• "U-A.App.State"
• "U-B.App.State" would be separate definitions for each user.

[shiftyscales]

Editing the title to indicate this is intended for offline/local use cases. They wouldn't be cloud variables because they wouldn't be stored in/read from the cloud based on your description.

I'm not certain directly how useful this would be, because if the local database were ever lost, so too would be the configurations/variables.

@alexderpyfox @paradoxical-autumn - could you please provide additional context/use cases for why it matters that the variable be set differently on a per-machine basis?

If they were locally stored/offline, they would implicitly be per-machine.

Unless you mean use of cloud variables (online) which have a different value stored per-machine- which again- if that's the request- what are the intended use-cases/goals for such a system?

In the coontext of "persistent avatar toggles"- you would want to use cloud variables because they would be fully persistent across machines/local databases/installs.

---

@paradoxical-autumn - Preventing tampering is covered by the hard permission system #1103.

[paradoxical-autumn]

I think the main reason why @alexderpyfox would want this to be per-machine is so that the restriction on the number of variables that can be created is either lifted or raised in this use case, as there's no storage required on your [YDMS'] end.

It would also potentially allow for local save data that isn't tied to an account, but rather a computer but I'm not sure how useful that would be.

I'm going to have to defer to @alexderpyfox for other uses for these.

[ko-tengu]

First use case that springs to mind is the ability to do autosaves and such in game worlds, instead of the current system game worlds have to do with giving you an orb to manually save and manage in your inventory; like how the farm world made for MMC this year has you do it.

Another use case I've run into is for presets for specific objects or worlds; Orange's Delicious Camera lets you make presets and save them into a crystal to put into your inventory, being able to save it into a local folder would dramatically simplify using and creating presets and remove a layer of inventory management.

quick edit for clarification: I think these are bad fits for cloud variables because they're a potentially endless list of files, I have dozens of camera presets even with the annoyance layer of having to manage inventory items and having 20-30 cloud variables taken up entirely with camera settings is undesirable.

[JackTheFoxOtter]

First use case that springs to mind is the ability to do autosaves and such in game worlds, instead of the current system game worlds have to do with giving you an orb to manually save and manage in your inventory; like how the farm world made for MMC this year has you do it.

Hi, I made the system you're talking about. You can already do this using cloud variables, however we actively chose not to, because doing it this way gives us more flexibility in how we structure our savegames. There is nothing "local variables" would allow that you can't already do with cloud variables, except perhaps remove the size limit, but they'd come with a significant drawback - they are local. That means they would be lost if the user clears their cache or just re-installs the game, or switches to a different device. They'd also only have a single version, so you wouldn't easily be able to create multiple different savegames.

From my understanding the issue here is that cloud variables only save a single value, and their creation is a bit more involved. Traditionally people (and myself) have gotten around that by just encoding the save state into a string, but that adds engineering complexity, string cloud variables have a length restriction and parsing / writing them is currently kind of awful to actually pull of.

The savegame object you can save to inventory appraoach leverages the systems Resonite already has (inventory), and massively simplifies the saving / loading part, given the tools we currently have available. I don't think what's proposed here would actually simplify savegame handling for creators, and they'd just end up in a worse user experience. (Why is my save gone? Why can't I make a seperate savegame?)

The way I see this the underlying issue is the lack of structured cloud variables. I believe this is better approached by supporting collections as a cloud variable type once we have #572. I don't think adding local information storage into the equation is gonna simplify anything, it's just gonna make everything a lot more messy.