I tested by replacing each access of cg.currentCmdNumber with the expression (cg.currentCmdNumber != trap_GetCurrentCmdNumber() ? (Sys::Drop("NTHNTHTNH"),0) : cg.currentCmdNumber).

Sadly I did not read #2660 first and created a duplicate version of one of the commits

Sadly I did not read #2660 first and created a duplicate version of one of the commits

When I commit a modified version of a code someone else wrote I usually add a Co-authored-by: line to the commit:

• https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors

cgame is not my area, but from my little knowledge, the code seems fine. I'd appreciate it if we could have some informations about the risks.
The benefits of the trap_call() reduction is obviously performance improvement, but there must be risks around this too?

I know we're not using that much, but I also think the value should have a default value, C++11-style. Here, it might (I said, I don't know the cgame area, right) be un-init. And if I'm wrong, I might become true in the future.
I think we should strive for default values in the structs/classes as much as we can as they avoid many risks, in exchange (arguable) for small performance impacts

This optimization is pretty safe. I doubt we can set a meaningful default value to this variable.

I doubt we can set a meaningful default value to this variable.

When I commit a modified version of a code someone else wrote I usually add a Co-authored-by: line to the commit:

Well I didn't modify yours; I independently rediscovered it 😆

I know we're not using that much, but I also think the value should have a default value, C++11-style. Here, it might (I said, I don't know the cgame area, right) be un-init. And if I'm wrong, I might become true in the future.

As part of the cg global variable it is initialized to 0.