fix: iw3/t4 DVAR_CODINFO flag value

[regenerance]

Summary

Fixes the DVAR_CODINFO flag value.

DVAR_CODINFO was incorrectly defined as 0x100, which prevented dvars using this flag from being properly updated/synchronized to connected clients.

The correct value is:

DVAR_CODINFO = 0x08

This restores the expected client-side dvar propagation behavior.

[michaeloliverx]

I don’t think this change is correct.

The stock IW3 GScr_MakeDvarServerInfo explicitly adds 0x100 to existing dvars, and registers new ones with 0x4100:

result->flags |= 0x100u;
Dvar_RegisterString(..., 0x4100u, ...);

KisakCOD matches this as well:

Dvar_AddFlags(dvar, 256);

and the server update path checks dvar_modifiedFlags & 0x100 before updating CS_CODINFO.

0x08 is the SYSTEMINFO flag and appears to use a separate replication path, so changing DVAR_CODINFO from 0x100 to 0x08 would not be equivalent.

I remember testing this in game with connected clients and the no barriers worked for everyone? Is this not the case?

[regenerance]

Hello, I'll explain a little about what happens.. When the dvar happens, it will change for the clients, BUT they experience a state of where the memory only appears patched for the host and not the others.

Example. no barriers on iw3 and t4 will work for other clients, but they lag in those areas as if their console memory was not patched.

By switching it to this, it appears that the lag and updates are fixed. I highly suggest taking the time to test with myself or others and you can see exactly what I mean.