Explanation of Security Scanner Warnings
Ritual Pyre separates its simulation code from its Unity visual code so that the core mod remains compatible with headless and server environments. This transparent implementation detail triggers several heuristic security warnings.
Loads an additional .NET assembly at runtime
The mod loads exactly one additional assembly:
RitualPyre.Unity.dll
This file is included visibly inside the distributed mod archive. It is not downloaded, generated, or loaded from an external location.
The filename is hard-coded, combined exclusively with the mod's own root directory, checked for existence, and then loaded:
The package validator explicitly requires both RitualPyre.dll and RitualPyre.Unity.dll to be present and rejects unexpected package contents:
The split exists because the simulation assembly deliberately excludes Unity-dependent visual classes:
Those classes are compiled into the separate visual assembly:
Accesses the filesystem
The mod performs only two filesystem operations:
File.ExistsFile.ReadAllBytes
Both operations target the hard-coded file RitualPyre.Unity.dll inside Manifest.RootDirectoryPath, which is the mod's own installation directory:
The runtime mod code does not:
- Write, create, modify, or delete files
- Read arbitrary user-supplied paths
- Access files outside the mod directory
- Access the Windows Registry
- Start external processes
- Use native libraries
- Perform network requests
The scanner warning is therefore caused by the broad detection of System.IO usage, even though the actual access is restricted to reading the mod's own shipped visual DLL.
Uses reflection by name
Reflection is used in exactly two places:
Mafi.Unity.UnityModis looked up in assemblies already loaded by the game. This determines whether the mod is running in a graphical client or a headless environment.RitualPyre.RitualPyreModelFactoryis looked up inside the shippedRitualPyre.Unity.dlland registered with the game's dependency system.
Exact implementation:
The mod does not use reflective method invocation, hidden API calls, GetMethod, GetField, or Invoke. Reflection is only used to locate these two known types and preserve headless compatibility.
Summary
The warnings describe techniques that can be dangerous in unknown software, but their use in Ritual Pyre is narrow and auditable:
- One hard-coded, visibly shipped DLL is loaded.
- Only the mod's own directory is read.
- No files are written or deleted.
- No code is downloaded.
- Reflection resolves only two explicitly named types.
- The complete source code is publicly available.