A clientside-only CVar that does not get synced
Moderator: GZDoom Developers
-
Guest
A clientside-only CVar that does not get synced
What says on the tin. This is for storing local data in the ini and nothing more. Obviously it's not supposed to work with multiplayer. I'm requesting this because server CVars have a buffer overflow with long strings and user CVars have a length limit. This suggestion seems to be the only real solution here that doesn't involve splitting the data into multiple CVars like I'm doing right now. That approach works, but for how long nobody knows. I'd rather get rid of such workarounds.
-
Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: A clientside-only CVar that does not get synced
Surely if this could be implemented the limits on the actually-supposed-to-be-synced cvars would have long been removed by now?
-
m8f
-
- Posts: 1445
- Joined: Fri Dec 29, 2017 4:15 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Manjaro Linux
- Location: Siberia (UTC+7)
- Contact:
Re: A clientside-only CVar that does not get synced
PR to extend nosave cvars to bypass network code: https://github.com/coelckers/gzdoom/pull/1016
nosave cvars are meant to be used as a storage for statistical data that doesn't affect gameplay. That's why this data isn't saved to the savefile in the first place. Therefore, there is no point in sending this data over network. It would have no meaning on machines other than local.
nosave cvars are meant to be used as a storage for statistical data that doesn't affect gameplay. That's why this data isn't saved to the savefile in the first place. Therefore, there is no point in sending this data over network. It would have no meaning on machines other than local.