[4.13.1] Derived Data Assets disappear after unrelated crash

Development Programming & Scripting
1

Build 4.13.1 Source

Steps

  1. Create a C++ Data Asset (UVehicleConfig)
  2. Create another C++ Data Asset (UVehicleUniformConfig)
  3. Add UPROPERTY reference in UVehicleConfig to UVehicleUniformConfig (so Vehicle configs can reference Uniform configs)
  4. Create Derived Data Assets in Editor: one VehicleConfig and one VehicleUniformConfig
  5. Reference the latter config asset in the former
  6. Add UVehicleConfig reference in AVehiclePawn header. In AVehiclePawn constructor, find and assign the VehicleConfig derived asset created in (4).
  7. Make code changes and perform hot reloads, perhaps with one or both of the derived data assets open
  8. Crash the editor, either through a crash on hot reload or a specific fatal gameplay error
  9. Fix crash, compile, and restart editor. One or more data assets will have disappeared.

Context

Previously I had most pawn code in C++ and some spread out in blueprints. This was messy, and with a recent engine upgrade became completely unstable (the blueprint pawn vehicle movement component was entirely disregarded after the first hot reload since reopening the editor). I have wanted to move to a “gameplay functionality in C++, declarative configuration data in data assets” approach anyway, but this is also proving unstable due to the data assets spontaneously disappearing.

I’m happy to supply my entire project if it helps with debugging. Please let me know. Thanks!

2

Hey piinecone,

After testing the issue, I was able to reproduce one of the data assets disappearing after performing a debug crash as the final step. However, what I did notice was that you are creating a circular dependency when you are referencing each of the data assets in each other. I believe that this is the cause of the issue that you’re seeing when your data asset is disappearing, as when I did not reference one of the assets inside of the other’s class, I did not see them disappear.

As a result, I do not believe that this is a bug, as I believe the circular dependency that was created is the culprit when it comes to this issue.

Let me know if you have any further questions or if you believe that I’m misunderstanding the issue and I’ll be glad to continue investigating.

Have a great day

3

Hey @Sean Flint, thanks for looking into this!

I don’t believe there is a circular dependency. The hierarchy should be:

UniformConfig.Color = "red"
VehicleConfig.Uniform = UniformConfig
VehiclePawn.Config = VehicleConfig

The pawn references the “pawn config”, which itself references a “uniform config”. None of the assets should contain a circular reference, in this case.

Let me know if you’d like me to supply my project. I would have to do so privately, but otherwise I don’t mind.

4

No problem, glad to help.

Okay, it’s possible I’m misunderstanding the issue then. If you have the project, you can zip it up and PM me a link to download it from Dropbox or Google Drive through the forums: https://forums.unrealengine.com/member.php?160394-Sean-Flint

5

Hi @Sean Flint,

I’ll zip everything up today and upload it, although I doubt there’s anything specific to my project causing this issue. I think if you work with a set of derived data assets long enough, you’ll eventually encounter some corruption.

This can happen without a crash. For example, I committed my work and shut everything down the other day. Upon reopening the project, a config asset is now unavailable in the content browser. Moving .uasset files from the saved/backup dir also does not work; they never appear, even after deleting the cache.

Perhaps I am the only person experiencing data asset corruption but that seems unlikely to me given how basic my usage is.

Would it help to include the corrupt assets?

6

I should add that it seems essential to perform hotreloads. I will occasionally change a header file, adding a blueprint exposed property to a config data asset base class, and hotreload. I don’t necessarily intend to do this because hotreload does not tend to handle header file changes well, but it does happen, and I do think it’s a bug that the downside is possible uasset corruption.

7

Yeah if you could also separately include the corrupted assets that might be helpful as well.

Let me know when you get the project sent and I’ll begin looking into it.

Thanks!

8

I have exactly the same problem. No circular dependency in my code though. Any news?

1 Like
9

Unfortunately, we have been unable to reproduce this issue locally. If you have a new set of repro steps that we can use in a clean project or a simplified test project that clearly showcases the issue, please provide those and I will be more than happy to take a look.

Thanks