On 6/24/22 12:54, Tohru Adachi wrote:
It doesn't seem like it. The disconnect buffer being sent from server ->
client was read then dropped/overridden on the client's end prior to
this update. I was under the impression that this was a
client-controlled var due to how the original update that changed this
functionality was implemented.
I'd have expected this to be prefixed with sv_ if it were a
server-controlled variable or a more verbal description appended to the
convar, so it did throw me a bit.
Oh I agree, but given server hosts have probably set it already, would
be kinda :/ to change it at this point.
(nice domain by the way, frogs are cool)
They are ribbiting! I like the .tf too :-)
- Joshie 🐸✨
-----
5DE7 65CE F99A B8FB 62A3
6613 A792 D15F DA9E F531
-------- Original Message --------
From: Joshua Ashton [mailto:jos...@froggi.es]
Sent: Friday, June 24, 2022, 1:45 PM
To: hlds@list.valvesoftware.com
Subject: [hlds] Mandatory Team Fortress 2 update released
On 6/24/22 12:41, Tohru Adachi wrote:
I was under the impression that the default value of 0 was to preserve
the behaviour from a previous update.
My previous question still stands, shouldn't this be a replicated var?
Valve servers keep it at 0 and retain the behaviour up to now,
community server ops can set it to 1 at their discretion and can have
kicks/bans/disconnects working as originally intended.
Replicated vars wouldn't work for this because a server could have this
set and reject a client well before replicating vars across and the
message would not get through.
The correct solution is to just have it do nothing on the client, which
is the intention all along.
- Joshie 🐸✨
-----
5DE7 65CE F99A B8FB 62A3
6613 A792 D15F DA9E F531
-------- Original Message --------
From: Joshua Ashton [mailto:jos...@froggi.es]
Sent: Friday, June 24, 2022, 1:22 PM
To: Alex; hlds@list.valvesoftware.com
Subject: [hlds] Mandatory Team Fortress 2 update released
On 6/24/22 12:13, Alex wrote:
On Friday, June 24th, 2022 at 6:05 AM, Joshua Ashton
<jos...@froggi.es> wrote:
The client does nothing with net_disconnect_reason.
It's an entirely server-sided convar.
A hah, I see. When I was attempting to repro, I was testing a client
sending it's disconnect message to a server, not a server forcefully
disconnecting a client and sending a disconnect message (which uses the
same message).
What ended up being fixed in the changelog was a different bug where
disconnect messages would sometimes not show in text chat due to a race
between player entity destruction and the player_disconnected event.
At least this misunderstanding led to fixing two bugs! :-)
This will be fixed in the next update, thanks!
- Joshie 🐸✨
It looks like the ConVar is used in engine code which affects how both
the
client and server process all disconnect messages. When set to 0 on a
client,
it will always override the disconnect reason with "Client Disconnect"
on the
client's end, which is unintended behavior (it's also what was happening
before this ConVar existed).
Video demonstration of this:
https://www.youtube.com/watch?v=BiacrieODC8
Alex K.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
