In fact, I don’t understand the reason for limiting vrcurl construction. Currently, people prefab a lot of URLs to achieve the functions they need, such as 100,000 URLs. This undoubtedly complicates development. People turn on the Allow Unsafe URL setting and have images. The function of constructing the URL after loading the function has become a natural thing.
Finally excited for more custom emoji slots. Now we need to ADD SOUND TO THEM.
Is the documentation incorrect when it says 49 Kilobytes per serialization on manual then, for current? Network Specs and Tips | VRChat Creation
Or is this undocumented changes?
Documentation is meant to document the current state of things. I don’t think we’ve changed anything yet, Phase is just saying we’re going to change it in the future.
Edit: Oh, nevermind, I see what’s happened here.
Manual sync is limited to roughly 49 Kilobytes per serialization.
idk, at certain scales, 62kb is “roughly” 49kb
I’ll get clarification and/or correction
Are we talking US to EU scales here?
(Imperial to metric for those that don’t get it)
I would also like to ask whether the 11kbps upload rate is accurate and/or is also changing?
xd indeed
Also
>Please select your **Top 3 Favorite Music Genres**
>no punk
Sounds like Persistence will obsolete a lot of the hacky stuff that I’ve been doing to make my worlds more disconnect proof. I also have lost count the number of times I’ve wanted to make things static in Udon, only to be reminded that I can’t. Really exciting!
Is there any plans to revive udon UI with this update too? the dev team has been dead silent on it for almost a year at this point if I’m not mistaken and having it would be a huge improvement
We added punk just for you! You can go back and edit your answer.
Is the documentation incorrect when it says 49 Kilobytes per serialization on manual then, for current? Network Specs and Tips | VRChat Creation
Or is this undocumented changes?
You’re right, that documentation is incorrect. Unfortunately a lot of these limits have always been quite fuzzy or unclear because they’re determined by a combination of several internal factors, not specified directly. It’s also confusing because sometimes it’s unclear if you’re talking about the amount of bytes you can actually send, or the serialization bytecount which adds some extra overhead. It’s then further obfuscated by the conversion from bytes to kilobytes, which makes it unclear whether you’re talking about decimal or binary.
Due to the increase coming from persistence, we’ve recently measured the precise end result, and came to the number of 65024 bytes as reported by the serialization bytecount, or due to overhead that means a byte array of length 64690.
As far as I’m aware, it was never 49kb, that was just another rough approximation. Apologies for also being fuzzy on that number in this thread as well. Documentation is being updated according.
I would also like to ask whether the 11kbps upload rate is accurate and/or is also changing?
Unfortunately this is similarly fuzzy, and affected by even more factors (including your own internet connection and ping). This is something we’ve been looking into and want to improve in the future, but we do not have clear test results to share with you at this time. At the moment, the 11kbps documented is a good enough rough approximation, although we’re aware that it doesn’t tell the whole story.
Another questions I have about Udon2:
Are all the udon behaviours will live inside single wasm environment or each in separate one? Will it be possible to communicate between udon behaviours inside wasm with zero overhead not relying on outside Unity/VRCSDK code?
How it’s going to be cheeked for possible dead locking? For example, in current Udon1 interpreter: if you make infinite loop, flow control returns back to interpreter after each instruction where it’s simply can check time spent (or whatever unusual/invalid behavior), but wasm doesn’t rly have interpreter, how it’s going to deal with while(true) {};
(or whatever unusual/invalid behavior)? I am not expert on wasm, isn’t it full-featured bytecode being compiled directly into cpu instructions and executed as native code? This makes some concerns about security.
I hope the decision comes down to privatize this data per-world because the first thing I can see happening are folks coming out with malicious/cheat worlds that manipulate data from other worlds in less than wholesome ways.
Thanks for clarifying
It’s okay that it’s fuzzy, just good to know the rough value we have available so we don’t sit there not understanding why something isn’t working
How does one get access to the Udon 2 closed beta? I would like to try it out as I have been a creator for a while and would like to test the capabilities of UDON 2 before it comes out, and report any bugs.
this is fixed if keys can just be initialized to be controllable or not by other worlds, essentially a flag that requires the specific world ID or not
(Realized I may be interpreting your point wrong, but as far as editing data my point stands. Reading it is another thing)
Worlds don’t have access to the persistent data of other worlds at all. That’s not the type of “private” they were asking about. They were asking about whether or not other users in the same instance can observe the values, in which case the answer is yes, at the moment. But we are interested in implementing “private” player data which only shares it with vrchat api, not other players.
I’m tempted to select this