NumberSequence.new(float n0, float n1) isn't applying to ParticleEmitter.Size

This is a fairly simple and repeatable bug. The title of this report suggests that it only applies to Size simply because I haven’t tested it otherwise.

I created a ParticleEmitter inside of a part within the Workspace. After that, I ran this code from the command bar:

workspace.Emitter.Particle_Damage.Size = NumberSequence.new(0.4, 0)

Strangely, though, the Size property was equal to a single value of 0 and hadn’t changed to what I told at all. My current workaround is this:

workspace.Emitter.Particle_Damage.Size = NumberSequence.new({NumberSequenceKeypoint.new(0, 0.4), NumberSequenceKeypoint.new(1, 0)})

Reproduction of the issue shouldn’t be too hard. Just do what I did.

1 Like

More precisely:

> print(NumberSequence.new(0,0.4))
0 0.4 0 1 0.4 0 
> print(NumberSequence.new(0.4,0))
0 0 0 1 0 0 

Although that made me think the order mattered, it’s something stranger. That first sequence actually creates a NumberSequence that has value 0.4 both at t0 and t1.

Doing NumberSequence.new(1,2,3,4,5) will act the same as NumberSequence.new(5). It seems that internally, it always use the constructor with one argument, using the last argument. (probably cuz stack[-1] in Lua C)

NumberSequence has only two constructors:
.new( double ) - creates a constant sequence
.new( { keypoint, keypoint, … } ) - creates a keypoint sequence

Passing two arguments is an error that just happens to be working because of how Lua treats function calls. We’ll see what we can do.

Someone on the studio team doesn’t agree it seems:

1 Like

Well, that is definitely wrong, because I’m looking at the source code right now, and there’s nothing there that takes more than one argument.

¯\_(ツ)_/¯

So maybe I should just add it as well, i dunno?

It’s very common to have a number range for size/transparency/rate between 5 and 15 (or something like that). Definitely seems useful.

still curious why it’s in intellisense but not in the actual code