You gotta fix purple screens, man#1122

Every time I play the game, I run into the same issue: I don’t get purpled on a hit, I die for it anyway despite good DI, I run to dragdown to check the angle, and I find that I DI’d it perfectly. SDI doesn’t affect the cases I’m talking about either. The calculation is undershooting by at least some tiny amount, and it’s really pissing me off, because not getting purpled means, to me, that if I DI right (which I usually do), I live the hit.

This is certainly the case and causes lots of frustration

i think this is the same issue as when get a purple but the opponent does not die: rollback. the effect and the rollback don’t work together well. sometimes you get a purple screen but it only flashes for 2 frames and then rollback happens and your opponent actually blocked, dodged etc last frame or he actually corredt DI last frame to survive. same can happen the other way around and thats what you are observing. I think the only solution is to delay the purple effect calculation by the number of rollback frames currently happening, but i have no idea if this would cause other sideffects.

That doesn’t make sense and is almost certainly not what’s going on.

it is. lets imagine on the last hit you were knocked in the direction of the side blast zone and the opponent hits for the finisher. on your screen the attack hits you 2 frames earlier and you might still be a little bit further away from the blast zone, so you would survive the hit. but in reality it hits you 2 frames later than you saw and thus you were a tiny bit closer to the blast zone so it actually kills.

It would cause it to flicker on and then off for a moment, or off and then on. Purples are almost certainly calculated when the attack connects, meaning a rolled back hit will recalculate the purple to correct it. Unless they’ve desynced purples from the game state, which makes no sense at all, it’s just undershooting.

the flicker on and off is the other direction i explained before. i don’t think it would delay trigger on rollback kill hit (the second scenario which i think it was you experience). i think it is calculated on the client side not the servers game state, but i could be wrong. But the problem you describe in the originial post only happens to me when playing online. never had it happen offline. thats why i am assuming its a rollback issue.

The system has to overcompensate like this to absolutely ensure every purple screen is guaranteed 100% a kill. Otherwise you get the reverse scenario of the above where the attacker is denied what they were told would be a kill.

No matter what, you’re going to have someone be given faulty information during gameplay, and I do think the current system of false-negative for the defender on certain death is the better way to go.

You can absolutely ensure correct calculations on launch trajectory.

The short answer: Making accurate trajectory calculations is much too expensive, especially online.

The long answer: At the end of every frame, the character’s position and velocity values are quantized before they’re stored in the state data. This means there are only a set number of values that each of these properties can represent, and so any sort of non-quantized, predictive calculations will include some extremely small amount of error. During trajectory calculations, we’re predicting a ton of frames all at once, with no quanitization on any of the values, so this miniscule error compounds into a larger error for the final position/velocity. In order to prevent false positives, which would be much worse than the false negatives we get now, we “move” the blastzones out by the maximum error margin of the calculation to ensure that the real trajectory will also cross the blastzones.

Now you might ask “why don’t you just quanitize the position/velocity values when predicting the trajectory?” The answer is simple: it’s MUCH MUCH MUCH too expensive. In order to predict if someone is guaranteed dead, we have to check every single possible DI angle. For most moves, this means checking 37 different trajectories (every number between -18 and 18, inclusive). Each of those trajectories normally has a large number of frames if the move is strong enough to guarantee a KO. For this example, lets say the move inflicts 90 frames of hitstun. That would mean we’re predicting a maximum of 3330 frames in the worst case scernario, where none of the trajectories end in a KO, which is extremely common. In order to perform a trajectory calculation, we need to track 3 different 2D vectors: position, velocity, and knockback velocity (6 values total). If we were to quantize these in every “frame” of the prediction, that would mean we would have to quantize 19,980 values in the worst case, which is not at all feasible, especially in a game with rollback netcode.

So yes, we can absolutely ensure correct calculations on launch trajectory IF we didn’t care about performance :)