0000089: custom 'sv_coop_damagefactor' value of server not reflected on the client

Notes
(0000291) Eruanna (reporter) 2010-10-08 13:30	Yeah, I do think this is actually very important, especially for demo playback, because it helps with the verifiability of a kosher game (to help make sure that someone really used the settings they've said they used).

(0000293) Torr Samaho (administrator) 2010-10-09 15:09	The sv_* variables the clients don't need to know of are not synced with the clients. sv_coop_damagefactor is one of those.

(0000302) unknownna (updater) 2010-10-10 03:08	IMHO, it'd be nice if everything was synchronized with the clients, even if not truly needed. It can be confusing in some cases when you see one variable set, but another one is in effect. That's the main reason to why I reported it; confusion. But then again, if it's too tedious to implement this, it's alright, as it's not a necessity.

(0000306) Torr Samaho (administrator) 2010-10-10 07:31	I'd need to take a completely different synchronization approach if we want all sv_* values to be synced in a feasible way. It would be nice to have this in the long run, thus I'll transform this bug report into a feature request so that it's not forgotten.

(0000323) Eruanna (reporter) 2010-10-10 16:20	IMHO, this is important. Not all sv_* values are important like this one. The main reason is verifiability. If we cannot have this value sync'd with clients, then I fully COMPLETELY disagree with it being in the Skulltag executable at all, and I think it should be taken out.

(0000327) Torr Samaho (administrator) 2010-10-10 19:19	There are various other CVARs that are as important as this one, like sv_killallmonsters_percentage and sv_suddendeath for instance. Nobody ever complained that the values are not synced with the clients. In general I agree that the sv_* CVARs should be synced, but IMHO it doesn't make any sense to do this just for sv_coop_damagefactor now and ignore the other CVARs that are equally important.

(0000344) Eruanna (reporter) 2010-10-12 01:33	Well, here's the concern: Say some guy says he put the sv_coop_damagefactor up to 3, and he's like, "yeah I recorded a demo of it, I'm the best Doom player ever haw haw haw!" ... you get the demo, and there's no way of telling, without really good judgment and really good knowledge of the game, if he really used that setting. And also, you never know, someone could just conveniently set it lower through rcon at just the right times, and no one would ever know by watching the demo.

(0000345) TIHan (reporter) 2010-10-12 01:52	Before, I had sv_coop_damagefactor as a CVAR_LATCH which was taken out. If it was a CVAR_LATCH, it would require the server to restart the map in order to make changes. So, no one could "convenietly set it lower through rcon at just the right times". So, I would suggest making sv_coop_damagefactor a CVAR_LATCH to get rid of this issue. I wouldn't be too concerned over this as it's not a huge deal at the moment. We are still in the beta builds.

(0002924) unknownna (updater) 2012-03-27 18:36 edited on: 2012-03-27 18:36	It's now apparently fixed. 'http://skulltag.net/tracker/view.php?id=704 [^]'

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2010-10-08 08:07	unknownna	New Issue
2010-10-08 13:30	Eruanna	Note Added: 0000291
2010-10-09 15:09	Torr Samaho	Note Added: 0000293
2010-10-10 03:08	unknownna	Note Added: 0000302
2010-10-10 07:31	Torr Samaho	Note Added: 0000306
2010-10-10 07:32	Torr Samaho	Category	Bugs => Suggestion
2010-10-10 07:32	Torr Samaho	Status	new => acknowledged
2010-10-10 16:20	Eruanna	Note Added: 0000323
2010-10-10 19:19	Torr Samaho	Note Added: 0000327
2010-10-12 01:33	Eruanna	Note Added: 0000344
2010-10-12 01:52	TIHan	Note Added: 0000345
2011-05-09 23:53	unknownna	Relationship added	related to 0000062
2012-03-27 18:36	unknownna	Note Added: 0002924
2012-03-27 18:36	unknownna	Note Edited: 0002924	View Revisions
2012-03-27 18:38	TIHan	Relationship added	related to 0000704
2012-03-27 18:38	TIHan	Status	acknowledged => resolved
2012-03-27 18:38	TIHan	Fixed in Version	=> 1.0
2012-03-27 18:38	TIHan	Resolution	open => fixed
2012-03-27 18:38	TIHan	Assigned To	=> TIHan
2018-09-30 19:54	Blzut3	Status	resolved => closed