Notes |
|
|
|
|
|
Tested it and it works. Thanks! This will help a lot when testing stuff. |
|
|
|
One issue I just found: If the client gains RCON access before disconnecting, it loses all server settings when disconnecting even if cl_keepserversettings is 1.
|
|
|
|
|
|
|
Hey, a quick test confirms that it didn't fix the issue completely.
I tested it with an oldschool Dwango5 team DM server, and when I use "map map01" in the console after having used "con_ctrl_d" as "send_password", it still loads up the map as regular coop instead of team DM. |
|
|
|
Quote from "unknownna I tested it with an oldschool Dwango5 team DM server, and when I use "map map01" in the console after having used "con_ctrl_d" as "send_password", it still loads up the map as regular coop instead of team DM.
This pipeline should fix the problem:'https://foss.heptapod.net/zandronum/zandronum-stable/-/pipelines/86663 [^]' but please test it to make sure that everything is working correctly. Note that this pipeline also fixes clients with RCON access not telling the server to set latched CVars (e.g. any of the game mode CVars) if it was done without the "rcon" CCMD. Please test this too to confirm that the issue's been fixed. |
|
|
|
I tested it very quickly and it still doesn¨t work completely. At least it now takes you to a deathmatch, but it still forgets that it's a team DM, i.e. "teamplay 1".
I didn't test it further since it's still broken. |
|
|
|
Quote from "unknownna" I tested it very quickly and it still doesn¨t work completely. At least it now takes you to a deathmatch, but it still forgets that it's a team DM, i.e. "teamplay 1".
I can't reproduce this for some reason. Can you please tell me the exact steps you took and/or WADs you loaded to reproduce this? FYI, this is what I did:
1. Hosted a team deathmatch server and connected one client.
2. Had the client login to RCON via "send_password" CCMD.
3. Ensured that "cl_keepserversettings" was enabled, then disconnected by typing "map MAP01" in the console.
4. The game mode was still team deathmatch in the offline game. |
|
|
|
I think I figured it out. It happens when the gamemode is changed after the client has connected to the server. Turns out I was actually starting a deathmatch server and changing it into a team DM.
1. Start a DM server and connect one client.
2. Acquire RCON access with send_password.
3. "rcon teamplay 1;rcon map map01" in the console.
4. Let next map load.
5. Acquire RCON access. // This step is important. Here, the client will think it's a DM server again.
6. "map map01" in the console to disconnect. The client will load up the game as a deathmatch instead of team DM.
I think I found the bug here. If the server has changed the gamemode after the client already connected, the client will acquire for itself the old server settings when it's granted RCON access. And these settings are desynced in real-time between the client and server.
You can simply connect 1 client to the server and start from step 3 with the server console. It's step 5 that's crucial to make the bug occur. |
|
|
|
|
|
|
Thanks, this seems to work properly now. The client seems to retain the proper server settings and isn't confused anymore after gaining RCON access.
I went through all the modes and made notes of my observations:
* Possession : OK
* TeamPossession : OK
* Teamplay 0 : OK
* Teamplay 1 : OK
* LastManStanding : Ok
* TeamLMS : OK
* Duel : OK (but duellimit can be changed on client without RCON access, desyncing the value between client and server)
* Cooperative : OK
* Survival : OK
* Deathmatch 1 : OK (but you can't toggle between DM and team DM unless you manually set teamplay to 0)
* Invasion : Not sure how to check this since maps with invasion spawns automatically turn into invasion, but probably ok.
* CTF : OK
* Skulltag : OK
* OneFlagCTF : OK
* Domination : OK
* TeamGame 1 : Only works if game isn't team-based already.
And if you enable one mode, but then change your mind and want another mode instead, it will only remember the first instance of mode change, for instance:
1. Grant client RCON access.
2. "possession 1" in the console.
3. "deathmatch 1" in the console. // You changed your mind and want deathmatch instead.
4. "rcon map map01" in the console.
5. Next map loads up as possession even if you set it to DM before the map change.
It seems to depend on which modes are selected after each other or something, but the example above always reproduces the issue. And I believe Zandronum/Skulltag always behaved like this IIRC. Shall I make a new ticket, or do you wish to iron out the bugs here? |
|
|
|
Thanks for checking over everything again! Regarding changing the game mode to cooperative, deathmatch, or teamgame: the current method of changing the game mode with the CVars is such a web-entangled mess at the moment (with lots of duplicated code) that if you want to change between survival and cooperative, TDM to DM, or CTF to teamgame, you must disable the former instead of enabling the latter. I tried cleaning up this mess a couple of years ago, but I can't remember if there were any issues with my changes. I'm not sure if it's worth doing it right now when we're so close to finishing 3.2.
Quote from "unknownna" Duel : OK (but duellimit can be changed on client without RCON access, desyncing the value between client and server)
I noticed earlier that "duellimit" wasn't actually a serverinfo CVar (and a few other ones) and could be changed by the clients. I actually fixed this in a separate topic that I worked on before this one:'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/f823d2e62208e9baedfa76559115c9ece0ffd01b [^]' so it'll be fixed there.
Quote from "unknownna" And if you enable one mode, but then change your mind and want another mode instead, it will only remember the first instance of mode change
This is because of the way latched CVars (all game mode CVars are latched) are currently set at the start of a new game. The list is "popped" (i.e. changes are applied in reverse order) instead of setting the CVars in the correct order they were changed. This is inherited from GZDoom 1.8.6, but this got fixed much later:'https://github.com/ZDoom/gzdoom/commit/7a1ec9ab9d2a38bc0891bbeff7174f1d22c82f82 [^]'
At first glance, it should be very easy to transplant this change into Zandronum right now, if we really need it.
All things considered, I think the issues with server settings not updating correctly for clients who have RCON access, whether "cl_keepserversettings" is enabled or disabled, have been fixed now. |
|
|
(0024087)
|
Kaminsky
|
2024-10-24 15:25
(edited on: 2024-10-24 15:31) |
|
|
|
|
Quote from Kaminsky At first glance, it should be very easy to transplant this change into Zandronum right now, if we really need it.
After thinking about it a bit, even if I could wait easily for long, I'd rather appreciate having it backported in for faster testing. It would skip some redundant "map" map changes, though this other issue would still remain for now:
Quote from Kaminsky the current method of changing the game mode with the CVars is such a web-entangled mess at the moment (with lots of duplicated code) that if you want to change between survival and cooperative, TDM to DM, or CTF to teamgame, you must disable the former instead of enabling the latter.
I can wait past 3.2 for this of course. No need to bother right now.
I think I found one final bug: If the client is in chasecam mode before gaining RCON access, the chasecam is reverted back to normal view after granted access. I noticed this while mapping out the tick offset sync issue.
Quote from Kaminsky rcon_logout
Is this to protect the client from desynced values? It's rather annoying to have to use this or "disconnect" before using a "map" command or starting a skirmish to quickly go offline. I'd then also add "or diconnect" to the message.
It would be a lot easier for me to use such commands if 0004331 was added for clients with RCON access. |
|