search

vrcx-team / VRCX

Friendship management tool for VRChat
MIT License
1.02k stars 185 forks source link

[Feature Request] Non world ID specifc persistance #658

Closed Happyrobot33 closed 7 months ago

Happyrobot33 commented 1 year ago

Essentially a way to store data that any other world can read AND write, so multiple worlds can work on the same set of keys

Myrkie commented 1 year ago

if i remember correct this feature was considered but has yet to be implemented.

Happyrobot33 commented 1 year ago

I might look into adding it and doing a PR then

Natsumi-sama commented 1 year ago

Wait till the creator gets back to you I'm pretty sure they had a "per world author system" in-progress

Happyrobot33 commented 1 year ago

Wait till the creator gets back to you I'm pretty sure they had a "per world author system" in-progress

Would that fall under say 1 system having a dictionary that any world ID can modify and read? For an easy to understand example, something akin to audiolink settings where changing it in one world would transfer to any other world you join

Myrkie commented 1 year ago

Wait till the creator gets back to you I'm pretty sure they had a "per world author system" in-progress

Would that fall under say 1 system having a dictionary that any world ID can modify and read? For an easy to understand example, something akin to audiolink settings where changing it in one world would transfer to any other world you join

you would have to ask @GroovyTeacup as its his part of vrcx

GroovyTeacup commented 1 year ago

Wait till the creator gets back to you I'm pretty sure they had a "per world author system" in-progress

Would that fall under say 1 system having a dictionary that any world ID can modify and read? For an easy to understand example, something akin to audiolink settings where changing it in one world would transfer to any other world you join

The currently planned system which is like half-made is simply that any world can retrieve/set the values of any world under the same author. So say a creator has CoolWorld, CoolWorld2 and CoolWorldHub, both non-hub worlds could theoretically get/set values on just the hub world ID. The global, shared pool of data between all worlds idea we thought about a bit when it was first implemented but I couldn't decide if it would be worth it since I'm not sure how many uses there would really be compared to some more structured way of sharing data. Plus it'd be really easy to abuse.

If you have any feedback on how the system should be I'd love any input; The idea has been on the backburner because I wasn't sure anyone really wanted it.

Happyrobot33 commented 1 year ago

Wait till the creator gets back to you I'm pretty sure they had a "per world author system" in-progress

Would that fall under say 1 system having a dictionary that any world ID can modify and read? For an easy to understand example, something akin to audiolink settings where changing it in one world would transfer to any other world you join

The currently planned system which is like half-made is simply that any world can retrieve/set the values of any world under the same author. So say a creator has CoolWorld, CoolWorld2 and CoolWorldHub, both non-hub worlds could theoretically get/set values on just the hub world ID. The global, shared pool of data between all worlds idea we thought about a bit when it was first implemented but I couldn't decide if it would be worth it since I'm not sure how many uses there would really be compared to some more structured way of sharing data. Plus it'd be really easy to abuse.

If you have any feedback on how the system should be I'd love any input; The idea has been on the backburner because I wasn't sure anyone really wanted it.

I think it could be worth implementing. I have a package I work on that id love for users to have the ability to have synchronized settings across any world that has the package installed, which is why I think this would be a useful thing to have. I will say, why not both systems? its almost like a protection level for the data, that creators can choose based on their use case. Ultra protected for 1 world only, Readable by other worlds but not writable, Readable and Writable based on world ID, and then global based on some identifier (Maybe use the world ID setup still but have it be the name of the system instead of a world ID?)

Happyrobot33 commented 1 year ago

Just as more of an example, these are all the setting keys I want to save, so then I can just add a "Load VRCX Settings" and "Save VRCX Settings" on here and every world with the compatible version of the package installed now has the ability for quick user saved settings. This is especially useful for things like this and maybe even things like swim systems, where users seem to have a strong opinion on how the physics or controls would like to be and are comfortable with certain values image

Unrelated side note but opening it up outside of world ID would also allow for ARG like worlds to pop up where multiple worlds could collaboratively share data, which could lead to cool things aswell

Happyrobot33 commented 1 year ago

also, and I can open a seperate issue for this if youd like, but if this gets added it would be nice to have some form of semver ability to ask VRCX what version its using to make sure the DB calls comply with what the udon script expects, instead of having to do a bunch of string load error checks to make sure DB features exist

GroovyTeacup commented 1 year ago

Just as more of an example, these are all the setting keys I want to save, so then I can just add a "Load VRCX Settings" and "Save VRCX Settings" on here and every world with the compatible version of the package installed now has the ability for quick user saved settings. This is especially useful for things like this and maybe even things like swim systems, where users seem to have a strong opinion on how the physics or controls would like to be and are comfortable with certain values image

I can see the benefits of a system like that, my only real concern is the potential for abuse and then subsequent complaints directed at VRCX. Something as simple as a toggle for seizure-inducing effects shared across multiple worlds across authors could be hijacked by a single world invalidating the data or turning it off. It'd be horrible design by whoever did it, but well, creators aren't always smart.

I doubt many creators in VRChat are even familiar with the concept of sanitizing/verifying inputs, and with global data keys that would become a potential "attack vector" for worlds. Not necessarily just from malicious creators, but also from creators that have no idea what they're doing.

That's my main sticking point with the idea. Perhaps I'm thinking too much into it; A second perspective would be nice.

also, and I can open a seperate issue for this if youd like, but if this gets added it would be nice to have some form of semver ability to ask VRCX what version its using to make sure the DB calls comply with what the udon script expects, instead of having to do a bunch of string load error checks to make sure DB features exist

This is planned! I think I might just return the current version with each api request

Happyrobot33 commented 1 year ago

I doubt many creators in VRChat are even familiar with the concept of sanitizing/verifying inputs, and with global data keys that would become a potential "attack vector" for worlds. Not necessarily just from malicious creators, but also from creators that have no idea what they're doing.

One thing to mitigate creators not knowing what they are doing is to atleast require "virtual" world IDs, so then you can say "packageA" has these global keys and so on