I don’t think compilaion will be heavy on load. Not many ppl upload worlds with complex scripts. No need to process tons of data as it is with asset bundles. Also priority queue may be implemented. Should be fine unless someone try to put entire embedded linux inside the world.
But if assembly already verified on server side there is no need to do runtime checks. Should be nice performance boost with direct calls w/o extra overhead on call checks, w/o unnecessary boxing/unboxing of variables.
It doesn’t matter if it’s “not heavy” in an individual context (which it is), you have to consider how much that with multiply when you have x thousand users all trying to upload stuff. They’d need new server systems for this express purpose, lest it will cause our existing issues to be much worse.
Money is always the issue. Better solution or not, it costs money to run dedicated systems for operations like these, rather than letting client systems handle the load. The only affordable alternative is some kind of blockchain method, but all that does is spread the load instead of just burst it on the system that is building the asset. Storage is cheaper than remote computing power, and vrchat’s storage is already very much not cheap.
It’s almost as if there is a difference between something being good enough for a third party mod and something being polished enough for implementation in the main game. 
I believe the SDK part mentioned was probably referring to the World Rules, where world owners could limit scaling if they wanted, not that it required an update to the Avatar SDK.
Not really. Many developers, even AAA, often make use of ad-hoc code to solve little issues or add little features, because they value speed and “if it works, it works.” Going on about “a lot more goes into it in actual game development” usually means they have an inefficient maze of QA approval process from what i’ve seen (though in some cases they have to go though licenses and so on to see what they can and can’t do legally etc).
The problem i have with this, is that VRChat often releases fairly ad-hoc features that may or may not be buggy anyway, so there isn’t a whole lot of difference. Very simple things like this should only need 1 coder (and if they know what they are doing, barely an afternoon to put it together), at most a single ui person to spend 5-10 minutes to add the ui elements in, a double checker, a triple checker, and then a beta launch. This could all be done in an afternoon by 2-4 people most.
You don’t need to spend countless hours testing it with everything else to make sure it’s all super peachy, that’s what the beta is for. That said, with isolated systems like this, it’s unlikely to interfere with much - especially because they already have dynamic virtual IPD adjustment with the arm/height slider. All they’d need to do is call an update to that when someone applies a scale on a scale slider.
OR they could just do SDK and add a 3.0 parameter for call update on virtual IPD.
Yes, computing servers are expensive, but you know, if there were servers for checking user’s content and validating user-to-user data, perhaps we would not need EAC at all. It’s a very bad practice to rely on clients if we seeking for privacy and safety.
Most of that money goes into upkeep and licensing etc. Running VRChat is much more expensive than people think. It seems fairly apparent that VRC+ is the money that goes into development (pads it out), not the investments, as development only really started picking up speed since they added that.
Well, yes, may be you are right. I’m not qualified enough in business/finance to argue about this.
But still, back to topic, IL assemblies can be validated on client side at world load, and the only security difference there is that validation proces is exposed, not hidden on the server, so may be easier to find exploits. No much difference comparing to suggested Blazor method.
As I understood from what OP and Merlin said and Blazor docs, some kind of embedded browser(?) will be used as Wasm VM, it will be executing user code and Blazor itself will only act just like .net imlementation (providing some useful common methods), as compiller IL to Wasm (AOT?) or like interpreter for IL (if no AOT?). So the task of sandboxing, ensuring security and safety lies on embedded browser? This sounds nor bad, nor good. if the browser will be connected directly to VRC w/o some strange compat layers / proxies it’s should be fast enough (browsers actually good at jit) and safe enough (well they are browsers after all).
But I still think just adding Mono/.Net runtime can give the same result with less steps and probably easier to implement, maintain and support. And allso fast enough (support jit).
We need to validate IL anyways in both cases: either to compile Wasms and run it in browser, or run it in Mono/.Net runtime. Both variants allows restriciton of available method calls.
So why there preference on Wasm? Some future-proof compatability goals? Better support/performance on Quest orother platforms? Better jit in browsers? Plans for user control on custom web-based UIs?
Correct me if I wrong on something.
Yes a reduced Udon interpreter will be run inside the Udon 2 runtime for legacy scripts. Part of that may involve converting some script’s Udon assembly to CIL at some point.
With udon 2 useing c# assembly couldn’t you just code c# and compile it into c# assembly just not useing udon entirely
Mono and .NET’s sandboxing is historically deprecated and highly recommended against by Microsoft. .NET currently is making some improvements to the CoreCLR’s sandboxing capability, but it is unknown when/if those would be useful enough for Udon. Assembly validation isn’t on its own a solution in those sandboxing models either. You need the runtime to provide many guarantees that require you to essentially audit the entire runtime’s libraries and implementation which isn’t viable.
Using Mono directly would also raise issues with platforms that it is not made for. For instance if we wanted to eventually run on iOS, web browsers, or consoles, those platforms generally have issues with either running JITs, or are architectures that Mono’s existing JIT doesn’t support. (don’t read this as an indication of any plans for platform support, this is just something we don’t want to need to eliminate as a possibility if we want to support one of those platforms at some point in the future)
This is not embedding a web browser in the client, it is embedding a standalone Wasm runtime. Right now Wasmer is what is used, but different runtimes may be used based on platform/feature requirements.
There is no IL validation in this runtime as it is not needed. It’s not possible to call Unity functions that we do not whitelist since the linkages are not generated. If you want to represent something that’s ‘unsafe’ like using pointers in C#, it’s totally possible but you are still subject to the Wasm VM’s sandbox so if you attempt to do anything malicious you’ll at worst end up crashing the Wasm runtime in the world. IL validation’s solution to stuff like that is that you just… can’t use unsafe code which prevents the use of many C# libraries.
Yes you can write C# scripts and use existing C# libraries in this system without Udon-specific code or considerations. Udon does provide syncing and other interactions with VRC’s APIs though so if you want to use those, you’ll need to touch Udon in some way.
Sounds reasonable.
And not overcomplicated.
Rly good idea and actually less dependencies than I thought.
Can’t wait phase 3 in 2023.
When this will be resolved? 2xfn28
My internet its 100% good i tested on other computer and this BUG didnt happen, the things is this only happens on my computer every 15,20 minutes being on a server my pc its; z690-p d4 / i7 12700k / 1TB SSD, other 500G SSD only for vrchat / 32 gb ram ddr4 / nvidia rtx 3060 this makes no sense for real because this happen even me playing on my desktop lol
When Momo presses “Save Video”, a timeline plays music and mixes between some virtual cameras. The button also starts and stops a local video capture, saving a file to a
VRChatfolder withinVideoson the user’s drive, or in theDCIMfolder on a Quest.
This feature will enable creators to create virtual production studios within their worlds, and help visitors capture amazing clips!
I asked for a similar feature a few weeks ago. I hope this expands beyond using this for UDON worlds and more for VRChat’s own camera system as many VRC Film makers would like to have these regardless of what world they’re in. It’ll especially be helpful for those that want to record with alpha channels too
That remote string loader updates seems to have a lot of possibilities in bridging the gap for worlds to actually have some type of persistence and progression systems.
Technically by doing this it seems some games could have a third party site that allows users to sign up and thus keep track of their progress on a world and have that be reflective in worlds if instead of getting the data from VRChat itself [which seems like it still isn’t possible] the data on user progression could simply be fetched from the world creators own database.
I think the biggest thing VRChat needs going forward is more progression systems both in general for the platform and of course for specific worlds/games.
I can assure you it is. I’ve tested native and udon, and it seems that it is hitting some weak points in the current Udon VM. Native C# is able to make it run at 100x its normal speed, and I just need a 30x speed up to get to normal speed with udon. I seem to have added an extra zero on my estimate by accident, so it should be 3,000 not 30,000.
I made a small error and added an extra zero, its more like 3,000x slower than C# runs the same code. not 30k
Is there any chance we’ll see client side plugins once Udon 2 is available? Or even avatar Udon?
I don’t think you understand how happy this makes me.
This means I can now create a basic API to store world save settings! Obviously I would prefer a local save so I don’t need to setup an API, but this is amazing! Thank you!
Also excited for the Udon changes. I was planning to get into it, and this new system looks much more interesting and possibly intuitive, as a programmer.
Ah, right. Good point. I forgot that GET doesn’t imply POST.
I will still probably make an API for world settings based on user ID or something. At the very least, I can probably have users set up the world settings, copy a JSON/string in VRC, and then provide a very basic web interface so they can save them into my API.
AHH! You’re right! I forgot that we can kind of ignore web standards to get around stuff, hehe.
To be fair, there are a LOT of features in VRC that are buggy or otherwise much worse than the mods they tried to replace. Just because you try to have a high standard for yourself and the features you implement, doesn’t mean it will actually be as good as the mod.
Completely agree. I am a little peeved that VRC constantly closes their beta branch, instead of just leaving it open (with feature parity when they aren’t testing). Heck, I’d be happy to have an “alpha” or “testing” branch where users can test features, even if it isn’t network-compatible with live VRC. This would go a LONG way in speeding up feature development, especially if they want to lock the branch behind some sort of QA tester authentication system, where people can apply for testing (like Tarkov’s EarlyTestServer who sign NDAs).
Just quoting this, since @lackofbindings mentioned that you should probably be able to use Query Params to send data to an API, so it would be a seamless process for the user and you can make a very, very basic API on a free system like Vercel, Firebase, Self-Hosted through Cloudflare, etc.
Edit: Oh yeah. This also should mean that worlds like Sword Art Online can finally save user progress without needing to use a specific avatar! I really, really hope that you can at least do Query Params to save data. This would drastically raise the ceiling for what people can create in VRC if they can have persistence.
Imagine game worlds where people spend hundreds of hours playing with persistent progress? Or maybe a DnD world where GMs can manage and host DnD events! I could even imagine having sync with DnD Beyond or other DnD systems! Heck, you could probably even create an interface to somehow connect VRChat with Discord! How cool!
Edit 2: @tupper sorry for the ping, but can you clarify if WASM can be directly written? I only ask because I can totally see using libraries like Subtitle Octopus or libass by compiling them into WASM (something a friend of mine did), and then using them in media worlds for software rendering of subtitles on video. This would be seriously helpful for people watching anime or that need closed captioning.
It is… interesting that worlds will be able to capture video before the in game camera can. I feel the latter is much more important for creation in VRChat - it’s a camera, so if other things can do video, it should be able to create video too like a real life camera can. trying to use the stream camera to capture with an external tool is clunky and often doesn’t lead to great looking results. Is this being worked on?
