sar_cam_control 0 doesn't give back normal camera if you loaded a save/map with TAS

[Burger40]

To reproduce:
Go into sar_cam_control 1
Play a TAS file that either loads a save or a map
When the TAS finished playing (or you stopped it manually with a bind) go into sar_cam_control 0
You'll be unable to move or look around now, until you type in_forceuser 0 in console.

If you do sar_cam_control 0 while the TAS is still playing this issue won't occur.

[ThisAMJ]

This is because of "janky hack mate". Basically cam control has a super fragile way of remembering what the value was before you turned it on, and TAS playback interferes with this.

//even junkier hack. lock mouse movement using fake in_forceuser LMAO
if (engine->hoststate->m_activeGame && !tasPlayer->IsActive()) {
	in_forceuser.ThisPtr()->m_nValue = engine->GetMaxClients() + 1;
}
...
//janky hack mate
//overriding cvar values, boolean (int) values only.
//this way the cvar themselves are unchanged
...
in_forceuser.SetValue(in_forceuser.GetString());

@Krzyhau is there a reason we don't want to change the cvars themselves, or was this just the way of avoiding making a variable to remember what the previous value was? I realise this was 5 years ago

[Krzyhau]

@ThisAMJ Yes, it's acting as an internal temporary override of a console variable. I'm not surprised that it's breaking, since we're most likely attempting this hack on the same console variable in multiple places. Ideally we'd have a system of cvar override controllers, each controlling only a single console variable, based on a list of currently active override providers. It would still use this hacky way of modifying the value directly and leaving its raw string value untouched, but at least it'll behave in a more controlled way.