DOCUMENTATION

Builds and installs

Build and load failures that looked like something else: a build that reported success and built nothing, a plugin that would not load in a Blueprint-only project, a Blender add-on that was not the code on disk. Read it if you compile the plugin, or if an install behaves like an older version than the one you put there.

For the first checks on any install, run verify_install.py as described in Troubleshooting. For setup, see Installation.

A build that exits 0 and builds nothing

What you see. A plugin rebuild finishes with exit code 0 and no error, and the plugin behaves exactly as before. The build output shows:

Total execution time: 0.44 seconds
Unable to find project '<EngineDir>\Engine\Source\"<ProjectDir>\<Project>.uproject"'.

What is happening. The quotes meant to protect the project path survived inside the argument, so the build tool looked for a project with literal quote characters in its path, found none, and exited 0 anyway. A call to a new endpoint then answers "unknown endpoint", and it gets debugged as a binding problem when no build ever ran.

What to do.

  • Do not quote the -Project= path when it contains no spaces. If it does contain spaces, check the log for a "Total execution time" of more than a second or two and for Compile and Link lines. A real incremental link takes tens of seconds.
  • Never branch on the exit code. A build can print Result: Failed (OtherCompilationError) and still exit 0. Search the log for Result: Failed and for error.
  • Note the plugin DLL's modified time before you build and check that it moved afterward. Moving is necessary but not sufficient: also check that nothing else moved (see the next section).
  • Do not use the "built" date string the bridge reports as evidence that your change is live. It is compiled into one source file, and a build that recompiles only the changed files can leave it showing the previous build's date. To be sure a change is in the DLL, search the binary for a string from the change. UE string literals are stored as UTF-16, so search for the wide encoding:
python -c "raw=open('Binaries/Win64/UnrealEditor-MifBridge.dll','rb').read(); print('the text from your change'.encode('utf-16-le') in raw)"

A probe build for one engine overwrote the DLL for another

What you see. After building the plugin against UE 5.7 in a scratch project, the plugin's own Binaries/Win64 DLL has changed size and date, and the next start of the 5.3 editor cannot load the plugin at all. The build said it succeeded. It was caught by looking, because the 5.3 editor happened to be closed. If it had been open, the DLL would have been locked and the build would have failed with a plain file-write error.

What is happening. The scratch project linked the whole plugin folder rather than just its source. Build tools write binaries and intermediate files into the plugin folder, and through a folder link that is the original folder. A module compiled for 5.7 cannot load in 5.3.

What to do. If you build for more than one engine, build each engine in a project of its own, and link or copy only the Source folder (and copy the descriptor file) into each. Let each project keep its own Binaries and Intermediate. A folder link goes both ways: link the narrowest thing that does the job, and ask what a build writes, not only what it reads.

The plugin refused to load in a Blueprint-only project (UE 5.6 and later)

What you see. In a project with no C++ code, the editor says "Plugin 'MifBridge' failed to load because module 'MifBridge' could not be loaded." The log names what the operating system loader could not find: UnrealEditor-MetaHumanCharacterEditor.dll and UnrealEditor-MetaHumanCharacter.dll.

What is happening. On UE 5.6 and later the plugin linked the MetaHuman Creator modules directly, while declaring that plugin optional. A plugin's binaries directory joins the loader's search path only when the plugin is enabled, and from UE 5.4 the plugin manager honors an optional reference only if the build's target receipt lists that plugin. A C++ project has its own receipt, where the build tool records the optional plugins it finds, so it loads. A Blueprint-only project reads the engine's receipt, which lists no MetaHuman modules on 5.6, 5.7 and 5.8. The failure appears before any MifBridge code runs.

What to do. If you hit this on a build from before the fix, enable the MetaHuman Creator plugin in the project and restart the editor. Do not conclude that a plugin loads everywhere because it loads in a C++ project: that is the case that hides the problem.

Does the current build protect you. Yes. The two MetaHuman modules are delay-loaded, which means the loader binds them only when first used. The two MetaHuman endpoints check that the module is loaded first, and refuse by name when the project has not enabled MetaHuman Creator. Declaring the plugin required instead would have force-enabled it everywhere: on one clean project that added about 30 more engine plugins and 29 more startup warnings on UE 5.7, and it would have stopped the plugin loading at all on 5.3 to 5.5, where MetaHuman Creator does not exist. A Blueprint-only UE 5.7 or 5.8 project that enables only MifBridge loads it and answers, and with MetaHuman Creator enabled the MetaHuman endpoints work.

The related rule for anything optional: a type from a delay-loaded plugin is a call into that plugin as soon as it is declared. See Editor crashes.

The Blender add-on was not the copy on disk

What you see. Operations you know are in the add-on are "not there" in Blender, or a fix does not take effect. Syncing the files makes the symptom go away, and it comes back days later.

What is happening. Blender loads an add-on from its own add-ons folder, not from where you edited it. On one machine there were four installs, every module stale in all of them and three about six days behind. Two faults hid each other: the version the add-on reported is a fixed value that does not change when a module's behavior changes, and the list of modules to hot-reload was a hand-kept list that had missed six modules, 40 operations among them. An edit to one of those survived a re-enable as old bytecode.

What to do. Compare where the running package was loaded from with what is on disk now. Two different problems look the same from Blender's side: the wrong copy needs reinstalling, and the right copy edited after startup needs a restart.

Does the current build protect you. Yes. ping returns three separate facts: addonPath (where the running package was loaded from), sourceHash (what is on disk there now) and sourceHashAtImport (what was there at startup), plus sourceChangedSinceStart. That last field is empty, not false, when the sources cannot be read. The reload list is read from the directory. verify_install.py reports an add-on whose files do not match the release, or a second copy that Blender also loads. See Troubleshooting.

A leftover Blender process answering as a fresh one

What you see. A check against what you believe is a fresh scene fails in a way that looks like a bug: for example, an operation that should refuse because the mesh is a closed cube instead succeeds, because the mesh already has open edges.

What is happening. Whatever process already listens on the add-on's port answers. A Blender instance started the day before, and used since, was answering as though it were a factory-startup scene.

What to do. Before concluding anything is broken, read the process id that ping returns and check when that process started. Restart Blender, or start a headless one with --background --factory-startup, and run the check again. See Blender modeling.