`ParticleEffect` is badly named, and easily confused with `Particle`

[enjarai]

I've recently been doing some stuff with particles, and found I had a really hard time figuring out the difference between the three main involved classes, Particle, ParticleEffect and ParticleType.

After actually digging into the code, It seems ParticleEffect is more like a configured instance of ParticleType than an instance of a "particle effect". It is also used for network transfer and command argument parsing, while Particle is purely client-side, and represents an actual particle in the world.

I don't know what a good alternative name would be, but I do think ParticleEffect should be renamed to reflect it's actual purpose, be less generic, and be more distinct from Particle.

[Linguardium]

having run into this recently, i agree. Its made even more confusing because you have EntityType which is to Entity as BlockEntityType is to BlockEntity, but ParticleType defines more of a serializer registry for ParticleEffect which is a configuration instance for the actual client rendered particle

[haykam821]

The cause of particle confusion could be helped with a few renames. Unfortunately, I think part of the issue is with how the particle classes are designed. For example, DefaultParticleType is both a particle type and particle effect. Some particle effects support various types, but others are tied to exactly one type. There isn't any type safety tying particle types to effects.

However, I think a few renames could be made to clarify the relationship between the particle classes:

• [x] DefaultParticleType class to SimpleParticleType
• [ ] *ParticleEffect classes to *ParticleParameters (this suffix is already used in parameter names)
• [ ] ParticleEffect.Factory class to Reader