Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004383Zandronum[All Projects] Suggestionpublic2024-08-11 19:352024-10-26 04:40
Reporterunknownna 
Assigned ToKaminsky 
PrioritynormalSeveritytweakReproducibilityN/A
StatusfeedbackResolutionreopened 
PlatformOSOS Version
Product Version 
Target Version3.2Fixed in Version3.2 
Summary0004383: [3.2] Let client keep server settings when disconnecting for faster testing purposes
DescriptionSomething changed in Zandronum where the client now resets all settings to default when disconnecting from the server and starting a new game. I could actually need the client to save the settings temporarily so I can quickly flick back and forth between online and offline play to check for any differences between them. This considerably speeds up testing since I can then simply load up the same map as the server and quickly go to the same spot on the map with all the settings intact.

I'm not sure, but maybe this is the commit that changed it:'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/a3a66f953c4a3bc0a691b62cb2e2a92723d70e06 [^]'
Attached Files

- Relationships

-  Notes
User avatar (0023968)
Kaminsky (developer)
2024-08-25 13:34

 This commit got pushed in a while ago:'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/995e928b020974b873b2095a7de6011cd5f11265 [^]'

If you want to keep the server's settings after disconnecting from an online game, then enable the "cl_keepserversettings" CVar (false by default). This CVar only works in testing releases and will be forcibly disabled in stable releases.
User avatar (0023973)
unknownna (updater)
2024-08-26 09:40

 Tested it and it works. Thanks! This will help a lot when testing stuff.
User avatar (0023974)
unknownna (updater)
2024-08-26 09:46
edited on: 2024-08-26 09:46

 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.
User avatar (0023999)
Kaminsky (developer)
2024-09-04 14:10
Quote from unknownna
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.


Can you please test this pipeline:'https://foss.heptapod.net/zandronum/zandronum-stable/-/pipelines/86550/ [^]' to confirm if it fixes this issue?
User avatar (0024004)
unknownna (updater)
2024-09-05 13:33

 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.
User avatar (0024010)
Kaminsky (developer)
2024-09-05 17:41
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.
User avatar (0024016)
unknownna (updater)
2024-09-05 21:02

 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.
User avatar (0024017)
Kaminsky (developer)
2024-09-06 01:35
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.
User avatar (0024018)
unknownna (updater)
2024-09-06 12:42

 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.
User avatar (0024023)
Kaminsky (developer)
2024-09-09 02:44

 Thanks for the detailed list of steps to reproduce! Here's a new pipeline that should fix that issue:'https://foss.heptapod.net/zandronum/zandronum-stable/-/pipelines/86891 [^]'

Please let me know if everything is working correctly now.
User avatar (0024028)
unknownna (updater)
2024-09-09 18:10

 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?
User avatar (0024037)
Kaminsky (developer)
2024-09-17 15:35

 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.
User avatar (0024087)
Kaminsky (developer)
2024-10-24 15:25
edited on: 2024-10-24 15:31

 A few commits pertaining to this issue have been pushed into the main repository:

-'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/d0d570335ae32b4d5f4b18ce6d24a6ca33013c3d [^]'
-'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/b9a12f15305b25887681420774642c7b1f8b735d [^]'
-'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/6664f14514b6f472e04baea35339dffd54ff2088 [^]'

Note that these don't fix the other issues discussed in my other comment (https://zandronum.com/tracker/view.php?id=4383#c24037). It's also worth noting that clients with RCON access must now log out first (via "rcon_logout" CCMD) before they can use the "map" CCMD on their end, or start an offline skirmish game. This is intended to be a workaround for clients with RCON access no longer being able to set latched serverinfo CVars for themselves (e.g. typing "sv_maxlives 2" as opposed to "rcon sv_maxlives 2") in case they decide leave the server and start their own offline game.
User avatar (0024100)
unknownna (updater)
2024-10-26 04:40
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.

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2024-08-11 19:35 unknownna New Issue
2024-08-25 13:34 Kaminsky Note Added: 0023968
2024-08-25 13:34 Kaminsky Assigned To => Kaminsky
2024-08-25 13:34 Kaminsky Status new => needs testing
2024-08-25 13:34 Kaminsky Target Version => 3.2
2024-08-26 09:40 unknownna Note Added: 0023973
2024-08-26 09:40 unknownna Status needs testing => resolved
2024-08-26 09:40 unknownna Fixed in Version => 3.2
2024-08-26 09:40 unknownna Resolution open => fixed
2024-08-26 09:46 unknownna Note Added: 0023974
2024-08-26 09:46 unknownna Status resolved => feedback
2024-08-26 09:46 unknownna Resolution fixed => reopened
2024-08-26 09:46 unknownna Note Edited: 0023974 View Revisions
2024-09-04 14:10 Kaminsky Note Added: 0023999
2024-09-05 13:33 unknownna Note Added: 0024004
2024-09-05 13:33 unknownna Status feedback => assigned
2024-09-05 17:41 Kaminsky Note Added: 0024010
2024-09-05 17:41 Kaminsky Status assigned => needs review
2024-09-05 21:02 unknownna Note Added: 0024016
2024-09-05 21:02 unknownna Status needs review => feedback
2024-09-06 01:35 Kaminsky Note Added: 0024017
2024-09-06 12:42 unknownna Note Added: 0024018
2024-09-06 12:42 unknownna Status feedback => assigned
2024-09-09 02:44 Kaminsky Note Added: 0024023
2024-09-09 18:10 unknownna Note Added: 0024028
2024-09-09 18:10 unknownna Status assigned => feedback
2024-09-17 15:35 Kaminsky Note Added: 0024037
2024-10-24 15:25 Kaminsky Note Added: 0024087
2024-10-24 15:25 Kaminsky Status feedback => needs testing
2024-10-24 15:31 Kaminsky Note Edited: 0024087 View Revisions
2024-10-26 04:40 unknownna Note Added: 0024100
2024-10-26 04:40 unknownna Status needs testing => feedback




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker