Skip to content

Conversation

Dentomologist
Copy link
Contributor

Preserve the configured logging level unless the user actually changes it, rather than capping LDEBUG to LINFO on release builds (which then persisted when going back to a debug build).

Rename LogManager::m_level to m_effective_level and distinguish between the config and effective level in various function/variable names.

@Dentomologist Dentomologist force-pushed the logging_avoid_overwriting_debug_verbosity_in_release_builds branch from 4750daa to bccd382 Compare September 12, 2025 03:53
@Dentomologist
Copy link
Contributor Author

I've fixed the build on Android, but I'm not familiar enough with the Android settings code to be sure the change is working as intended there. If someone could test that when they have a chance that'd be great.

Copy link
Contributor

@Pokechu22 Pokechu22 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested and can confirm that this works on Windows. I haven't looked into Android.

Copy link
Member

@JosJuice JosJuice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I haven't tested it, I believe it's the case both in master and in this PR that Android only sets the value when the user explicitly changes the value.

Preserve the configured logging verbosity unless the user actually
changes it, rather than capping it to LINFO on release builds.

Rename LogManager::m_level to m_effective_level and distinguish between
the config and effective level in various function/variable names.
@Dentomologist Dentomologist force-pushed the logging_avoid_overwriting_debug_verbosity_in_release_builds branch from bccd382 to 3fea0a4 Compare September 15, 2025 20:34
@JosJuice
Copy link
Member

If someone were to set LOGGER_VERBOSITY without going through SetConfigLogLevel (or manually calling SetEffectiveLogLevel afterwards), m_effective_level wouldn't get updated, right? This scenario can be triggered using game INIs. You could solve this either using a config changed callback, or by having GetEffectiveLogLevel check Config::GetConfigVersion and call SetEffectiveLogLevel if the config version has changed since the last SetEffectiveLogLevel call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants