4.18.1 Nativazation issue

Hello,
I upgraded my project to 4.18.1 and when i try to package it, i get this error on all my nativized BP’s.

UATHelper: Packaging (Xbox One): D:\4.18.1\SPARTAN\Intermediate\Plugins\NativizedAssets\XboxOne\Game\Source\NativizedAssets\Private\Wind_Blow_RIGHT_BP__pf1396773228.cpp(2535): error C2440: ‘’: cannot convert from ‘initializer list’ to ‘FBlueprintDependencyData’
UATHelper: Packaging (Xbox One): D:\4.18.1\SPARTAN\Intermediate\Plugins\NativizedAssets\XboxOne\Game\Source\NativizedAssets\Private\Wind_Blow_RIGHT_BP__pf1396773228.cpp(2535): note: No constructor could take the source type, or constructor overload resolution was ambiguous

Up until 4.17 i could package my game with no issues.

Thank you.

Second this. Though mine is 4.18. No clue how to fix it.

Hello ,

I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

  1. Can you reproduce this issue in a clean project?
  2. If so, could you provide a detailed list of steps to reproduce this issue on our end?
  3. Could you provide screen shots of any settings/blueprints that may be involved with this issue?

I have the same problem and I can’t reproduce it in a clean project, what I have is a project that’s been in development for half a year. Is there a way you could have a look at it if I email it to you?

I’m getting the same error when building for Windows x64 across all BP’s I’m trying to nativize. The project will build without nativization, but gets this error on attempting a nativized build. (The error will also re-appear even if I disable nativization under Project Settings > Packaging again; it appears to re-attempt compiling nativized BP’s anyway.)

I can’t reproduce this issue in a clean/new project yet. The issue seems to occur on every BP I have in the project.

My best guess is that something in the cpp BP nativization changed data type on how it gets the BP dependencies (as the error message implies) when going to 4.18. This could be how the new “Find in Blueprints” feature works; by using the FBlueprintDependencyData type instead of initialization list, but perhaps this change somehow isn’t propagating to older projects that were upgraded to 4.18. I don’t know much about how BP nativization works under the hood though. If there’s a way to update 4.17 and older BP’s to sort this out, that seems like it could fix the issue. Or perhaps the issue is related to the nativization compiler?

Perhaps I’ll have to test in a blank project from 4.17 and upgrade it to 4.18.

I’m getting the same error when I try to nativize and package. If I remember correctly, the project nativized fine on 4.18 but doesn’t want to nativize in 4.18.1.

Hello drb1992,

Are you able to reproduce this issue in a clean project? If so, could you provide a detailed list of steps to reproduce this issue on our end?

This is a shot in the dark, but what happens if you disable the Event Driven Loader? I’m on 4.17 but I’ve noticed a LOT of strange conflicts between the two systems

That is it. I had disabled EDL as it was causing random crashes on startup. I re-enabled it and now the project successfully nativizes, so I guess I need to figure out how to fix the EDL crash (other than disabling it) if I want to nativize my project.

I just enabled EDL and created a new Xbox One build, and it doesn’t seem to be crashing at all in 4.18. It compiled the nativzed blueprints and runs fine. No freezes or crashes and I played about an hour of my game. Though might be different for everyone, these were just my results with EDL enabled.

AHHHHHHHHHHHHHHHHHHH

that’s scary. makes me want to delay in updating to 4.18 since I’m already settled into my 4.17 workarounds… we need definitive fixes for these two systems, badly

EDIT: I have EDL disabled for that same reason on 4.17. I’m in a discussion about it and it was suggested that I try 4.18 but I’m putting it off for obvious reasons. Were you having EDL related crashes in 4.18?

whatever your event driven loader setting is, try the opposite

that is comforting, but my issue was on random PC’s. None of my 3 were affected, just a few customers. It seems to be somehow related to the user’s PC build

I’ve resolved this issue! I just had to migrate everything to a new project. Following is the process I had to use; your mileage will vary especially since my project still doesn’t contain any of my own C++ code yet. (Everything is Blueprint!) In addition, not everything necessarily has to be done in this order, since the engine is more tolerant of missing items and errors these days.

  • Copy configs: InputActions and Collisions. Rather than directly copying, I only copied the portions I needed.

  • Set your basic, most crucial settings i.e. disable auto-save, auto-exposure, etc. if that’s what you do.

  • Enable any plugins you were using. I need Apex destruction for the DestructibleMesh.

  • Replace the entire content folder with what you had. Clean out any default/starter content if needed.

  • Fiddle around, get the shaders compiled, etc. All I had to do was let shaders recompile and export a build under inclusive BP nativization. (My project has no built lighting at the moment.)

The project has a history dating back to 4.16, so it’s about time I did this and cleaned things up! It must not have been updated properly during one of the version transitions.

Wow, this is pretty bad news really but thanks for the tip

For simple BP-only projects, it’s been very straightforward so far. For C++, I don’t know the details. I just discovered this morning that 4.17 made some major changes to the headers in order to speed up compile times, details of which can be found here. https://docs.unrealengine.com/latest/INT/Programming/UnrealBuildSystem/IWYUReferenceGuide/

I suspect the new IWYU changes might be related to the BP nativization problems I had earlier.

I suppose I really need to review the release notes in more detail whenever I upgrade. That said, at least it seems like BP-only projects are quite portable, and so far, all of my game functionality only requires BP. I’ll probably only touch C++ when I get to the performance profiling stage and find issues.

Best of luck!

Hello ,

I have ran a few tests on our end with the information provided on this thread. However, I have been unable to reproduce this issue. I will be closing this thread for tracking purposes. If at any point someone has more information on how to reproduce this issue in a clean project please let use know and I will be happy to assist further. All you need to do to reopen the thread is to post a reply with the information needed.

Thanks,

I’m in the same boat with this. I have tried to port my BPs to a clean project to test but it won’t repro. Is there a way I could send my project to Epic for testing?

Are you just ignoring our requests to send you a project to look at? Is there a better path here to get action on this issue? I have no way to reasonably try and recreate the issue in a clean project because I don’t know what is causing it. I just receive C++ compiler error messages that are not actionable.

I came across this problem today (never seen this before).

It was caused by bad calls to ConstructorHelpers::FObjectFinder<> inside class constructors.

  • people are casting UObjects on FObjectFinder with missing header include while developing with IWYU enabled *