Skip to main content

Frequently asked questions

Does it modify my original project?​

UEAPM changes the project it runs on, in place. That is why the project must be a copy or be under version control. Every modified file is also backed up once to Saved/UEAPM/Backup/, but keep the original 4.27 project untouched: it is your real safety net. With -target, the changes go to the target project, never to the host.

Is Cascade still supported?​

Yes. Cascade still runs in UE 5.8, which is why UEAPM keeps the original particle systems and only reports (as a Warning) the references it cannot replace. The converted Niagara systems sit next to them as <Name>_Converted. Moving to Niagara is still recommended: Cascade receives no new features.

Why is Enhanced Input opt-in?​

The legacy input system still works in 5.8, and switching changes how input is processed at runtime (triggers, modifiers, mapping contexts, and C++ bindings that UEAPM only reports). It is a design decision for your project, so the input step runs only when you select it.

What if a step says restart required?​

The step enabled an engine plugin (for example Chaos Vehicles), which loads only after a restart. The runner stops before the next step. Restart the editor and run again: finished steps find nothing left to do and the migration continues. In the commandlet this is exit code 2.

Can I rerun it?​

Yes, as often as you want. Every step is idempotent, and every run adds a copy of its report to Saved/UEAPM/History/. A typical loop is: run, fix the open items by hand, run again, check the report is clean.

What about third-party marketplace plugins?​

UEAPM does not migrate other plugins. Enabled plugins that 5.8 does not know are listed in the report by the project step; install their 5.8 versions from Fab or their vendor. Content and Blueprints of your own project that use those plugins are handled like any other asset once the plugin is present.

What if my C++ does not build after the cpp step?​

  1. Check the C++ source section of the report: report-only rules list each match with file:line and a suggestion (for example PhysX or Matinee code that needs a human decision).
  2. Fix the remaining errors from the compiler output; they are usually API changes specific to your code.
  3. Build again with the command in the report's Notes, then continue with the remaining steps.

You can rerun the cpp step at any time: it only touches lines that still match a rule.

Mobile projects, Lumen, Nanite and Virtual Shadow Maps​

  • For projects that target mobile hardware, the rendering step writes explicit values that keep Lumen global illumination and reflections and Virtual Shadow Maps off, and the project step raises the Android and iOS minimums to the 5.8 ones.
  • For desktop projects, UEAPM does not turn on Lumen, Nanite or Virtual Shadow Maps. Your 4.27 lighting setup is kept; enabling the UE5 features is a separate, per-project decision.
  • Nanite is never enabled on meshes automatically.

Vehicles: what carries over?​

4-wheel PhysX vehicles are converted to Chaos: the vehicle and wheel Blueprints are re-parented to WheeledVehiclePawn and ChaosVehicleWheel, and the mapped parameters carry over: mass, drag, chassis, input rates, torque curve and max torque, RPM, moment of inertia, gears, reverse, shift RPMs, differential, steering curve, wheel setups, and per-wheel radius, width, mass, steering, brakes, suspension travel and axle flags. Nodes that used the old classes are retargeted.

Tuning parameters without a Chaos equivalent are listed in the report. Chaos vehicles do not drive exactly like PhysX ones: expect to retune handling. TireConfig assets, simple (non-mechanical) vehicles and DestructibleMesh assets are reported with their Chaos equivalents.