Notes |
|
|
I wonder if it'd be possible to make it such that if the string to join is empty/null, then the server would not let browsers know there is a password, and if it's empty/null than anyone could join. That would reduce this redundant command. |
|
|
|
Oppose. What if I wanna to turn off join passwords, say, for a day (public started), but then enable it again? I'd have to clear my sv_joinpassword and fill it again that's much complicated than just toggle sv_forcejoinpassword. |
|
|
|
Wouldn't it just take a few seconds to do
Quote rcon sv_joinpassword "passhere"
to enable it again?
For me, I find people get confused that there has to be an sv_forcejoinpassword boolean enabled for passwords to work, and tends to lead to a lot of confusion unless they know the wiki exists and/or have someone to help them. I was even one of those people. |
|
|
|
How is clearing your joinpassword any more complicated than sv_forcejoinpassword? When I host, I think setting a joinpassword would automatically be in effect, but then you need to enable another pointless flag for it to take effect. |
|
|
(0005959)
|
ZzZombo
|
2013-02-07 04:21
(edited on: 2013-02-07 04:30) |
|
Watermelon: RTFM I'd say.
bluewizard: compare "toggle sv_joinpassword; (play without join password); (arrow up in the console to issue) toggle sv_joinpassword;" and "sv_joinpassword ""; (play without join password); sv_joinpassword "your_old_password"". The first can be done in one sec, excluding the time of playing without the password. The latter varies on your ability to type texts and as for me, it takes too long time, especially for complicated (autogenerated, for example, possibly some hosts use them) passwords.
(On a side note: I think that Source engine's built-in help for console commands and variables might be useful for situations like this. You know, "help <command/variable name" outputs the help string of the given command. In their constructors you just supply the help string and it's done.)
|
|
|
|
How is doing sv_joinpassword "", and sv_joinpassword "blah" and less complicated?
Having it blank will have it off, otherwise it'll stay on. |
|
|
|
Oppose.
Although two flags was surprising to me as a host, I ultimately found it far more convenient for times when I want to flip on or off the ability to join the server without a password. That way, I don't have to memorize what the join password is for that particular server. |
|
|
(0007312)
|
Qent
|
2013-10-02 20:21
|
|
While I do enjoy the convenience of sv_forcepassword and sv_forcejoinpassword, their removal would be of great benefit to inexperienced server admins using Best Ever servers, for instance.
To fulfill the needs of those hosts who do use sv_forcepassword and sv_forcejoinpassword, perhaps something along these lines could be added to the KEYCONF lump of mods that might need it, or added to one of the server's configuration files: alias disablepassword "test ! $pw_backedup \"set sv_password_bak $sv_password\"; set pw_backedup 1; set sv_password \"\""
alias disablejoinpassword "test ! $pw_joinbackedup \"set sv_joinpassword_bak $sv_joinpassword\"; set pw_joinbackedup 1; set sv_joinpassword \"\""
alias restorepassword "test $pw_backedup \"set sv_password $sv_password_bak; set pw_backedup 0\""
alias restorejoinpassword "test $pw_joinbackedup \"set sv_joinpassword $sv_joinpassword_bak; set pw_joinbackedup 0\"" |
|
|
|
Does anybody know what happens if you enable the join password but leave the join password blank?
If it's not already, I think that combination should be the same as being unlocked, and that the default should be to 'enable join password' in that case. That would be a good compromise, in my opinion. |
|
|
(0007315)
|
Konar6
|
2013-10-03 18:41
|
|
That was actually my idea as well.
To answer your question, the server shows having a password in browsers, but it's not in fact passworded. |
|