One issue i find, is that the revamped NYE worlds don’t lend well to being good hangout worlds. They’re a bit too busy. The old Times Square worlds had a lot of space and even a rooftop venue to hang out in while waiting for the countdown. They were quite popular, to the point people even went back to the classics.
2 Likes
Scaling, Freeze Frame, Camera Animations, all seem to be stuck in the ‘we’ve talked about it’ phase for awhile now. Honestly am disappointed and am getting the impression that these highly community requested features are now stuck in Canny Limbo. Hope I’m wrong. 
4 Likes
Still waiting for video players and post-processing toggle.
1 Like
Udon 2, not Twodon, or tUdon?
2 Likes
All of these features you’ve listed remain firmly in the “we have talked about it” section!
As has been noted several times in several previous Dev Updates, Scaling (I assume you mean Avatar Scaling) is locked behind a system we want to implement called “World Rules”, which will allow both world and instance owners to define rules that govern how scaling behaves in the world.
Implementing this system first allows us to add more systems to it other than just Scaling. That way, we don’t paint ourselves in a corner later on when we want to add in Rules after we added scaling, and some design/implementation hiccup holds us back. So, better to do it properly than to do it immediately.
In particular, the rules and scaling systems depend on input from various teams-- primarily SDK, UX, UI, and design. Those teams have been pushing hard on things like Groups and (sorely needed) Udon improvements for the latter quarter of this year.
Unfortunately, we’re not a huge developer! We have limited resources. The things we have released have been the result of very high-powered multi-team pushes.
At VRChat, we’re super excitable about new features, including the new camera features you mentioned. We LOVE talking about ideas, about things we wanna do.
A while ago, we decided to be more transparent (at Community team’s request!) regarding features we’re working on. However…
There is a cost to sharing those ideas before we are close to shipping them. Even if we say “We don’t know when we can ship X feature, but it’s a cool idea!” people will still set an internal, mental timer on it, expecting it to be out by that time. I think Discord’s CEO, Jason Citron, jokingly put that timer at ~6 months during an interview. That sounds about right.
Sometimes we talk about things that might be a good way off, or locked behind other features, or fit into other plans, or get pushed behind other, more time-important priorities.
The development of a product like VRChat is tough. Triage is a daily occurrence. You have to pick your patients, and something ends up languishing out of necessity. It isn’t fun to see something you were personally looking forward to getting delayed just a little bit more-- trust me, I know.
I’m sorry the features you’re looking for aren’t in yet, but rest assured that we know you want them, and we want to get to a point where we can deliver them. Your patience is appreciated, though!
We… have video players? 
Am I misunderstanding you?
We’ve stated in a previous Dev Update we’re not planning on implementing this, so please, don’t wait up on it! :S
Oh, wait, do you mean a video player toggle? If that’s the case, I don’t think that is a feature under consideration at all. I’m making some assumptions, but I think the solution we assume creators will use here is a toggle in a world.
I actually don’t know if it does or not! I’d check the AVPro documentation. You could always create a quick Unity project yourself and test it out to see if it works. I think AVPro’s free version will work, albeit with a watermark.
We don’t particularly design them as what a VRChatter would consider a hangout world, so that makes sense. They’re more meant to support the event (VRChat NYE) that they’re built for.
3 Likes
I think the solution we assume creators will use here is a toggle in a world.
Video players is very problematic:
- It’s not hardware-accelerated, so if someone put high-bitrate 4k video in the player, some users may get troubles with all cpu cores 100% load easily and major fps drops with entire audio crunching.
- Since EAC, it often drop errors about codecs, because EAC blocks some codecs. Some times it turns into error-windows DoS attack, with errors like this:
- Some videos may contain intentially corrupted data to cause problems. Ex. this 4daa9c51d9018156.mp4 — Yandex Disk video can cause various crashes on some systems from app crash to entire system video driver crash (try with caution n different browsers and video players). This also can be used in malicious way.
- Users may just drop shitpost/noisy/shock content videos into the player. And you can’t even do anything with that and not always able to figure it out who it was that, who must be reported. This is major problem in public instances right now, seems to be main entartaiment for trolls.
- Content creators often unaware about these problems and/or just doesn’t know how to fix that. They usually use drop-in prefabs that hard to modify or extend. It’s complicatead security and safety topic, not many ppl competent enough with that. It seems just toggling GameObjects or keep it off by default breaks sync for everyone in the instance in most community prefabs.
All of these issues have been mentioned on canny over the last 5 years.
Only solution for now is just to block yt-dlp.exe in windows firewall.
Users should not depend on creators.
Does the same logic apply to avatar features? It has switches for some reason. Why not the same with world features?
I could agree with this if the worlds had a system of public reviews and ratings, but there is nothing like that. Entering an unfamiliar world, you take a cat in a poke, a cozy chill can await you, or maybe frustration.
(And the same applies to the post-processing too but much less.)
3 Likes
Extremely excited for some of those Udon features announced. Being able to work with text data will be great for the Gameshow and quiz game worlds for updating their question databases. In general, being able to access plain text data opens up all kinds of capabilities.
For worlds with existing Udon Sharp, will classes all happily talk to each other? So for example an ‘U# 1.0’ script can talk to an ‘U# 2.0’ script and so forth? I’m guessing so but wanted to check. 
1 Like
U# 1.0 scripts work in Udon 2, you wouldn’t have U# 1.0 installed as it would cause conflicts.
2 Likes
any chance for jit in future?
Technically Wasm JITs the Mono runtime in this case. For user code, partial AOT to Wasm so the Wasm VM can JIT it is something we want to look at integrating.
1 Like
Actually, wouldn’t it be better to give access to a limited instruction set on the Engine level in C# or through components? Because with that wouldn’t we all get engine-level performance and not need any additional overhead on the game itself. Because even if the use of an Wasm VM will give us better performance rather than UdonAssembly, it is still an overhead that might not be good for both platforms, PC and Quest alike.
1 Like
Do I understand correctly: To properly support Udon 1.0 VM assemblies, the Client will also contain translator of Udon 1.0 bytecode (as .vrcw may not contains sources, just compiled instructions?) co C# texts and compiller of C# texts to IL-assemblies? Or it will be directly Udon 1.0 bytecode to IL bytecode translator? Any thoughts how fast initialization of Udon 1.0 worlds will be? Any cache for “converted” scripts?
1 Like
Agree, I don’t know how safe is it, but I guess it’s much simplier and performant to implement pure Mono/.Net runtime in the Client and provide creator’s assemblies into that runtime. As I know it can give some level of sandboxing and isolation.
Assemblies may be generated on server-side to avoid any ways to upload boken/malicious assemblies and also to validate both source code, compilation process and generated assembiles. Unwanted calls to not-whitelisted code and other various sus instructions can be easily detected there, as every method if explicitly referenced. Some unsafe direct memore instructions require explicit unsafe falg that can be prohibited. Etc.
May be main problem will be ability to make dead-end / infinity loop code, as it is not interpreted but running by runtime itself, but I guess it can be monitored by off-thread watchdog or something like that, it’s does not look like unsolvabe problem.
I suggested that in early Udon canny and I still beleive this may be “the way” to performant complex scripts execution.
1 Like
This has also been counter-argued thoroughly. Avatar scaling already exists for avatars, albeit in a slightly janky way, and it causes no significant issues in worlds. Also in a game world, nothing stops someone from swapping into a giant avatar at any point and mucking everything up (or animating their armature away to avoid armature-added colliders). The only realistic solution for this is an old trick of the world checking for the distance between the camera and the player’s origin and automatically ‘disqualifying’ users from the play area if they get too tall or playspace move too far up (ex. Loli Sanctuary). Even your “World Rules” won’t be as capable of solving the potential issues of oversize avatars as that old height check method is. Plus it’s completely bizarre to let world creators completely block out what ought to be a lucrative social feature.
protip: add an “avatar height” float node for the udon graph. then people can easily have worlds do things if your avatar is too tall or too short at any time, if height is important enough to the world (or even take advantage of it, like making you go into a mouse hole in a small avatar).
I think what bothers people about stuff like this, is that a scaler was already made in a mod, it was very basic and automatic, and did not require much development time to cook up. In the UI you’d need only add a single simple slider somewhere in the gear tab of the quick menu and call it done. Don’t even need to let people scale that much, like 4x size down to 0.125x size or something (0.125 intervals as integer notches), just for a general functional range for most people and to improve ease of interaction between people of all different size avatars. Quick, dirty, make sure it doesn’t crash and does what it’s supposed to, release. At most add a “confirm” button so that the virtual IPD updates once instead of as you are sliding it. It was one of the things that was very widely used by the modders because it was very freeing and useful for interacting with people. I saw many even get mods for the first time specifically for the scaler mod only.
ps: the mod didn’t require ANY SDK additions, the mod only required you scale the base gameobject that held the avatar descriptor and then the mod made the game automatically update your virtual IPD. The current scaling methods use a funny little trick in 3.0, which upon reloading your avatar (using osc or ik toggles), cause vrchat to automatically reference the virtual IPD - probably taking advantage of the new armspan-vs-height scaling system that updates your virtual IPD on adjustment. I haven’t looked at the systems for that, but they may also be as simple as rescaling the avatar.
This is why it would be really cool if you guys expanded your QA team a bit and added a “volunteer branch” for people who want to develop for vrchat unpaid, and just have a couple people or small team in charge of looking over code of things the volunteers write. This is all the modders actually wanted, was a way to contribute and make vrchat better. Sort of like a novelist/editor dynamic where a team member checks the code and lets the coder know where they need to have open slots for internal variables etc so they can edit and send in again, and if it’s usable enough, then VRChat team needs only adjust it enough to slide it into the game’s code and checked over by the rest of the team (any implemented volunteer code would be the responsibility of the ‘editor’ ofc). Note contributor credit in-line and mention thanks in patch notes, ez.
1 Like
The issue is, without completely sandboxing everything, people are going to find exploits and security holes everywhere, causing a complete developer nightmare trying to close all the holes (assuming they even get found/reported), meanwhile people are at risk. Nobody wants to deal with that, hence most games/platforms opt for total sandboxing.
That requires a bunch of investment in computing server space to run those compilers. This is the same reason avatars are built clientside in the SDK and uploaded as-is. Script whitelisting is done at runtime, though the SDK tries to lighten the load by just deleting these at build.
Yeah, true. But a Sandbox also isn’t a holy grail for everything. Also, don’t we have EAC for helping us out for that?
1 Like
EAC doesn’t really help with that at all. Just maybe somewhat discourages it. Also if the malicious code comes from inside the game EAC probably won’t even see it. It’s job is to prevent external manipulation of the program it’s attached to, not be an antivirus.
1 Like
what about gameobject and component constructors?
1 Like
But Mono and .Net both have sandboxing techinques. The only main difference is Blazor aims for web browsers and Mono/.Net for native apps. How you can tell one is more secure than another? Is there any guarantess there will be no exploits in Blazor?
Idk, I am not a pro on this topic, but I afraid that suggested solution may be overkill: you will have to drag along too many dependencies in the client: the browser engine (to run Blazor; chromium?), Blazor itself, the IL translator to WebAssemblies (or is it part of Blazor?; it is said that it will be forbidden to use your own WebAssemblies), a C# to IL compiler (Roslyn?), and a Udon1 to C# or IL translator (to ensure compatibility).
I am sure somwhere is this chan will be few critical RCE exploits or something like that. You need to trust in more 3rd components than just Mono/.Net and own filters.
Also, may be it will close to native code on performance, as modern browser engines are fast enough, but it will give large impact on system resources for sure. As I look on apps like Discord or Spotify I am terrified, those guys are literally own chromium-browsers who can randomly eat a gig of ram. Imagine some extra level of sandboxing/virtualization on top of, in Blazor itself or by other 3rd tools…
1 Like
Did the vket2022w panel in the world list get taken down before the end of the event? I thought I had more time to look at stuff. I know I can search vket2022w, but the tab was nice and consistently sorted. Unless there is a new event to replace it, it’d be nice to have the tab there for an extra day, stamp it with “over”