What’s the implications of the change in Particle Systems?
E.g., I have a bow prefab on my avatar, that can shoot an arrow, and when the arrow hits a surface it autodestroys, and spawns a new arrow in its place as a “decal”. Will that be affected?
1 Like
We have our own workflow in mind, but it looks to have some similarities. Still cooking though, promise it’ll be easier than ever!
What you’re describing is most likely a particle system that activates/emits a child particle system on particle death, not destruction. The destruction behavior mentioned in the post permanently deletes the entire game object, which can only happen once, and is a vector for exploits.
1 Like
Still wanting the option for user to see their own very poor avatar on mobile. Been over a year, and is wanted in the canny.
Optimising for triangles is basically difficult.
It is very likely that the appearance will be broken and cause anomalies, unless a cartoon shader is used, because the breakage is hidden by the change in normals.
However, in the case of a normal shader the appearance may be broken or the improvement is limited, and it is not clear how to solve it, as there is still not much algorithmic progress in geometry.
2 Likes
You did the thing! :D
No cell phone to test, bluestacks dont work and no quest headset for me either.
so, no way for me to find out ANYTHING unless i have a quest user tell me something is off/wrong in my world or for avatars.
(and even then, its better to visually see the issue to know what the true issue is)
and that is rare, as a lot of people dont bother messaging me if there is an issue… like ever(only if i am there will they do it).
so, would be good to know if an issue arises, and if it does pop an error on the quest side(i had models randomly revert to my 2017-18 editions for no reason, then i have to reupload them again to the current ones again… and i even had a bug where even a PC model became errored/corrupted for no reason just last month when they’re rated Good)
1 Like
This website has ERP and lap dance groups listed with direct links to their NSFW Discord servers, just so you’re aware. 
3 Likes
Forgot to put this down earlier but I was convinced that the new avatar limits would take effect around the same time the SDK would block to big of avatars. Was kinda surprised when I saw the date was Nov 1st. Either way, it’s very good letting people know of the change and giving them almost a full year to get ready for the new limits.
On paper seems like some great stuff in the pipeline. Always good to see more U# improvements. My only worry I hope they don’t swap focus around seemingly at random again 
I could see that automated optimization taking up a lot of dev time that could be put to a better cause, because only a small part of the user base actually upload their own avatars. Being able to optimize actually makes you a valuable asset in the community and people will pay for your services.
Kind of contradictory to the point I just made but, hopefully once we finally come out the other side of this years-long backend and quality of life update tunnel, we could potentially see some more crazy innovations that affect everyone. Like item inventories to make and share items with across lobbies, or something new for us to interact with in game.
1 Like
I’ll go ahead and cave in to post here, since @tupper once again backed out of the conversation silently and deleted his post. Again.
Given how just a couple of days ago a bug involving VRCConstraints and this feature was pushed to the canny, and this feature was available since around 5.3, I’d like to hear an explanation as to why this is necessary. So far outwards it just looks like you can’t be bothered to implement VRCConstraints properly.
For over seven years this was not a problem–you seem to refuse to fix an issue involving a garbage collection of animators on unbound skeletons since the first days of AV3, which is about as bad–and suddenly it now is a thing worth considering as a new constraints system is rushed out to mainline.
Seeing how awfully underbaked 1491 was, and how much work yet is ahead of you to bring vive controllers back on par with their pre-update state, maybe start actually feature- and unit-testing your updates?
Anyway, if NREs come out when base unity features are used against your systems, consider rewriting those systems instead of removing features in question. Do basic safety instead of falling into NREs and throwing in the towel and nuking everything related to the issue. If unity can handle it gracefully, you should too–that is, if you’re trying to incentivise people to switch to your “better” system.
This feature may not be the most commonly used, but it is a feature, and it is used. I could see reasons in disallowing this feature to be used at prefab roots–not that you need to–but the bundled hierarchy should be up to us to modify. If your new system can’t handle this basic idea of a job, it’s a good indicator that it isn’t ready for mainline.
And using this, I’ll plug in the request to whitelist LODGroup, as last time it was talked about some two-ish years ago, we were given a bunch of nonsense as to why it won’t be implemented.
1 Like
It’s a big change – and it takes some time for messaging to spread. If we have the luxury of time, it’s always worth trying to get things some time to propagate.
Obviously we aren’t always able to do that, but we try.
Nevertheless, I hope that the claimed date will not be changed so often…
Instead, some compensatory measures could be made, such as in-game reminders or a better news system.
This might allow some players to pick up the message and discuss it so that it spreads across the board.
There’s always a problem with dissemination, and it’s hard to get the word out to everyone.
Frequent date changes can lead to confusion.
In the document it was originally by 7/17, now it is by 8/16.
Personally, I’m afraid of frequently changed specifications, dates, and the uncertainty that comes with them.
I hope there is a good reason why it should be changed.
Hi Riergard – for clarity, I didn’t delete my post on Reddit! I haven’t posted in this thread up until this point, but thought it important to ensure clarity and correctness.
I did block your account temporarily because I was getting spammed with notifications from that thread during my off hours, so perhaps that’s what happened?
Regardless, your feedback has been heard and we’ve passed it back up! I understand that you have found uses for the ability to Destroy the object a particle emitter is attached to, and we’re examining the cases in which using Disable instead is insufficient.
Apparently that is now the case, as your posts and your account both appeared as if you have deleted them. Consider separating your personal and your CM accounts, but you can also unfollow various threads. Given previous conversation outcomes, you can see how this can cause unnecessary confusion.
To be clear: I don’t claim to having found these uses. Pretty sure there were some uses of trail renderer destroys even before Pug was published, in early 2017 or so.
Both particle emitter and trail renderer are used. The latter less so nowadays, however it is still a good failsafe for congested network and desynced conditions, especially if controlling a resourse-intensive chain. This also allows for more reliable object eviction should any client need to do that.
Breaking references is necessary in some cases where no script access is available.
1 Like
Thanks for the advice! I’ll pass up that info.
I don’t want the Avatar SDK to perform automatic decimate. It would produce better result to do it manually outside of SDK, and it usually does not worth to do unless uploader trying to “optimization” for the performance ranks.
I don’t trust your decimate because of imposter; it looks quite different from original, it doesn’t keep topology (i.e. make hole on costume mesh).
Decimating mesh shall not be included in usual build pipeline, and I would want it to be opt-in. It will cause confusion among people because a) normally people won’t think that their avatar will be decimated without any configuration[*] b) you don’t test it without beta-user.
[*]: people does not read documentation.
b) is analogy from confusion about VRC Constraint auto conversation on the client side.
Aside from that, I welcome rest of optimization option in general.
Oh yeah, on another note, is there any update on the age-restriction for Sexual and Adult content tags?
Tupper mentioned it was disabled back in 2023 and would be re-enabled in Early 2024… but it’s getting past mid 2024 and there has been no word on it.
It’s a pretty important thing, since many groups and people are relying on those tags to block minors from events and NSFW instances.
Not trying to promote NSFW instances, but they happen, and it seems like really, really important info that many people are still not aware of.
1 Like
Hello! So, are we gonna get the money back on the avatars that we spent? That go over the limit? Because that is unfair of y’all to do that when they are already uploaded~ So i believe y’all need to pay us our money back or alot of people is gonna quit vr chat.
2 Likes
It is not the fault of VRChat that your avatar is above the limit. It doesn’t take much effort to reduce an avatar below 500 MB uncompressed or 200 MB download.
Instead, you should be asking the avatar creator or people you commissioned to provide an optimized model. Or alternatively learn how to optimize.
VRChat is not involved in a product you bought off-platform.