Repo: BattletechModders/ModTek · File: ModTek/Features/Manifest/ModsManifest.cs
Branch verified: master (as of 2026-05-24) · Severity: low / log-volume + I/O
Summary
UnsupportedFeatureContentPackRequirements() logs a Warning for every manifest entry that
specifies a RequiredContentPack (an unsupported feature that ModTek then nulls out). In a
content-heavy pack like RogueTech — where thousands of entries carry RequiredContentPack — this
single line accounts for 16,809 log lines per session in our captures (17/17 sessions), the
single largest contributor to ModTek.log size by three orders of magnitude.
[WARNING] Specified RequiredContentPack is being ignored. ← ×16,809 / load
It's pure noise: the message is identical every time, carries no per-entry detail, and is not
actionable by the player or pack author on a per-entry basis. The cost is string formatting +
disk writes for ~16.8k lines on every launch.
Source
ModTek/Features/Manifest/ModsManifest.cs (lines ~374–389):
private static void UnsupportedFeatureContentPackRequirements(ModEntry entry)
{
if (entry.RequiredContentPack != null)
{
Log.Main.Warning?.Log($"\t\tSpecified {nameof(entry.RequiredContentPack)} is being ignored.");
entry.RequiredContentPack = null;
}
}
private static void UnsupportedFeatureAddToDb(ModEntry entry)
{
if (!entry.AddToDB)
{
Log.Main.Warning?.Log($"\t\t{nameof(entry.AddToDB)}={entry.AddToDB} is being ignored");
}
}
(AddToDB's sibling notice on line 387 has the same per-entry-warning shape and the same problem,
at lower volume.)
Why a level-downgrade does NOT work here
A tempting one-liner is to downgrade these from Warning to Debug. That does not reduce
volume in ModTek's default configuration: Log.Main is created at NullableLogger.TraceLogLevel
(Log.cs:8), i.e. it emits everything including Debug and Trace. Captured logs confirm it —
they contain 16,245 [DEBUG] and 182 [TRACE] lines. Downgrading would merely relabel the 16,809
lines from [WARNING] to [DEBUG]; they'd still be written. The fix must stop emitting per entry.
Suggested fix — aggregate to a single summary line
Count ignored entries during manifest processing and log one summary after the loop instead of one
line per entry. Concretely in ModsManifest.cs:
// class fields (near line 25)
private static int s_ignoredContentPackEntries;
private static int s_ignoredAddToDbEntries;
// UnsupportedFeatureContentPackRequirements (~378): replace the per-entry Warning with a count
if (entry.RequiredContentPack != null)
{
s_ignoredContentPackEntries++;
entry.RequiredContentPack = null;
}
// UnsupportedFeatureAddToDb (~387): same
if (!entry.AddToDB)
{
s_ignoredAddToDbEntries++;
}
// end of BuildModdedBTRL(), after the `foreach (var modDef in mods)` loop:
Log.Main.Warning?.LogIf(s_ignoredContentPackEntries > 0,
$"Ignored unsupported RequiredContentPack on {s_ignoredContentPackEntries} manifest entries (feature not supported).");
Log.Main.Warning?.LogIf(s_ignoredAddToDbEntries > 0,
$"Ignored unsupported AddToDB=false on {s_ignoredAddToDbEntries} manifest entries (feature not supported).");
s_ignoredContentPackEntries = 0;
s_ignoredAddToDbEntries = 0;
This keeps a visible, actionable signal (the counts) while removing ~16.8k lines/load — the
dominant ModTek.log line family — and cuts per-launch log I/O substantially. The loop is
single-threaded (BuildModdedBTRL is a sequential enumerator), so plain counters are safe.
Notes
- The root-cause volume originates in content packs declaring
RequiredContentPack on entries
ModTek can't honor. That's arguably valid forward-looking metadata, so suppressing the log
(ModTek side) is the better fix than stripping the fields from every pack.
Evidence
ModTek.log search: Specified RequiredContentPack is being ignored. → 16,809 occurrences in
the latest captured session; present in all 17 sessions.
Repo:
BattletechModders/ModTek· File:ModTek/Features/Manifest/ModsManifest.csBranch verified:
master(as of 2026-05-24) · Severity: low / log-volume + I/OSummary
UnsupportedFeatureContentPackRequirements()logs aWarningfor every manifest entry thatspecifies a
RequiredContentPack(an unsupported feature that ModTek then nulls out). In acontent-heavy pack like RogueTech — where thousands of entries carry
RequiredContentPack— thissingle line accounts for 16,809 log lines per session in our captures (17/17 sessions), the
single largest contributor to
ModTek.logsize by three orders of magnitude.It's pure noise: the message is identical every time, carries no per-entry detail, and is not
actionable by the player or pack author on a per-entry basis. The cost is string formatting +
disk writes for ~16.8k lines on every launch.
Source
ModTek/Features/Manifest/ModsManifest.cs(lines ~374–389):(
AddToDB's sibling notice on line 387 has the same per-entry-warning shape and the same problem,at lower volume.)
Why a level-downgrade does NOT work here
A tempting one-liner is to downgrade these from
WarningtoDebug. That does not reducevolume in ModTek's default configuration:
Log.Mainis created atNullableLogger.TraceLogLevel(
Log.cs:8), i.e. it emits everything including Debug and Trace. Captured logs confirm it —they contain 16,245
[DEBUG]and 182[TRACE]lines. Downgrading would merely relabel the 16,809lines from
[WARNING]to[DEBUG]; they'd still be written. The fix must stop emitting per entry.Suggested fix — aggregate to a single summary line
Count ignored entries during manifest processing and log one summary after the loop instead of one
line per entry. Concretely in
ModsManifest.cs:This keeps a visible, actionable signal (the counts) while removing ~16.8k lines/load — the
dominant
ModTek.logline family — and cuts per-launch log I/O substantially. The loop issingle-threaded (
BuildModdedBTRLis a sequential enumerator), so plain counters are safe.Notes
RequiredContentPackon entriesModTek can't honor. That's arguably valid forward-looking metadata, so suppressing the log
(ModTek side) is the better fix than stripping the fields from every pack.
Evidence
ModTek.logsearch:Specified RequiredContentPack is being ignored.→ 16,809 occurrences inthe latest captured session; present in all 17 sessions.