sweeeeeet, now i can actually wear the hats that have particles without getting blocked by the particles
2 Likes
I don’t mind changes like this when we’re given solutions to avoid them if needs be (which we were, ty)
4 Likes
Broooo this is acc fire cause I swear whenever using horns or ghosdeeri it’s legitimately impossible to see ahead cause of the obstruction 
thank you
4 Likes
My Doomsekkar is very excited about this - and it seems like the workaround is easy enough for people who want to keep the previous behavior for their custom particle effects!
3 Likes
only took yall like 15 years lol
3 Likes
What about Tools used as Accessories, because of this issue:
I don’t pursue Accessories in Tools, but I’ve seen a very few Experiences actually pursueing that method, solely due to this issue:
1 Like
This is very useful as I have trouble playing any VR games that don’t have this behavior by default. Big ups for this one, will no longer have to deal with fire balls on both my eyes at all given times.
This change has now been released! Please let us know if you notice any issues or have any feedback.
2 Likes
Works great! Thanks for the awesome update! I already had a script running in my game that did this but now that its officially in the engine I have removed it and hopefully it removed at least some sort of lag. Great update!
Just noticed that flame effects don’t completely become invisible when in first person.
Thanks for your report. There was a slight issue with our implementation of LocalTransparencyModifier for ParticleEmitters and Fire effects where we didn’t take into account scaling the Envelope (variance) of the transparency sequence. We will release a fix fo this fairly soon.
2 Likes
I’m using a Scriptable 3rd person camera, and giving players the ability to enable the default First-Person when a key is pressed. Prior to this update, when in the default First-Person the player would see both the First-Person particle effects, and the 3rd person particle effects. Now It seems alright at first glance. 3rd person effects work fine, player goes First-Person and they only see the desired particle effects, but upon switching back to 3rd person the particle effects that are attached to the players character are no longer visible. Not sure if this is an issue with the update, or if I simply have to update something in my View-Swapping code to resolve this issue.
Actually the partial transparency seems better for me, I haven’t tested this out yet, but is there an option to change how transparent it gets (or will there be one)?
Thank you so much! Glad I could help.
Does your code currently modify the LocalTransparencyModifier property of Parts in the players character when switching back to 3rd person? If so you probably need to modify your code to do the same thing for ParticleEmitters and other similar effects.
If your code doesn’t do this manually and it’s being done automatically for Parts, I can take a look. If you could DM me a place file with just the view switching code, that would be helpful.
If partial transparency is better for your game, you can modify how the TransparencyController ModuleScript in the PlayerScripts applies the LocalTransparencyModifier.
2 Likes
Yup, good catch on the LocalTransparencyModifier for particle emitters, everything is working great now! Thanks for the assistance!
1 Like
While this change is overall a net positive, the change of all particles parented to the Character being hidden poses an issue for games whose weapons have particles but do not rely on the traditional Tool Instance for their weapons.
In a game I am helping develop, the weapons system utilizes a model and welds for the visuals. When using weapons that emit particles (e.g.: the gun in the video that has a muzzle flash), they look very weird without the flash in first-person mode.
Not having a way to disable this feature or a special tag for exception handling is a big issue; offsetting the task of handling particles being parented outside the character feels very unsympathetic to game frameworks who have been designed to function with a system/game function (in this case, particles NOT becoming transparent in first person) that has functioned the way it has for over a decade. Having to make such a radical change to a myriad of weapons/code is a great nuisance.
A simple tag addition would make all the difference but still be easy to manage (I am aware of an earlier staff member response regarding why an exception tag wasn’t added; a simple search on the forum for this issue should quickly give the creator the tag name).
2 Likes
Seconding this. I often used particle FX inside the character to show status ailments. I designed them in such a way that they worked for both first and third person. Having to recode all of these systems or redesign all of these systems is a pain. Having a property to negate this change on a per FX basis would be way more convenient.
I mistakenly thought LocalTransparencyModifier was an override rather than an additive - meaning it doesn’t solve this.
It works in new games that I create, but in games that I created before you said was released, the update doesn’t seem to have applied. Do you know how I can fix this?