MCD_ERROR: surface error logs in Release builds

[Mosch0512]

Summary

Makes g_ConsoleDebug->Write(MCD_ERROR, ...) actually produce output in stock Release builds. Companion to PR #66 — without this change, the safe_cast size-mismatch diagnostics added there compile but never reach the user, because the entire Write body is gated by #ifdef CONSOLE_DEBUG (not defined in any production build).

Changes

src/source/Core/Utilities/Log/muConsoleDebug.cpp:

1. CmuConsoleDebug::GetInstance() now always returns a valid static instance. Previously it returned nullptr unless CSK_LH_DEBUG_CONSOLE was defined, which made every g_ConsoleDebug->Write(...) call site a null-pointer member-function call. It only "worked" because the Write body was empty when CONSOLE_DEBUG was undefined; any non-empty code there would have crashed.

2. Write() now routes MCD_ERROR to g_ErrorReport.Write (file-based, always compiled, opens MuError.log on startup) before the existing CONSOLE_DEBUG-gated console path. MCD_SEND / MCD_RECEIVE / MCD_NORMAL stay debug-only so production logs aren't flooded with per-packet trace messages.

Effect

Any existing or future g_ConsoleDebug->Write(MCD_ERROR, ...) call -- including the safe_cast diagnostics from PR #66 -- now lands in MuError.log in Release builds. Example after the join-map struct guard would trip:

[MCD_ERROR] safe_cast<PRECEIVE_JOIN_MAP_SERVER_EXTENDED>: received 91 bytes, expected at least 92 -- packet dropped
[MCD_ERROR] [ReceiveJoinMapServer] dropped -- protocol state stays REQUEST_JOIN_MAP_SERVER, main render will not be enabled (loading screen will appear frozen).

MuError.log is rotated by the existing CErrorReport::CutHead logic, so this won't grow unbounded.

Test plan

• Builds clean: MinGW-w64 i686, Release.
• Manual: launch client, confirm MuError.log is created in working dir (already exists today).
• Manual: trigger an existing MCD_ERROR path (or temporarily downgrade an MCD_NORMAL to MCD_ERROR) and confirm the line appears in MuError.log.
• Manual: verify SEND / RECEIVE / NORMAL chatter does NOT appear in MuError.log (only ERROR survives Release).

Scope notes

• Diff is +17/-4 in a single file.
• No behavior change for CONSOLE_DEBUG-enabled builds: the console output still happens after the file write.
• _EDITOR (ImGui console) path is unchanged — still gated by CONSOLE_DEBUG together with the rest of the console output.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enables persistent error logging for Release builds by decoupling MCD_ERROR messages from the debug-only console output. By ensuring the console debug instance is always initialized and routing error logs to the existing file-based error reporting system, the changes allow critical diagnostic information to be captured in production environments without introducing unnecessary noise from trace-level logs.

Highlights

• Always-on Error Logging: Modified CmuConsoleDebug::Write to route MCD_ERROR messages to MuError.log in all build configurations, ensuring critical diagnostics are captured in production.
• Singleton Instance Stability: Updated CmuConsoleDebug::GetInstance to return a valid static instance instead of nullptr in non-debug builds, preventing potential null-pointer dereferences.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request ensures that CmuConsoleDebug::GetInstance always returns a valid instance to prevent null-pointer dereferences and updates the Write method to always log MCD_ERROR types to the error report regardless of debug flags. A high-severity issue was identified in the new logging logic where the use of a small fixed-size buffer and an unsafe vswprintf call could lead to a buffer overflow; a suggestion was provided to use a larger buffer and a size-limited formatting function to ensure safety and consistency.

[gemini-code-assist]

The buffer szErrorBuffer is limited to 256 characters, which may be insufficient for detailed error messages (e.g., long file paths or complex packet diagnostics). More importantly, the use of vswprintf with only 3 arguments is non-standard and unsafe as it lacks a buffer size limit, risking a buffer overflow if the formatted string exceeds the buffer capacity. Note that CErrorReport::Write in ErrorReport.cpp correctly uses the 4-argument version of vswprintf with a 1024-character limit. To ensure safety and consistency, the buffer size should be increased and the size-limited version of the formatting function should be used.

Suggested change

	wchar_t szErrorBuffer[256] = L"";
	va_list pArgsForFile;
	va_start(pArgsForFile, pStr);
	vswprintf(szErrorBuffer, pStr, pArgsForFile);
	va_end(pArgsForFile);
	wchar_t szErrorBuffer[1024] = L"";
	va_list pArgsForFile;
	va_start(pArgsForFile, pStr);
	vswprintf(szErrorBuffer, 1024, pStr, pArgsForFile);
	va_end(pArgsForFile);

[Mosch0512]

Consolidating into #66 — these belong together; #67 was an unnecessary split.