its is necessary as overall suggestion not only about his needs…
and that you can run the trails without problems does not mean that everyone else can even on the weakest phone.
just saying the the trails limits no matter if length or lifetime shoudlnt be so limited at all .
Simply limiting how many trails or segments a user can show on screen at the same time could be a more optically pleasing limit.
#segments are already automatically adjusted by graphics level. Rest assures, as ROBLOX engineers always make sure their features are suitable to use on even the lowest-spec’d hardware.
Mostly just not wanting to upload a new texture every time I want to change the size of a specific trail (and if I want to have the same sizing done on other trails I wouldn’t have to upload many other textures just for one sizing effect), and for access to automate the sizing of the trail using code.
Love the update! 
FaceCamera property is now enabled on PC.
Unfortunately I made some mistakes on the calculation of the last segment. It might look weird now. I’ll fix them next week.
Also don’t use this in scripts because some platforms don’t have this feature yet.
Tell me if there are any other bugs.
I just opened my testing file for this to check FaceCamera out, and it seemed like my Attachment0 and Attachment1 properties didn’t save (they are empty now). Maybe this is already fixed by now though, this testing file is a couple weeks old already.
EDIT: Should have retried before posting, yes this is fixed 
We switched from P0/P1 to Attachment0/Attachment1 right before the release, is it possible that your file is from manually enabling the flags before that change took effect?
Yep, that would be the case, sorry about that.
Love the new trails but is there any chance the error message could be removed when instancing a new trail without a set texture? The error occurs sometimes in F5 and occurs always when testing using F6 or on a local or roblox server.
E.g.
Instance.new(“Trail”, workspace)
Will result in;
Image “” failed to load in “Workspace.Trail.Texture”: Unexpected URL
Pre-created trails without the texture property set will not cause this message.
More of a mild annoyance than anything else.
Yeah, just like ParticleEmitters, Trails should have a pre-set texture so creating new instances doesn’t throw errors.
Textureless trails are already handled by being set to a pure color plane, which is what I’m using it for, and the color of the plane is adjustable through the Color property. It’s only a visual error that doesn’t impact the game or the script it resides within, there’s no need to have a default texture.
made some rain with it
so far I know of 3 ways to make rain with trails:
I’m currently unsure what’s best for phones, though. #2 or #3?
maybe I can increase performance by changing the default 1-streak texture to a texture that has multiple streaks already in it?
I’m able to run hundreds (thousands?) of these without lag with one of my optimizations. I have just one part at 0,0,0 and use basic cframes every heartbeat to move attachments. Every attachment is inside of said part so no physics or lighting updates.
Same thing I’m doing, you can even dump the part if you just stick the attachments in Terrain instead ¯\_(ツ)_/¯
I’ll work on this.
Loving the new effect. Going to use it for swords and bullet trails. This update came just in time too. 
So how would you create a trail to leave behind footsteps, as per your example image of the character walking in the snow? Where do you put the two attachments, for example?
Raycast down from the bottom of the feet. That’s your Attachment0/Attachment 1 position.
the last segment is still bugged ):
They should have been fixed on desktop.