WHAT
Blueprints has unlocked the power of programming to designers and artists the world over. As you learn to use Blueprints and create more complex systems, you can run into some common challenges. During this week’s stream, Tom Shannon and Victor Brodin will demonstrate how using concepts such as inheritance and base classes unlocks the true potential of Blueprints.
At a high level the most important distinction is between loaded assets and unloaded assets. When a blueprint is loaded we will not automatically load its child types, but we will automatically load every blueprint that said blueprint references and that may include some or all of its child blueprints. For example, if a blueprint has a cast node in it then when said blueprint is loaded the type of blueprint in the cast will also be loaded. The loaded set of blueprints also tends to only grow - the editor does not typically unload assets. That means if you open a map that references all your child types then they will all be loaded.
With an understanding of the load set we can now begin to dissect what happens when we make a change. Here’s a specific example: removing a component from an actor blueprint.
Operation begins in SSCSEditor::OnDeleteNodes and results in expected mutation of object graph in the asset that you’re editing
Later in SSCSEditor::RemoveComponentNode we get all loaded child blueprints and also remove the copy of the component in them - this is done because otherwise loaded children would still have the copy of the component they instantiated.
Much later, if some other child is loaded we remove their deleted inherited components in a special postload step
I’m walking a line here between specifics and simplicity, so feel free to ask for further details.
In this case it seems likely that the ones that ‘didn’t require saving’ were correct because they were not loaded, but it’s also possible something went deeply wrong in property propagation logic.
This complexity means that what assets are loaded is often very critical to finding a repro for a bug. In the long term we hope to further simplify the loading code so I’m confident that we will trend towards greater stability, but that’s no reason not to fix issues for which we’ve nailed down a repro. Keep your eyes peeled.
You could write a routine to find them, but there is no way to distinguish between legitimate user changed values and values that have been unintentionally stomped or failed to propagate.
Work on a text format for uassets is ongoing. You can enable the experimental support (TextAssetFormatSupport in experimental settings) and then right click on a blueprint and select export to text asset (don’t recall the exact phrasing). Your .uasset will become a .utextasset and you’ll be able to open it in notepad or whatever text editor you use. You’ll see significant amounts of binary data that has simply been converted to base64, but other parts of your blueprint will be quite comprehensible.
We hope to begin using text assets internally in production (rather than in engine test environments) very soon. Just to emphasize: at this time I would not recommend exporting all your blueprints to text assets and working that way - you would be the first person in the world to do so and would likely find some pretty rough bugs! It is a useful tool to audit the editor, though!
