A clientside-only CVar that does not get synced

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: A clientside-only CVar that does not get synced

Re: A clientside-only CVar that does not get synced

by m8f » Tue Jan 14, 2020 8:17 am

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.

Re: A clientside-only CVar that does not get synced

by Matt » Mon Jan 13, 2020 6:10 pm

Surely if this could be implemented the limits on the actually-supposed-to-be-synced cvars would have long been removed by now?

A clientside-only CVar that does not get synced

by Guest » Mon Jan 13, 2020 2:35 am

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.

Top