I noticed some scenarii where Blueprints are marked as “changed” whereas nothing was done directly on them. It is particularly annoying when working with Perforce because even when everyone pays attention not to modify anything on other’s Blueprints, they are still marked as “changed” and cannot be reverted without restarting the Editor.
There are these scenarii :
When opening a Blueprint without doing any changes (to check its content, for example)
When modifying a Blueprint A referenced in a Blueprint B, the Blueprint B is marked as “changed”
When modifying a mother class Blueprint, all the children Blueprints are marked as “changed”
May be I’m not using the Editor properly to work with Perforce, I don’t know, I’m pretty new to both the Editor and Perforce. But if this is really an issue, resolving it would greatly enhance the team workflow with Blueprints.
The scenarios that you explained above are the intended behavior. This is the same thing we experience in-house everyday.
If a blueprint is effected in any way (parent/child, referencing) then they will be marked as changed because they technically are. This also happens the same way if you are using code instead of blueprints.
Hopefully once it’s understood that this is going to happen, it can be planned for and your team can workaround the issue.
This has been plaguing me for a while as well and its interesting to hear that this is intended behaviour. ( although it does make logical sense if the other blueprints are actually changed, though in most cases diff-ing the assets show no actual changes using the blueprint diff tool)
Thanks for your answer, but I still don’t understand…
When you are using code, if you open a class without changing anything, the file is not marked as changed.
When you are using code, if you modify a class referenced in another one, this last class file is not marked as changed.
When you are using code, if you change a mother class, the children class files are not marked as changed, even though obviously their behaviour are modified.
What I’m waiting from the BP system is to behave like if I was coding. Because even if I am aware that a guy in the team is working on a BP, how can I check its content, how it works etc, without opening it and thus marked it as changed ?
And what is bugging me even more is the fact that if I close the editor with BPs marked as changed for one if the reason explained above and without saving anything (reverting eventual changes made to this BPs) and the open the editor again, everything will work fine. So I wonder “what are those changes that made the editor mark my BPs as changed ?”
Opening blueprints to check content marking blueprints dirty was a bug and has now been fixed - there was no reason opening a blueprint without modification should trigger anything to be dirtied.
It’s true blueprints don’t interact with source control in the same way native code does and we are aware of the issues with source control. Some work has recently been completed to try and minimize how aggressively dependencies are dirtied and was committed in changelist 2266069 on the 28th August. I don’t expect that this will completely eradicate the issues, but other efforts are being made to try and improve workflow with source control and blueprints such as the merge tool.
If you find once you have these changes that you still see instances you are sure are errant with blueprints being dirtied please report the issues and we will look into them.