Okay. This is way better. This is making me happy. Three things, though:
Can some communication please be had with the virtual desktop team on the oculus version? It’s rather unacceptable that it would just be broken. Please try to fix that.
Is a joinnotifier for friends on the internal roadmap? This is something i’ve been really wanting for a long time in vanilla - it’s not like its private knowledge when a friend joins anyways; a notifier would just be a nice way to know so you don’t have to keep checking your social menu, or if you’re waiting for a friend to join, you know when to pop back in to greet them.
Can we get a confirmation that the team will be working on every single anti-crash tech that was originally offered by mods? This means everything the mod community knew about and were fixing themselves. You don’t have to be specific, just telling us that you’re going to work on implementing everything anti-crash that we had before.
I would like to add the avatar search because it’s really something I need it’s super practical to have the avatars of the creators or specific searches in different needs
That’s up to the VD dev. Oculus VD works by injecting a DLL at runtime and there’s just not a way around that. I’d recommend doing what the Virtual Desktop dev states, which is “use SteamVR via VirtualDesktop instead”:
You should look into this XSOverlay plugin in the meantime. It doesn’t discern friends, but its open source, so I imagine that could make a pretty good PR.
No, i can’t confirm that precise statement of “we will be working on every single anti-crash tech that was originally offered by mods”.
A lot of the methods mods used were pretty destructive, so we want to be careful. Also, for obvious licensing concerns (some were MIT, but others were under more restrictive licenses) we can’t look at their code or even their methodology.
We’re looking into every avatar crasher that we have on file (and oh boy do we have a lot). We also have very good working knowledge of the ways people crash other people. We’ve got a method we can’t talk about yet (and, honestly, we may never talk about too much, sorry) that’s far more effective than how modifications ever did it, but it’ll take a bit longer.
I suppose this is fair, and I was perhaps too vague on anti-crash functionality that was in use before. I didn’t want to be too specific, but the big concerns were:
corrupted asset bundles - The community implemented a sandbox to load and verify bundles.
event crashing - NetworkSanity combatted this in a way that did not break functionality like other implementations that blocked events more carelessly impeded functionality.
avatar safety - Being able to fine tune safety settings/avatar blocking based on more modular things, such as polygon count, mesh count, etc. was a huge boon for power users.
trueshaderanticrash - I will admit this one was rather destructive; however, in many instances, it was a complete lifesaver. Something of the sort which was opt in and under a new “Advanced safety settings” menu, alongside things like finer tuned avatar safety, would be a major plus and make me more confident in the team looking to seriously fix crashing issues in my book.
I think something that I would strongly like to see is implementing optional safety features which may impede the game, but severely help power users in the long run. I understand the wish to not break features of the game; there can, I feel, also be a tradeoff provided to users who are more knowledgeable, in empowering them to take control of their experience.
I would strongly urge for a rethink of the all-or-nothing approach and also take into account the “here there be dragons” approach a lot of commercial software takes - see “about:config” and its big warning in firefox, for an example. It would make a lot of people really happy, I think, to be entrusted with power tools as long as all possible outcomes are disclosed, without compromising platform security.
These got addressed months and months ago, they no longer exist AFAIK. Hit up our exploit report form at help.vrchat.com if you’ve a POC.
Safety’s weird. We meant for it to be a way for people to block things like full-screen shaders for shock images and etc but then it got sorta turned into a performance thing too.
Either way, yeah, I want to be able to configure these and set hard limits too. Probably on the way, just needs to find a spot.
If I understand how this one works (I’ve only gotten it through hearsay) it was pretty hamfisted. There might be better ways to address the crashes this one handled.
See above regarding avatar safety but this is a separate item from shader stuff IMO.
If you’re talking about whitelisting certain mods, that’s not going to happen. about:config as a comparison is disingenuous-- about:config is more like our config.json file than anything else. You can’t get your password stolen and your account used as a botnet for ripping avatars by setting your about:config wrong.
If you’re talking about obfuscating power features a bit in a UI likeabout:config… yeah, probably. We don’t mind that too much but the more we add to config.json, the more we get push-back on putting more things in. Also, remember that over half our users can’t access their config.json file. So. It’s gotta have UI.
Anyways. Goal at first is to tackle low-hanging fruit-- the P1s that are close to shipping already or the easy dunks. That’s what we’re doing.
I used an edited Open_Vr.dll File to Downscale then upscale VRC. This gave me and many others who can not afford top of the line PC the ability to play VRC with higher FPS. Now that it has been removed VRC looks blurry and my frame rate is too low. Please implement something like this into VRC. I am aware of the in menu graphic settings but they are not the same thing.
On another note. Their is something wrong with the in game circle menu. It does not always open when you hold down the button.
This is really good - I was indeed talking about obfuscating power features a bit in UI. All of this is really good stuff to hear. Thank you for taking the time!
I was able to collect more information from someone more in the know about the functionality of TSAC:
the main thing it did was limit tessellation, along with some other stuff
the only shaders that would ever pass those limits were raymarching stuff
and it didnt even break those, just reduce their intensity
an avatar should never get even close to any of the limits in tsac
because that means it has some awfully optimised shaders on it
That isn’t precisely what I meant by “how it works”-- but either way, we can’t look into the functionality of mods like that one (not even anecdotally) due to licensing concerns.
In several spots in Dev Update I see a mention of “Feature Jam” and that several features have been made for/during it. What is that about if I may ask?