Post by knightmare on Jun 18, 2018 12:29:08 GMT -5
#1. I wasn't able to interrupt the game loading by pressing Esc, possibly because my PC is too fast. But I was able to get it to crash in S_IssuePlaysound right after the map loads by spamming Esc. That added buffer check does fix that.
#2. Already had this fixed when I totally re-wrote the menus for my current development branch. But it was still in the 0.20 update source, so that helped.
Also, some of these PVS-Studio changes aren't allowed by many/most C compilers, like declaring variables in for loops or after the start of a function.
Any particular reasons for that? I was also using VS2008 when I worked on my C# project a couple years ago. My main reasons for sticking with it were: 1. VS2008 + ReSharper provided more editing features than VS2013 without ReSharper. 2. VS2013 without ReSharper worked excruciatingly slow compared to VS2008 with ReSharper. I'm talking "intellisence pops up 10 seconds after pressing Ctrl-Space", "VS hangs for several minutes after pressing Debug button" and "Characters appear on screen 2-5 seconds after I typed them" slow.
VS2017 with ReSharper worked fine for me for all C/CPP projects I edited with it.
OGG music logic involving bgTrack_t.introName, bgTrack_t.loopName and bgTrack_t.ambientName seems underdeveloped: 1. introName and loopName are always set to the same value. 2. ogg_loopcount and ogg_ambient_track are CVARs, which makes them more or less useless to a map maker.
3. ogg_ambient_track is initialized to "track11", so after initial track loops 5 times and there's no "track11.ogg" in the game files, "S_OpenBackgroundTrack: couldn't find track11" warning will be periodically displayed.
4. if you set ogg_ambient_track to "" via console, the engine will try to load "music/.ogg", because there's no ogg_ambient_track validation in S_StartBackgroundTrack.
Post by knightmare on Apr 15, 2019 14:10:10 GMT -5
I've already eliminated both of those bugs in my current development version (the second via a near-complete rewrite of the menu system).
But thanks anyway for pointing them out, as I had indeed missed them in my 0.20 update branch. The second is actually an invalid array access, which I just patched by enlarging the m_savevalid array by 1, and setting the index in DrawSaveshot() to MAX_SAVEGAMES if it's not in the range of the save/load actions.
CL_Shutdown() and Qcommon_Shutdown() are called multiple times during shutdown.
During normal shutdown, CL_Shutdown is called from both Com_Quit and Sys_Quit.
During shutdown due to error, CL_Shutdown is called from Com_Error, Sys_Error and Sys_Quit, and Qcommon_Shutdown is called from both Sys_Error and Sys_Quit.
Sys_Error calls Sys_Quit twice: once indirectly when the console window is closed, and from the wait loop at the bottom of the function (I was never able to thigger that code during the debugging though). This results in a logfile with a single "recursive shutdown" line when using logfile in overwrite mode (logfile cvar set to 1 or 2).
Colored text marker (byte with value 1 or 2 as the first char of the text) is printed to the system console, resulting in a strange char being printed (see Com_Printf call at the bottom of CL_ParseServerData).
The above and text coloring sequences (^1 and such) are written to the logfile if it's enabled.
Text coloring sequences are written to the file created by using condump command.
LoadGameCallback() tries to load saveshot for slot 0, which is "Entering map XXX" item and thus never has a saveshot.
Out of curiosity, why are there 2 levels of images-failed-to-load caching (Mod_CheckTexFailed and R_CheckImgFailed)? Why the logic still checks image name if a name hash matches? Why NUM_FAIL_IMAGES is so low (352 textures are loaded for base1.bsp, while NUM_FAIL_IMAGES is only 256).
Also, why updating the system console textfield when dragging the scrollbar is explicitly disabled (see case WM_VSCROLL in Sys_ConsoleEditProc)?