Page 1 of 3
Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 8:36 am
by Fairman
Settings files vs hardcoded inputs: managing EA parameters across accounts
Once you run an EA on more than one account or symbol, managing the settings becomes its own problem. Which version of the parameters is on which chart? Did you change the risk on the demo but not the live account? What were the settings last month?
MT4 and MT5 let you save input sets as set files. That's the simplest way to keep track. Save a set file for each account and symbol combination, name it clearly, and keep it in a folder you back up. When you change something, save a new version with a date in the name instead of overwriting.
Hardcoding values in the EA is the worst option. Every change means recompiling, and it's easy to lose track of which compiled version has which values.
Another option is having the EA read settings from a file on startup, like a JSON or CSV. That lets you manage all settings in one place, and you can change them without touching the chart. It's more work to set up but scales better if you run many instances.
Whichever approach, write the current settings to the log when the EA starts. Then the log itself records exactly what was running, which helps a lot when you're trying to work out why results changed.
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:18 am
by PTScalper
Fairman wrote: Sat Oct 17, 2026 8:36 am
Settings files vs hardcoded inputs: managing EA parameters across accounts
Once you run an EA on more than one account or symbol, managing the settings becomes its own problem. Which version of the parameters is on which chart? Did you change the risk on the demo but not the live account? What were the settings last month?
MT4 and MT5 let you save input sets as set files. That's the simplest way to keep track. Save a set file for each account and symbol combination, name it clearly, and keep it in a folder you back up. When you change something, save a new version with a date in the name instead of overwriting.
Hardcoding values in the EA is the worst option. Every change means recompiling, and it's easy to lose track of which compiled version has which values.
Another option is having the EA read settings from a file on startup, like a JSON or CSV. That lets you manage all settings in one place, and you can change them without touching the chart. It's more work to set up but scales better if you run many instances.
Whichever approach, write the current settings to the log when the EA starts. Then the log itself records exactly what was running, which helps a lot when you're trying to work out why results changed.
Hi Fairman,
Settings files vs hardcoded inputs: Managing EA parameters across multiple accounts
Running an Expert Advisor (EA) on a single demo account is easy. Scaling it across multiple live accounts, prop firm challenges, and a dozen currency pairs is where the real headache begins. If you aren't organized, you will eventually face the classic algorithmic trading nightmare: waking up to a blown account because the risk multiplier was set to 1.0 instead of 0.1, or realizing you have no idea what settings generated last month's stellar backtest.
Here is a breakdown of the three main ways to manage your EA parameters, from the worst practice to the institutional standard.
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:18 am
by PTScalper
1. The Trap: Hardcoding Inputs
Hardcoding your parameters directly into the MQL4/MQL5 source code is the absolute worst option for scaling.
The Recompile Nightmare: Every minor tweak requires you to open MetaEditor, modify the code, and recompile.
Version Confusion: You inevitably end up with a folder full of files like GridBot_v2_lowrisk.ex5 and GridBot_v2_EURUSD_Live.ex5. Within weeks, you will lose track of the exact numerical differences between these compiled files.
Zero Flexibility: You cannot share the EA or run different strategies simultaneously without distributing completely separate compiled files.
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:18 am
by PTScalper
2. The Standard: Using .set Files
MetaTrader’s native .set files are the most accessible way to manage parameters. You hit "Save" on the EA inputs tab, and it exports your exact configuration to a file.
To make this work reliably at scale, you need a militant file management system:
Strict Naming Conventions: Never name a file good_settings.set. Use a structured, readable format: [EA_Name]_[Symbol]_[Timeframe]_[Account_Type]_[Date].set. (Example: BreakoutPro_EURUSD_H1_Live_20261017.set).
Never Overwrite: When you tweak a setting, save a new file with today's date. This creates a historical backup of your parameter evolution so you can always roll back.
Centralized Backup: Keep your presets folder synced to a cloud drive or GitHub repository so your configurations are backed up and identical across multiple VPS instances.
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:19 am
by PTScalper
3. The Pro Setup: External Configuration Files (JSON/CSV)
If you are running a fleet of EAs across 20+ charts and multiple VPS servers, opening each chart to manually load a new .set file becomes tedious manual labor. The scalable alternative is coding your EA to read its parameters from an external file upon initialization.
Centralized Control: You maintain a single config.json or settings.csv file in the terminal's Common\Files directory. All your EA instances automatically read their respective parameters from this single source of truth.
Headless Updates: You can adjust risk parameters, update trading hours, or pause trading globally by editing one text file—without ever needing to click through the MetaTrader UI or touch a chart.
The Trade-off: It requires significantly more MQL programming to build a robust file parser that can handle missing files, syntax errors, and type casting (converting JSON strings to doubles/integers).
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:19 am
by PTScalper
The Golden Rule: Log Everything on Startup
Regardless of which method you choose, your EA must leave an airtight audit trail.
Always write a function in OnInit() that prints the critical settings to the Experts log the moment the EA attaches to the chart.
Code: Select all
int OnInit() {
Print("--- EA STARTUP LOG ---");
Print("Version: 2.1 | Symbol: ", _Symbol, " | TF: ", EnumToString((ENUM_TIMEFRAMES)_Period));
Print("Risk %: ", RiskPerTrade, " | Max DD: ", MaxDrawdownLimit);
Print("Magic Number: ", MagicNumber);
Print("----------------------");
return(INIT_SUCCEEDED);
}
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:19 am
by PTScalper
When your forward-testing results suddenly diverge from your backtests, this log is your only mathematical proof of what was actually running on the chart at that exact moment.
How is everyone else managing parameters across large server farms? Are you strictly relying on rigid .set file naming conventions, or have you transitioned to reading external JSON files/databases on startup?
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:20 am
by PTScalper
If you are used to the seamless System.Text.Json deserialization in .NET, MQL5's approach requires a bit more manual lifting. Because MQL5 does not have a native JSON parser in its standard library, the industry standard is to use a robust, open-source header file from the MQL5 CodeBase—the most popular being JAson.mqh.
Here is a complete, production-ready example of how to read a config.json file and parse it.
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:20 am
by PTScalper
1. The JSON Structure
Imagine you have a single config.json file used to control risk across multiple EAs:
Code: Select all
{
"RiskPercent": 1.5,
"MaxDrawdown": 10.0,
"TradingHours": "08:00-17:00",
"MagicNumber": 123456,
"Symbols": ["EURUSD", "XAUUSD"]
}
Re: Settings files vs hardcoded inputs: managing EA parameters across accounts
Posted: Sat Oct 17, 2026 9:20 am
by PTScalper
2. The MQL5 Implementation
To make this highly scalable across multiple MetaTrader terminals on a VPS, the FILE_COMMON flag is used. This forces the EA to look in the terminal's shared Common/Files directory rather than the local MQL5 sandbox.
Code: Select all
#include <JAson.mqh> // Ensure JAson.mqh is in your MQL5/Include folder
// Global configuration variables
double g_RiskPercent;
double g_MaxDrawdown;
string g_TradingHours;
long g_MagicNumber;
//+------------------------------------------------------------------+
//| Loads and parses the JSON configuration file |
//+------------------------------------------------------------------+
bool LoadGlobalConfig(string filename)
{
// 1. Open the file from the shared Common/Files folder
// FILE_COMMON allows multiple MT5 terminals to read the exact same file
int fileHandle = FileOpen(filename, FILE_READ | FILE_TXT | FILE_ANSI | FILE_COMMON);
if(fileHandle == INVALID_HANDLE)
{
Print("CRITICAL ERROR: Failed to open config file. Error code: ", GetLastError());
return false;
}
// 2. Read the entire file content into a string
string jsonText = "";
while(!FileIsEnding(fileHandle))
{
jsonText += FileReadString(fileHandle) + "\n";
}
FileClose(fileHandle);
// 3. Deserialize the JSON string using CJAVal
CJAVal json;
if(!json.Deserialize(jsonText))
{
Print("CRITICAL ERROR: Failed to parse JSON string. Check syntax.");
return false;
}
// 4. Extract values and cast them to MQL5 datatypes
// JAson uses a map-like syntax for root elements
g_RiskPercent = json["RiskPercent"].ToDbl();
g_MaxDrawdown = json["MaxDrawdown"].ToDbl();
g_TradingHours = json["TradingHours"].ToStr();
g_MagicNumber = json["MagicNumber"].ToInt();
// 5. Example of iterating through a JSON array
Print("Authorized Symbols:");
for(int i = 0; i < json["Symbols"].Size(); i++)
{
Print("- ", json["Symbols"][i].ToStr());
}
// 6. Log the successfully loaded parameters
Print("--- Global Config Loaded Successfully ---");
Print("Risk: ", g_RiskPercent, "% | Max DD: ", g_MaxDrawdown, "%");
Print("Hours: ", g_TradingHours, " | Magic: ", g_MagicNumber);
return true;
}
//+------------------------------------------------------------------+
//| Expert initialization function |
//+------------------------------------------------------------------+
int OnInit()
{
if(!LoadGlobalConfig("master_config.json"))
{
// Fail initialization if the config cannot be read securely
return(INIT_FAILED);
}
return(INIT_SUCCEEDED);
}