Module Core

Core

MCF_Core. The shared layer every other module runs on. It adds no gameplay by itself, and you never load it alone on purpose — you load it because something else needs it.

If you are building a mission you will barely touch this page. It matters when something is not saving, a screen is not drawing, or you want to know what the self test is telling you.

In the Workbench

Nothing to place

Load MCF and Core starts, on whatever game mode your mission uses — the vanilla Game Master one, Conflict, Combat Ops, or somebody else's modded game mode. There is no Core node in the entity browser and nothing to drag into a world.

It works through a modded SCR_BaseGameMode rather than a prefab override, so it does not fight with other mods that touch the same game mode. Intelligence and Dialogue attach the same way.

One piece cannot work like that: the tick source has to be driven by frames, and frames need an entity. Core spawns a small systems entity for it — unless your game mode already carries a tick manager, in which case it leaves yours alone. You will see one of these two lines in the log:

[MCF] MCF systems entity spawned -- tick source and game loop are up
[MCF] tick source already on the game mode -- not spawning MCF's own

followed, once it is actually ticking, by:

[MCF] tick running -- critical every 0.5s, cosmetic every 5s

Settings, if you want them

MCF_Core_GameModeComponent is optional and exists only to change Core's three start-up settings for one mission: the AAR manager, hostility decay and its rate. Add it to your game mode entity if you need those; otherwise leave it off. The same goes for MCF_Ops_GameModeComponent, which only turns the sample taskings on.

What it provides

Persistent storage. A key-value store written to $profile: through FileIO, deliberately outside the engine's world and session saves. A mod update or a world reload cannot wipe it. Every module keeps its own namespace inside it.

This is why taskings and intel survive a server restart.

Screens on world objects. A surface-and-view split that puts a real, interactive UI layout onto a prop — a board, a monitor, a sheet of paper. The widget tree is built when a player comes close and torn down when the last one walks away.

The same view code runs on a prop and in a menu. That is how the laptop desktop appears both on the object in the world and full screen when you open it.

The event layer. Publish and subscribe by name. Every publisher and subscriber registers itself at init, so a chain that can never fire gets reported at startup instead of being discovered in a session. See event wiring, once Objectives ships.

Tick and budget management. Critical and cosmetic work run on separate intervals, so a mission with a lot of scripted props does not spend its frame on things nobody is looking at.

Roles. The rank and role resolution that the tasking permissions use.

Logging. One switch, one prefix. Warnings and errors ignore the switch, so turning the trace off still leaves you the things that are actually wrong.

MCF_Core_Log.SetEnabled(false);

In Game Master

Screen tuning

Every MCF object that draws a screen picks up five rows in the properties panel:

Setting	What it does
Read range	How close before the screen becomes readable
Fade distance	Where it starts fading out
Refresh rate	How often it redraws
Sharpness	Render resolution of the surface
Object size	How big the object itself is, 25 % to 600 %

Turn the refresh rate down on anything that is not changing. A board full of static text does not need to redraw every frame.

Object size is the odd one out: it changes the object rather than the picture on it. A board on a table and a board covering a briefing wall are the same prop at two settings, and 100 % is the model's own size. The collision is rescaled with it, so a large one is still something you walk around rather than through — worth checking when you make one very big, because a board you can stand inside is a board somebody will stand inside.

Mission data

Right-click the operations board and choose Mission data. That screen is Core's data set registry made visible: each module registers what it stores, and the screen lists it with real counts from the server.

Full description on the Intelligence page, since that is where you reach it from.

The self test

MCF carries a test suite that runs inside a live session with real connected players. That is deliberate — the faults worth catching in Enfusion are replication faults, and those do not reproduce in a single-player editor.

It arms itself when the mission starts and waits for two players on two factions:

[MCF] SELFTEST armed -- waiting for 2 player(s)
[MCF] SELFTEST start -- 2 player(s): 1 (US), 2 (USSR), 11 check(s)
[MCF] SELFTEST faction-intel: PASS -- player 2 (US) was sent only its own
      faction's records, and is shown them
[MCF] SELFTEST done -- 16 passed, 1 failed

Each check says what it measured and, on failure, what it would have cost a player. A check that cannot apply — because a needed system is not in the world — skips rather than failing.

To run it: start the mission, connect a second peer with the Peer Tool, put the two on different factions, and read the log. See the development wiki.

Known gaps

• Role resolution is correct and has never refused anything, because the everyone-may-do-everything switch was on for most of development. It is off now and wants a session with real ranks.