Ideally, the RNG should be seeded with the same value for all peers as it would guarantee they generate the same IDs in the same order.

This would give some guarantee to ID uniqueness (in fact if we generate a used ID something has gone very wrong) while also giving some more server validation possibilities (eg: server would also generate an ID when a weapon is fired and it should match).

That all being said, I'm not sure how much of a refactor that would take and I'm definitely not going to be the type to demand things be done my preferred way on someone else's project. This is already a very good improvement :)

Seeing Nano ID which is the inspiration for this ID generation:
With 12 characters, you would need 9 000 000 000 projectiles for one to have 1% to conflict another.

So I think doing a check isn't required - after all, that is why such a long string is used: In order to avoid comparing ID with other projectiles. If you compare with existing IDs, may as well use a normal integer-based ID system.

Alternative solution is to raise length 12 higher, but honestly, 12 is good as it is, there are no practical chances for collisions. I would argue this PR is needless.

Ideally, the RNG should be seeded with the same value for all peers as it would guarantee they generate the same IDs in the same order.

Session ID of #269 could be used as a random seed which is the same among all users. If it's not enough (I remember some seeds having multiple integers in them instead of just one), I can expand that PR to include a shared random seed.

@Lexari0

That all being said, I'm not sure how much of a refactor that would take and I'm definitely not going to be the type to demand things be done my preferred way on someone else's project. This is already a very good improvement :)

Appreciated :) I also want to understand your POV, especially on this:

Ideally, the RNG should be seeded with the same value for all peers as it would guarantee they generate the same IDs in the same order.

The idea is to generate an ID that is unique across projectiles and peers. The point is to avoid generating the same ID, so whenever someone requests a projectile, they don't request it the same ID as anyone else would.

I wonder if there's something about the codebase / approach that suggests matching ID's?

@TheYellowArchitect sure, check removed

Merged as I didn't want to keep this fix waiting for longer, but I'm still up for discussion here.