ID:2718604
 
Not a bug
BYOND Version:514
Operating System:Windows 10 Home 64-bit
Web Browser:Firefox 92.0
Applies to:Dream Maker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

Numbered Steps to Reproduce Problem:
Spawn a particle system such as the following. (preferably many in a grid to give a better visual idea of it.)
Code Snippet (if applicable) to Reproduce Problem:
/particles/fire
width = 48
height = 48
count = 60
spawning = 20
lifespan = generator(1 SECOND, 5 SECONDS)
fade = 1 SECOND
position = generator("square", 16, -16)
drift = generator("circle", -0.1, 0.1)


Expected Results:
Remotely even distribution
"UNIFORM_RAND Default. Random values are uniformly likely to be chosen. "

Actual Results:
Very noticeable bias toward the center of the generator system.

Does the problem occur:
Every time? Or how often? Every time.
In other games? Most likely. Not tested.
In other user accounts? Not relevant to this kind of issue.
On other computers? Do not have access to another machine.

When does the problem NOT occur?
Seems less noticeable when using "vector". Have not tested with other generators.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:
Not applicable.
Here is a video of this bias in action.
https://streamable.com/pmt01c

Edit:
Without drift,as I realized that could be interfering with my findings

https://streamable.com/rlo38a

It does not appear to be.
Is it possible it's set to NORMAL_RAND by default?
I need a test case for this.
https://drive.google.com/file/d/ 1aKZhSNPieB5lRURc6bdPlY3GLVeaqBM5/view?usp=sharing here is a test case. You can see a lot of overlap with the particles.
There's definitely a central bias in the native square generator.

Here's a test project to show differences between the native square generator and a few custom square generators:
Brute force, generates points until it's in bounds.
Circle bounded, generates points between circles until it's in bounds.
Circle bounded with a central bias, generates points between circles non-uniformly until it's in bounds, resulting in a similar center bias to the native generator.

http://files.byondhome.com/Kaiochao/bug/ SquareGenerator_src.zip
In response to Kaiochao
Using LINEAR_RAND seems to fix it, though. Without knowing how the native square generator works, it's not clear how any of the random distributions should affect it. But I think there's definitely an expectation that the default UNIFORM_RAND should result in a uniform distribution over the desired area, no matter what shape that area is.
In response to Kaiochao
Shapes and areas and particle emission points reminded me of Godot's emission masks which support a mask (icon) defining where particles are emitted. I looked into the Godot source to see how they do it, and it turns out they just pick a point from a list of points that was built from the non-transparent pixels of the emission mask image. Trying it myself, a square generator that picks from a list of points is actually 3x faster at producing points than the built-in square generator. Might be worth considering.
Ah! I finally see what you mean here about the bias.

Actually the bias is expected with UNIFORM_RAND. LINEAR_RAND is the correct choice to use.

The reason for this is that the perimeter of the square is directly proportional to its size. Therefore if all sizes are equally likely, you'll have a greater density of results toward the center of the shape and lower density toward the edges. LINEAR_RAND makes the chance of selecting a given size directly proportional to abs(size).

For even distributions with the square and circle generators, use LINEAR_RAND. With the cube and sphere generators, you would use SQUARE_RAND (since the surface area is directly proportional to the square of the size).

I'll look into documenting this better.
Lummox JR resolved issue (Not a bug)