From version 4.12 unreal start to as modified a lot of files, which where not changed or edited. Even opening an closing project leaves some files in changed state and unreal engine propose to save them.
That is quite annoying when work in team. Team members do not know which files they need to commit, which files to merge, and saving some big assets makes repository grow very fast.
Can epics do something to this?
Hello ,
Could you be more specific as to what kind of assets are becoming marked as changed, in what scenario, and what the makeup of these files are? Please ensure that they’re not referring to other files that may be getting changed, which would them as being changed as well. There was a bug put in recently for levels becoming dirty when using the Launch option from the editor while connected to source control but that is the only instance I’ve seen of this issue, and from testing it didn’t occur in 4.12. You can find that bug report here: UE-36250
Hi Matthew,
It looks like compiling blueprint marks that blueprint dirty.
Setting breakpoints in blueprint marks that blueprint dirty.
If some blueprint is marked dirty, than blueprints referencing that blueprint are marked dirty.
Otherwise it is hard to explain that setting breakpoint and removing some objects on level (that two assets) - and ue wants me to save 13 assets, some of which are even UI widgets. 
Even just opening some blueprint like GameInstance which can be referenced by a lot of, pressing compile and save there without any changes - and a lot of assets now want to save in project as well.
I don’t know if this was done by design, but compiling parent BP causes to save all child BP’s. There is a logic in that, but sometimes there is a lot of child BP’s
As mentions, if these extra saved BPs are children of the one you compiled and saved, then it’s expected that they would become dirty and require saving.
To make sure we mean the same thing when we say “dirty”, you mention that compiling a blueprint makes it dirty. Do you mean that the blueprint is then marked with an asterisk in the Content Browser and needs to be saved, or that it is then checked out and needs to be submitted? If it’s the former, does it happen with all blueprints? If not, what is the setup of one of the affected blueprints? If it’s the latter, this is expected as you’re forcing a save on the asset, as I assume you have Compile & Save on, which will prompt it for a checkout.
Hi Matt,
Sorry, compiling blueprint does not make it dirty, but setting a breakpoint do - blueprint became marked with asterisk. Breakpoints are something user specific and should not affect blueprints I believe.
Unfortunately it doesn’t work this way. Even Visual Studio requires a certain type of saving to add breakpoints but it just doesn’t include the file itself (Breakpoints for VS are stored within the .vs directory in the project, inside of the .suo folder) and they are just automatically saved upon closing Visual Studio. This is more data being added to the blueprints which needs to be kept intact so the file needs to be saved.
If you’re putting the breakpoints in for your own debugging purposes and don’t need to keep them there, you can feel free to use the source control menu’s option to revert the changes made to the file instead of saving it, so that it isn’t part of your commit.
Prove me wrong, Matt, but I don’t see why Epic’s cannot do the same - store breakpoint information in separate files parallel of main blueprint assets.
Your solution have two drawbacks - first I need to remember which files I set breakpoints and which I changed logic.
Second is I need to loose all breakpoint setup whenever I want to commit code to source control.
And third - usually I save assets before running the game in editor (other people do that too I think) If some breakpoint saving will trigger resaving other assets then situation is hardly manageable.
Unfortunately it isn’t a very simple process to separate these two things. I’ve placed a feature request in for the issue as after speaking with the developers involved in this field, they mentioned that this is the current intended functionality. I’m not sure when they’ll get around to it but you should be able to track the progress there.
As for checking in your breakpoints, there is something already in place for that. If you check in a blueprint with activated breakpoints, they will be deactivated whenever someone syncs to that blueprint, although not deleted. I would also suggest the use of Developers folders for assets that you’re actively working with, as it would be easier to keep it separate from things that other people need to be syncing.
Thanks, Matt, hope to see this feature soon. Actually breakpoint setup should be stored in developer folders I think. For now they are hardly used at all.
And breakpoints are only part of the problem, there are a lot of user specific data which is saved to shared assets - like level lock and visibility setting, anim blueprint preview parameters and many other setting I think.
Also I was asking long ago if it is possible to store lightmaps and level scripts in separate files form levels, maybe landscapes can be separated too. So that is some broader task of storing assets in multiple files. It would be cool if this feature would be implemented in near future. It will ease team work on assets. And make possible merge of level scripts. For now I know we can store level blueprints in separate actors, but that is not very convenient and defeats the idea of having level blueprints at all.
Hi Matthew, I think I found one reason why some blueprints are invalidated - looks like if in one blueprint you have Spawn Actor or Create Widget node with some other blueprint set as class, than this blueprint is invalidated when dependent blueprint is changed.
It makes logic if you have changed Expose on spawn fields or Blueprints interface, but if not… It must be not easy to implement this, but some check should be done if changing one blueprint really changes dependent blueprints or not, to minimize that blueprint savings.