|
Notes |
|
|
|
|
Judging from a quick glance it looks like you are missing some server side stuff in the definition of sv_coop_damagefactor, e.g. the SERVERCOMMANDS_SetGameModeLimits call, to properly sync the sv_coop_damagefactor value between clients and server. |
|
|
|
(0002793)
|
|
TIHan
|
2012-03-11 19:31
(edited on: 2012-03-11 19:44) |
|
We don't need it in the definition as the map has to restart in order to actually change it. sv_coop_damagefactor is now a CVAR_LATCH. When clients connect, SetGameModeLimits gets fired to send the client the correct information.
Edit: Unless would you prefer it not to be a CVAR_LATCH, then we have to add in SetGameModeLimits as part of the definition.
|
|
|
|
|
|
Oh, I see, you are right. I didn't take into account that you added CVAR_LATCH. Why do you prefer to make sv_coop_damagefactor latched? |
|
|
|
(0002796)
|
|
TIHan
|
|
2012-03-11 20:37
|
|
> Why do you prefer to make sv_coop_damagefactor latched?
I don't want the client knowing that the damagefactor could be changed at any time while he is playing the game. With it latched, it is enforced by ST, that the map has to be restarted. This is the same reason why sv_cheats needs map restart.
Off topic here: In the future, I want to be able to call vote on damagefactor and maxlives. But, I would only want those settings to actually be set right before a countdown or new match starts, but not on a map restart. In that case, we may need a new CVAR flag to handle that, such as CVAR_COUNTDOWN or CVAR_MATCH. Btw, this is not necessary for 98e. |
|
|
|
|
> This is the same reason why sv_cheats needs map restart.
AFAIK the main reason to make a CVAR latched is because dynamic changes to it would be difficult/ambiguous to handle technically. Take sv_cheat for example: What should happen to players with active cheats when sv_cheat is turned to 0? Or sv_maxlives: This value is only used when a player spawns initially. Dynamic changes to it don't have any inherent effect. Dynamic changes to sv_coop_damagefactor on the other hand can be treated easily.
In other words, unless there is a technical reason, why do you want to restrict the possibilities of a server admin / local player to configure the game to his liking?
> CVAR_COUNTDOWN or CVAR_MATCH
That's an interesting idea. We should keep this in mind, would definitely make sense for sv_maxlives. |
|
|
|
(0002799)
|
|
TIHan
|
2012-03-11 21:40
(edited on: 2012-03-11 21:55) |
|
> AFAIK the main reason to make a CVAR latched is because dynamic changes to it would be difficult/ambiguous to handle technically.
Hmm, I wasn't aware of that.
> why do you want to restrict the possibilities of a server admin / local player to configure the game to his liking?
Well, I don't like restricting the server admin from having to dynamically change his settings on the fly, but I also do not want the client to always know while he is playing, real game changers like "damagefactor" could be changed at anytime while he is playing - affecting his play through.
But, your reasoning gives me a better reason not to make damagefactor be latched. I guess if you could just make it not be latched and add in the SetGameModeLimits, I think it should be fine. But let's be aware that I do want to add restrictions similar of how the idea of CVAR_COUNTDOWN/CVAR_MATCH work in the future.
Not latched:'https://bitbucket.org/TIHan/tst/changeset/8965f6ebf321 [^]'
|
|
|
|
|
> I also do not want the client to always know while he is playing, real game changers like "damagefactor" could be changed at anytime while he is playing - affecting his play through.
Well, the server admin can alter lots of things dynamically that considerably change the game, just look at all the dmflags for example.
> But let's be aware that I do want to add restrictions similar of how the idea of CVAR_COUNTDOWN/CVAR_MATCH work in the future.
As I said, for something like sv_maxlives, where there are no technical problems to change the value during a map reset, this kind of flag makes perfect sense. If you intend to impose additional restrictions on the server admins though (changing a CVAR from CVAR_LATCH to CVAR_COUNTDOWN lessens restrictions), you will need some very good arguments to convince the server admins why it's necessary to restrict the control they have over their own server. |
|
|
|
(0002801)
|
|
TIHan
|
2012-03-11 22:19
(edited on: 2012-03-11 22:20) |
|
> Well, the server admin can alter lots of things dynamically that considerably change the game, just look at all the dmflags for example.
Very true.
I guess we need to really have a full on discussion about additional restrictions on certain CVARs that could alter the game state in a way we may not want. Such as the server admin changing the max lives instantly from 3 to 1 while a client is playing.
|
|
|
|
|
> I guess we need to really have a full on discussion about additional restrictions on certain CVARs that could alter the game state in a way we may not want. Such as the server admin changing the max lives instantly from 3 to 1 while a client is playing.
So I assume your intention is to protect honest clients from unpleasant surprises possibly coming from the server admin? Certainly a noble goal, but unfortunately any additional client protection inevitably comes at the expense of the server admin's freedom. Thus this is a controversial issue that would need to be discussed extensively in public.
I personally think it's no problem to allow the server admin to change everything technically possible to his liking. If the players don't like what an admin is doing, they will just use another server. In the end the server admin will always be able to ruin the playing experience of anyone (you simply can't forbid an admin to kick people at will for instance), so the players always have to trust the admin to a certain degree. Nevertheless, feel free to start a discussion about this on the forum (or wherever you like). Possibly the community doesn't share my opinion on this. |
|
|
|
(0002804)
|
|
TIHan
|
|
2012-03-12 07:51
|
|
> I personally think it's no problem to allow the server admin to change everything technically possible to his liking.
Be careful about what you say here. :) It's fine to let admins do whatever they want, but Skulltag needs to have some standards and consistency between servers. I'm not saying lets add restrictions on all game altering CVARs - any restrictions should be carefully and well thought out. Example: Adding a restriction for the admin toggling wall running while a game is in progress is pointless. However, adding a restriction for say monsters respawning while a game is in progress, could be debatable. |
|
|
|
(0002810)
|
|
TIHan
|
|
2012-03-12 22:06
|
|
Seems a few people are speaking about this in the thread.'http://www.skulltag.com/forum/viewtopic.php?f=3&t=31142 [^]'
I made the wrong argument to provide some sort of consistency in gameplay between servers. Maybe some type of default game settings for popular game types, AOW, CTF/DUEL/DM,etc., GVH, Megaman would be better. Easier for admins to setup. |
|
|
|
|
|
FYI, I think you forgot to adapt the SERVER_CheckClientBuffer call in SERVERCOMMANDS_SetGameModeLimits to the addition of sv_coop_damagefactor. The design of SERVERCOMMANDS_* is absolutely awful though (I really wonder who originally designed it like this...) and I finally took the plunge to redesign this (see the latest changesets). |
|
|
|
(0002820)
|
|
TIHan
|
|
2012-03-17 19:59
|
|
|
|
|
|
|
I ported your patch with some small modifications: sv_coop_damagefactor is declared as EXTERN_CVAR in cooperative.h instead of declaring it in cl_main.cpp and sv_commands.cpp. I didn't remove CVAR_ARCHIVE from the declaration of sv_coop_damagefactor since it was not apparent whether you removed it intentionally (your commit message only mentions removing CVAR_LATCH). And I didn't include the scoreboard.cpp changes. Since the value can be changed on the fly it doesn't make much sense any more to display it during the countdown. |
|
|
|
(0002825)
|
|
TIHan
|
|
2012-03-17 21:45
|
|
|
|
|
|
|
You're welcome :). Can I consider this issue to be resolved then or do you want to discuss a way how to display this value to the clients? |
|
|
|
(0002829)
|
|
TIHan
|
|
2012-03-18 21:40
|
|
|
I guess we could discuss how to display this value. What is your suggestion? I say put it in the scoreboard. |
|
|
|
|
|
Scoreboard could work, possibly below the "monsters remaining line". |
|
|
|
(0002832)
|
|
TIHan
|
|
2012-03-18 22:41
|
|
|
|
|
(0002843)
|
|
TIHan
|
|
2012-03-19 06:55
|
|
|
|
|
|
|
Looks pretty good, I think it should only be displayed though if sv_coop_damagefactor is not 1. |
|
|
|
(0002845)
|
|
TIHan
|
|
2012-03-19 12:03
|
|
|
|
|
|
|