MantisBT - Zandronum
View Issue Details
0000459Zandronum[All Projects] Bugpublic2011-05-19 23:522024-04-15 14:44
unknownna 
 
normalminorsometimes
confirmedopen 
98d 
 
0000459: "one/five minute warning" message always displayed for newly connected clients on certain maps
The "one/five minute" warning message will always be displayed for newly connected clients, even when the map time isn't 05:00 or 01:00. It seems that cl_startasspectator makes a difference here.
NEW steps:

1. zandronum -iwad doom2.wad -file 1minwarning_01.wad -host +timelimit 1
2. zandronum -iwad doom2.wad -file 1minwarning_01.wad -connect localhost +cl_startasspectator 0
3. "reconnect" in the console. Upon every reconnect, the announcer will shout "1 minute warning!".

1. Start a DM server with igpack11.wad loaded.
2. "timelimit 1" in the server console.
3. "map d2ig01" in the server console.
4. Connect a client to the server with cl_startasspectator set to 0.
5. "reconnect" in the console.

If cl_startasspectator is set to 1, the bug will not occur.
Confirmed maps:

* D2IG01
* D2IG05
* D2IG10
* D2IG24
* D2IG31
No tags attached.
related to 0001971confirmed Torr Samaho Floors don't reset properly online for clients 
related to 0000140closed Torr Samaho announcer says "5 minute warning!" after warm-up countdown if "timelimit" is set to 1. 
png Screenshot_Doom_20110520_222705.png (201,685) 2011-05-20 20:37
https://zandronum.com/tracker/file_download.php?file_id=334&type=bug
png

png 1minwarning_cause.png (39,469) 2024-04-14 23:31
https://zandronum.com/tracker/file_download.php?file_id=2962&type=bug
png

? 1minwarning_01.wad (4,446) 2024-04-14 23:31
https://zandronum.com/tracker/file_download.php?file_id=2963&type=bug
Issue History
2011-05-19 23:52unknownnaNew Issue
2011-05-20 01:02Torr SamahoNote Added: 0001694
2011-05-20 01:02Torr SamahoStatusnew => feedback
2011-05-20 04:26unknownnaNote Added: 0001699
2011-05-20 04:26unknownnaStatusfeedback => new
2011-05-20 05:01unknownnaNote Edited: 0001699bug_revision_view_page.php?bugnote_id=1699#r863
2011-05-20 12:27Torr SamahoNote Added: 0001702
2011-05-20 12:28Torr SamahoStatusnew => feedback
2011-05-20 20:32unknownnaNote Added: 0001705
2011-05-20 20:32unknownnaStatusfeedback => new
2011-05-20 20:37unknownnaFile Added: Screenshot_Doom_20110520_222705.png
2011-05-21 16:49Torr SamahoNote Added: 0001711
2011-05-21 17:17Torr SamahoStatusnew => feedback
2011-07-10 16:12unknownnaRelationship addedrelated to 0000140
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2024-04-14 23:30unknownnaNote Added: 0023609
2024-04-14 23:30unknownnaStatusfeedback => new
2024-04-14 23:31unknownnaFile Added: 1minwarning_cause.png
2024-04-14 23:31unknownnaFile Added: 1minwarning_01.wad
2024-04-14 23:33unknownnaStatusnew => confirmed
2024-04-14 23:33unknownnaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=14166#r14166
2024-04-14 23:34unknownnaRelationship addedrelated to 0001971
2024-04-15 10:56unknownnaNote Edited: 0023609bug_revision_view_page.php?bugnote_id=23609#r14168
2024-04-15 10:57unknownnaReproducibilityalways => sometimes
2024-04-15 14:44unknownnaNote Edited: 0023609bug_revision_view_page.php?bugnote_id=23609#r14169

Notes
(0001694)
Torr Samaho   
2011-05-20 01:02   
Can you try to rip apart one of the maps that has this problem to see which property of the map causes this?
(0001699)
unknownna   
2011-05-20 04:26   
(edited on: 2011-05-20 05:01)
I copied D2IG05 to a new WAD. It seems that a LOADACS-script is acting as the catalyst here. It works as intended if I remove the SWLIGHT lump.

Here's the source:

#library "swlight"
#include "zcommon.acs"

script 256 ENTER net
{
int usesoftware = GetCVar ("vid_renderer");

//I would have used an array for the gradient textures,
//but ACC is convinced it isn't a map script. Oh well.

    if (usesoftware == 0)
    {
         ReplaceTextures("XLIGHT-B","TNT1A0");
         ReplaceTextures("XLIGHT-G","TNT1A0");
         ReplaceTextures("XLIGHT-O","TNT1A0");
         ReplaceTextures("XLIGHT-R","TNT1A0");
         ReplaceTextures("XLIGHT-W","TNT1A0");
         ReplaceTextures("XLIGHT-X","TNT1A0");
         ReplaceTextures("XLIGHT-Y","TNT1A0");
         ReplaceTextures("YLIGHT-B","TNT1A0");
         ReplaceTextures("YLIGHT-G","TNT1A0");
         ReplaceTextures("YLIGHT-O","TNT1A0");
         ReplaceTextures("YLIGHT-R","TNT1A0");
         ReplaceTextures("YLIGHT-W","TNT1A0");
         ReplaceTextures("YLIGHT-X","TNT1A0");
         ReplaceTextures("YLIGHT-Y","TNT1A0");
    }
}


(0001702)
Torr Samaho   
2011-05-20 12:27   
Interesting. Is the source of swlight available?
(0001705)
unknownna   
2011-05-20 20:32   
SWLIGHT = compiled ACS
SLITESRC = Source (the code above)

The "x minute warning" bug occurs even when I remove all scripts, things and sector/line specials from the map. An empty shell of the map is all that is left and it still happens.
(0001711)
Torr Samaho   
2011-05-21 16:49   
Strange, I can't reproduce this. Tested D2IG01 and D2IG05.
(0023609)
unknownna   
2024-04-14 23:30   
(edited on: 2024-04-15 14:44)
Revisiting this years later, it seems to be caused by some undefined behavior from linedef action 103: Scroll Texture Down

Here's the interesting part: The textures have to be scrolling at a speed for it to happen, and it has to be at minimum 14 linedefs present on the map that is using this special for the glitch to occur.

1. zandronum -iwad doom2.wad -file 1minwarning_01.wad -host +timelimit 1
2. zandronum -iwad doom2.wad -file 1minwarning_01.wad -connect localhost +cl_startasspectator 0
3. "reconnect" in the console. Upon every reconnect, the announcer will shout "1 minute warning!".

Double-checking today, it seems to not always occur in the example wad. Sometimes after reconnecting the glitch doesn't happen, but I'd say that it happens around 80% of the time. I use a local wireless connection from a laptop to a router located around 3 meters from it, if it helps.

Edit:

Even more confusing is that the example wad only breaks in 3.1, but not in earlier versions. I guess this commit'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/ee36bf542180b8b74d641cf72449c52a9077de44 [^]' is causing some underlying issue to appear more frequently in 3.1 compared to before. Feels like some packet order issue.