[Bug]: AutoExecConfig regression in SM 1.13

[CurTInq]

Prerequisites

• I have checked that my issue doesn't exist yet in the issue tracker

Operating System and Version

Debian 12

Game / AppID and Version

Any

SourceMod Version

1.13.0.7472

Metamod:Source Version

1.12.0-dev+1226

Version Verification

• I have updated SourceMod to the latest version and the issue persists
• I have updated SourceMod to the latest snapshot and the issue persists
• I have updated Metamod:Source to the latest snapshot and the issue persists

Updated SourceMod Version

1.13.0.7472

Updated Metamod:Source Version

1.12.0-dev+1226

Description

Expected behavior:

AutoExecConfig(true, ...) generates a config file for a plugin with convars which don't have FCVAR_DONTRECORD flag set. Never removes any plugin-related settings (convars) from it which were added manually later.

Current behavior:

AutoExecConfig(true, ...) overwrites the plugin config file, removing plugin-related convars from it if they have the FCVAR_DONTRECORD flag set, even if they were added manually.

It seems like this regression was introduced in this PR. While automatically adding new convars to the config file may be useful, removing existing convars is a breaking change. IMO, this destructive behavior shouldn't have been introduced to AutoExecConfig in the first place. Instead, a separate function - such as AutoExecConfigEx - should've been created.

The proper fix would be:

1. Revert the behavior change of AutoExecConfig to maintain backward compatibility with old plugins and servers setups. FCVAR_DONTRECORD convars still should not be inserted into generated configs. This behavior should be documented (right now it is "documented" only on the wiki, but not in the includes nor docs);
2. Create an AutoExecConfigEx function. I'll describe the function signature below;
3. Add an sm_configs_cleanup_unsafe <all/specific/config/path> command for server operators so they can execute the current behavior if they need to.

AutoExecConfigEx:

The default function signature should look like this:
void AutoExecConfigEx(int iFlags = 0, int iCvarFlags = FCVAR_HIDDEN | FCVAR_PROTECTED | FCVAR_CHEAT | FCVAR_DEVELOPMENTONLY, const char[] sConfigName = "", const char[] sFolderName = "sourcemod")

The arguments:

1. iFlags - AECFLAG_*, described below;
2. iCvarFlags - FCVAR_* flags that cause a convar to be ignored when generating the config file;
3. sConfigName - name of the config. Same as in the current AutoExecConfig;
4. sFolderName - name of the parent folder. Same as in the current AutoExecConfig.

Function flags:

1. AECFLAG_GENERATE_CONFIG = (1 << 0) - if set, the plugin config will be generated. Does nothing if the plugin config already exists. Respects iCvarFlags;
2. AECFLAG_STRIP_CONVARS = (1 << 1) - if set, convars not registered by the plugin will be removed from the config;
3. AECFLAG_STRIP_CONVARS_STRICT = (1 << 2) - overrides AECFLAG_STRIP_CONVARS if both are set. Extends the AECFLAG_STRIP_CONVARS behavior but respects the iCvarFlags argument. Any convar that has an ignored flag or does not belong to the plugin will be removed;
4. AECFLAG_INSERT_NEW_CONVARS = (1 << 3) - inserts new convars into the existing plugin config with respect to iCvarFlags. If no plugin config exists, this does nothing.

Steps to Reproduce

1. Make a plugin which registers convars with FCVAR_DONTRECORD flag set and executes AutoExecConfig(true, ...) after that.
2. Add and set a convar in the config which wasn't already there (has FCVAR_DONTRECORD flag set) but belongs to the plugin.
3. Change map and you will see the convar removed from the config. This happens only in SM 1.13.

Relevant Log Output

[Rushaway]

Can you provide a real demo ?
In all cases any convars external from the plugin itself should not be present in auto generated config.
It force user to keep things organized, and that the way to go.

If your issue is only about FCVAR_DONTRECORD, the solution is a fix instead of a revert.

[CurTInq]

Thank you for replying. Your reply shows that I probably wasn't clear on some points. Sorry in advance if this reply comes across as a bit... harsh.

Can you provide a real demo?

Any plugin that meets the criteria would be a real demo. Do I really need to provide a demo of a plugin that registers a convar with the FCVAR_DONTRECORD flag and calls AutoExecConfig(true, ...)?...

In all cases any convars external from the plugin itself should not be present in auto generated config.
It force user to keep things organized, and that the way to go.
If your issue is only about FCVAR_DONTRECORD, the solution is a fix instead of a revert.

You're confusing how it's supposed to work - or how you want it to work - with how it was guaranteed to work for many years, and how plugin authors, server operators, and other developers assumed it worked for about a decade. To be honest, I thought I had made it clear what the issue is and why the proposed approach is the way to go, but clearly I was wrong about that assumption, so let me explain more clearly:

1. Changing this function's behavior breaks those guarantees, effectively breaking plugins, server setups, and other systems (e.g. ci/cd scripts) that relied on them for many, many years. This is a clear regression in the worst way possible, because these changes are destructive.
2. Forcing server operators - especially those who host many servers and rely on ci/cd systems - to change their plugins, scripts, and other logic just to follow destructive mechanics they didn't ask for is not something they will be happy about. Instead of forcing them to change their setups, review all the configs, and fix all the issues that will pop up when configs get rewritten after upgrading to sm 1.13, a new command could be added to sm (e.g, sm_configs_cleanup_unsafe <all|specific/config/path>) that lets server operators rewrite their configs on their own.
3. You're right that not rendering convars with the FCVAR_DONTRECORD flag set into configs is not the right approach. In fact, it was wrong from the day it was introduced. However, you can't just remove this behavior for the very reason I described in point 1. There are plugins that already rely on the assumption that FCVAR_DONTRECORD convars won't be rendered into configs automatically, and changing this behavior would also mean breaking guarantees that have worked for about a decade.

So, once again, the real fix would be reverting the changes made to AutoExecConfig to keep the guarantees and introducing a new function instead (e.g., proposed AutoExecConfigEx, which is also better by design and can support more flags in the future if needed).

[Alienmario]

I suggest just adding a toggle between the old and new behavior to configs/core.cfg
If missing (e.g. old installation) it would default to old behavior.
For new installations, SM would ship with the toggle turned on.