MantisBT - Zandronum |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0004168 | Zandronum | [All Projects] Bug | public | 2023-10-31 19:16 | 2024-03-23 05:56 |
|
| Reporter | RusselCS | |
| Assigned To | Kaminsky | |
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | |
| Platform | PC | OS | Windows | OS Version | 10.04 x86-64 |
| Product Version | 3.1 | |
| Target Version | 3.2 | Fixed in Version | 3.2 | |
|
| Summary | 0004168: Server CVars do not save to LocalServerInfo.mod when in multiplayer emulation |
| Description | When playing offline with multiplayer emulation enabled (ie, offline bot matches of any sort--including campaigns) you cannot update server cvars defined by CVARINFO. |
| Steps To Reproduce | 1) Load the attached wad onto a server
2) In the server, set `user_sv_testtoggle` to `true`.
3) Connect to the server.
4) Close your client.
5) Re-open the client, but do not connect to the server.
6) Open Offline Skirmish in any map in Deathmatch.
7) Set `user_sv_testtoggle` to `false`.
8) Close and re-open the game, re-enter offline skirmish. Check the status of `user_sv_testtoggle`.
Expected: `user_sv_testtoggle` should be `false`.
Actual: `user_sv_testtoggle` is `true`. |
| Additional Information | Conversation with Kaminsky came to the conclusion that server cvars changed by the client are not properly stored into the "LocalServerInfo.mod" block of the ini when the client's netstate is NETSTATE_SINGLE_MULTIPLAYER. Is it only properly persisted into that block when the client's netstate is NETSTATE_SINGLE. |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  3.2_cvartesttoggle.pk3 (1,534) 2023-10-31 19:16
https://zandronum.com/tracker/file_download.php?file_id=2869&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2023-10-31 19:16 | RusselCS | New Issue | |
| 2023-10-31 19:16 | RusselCS | File Added: 3.2_cvartesttoggle.pk3 | |
| 2024-03-14 15:59 | Kaminsky | Note Added: 0023397 | |
| 2024-03-14 15:59 | Kaminsky | Assigned To | => Kaminsky |
| 2024-03-14 15:59 | Kaminsky | Status | new => needs review |
| 2024-03-14 15:59 | Kaminsky | Target Version | => 3.2 |
| 2024-03-15 00:58 | RusselCS | Note Added: 0023405 | |
| 2024-03-15 00:59 | RusselCS | Note Edited: 0023405 | bug_revision_view_page.php?bugnote_id=23405#r14139 |
| 2024-03-16 04:34 | Kaminsky | Note Added: 0023409 | |
| 2024-03-17 12:13 | Kaminsky | Note Added: 0023416 | |
| 2024-03-17 12:13 | Kaminsky | Status | needs review => needs testing |
| 2024-03-23 05:55 | Ru5tK1ng | Note Added: 0023472 | |
| 2024-03-23 05:55 | Ru5tK1ng | Fixed in Version | => 3.2 |
| 2024-03-23 05:56 | Ru5tK1ng | Status | needs testing => resolved |
| 2024-03-23 05:56 | Ru5tK1ng | Resolution | open => fixed |
|
Notes |
|
|
|
I opened a new merge request to address this issue:'https://foss.heptapod.net/zandronum/zandronum-stable/-/merge_requests/58 [^]'
Something else that I noticed when addressing this is that the server's settings also get archived when the client closes the game. Personally, I believe the server's settings should be discarded when the client disconnects. As such, the MR also includes a commit to discard the server's settings upon disconnecting, especially so they don't overwrite the client's when they're archived. |
|
|
|
(0023405)
|
|
RusselCS
|
2024-03-15 00:58
(edited on: 2024-03-15 00:59) |
|
This appears to solve the issue.
Tested with the above wad, using different test scenarios I could think of.
Turned the variable on in deathmatch, closed the game, relaunched and the setting was properly persisted.
I also tested with the server -> client transfer as discussed, and the cvars do not remain on the client after they leave the server.
Tested in MM8BDM with its new settings and the issue does not appear there with this build either.
|
|
|
|
|
|
Thanks for testing! It sounds like everything's working as intended and solves the issue. |
|
|
|
|
|
The merge request above has been pushed into the main repository. |
|
|
|
|
|
Tested in 3.2 and it seemed that the CVAR's value stuck to what the client specified. Connecting to the server did not overwrite anything. |
|