Scriptacus

Thanks for the input. I agree that the BEST way would be to allow customization, but the scope of what I'm looking for here is adjustments to what currently exists. Larger scale features like full customization won't happen in the short term; they require work from multiple departments, they must be prioritized vs. all existing scheduled work, etc... I'm capable of improving the colors that are already there and getting those changes into players hands in the short term, and I'd like to do so. Unfortunately, I'm not colorblind myself, and the folks here that are seem to be OK with what is there.

Heavy ammo tends to hit harder within it's weapon class (smg, sniper, assault, etc...) but has more pronounced bullet drop and lower velocity.

Thanks for the feedback. If yourself and other colorblind players are willing to provide feedback/direction, I can make adjustments to the current colors for a patch in the near future. I'm including a link that details the current base colors that we use. If you want to suggest adjustments, I'll see what I can do. I would only ask that anyone providing feedback only do so for the columns that match their own particular type of colorblindness. Anyway, here's the image:

https://imgur.com/XMJn6on

Correct that fortified legends do not get slowed down. The slow down hits pretty hard but wears off very quickly. There's also a few seconds of debounce where you can't be slowed again.

Source here, level 4.

All bullets have the same slow down behavior, and always have.

Well, I can try to explain a little:

Imagine that when a player takes damage, we have a "flinch" animation that we play. Imagine you're lagged and you shoot a player; on your client you predict that you hit them (based on their position relative to your gun). Keep in mind that the server doesn't even know you've fired a bullet yet, so you also predict their playing of the flinch animation. If your client didn't do this, any followup shots might appear to hit the enemy on your screen, but might miss on the server because the server played the flinch, which changed this position of the enemies hitboxes, meaning your bullet passed an centimeter from their head instead of hitting it. That's an example of something that has to be predicted and played in sync on the server and the client. Now imagine we have 3 flinch animations instead of 1, and we want to choose one at random to play. To do this, you need to use a deterministic random number generator so that the client and se...

True. We erred on the side of caution with the prediction error icon, so a lot of the prediction errors that you see are false positives. This one doesn't fall into that category.

Nope. The issues tend to be caused by things not being calculated the same between the client and the server in prediction. For example, some of the previous hit-reg issues were caused by the client and the server calculating IK poses differently. That can be caused by something as simple a slightly different code path being taken in a function, to a more fundamental issue like some piece of code incorrectly generating a non-deterministic number for a random value that is used by another part of the prediction code.

The prediction error icon is definitely related. That icon appears when we detect a mismatch between what your client predicted would happen vs. what the server determined actually happened. Here, your client predicted your EVA-8 rounds hitting (hence, the fountains of impact sparks), but for some reason the server thinks the shots missed. Unfortunately, the icon doesn't tell us WHY the prediction error occurred, but I've forwarded the video to QA to see if they can help find a repro. Over the past months we've found and fixed a number of prediction error related issues, but clearly some still remain.

Indeed

Nearly every gun in the game has some minor amount of randomness within their overall fire patterns, and has since launch. You can see this in training by firing full magazines at the wall while NOT making any corrections for recoil. Examples linked: https://imgur.com/a/hoDJgNZ

No, the guns have different muzzle velocities.

Not ruling out that you haven't encountered a bug, but in local testing I cannot reproduce this at all. You can see results for a 500m test here. I also tried both the 4x and 6x at 200 and 300 meters with accurate results.

https://imgur.com/a/PzfH732

For the optics that do that, that should be fine, as long as you're adjusting your aim to the mildot after range finding but before firing.

If the 200 isn't lining up that's a bug. You can verify if it's working or not by pinging a location, checking the reported distance, lining up the mildot, firing, and checking the impact point vs. where you pinged.

That's a good point. The 50m had to do with the ranges that engagements actually tend to take place in Apex, and the exaggerated velocity and drag of the projectiles (there are reasons for that too, but they're outside the scope of this discussion). The combination created instances where targeted headshots at average engagement ranges (generally far less than 100m) would pass over the head of the target, due to the upward trajectory required to zero at 100m.

That said, I believe at some point we increased the sniper class weapon projectile velocities, so it seems worth revisiting the zero distance. I realize that user adjustable zero distances could also help resolve this, but it's a pretty meaty feature to add for a type of gameplay (long range sniping) that isn't really how Apex tends to be played. (that doesn't mean it's completely off the table)

Projectile has a velocity, the velocity is modified by gravity and drag. I think the calculations are done using Runge Kutta 4, which is pretty standard in games.

> ...but the bullet velocity is always constant

For the record, this is completely untrue. Where did you get such an idea?

Edited for clarity; quote shortened to relevant portion

I believe you may actually need to downgrade your drivers. See details here:

https://www.reddit.com/r/apexlegends/comments/cl83sc/respawn_checkin_822019/

It's random, but there are some validity checks on the final locations, meaning there are some places that the ring can't end.