Saving and transferring configurations (.set)

Tool versions: OkurraButton 2.00 · OkurraGlobal 2.00 · O!kurra Capital Defense EA 2.00

Table of contents

7.1 The .set file — a portable configuration artifact 7.2 Saving: how a .set is created 7.3 Two kinds of .set — full and strategies-only 7.4 Loading in the panel (Load) and the file manager 7.5 Where the files live: sets, history, working state 7.6 Loading into the EA (F7 → Load) 7.7 Practice: naming and managing variants 7.8 The license key and .set files 7.9 The position ownership registry and restarts

7.1 The .set file — a portable configuration artifact

The .set file is the bridge between designing and execution — the only way a strategy designed in the panels reaches the robot (chapters 2.4 and 2.7). It is worth understanding well, because your entire strategy archive is precisely a collection of .set files.

Technically, a .set is a plain text file in the standard MetaTrader 5 settings format: each line is ParameterName=Value, and lines starting with a semicolon (;) are comments. The Okurra panels prepend a short comment header to the file with information about where and when the file comes from (instrument, broker, timestamp, and a note whether it contains the global section). The EA reads the .set natively — the robot does not know and does not care that the file was created in an Okurra indicator; it sees a valid .set that can be loaded.

The key advantage of this approach: the configuration is a durable document, not a fleeting state. You can name every strategy variant, archive it, compare it with the previous one, load it on another account, or pass it on. This is a discipline that pays off when you research many variants — you will not lose what worked.

7.2 Saving: how a .set is created

You create a .set file with the Save button in a panel (OkurraButton or OkurraGlobal — chapters 4.8 and 5.7).

After clicking Save, a small save dialog opens, in which you type the file name right away, and confirm with “V” (or cancel with “X”). This matters: you give the name during the save — you do not have to create a file with an impersonal timestamp and rename it only afterwards. You can immediately type something readable, e.g. XAUUSD_mean-rev_M1. (Renaming later is also possible — in the Load dialog, section 7.4.)

The file lands in the directory MQL5/Files/OKU/sets/ inside the MetaTrader sandbox. At the top of the file, the panel writes a comment header, e.g.:

; --------------------------------------------
; F-ExportSet: Okurra .set written by OkurraButton
; --------------------------------------------
; symbol       : XAUUSD
; broker       : <broker name>
; timestamp    : 2026.06.13 14:22:05
; --------------------------------------------
; Note   : per-button sections only (B1..B5).
;          Global section: use OkurraGlobal [Save] for that.
; --------------------------------------------

A file saved from OkurraGlobal has an analogous header, just with the description “F-ExportSet: Okurra EA setup snapshot (.set)” and additional lines source (where the file comes from) and ea_revision (the EA revision the configuration is compatible with). Thanks to this, opening the file weeks later, you immediately know where it comes from and what it contains.

7.3 Two kinds of .set — full and strategies-only

Which panel you click Save in determines what ends up in the file (chapter 2.4):

Save in OkurraGlobal → a full setup. The file contains the global section (all EA-wide settings) and the parameters of all five buttons (B1…B5). It is the complete configuration of the whole robot — you load it into the EA in one move and you have everything. This is the file you normally use to move a finished setup to the EA.

Newer global settings travel in the .set too. A full file from OkurraGlobal carries, among others, the “own only” mode switch (Global_MonitorOwnOnly, chapter 5.5), the “own only” trade-marker filter (Global_TradeMarkers_OwnOnly), the close model (Global_CloseModel) and its cooldown (Global_CloseAdaptive_CooldownMin) — moving a setup to another terminal, you move these behaviors too. One deliberate exception: Global_OwnOnly_AdoptExisting (a one-time adoption of existing positions into the “own only” registry) exists only in the EA’s Inputs window (F7) and does not travel in the .set — it is an operational safety fuse you do not want to accidentally carry along with the configuration.

Save in OkurraButton → strategies only. The file contains only the parameters of buttons B1…B5, without the global section (the file header states this explicitly: “per-button sections only”). Useful when you want to move just the strategies, keeping the global settings you already have in the EA.

Which one to use? If you are designing a complete setup and want a single file to load into the robot — save from OkurraGlobal (full). A file from OkurraButton makes sense when you deliberately want to separate strategies from global settings (e.g. you have one global set and several different button sets to test on it).

7.4 Loading in the panel (Load) and the file manager

The Load button in a panel opens a browser of .set files from the OKU/sets/ directory. It is not just a “file picker” — the dialog works like a small manager:

• Loading — you pick a file, and the panel immediately adopts it as the current configuration. There is no need to click Apply afterwards — the loaded .set becomes the applied state, and the companion indicators redraw to match it. (In practice: the fields do not glow gold, because “working” and “applied” are identical after loading — chapter 4.7.)
• Renaming — in the dialog you can rename a file (e.g. an impersonal Button_<timestamp>.set to XAUUSD_scalp_M1.set). A convenient way of tidying the archive without leaving the panel.
• Deleting — you can also delete a .set file you no longer need. Deletion is two-step (a safeguard against an accidental click): the first click only arms the button (asks for confirmation), and only the second click deletes the file. A single click deletes nothing — if you do not click a second time within 5 seconds, the safeguard disarms itself and the file remains untouched.

Cross-sync on load. If you have both panels on the chart, loading a .set in one automatically refreshes the other (the mechanism from chapter 2.5): you load a full .set in OkurraGlobal → Global adopts the global section, and OkurraButton adopts B1…B5 from the same file (and vice versa). One load is enough — you do not load the same file twice.

7.5 Where the files live: sets, history, working state

Everything the tools save goes into the MQL5/Files/OKU/ directory. From the perspective of everyday work you do not go in there by hand — but it is worth knowing what lives where, because these are three different things:

Four things worth remembering:

1. Only a .set from sets/ reaches the EA. The .ini files in history/ and applied/ are the panels’ internal memory — the robot never reads them (chapter 2.6). One nuance: the EA writes its own preview files to the subfolder applied/viz/ — the companion indicators on the EA’s chart read them (to show what the robot actually sees); this is traffic in the other direction, the EA still loads nothing from applied/ as configuration.
2. The working-state file names carry a chart suffix. The files in applied/ are named B<N>_c<id>_applied.ini / Global_c<id>_applied.ini, where <id> is a shortened chart identifier — thanks to this, two charts of the same instrument do not mix up each other’s design state. Worth remembering when you look for the files by hand.
3. The history (history/) is a safety net. On every Apply the panel appends a copy there. It is not cleaned automatically — the files accumulate, and you delete them manually when you see fit. Thanks to this, you can go back to an earlier design state even if you did not save it as a .set.
4. Reset (R) in the panel does not touch the history. Reset clears the working state (applied/), but history/ remains — so even after a reset you have something to recover the configuration from (chapter 4.8).

7.6 Loading into the EA (F7 → Load)

This is the final step of the bridge: moving the designed configuration into the running robot. It happens in the EA itself, via the standard MetaTrader mechanism — there is nothing Okurra-specific here except that you point to the previously saved .set file.

Step by step:

1. Open the EA configuration window. On the chart with the running (or freshly dropped) EA press F7 — or right-click on the chart → Expert Advisors → Properties. A window opens with the Inputs tab.
2. Click Load (the button at the bottom of the MT5 configuration window).
3. Point to the .set file from OKU/sets/ — the one you saved in the panel (preferably the full one, from OkurraGlobal).
4. Confirm with OK. The EA starts (or restarts) with the loaded configuration — all global settings and all five buttons at once.

A reminder from chapter 2.7. The design panels and the EA work on separate charts. You save the .set file on the design chart (with the panels), and you load it on the execution chart (with the EA). It is a deliberate transfer — the robot changes its configuration only when you load a .set yourself, never “live” from the panel.

.set works both ways. The EA can not only load a .set, but also save its current settings to a .set — with the native Save button in the same F7 window (a MetaTrader standard). Such a file has exactly the same parameter names as a .set from the panels, so you can load it back into OkurraButton/OkurraGlobal (Load), modify it on the design chart and save it as a new .set. Thanks to this, the .set is a fully-fledged, two-way exchange format between the panels and the robot — not just “panel → EA”. (It is still transfer by files, not a live connection — chapter 2.7.)

Sets from before release 1.28 — how they migrate. The new fields (Extreme Mode, Filters Mode, the OKUR bounce rows) take their default values when an old file is loaded, i.e. behavior exactly as before 1.28 — with one exception: if the old set had “Keep Extreme Across Zone Exits” enabled (a field removed in 1.28), that setting migrates only through the panel. Load such a file into OkurraButton (Load) — the panel translates the old key into Extreme Mode = Keep Across Exits — then Apply and Save produce a file in the new format. Loading the old file straight into the EA via F7 silently skips that key and the button falls back to Classic (MetaTrader ignores unknown names without a warning). Chapter 9.6.

7-button sets (from before release 2.00) — how they migrate. The B6_*/B7_* keys are silently skipped on load (like any unknown names), and the B1–B5 strategies from the file work unchanged. One thing is actively tidied up in the process: a trigger target pointing at the former B6/B7 — the EA ignores it and writes a message about the non-existent target to the journal, and the Button panel cleans such a target already when the file is loaded, so it never carries into new saves. Two changed factory defaults (the EA starts with its switch OFF; the Price Movement sensors are factory-disabled) affect sets that do not contain those keys — the full checklist for updating: chapter 3.5.

Iteration. When, after observing on a demo, you want to change the strategy: you go back to the panels, adjust, save a new .set, and load it into the EA (F7 again). The old .set stays in sets/ as an archive — you can come back to it and compare.

7.7 Practice: naming and managing variants

The .set is your research archive — a few habits will make sure that two weeks from now you still know what is what:

• Give descriptive names right at save time. Instead of Button_20260613_142205.set, type something in the save dialog that describes the content: XAUUSD_meanrev_M1_v1, NAS100_momentum_3butt, hedge_symetryczny_test. The name is the first thing you will see in the Load dialog.
• Version manually with a suffix. When you iterate on the same idea, append _v1, _v2, _v3. Do not overwrite the previous version — let it remain as a reference point. This is a “manual history” of variants, more readable than the auto-copies in history/.
• Keep one “full” file per setup. It is most convenient to operate with full files from OkurraGlobal (Global + B1…B5) — one file = the robot’s entire configuration. Leave the “strategies only” files from OkurraButton for deliberate cases (one global set, many button sets).
• Clean up history/ when it grows. The auto-copies from every Apply do not delete themselves. When the folder swells, delete the old ones manually — after all, your important variants are saved as named .set files.
• Note what a given .set was meant to show. The file says how you configured, but not why. A short note (“v3 — deeper threshold, fewer signals, trend test”) alongside the demo observations completes the picture. You can also add your own description to the comment header of the file in a plain text editor — it is pure text, after all.

All of this makes up the work rhythm with O!kurra: design in the indicators → save the .set → load into the EA → observe on a demo → return to designing. The .set file is the axis of this cycle — and your archive of what you have learned.

7.8 The license key and .set files

The EA’s license key (the LicenseKey parameter, chapter 3.7) may — but does not have to — travel in a .set file. It is worth knowing which file carries it and what happens on load:

Which file contains the LicenseKey line:

• A full .set from OkurraGlobal — always contains a LicenseKey= line. The Global panel does not verify the key (the indicators are free) — its key field is only a preview of the value from the most recently loaded file, so in practice the saved line is most often empty.
• A “strategies-only” file from OkurraButton — never contains the key (the global section is not saved).
• The factory sets of releases (Okurra-Defaults-<version>.set) and sets from the Creator — deliberately do not contain the LicenseKey line at all.

What happens on loading via F7 → Load:

• If the file contains a LicenseKey= line (even an empty one), its value overwrites the key field in the EA window. An empty line = the key is cleared — at startup the EA will show the alert “Enter your License key in EA inputs” and will not obtain a valid license.
• If the file does not contain that line, the key field remains untouched — the key you pasted earlier survives the load. That is why the factory and Creator sets omit this line.

Nothing permanent and nothing dangerous. A cleared key is a local inconvenience — just paste it again (the license lives on the okurra.com server, bound to your account). And even if your key “traveled” in a file you shared: the key works only on the MT5 account numbers assigned to it in the okurra.com panel — on someone else’s account it will not pass verification.

A hygiene rule when sharing sets: before you share a file saved from OkurraGlobal, open it in a text editor and remove the LicenseKey=... line (or at least its value). You do not share your key — and you spare the recipient the surprise of their own key being cleared after loading your file.

7.9 The position ownership registry and restarts

A robot running in “own-only” mode (Global_MonitorOwnOnly, chapter 5.5 — the factory behavior) keeps a private notebook of its positions: on every open it writes the position number to a small file on the terminal disk. After a platform restart, an F7 reload or a recompile, the EA reads that notebook back and takes care of exactly the positions it opened itself — a sibling instance on the same symbol is never touched. The notebook is separate for each combination of account + instrument + Magic Number base + chart.

What this means in practice:

• A plain platform restart is safe. The notebook survives; the positions come back under full care (BE/TS, virtual SL/TP, baskets, Close All).
• Pending orders do NOT survive a restart — by design. The pending watch-list lives only in the robot’s memory. After every restart the EA sweeps its own leftover broker pendings so that a stale, no-longer-supervised setup cannot fire days later. Since EA 1.26 you get a notification about it (previously this happened silently — hence the “the robot cut my orders after a restart” reports).
• The orphan position. If a position carrying the robot’s Magic Number is missing from the notebook, an own-only robot does not manage it: no Break Even or Trailing, no virtual SL/TP (with Virtual SL enabled such a position is naked — the stop does not exist at the broker either!), excluded from the BEa basket and the account guards, and Close All will not close it. Where orphans come from:
  • a pending order filled while the platform was off (e.g. a weekend gap) — the notebook entry never had a chance to be written;
  • positions opened in another environment — the built-in MetaTrader VPS does not migrate the robot’s files (the files folder stays on your computer), so the VPS and the local machine keep separate notebooks;
  • more rarely: a netting account or slow broker confirmations recorded a wrong number in the notebook.

New in EA 1.26 — detection and repair:

VPS and a second terminal — one iron rule. On a single account, a given Magic Number base should have one active robot at a time. The built-in MetaTrader VPS enforces this by itself (a chart “moved” to the VPS stops working locally), but remember: the robot’s files do not migrate — after every migration the VPS notebook starts fresh (the first start auto-adopts positions by MN), and the local notebook knows nothing about positions opened on the VPS. After coming back from the VPS you will see orphan alerts — that is exactly this mechanism at work; switch reconcile to Adopt (or use the one-shot Global_OwnOnly_AdoptExisting) and the robot takes them back.

Magic Number 0. Setting Global_MagicBase=0 makes the first button trade with MN = 0 — the same value manually opened positions carry (reports then show an empty magic column). The robot and the human become indistinguishable. Since 1.26 the EA warns loudly about this; keep the base ≥ 1, with at least 5 between instances.

This closes the designing part (chapters 4–7). In the next chapter we move to execution — starting with the full anatomy of the EA control panel: what you see on the chart after loading the configuration and starting the robot, and how to steer it tactically during operation.