That is weird that the UI sound settings doesn’t apply to it, they should fix that.
1 Like
This is great and I am looking forward to using it. It will be interesting coming from JavaScript/TypeScript and how this will work. I’m at least glad Lists are in here too because I needed dynamic arrays!
My only question: Does this JSON feature imply that we will be getting world saves soon? Being able to save some sort of world state would be great for people who want to persist their settings or make games that can have progression long-term.
It seems Momo mentioned that it will likely not be for a while, based on the 2-3 month rule about announcements?
https://feedback.vrchat.com/vrchat-udon-closed-alpha-feedback/p/save-load-persistent-world-data
Always happy to have more functionality!
I don’t think it would be that bad. That’s what web requests often do on most websites. It’s stringified JSON. Unless the Udon VM has really strict memory requirements?
My only question: Does this JSON feature imply that we will be getting world saves soon? Being able to save some sort of world state would be great for people who want to persist their settings or make games that can have progression long-term.
It’s definitely true that people want generic key-value storage for persistence, and this will fill that need. But it’s not directly connected or implying anything about the release date of persistence.
I don’t think it would be that bad. That’s what web requests often do on most websites. It’s stringified JSON. Unless the Udon VM has really strict memory requirements?
JSON is not bad in the context of the web because it’s not (usually) real-time. So you can bundle up an entire website into one (relatively) massive packet and send it all at once. As a result, the infrastructure has been optimized for individual, large downloads. In realtime networking such as games or vrchat, you need to send many small packets, and so the infrastructure has been optimized for that use case. Generally, a system that has been optimized at doing one thing very well is not going to be very good at doing the exact opposite. Additionally, realtime networking is expensive because of those optimizations to make many small packets possible, the limited number of users that each server can deal with at once, and maintaining a live connection to all those users at the same time. It’s not that it can’t, it’s just that sending a large packet through realtime networking is a big waste of resources because other systems that are more suited for the task can do the same thing for much cheaper.
Anyway, all that is to say - if you try sending 50kb of json, you’re gonna be able to do it, it’ll just cause you to get “Clogged” for a while, which is VRChat’s way of slowing down network sync to make sure we don’t break the bank. But 50kb of json is a lot of data, so hopefully you won’t need to do that very often. Most simple game states as json would be well under 1kb and could go through totally fine, but that’s still kinda a lot in the context of realtime networking, where you may be dealing with individual bytes.
1 Like
I understand now. In the context of network packets for games, JSON is really large and probably can’t be very quick to update on 30, 20, or even 15 tick.
Though I would imagine that JSON for manual sync may be acceptable, depending on the situation?
Is there any consideration to tweak the Avatar performance formula? For example, each attribute has a different weight for its value, and the final sum is used to grade it, instead of one item exceeding a limit being indicated as vrey poor. this makes it useful to hide avatars by performance (90% of avatars are now very poor), and may also motivate authors to optimize when making models.
We have analytics showing us avatar stats, and this isn’t true 
You could do that, but it obfuscates the problem that the avatar might have, and makes the avatar performance system even more nebulous and hard to decipher. We set pretty specific targets for various metrics intentionally, and turning that into a Second Life-esque “performance score” has a bevy of problems all its own.
Thankfully, as previously mentioned, we have research! This is what Second Life has been doing for years, and it has lots and lots of problems we want to avoid!
Yeah, 90% is just a complaint. Since I can often encounter avatars that can plummet me by tens of frames ravaging my computer, blocking by ID is a very useful feature. I’m glad to hear you guys care about this. If performance ratings can be reformed, maybe blocking by rating can become popular among users (many players don’t know what all the performance parameters mean, and the current ratings can’t be used as a reference), and more Avatar authors might optimize it.
1 Like
I would say that the current system isn’t much better. Many avatars these days are very poor, even if they only have 2 inactive lights or maybe a poly count that is 70,050 (very poor) versus 69,950 (good).
Has there been any interest in trying to make an “active avatar stats” which can see the active objects and take a guess at the current performance? For example, someone in the community I’m in was protesting about the basic restriction they proposed of 200 MB VRAM and 64 materials, saying they already have 140 MB of VRAM but they have 193 materials, where I guess maybe a dozen or two at most are active at once.
Even if they are just really early ideas or no ideas have been formed, has VRC been trying to at least look into changing the current stats, beyond the recent addition of texture memory?
Json is incredible news. Will there be a way to have VRChat read a json file from the internet or write to an online json file? Can they be stored on a server owned by users and accessed, or stored in VRChats server, changed, and saved there?
Saving games has always been a tipping point for imagining certain VRChat projects for me.
1 Like
Any plans to add a stereoscopic picture mode(s) to the camera? (side by side)
I am also interested in this. I understand that sending HTTP requests crafted at runtime can be a security/privacy nightmare, but having the ability to permanently store JSON somewhere would be a huge game changer when it comes to Udon!
And, let’s be honest, not being able to instantiate HTTP requests at runtime only makes it harder to send data, not impossible. There are already worlds that work around that limitation, even though remote string loading is not even released yet 
Or just having the ability to store parameter values like in Avatars, would even be a 100% local solution.
@EinDev @lossycoffee A few dev updates ago, they mentioned the “String Loader”, which allows you to call endpoints and get JSON. Tupper also mentioned that it should work like Video URLs already do, so there will be whitelisted URLs, but with “untrusted” on, you should be able to request any URL.
However, this system seems to only support GET requests. Also, someone was telling me that based on the way VRCURLs apparently work, they can not be modified at runtime. It apparently is something that can only be triggered through a URL field from a user. However, I don’t know if there is a way to get around that, and at the very least, it may suggest that a user can copy and paste a string into a URL field.
My idea was to use query params to send a string of data for world state. I.E: User settings for a world, so they can persist. But yeah, we will see if that is actually possible and to what extent.
1 Like
If it wasn’t for this being something that could/would break worlds in the future, having VRCPlayerAPI.GetPlayersWithTag spit out a DataList with VRCPlayerAPI would be a nice, so we could actually use it ^^
But glad we’re getting some form of list. Take it a full list over available list properties and methods will be available during beta release?
Will this be what’s used in the early version of Remote String Loader?
1 Like
Hello, Tupper, this is one of the VRChat user, xKiD.
I’m happy to hear about the multi-languages support in VRChat since I saw many of my Korean friends were having trouble with finding the correct options for what they want to choose.
Now, since I’m attending one of the university in Canada, I can help with the Korean translation for VRChat. If there’s any help needed, feel free to contact me.
Wishes the best!
regards.
1 Like
Volume A+ 
Localized Tooltips - I am really happy to see this change, so thank you to who ever put the effort into doing that. 
I have no complaints this round 
Imagine that. Keep up the awesome work. \
Side note: what is Groups looking like in the months to come? Will this ever be a public thing? It does seem more profitable to keep it as a VRC+ thing but just wanted to know what direction you guys are headed with that.
1 Like
I keep forgetting to ask about two things in VRChat home. For the avatars on page 3, himiko doesn’t have working gestures, but I saw a copy in vket2022w that does. Both are same exact author. It has to do with masks on the animator I believe. I don’t actually understand Japanese, I just can read through the output of Google translate. Maybe I can somehow ask VRChat to ask the author to fix the fallback version? My suspicion is that maybe the default fallbacks are locked from change.
The other thing is that right next to himiko there is a yellow/black pattern, not sure how to describe it but it’s a selector for avatar that is not available. Could this slot be filled? It’s been like that for awhile.
This topic was automatically closed after 7 days. New replies are no longer allowed.