I found that clicking the “Save” button for an asset changes its file even if no actual changes have been made to the asset. For example, open a project in the editor with a the typical view of the map. Look at the size of the corresponding .umap file in the OS. Now click the “Save” button in the map window. The file timestamp and size are changed. Keep clicking while doing nothing else and the file keeps changing. Note that clicking File->Save All only changes files on disk that have actually been modified in the editor which is exactly what you would expect to happen.
This is a problem because source control thinks changes have been made to an asset even when there are none. For my simple example of the map using the FirstPerson template, source control wants to check in a new 20 MB file that hasn’t really changed at all. It also results in files being added to changelists that have nothing to do with changes that have actually been made thus confusing the source control narrative.
I can’t believe I am the first person to notice this but I haven’t been able to find a single mention anywhere. Did I miss something?
Does this only happen with .umap files and only when using the Save button on the toolbar above the viewport (in the default layout)? If so, this save button is only for the current level and is a way of forcing a save, no matter if changes have been made or not. If you wish to save without saving the level, it would be best to use the other options.
The same situation can occur when using the Save button inside of the Blueprint editor. Clicking this button is a way of telling the editor that you’d like to save this asset, despite if there are any changes.
Also, what kind of source control are you using? When using perforce, if I don’t have the .umap checked out, it’ll ask me if I wish to either check the .umap out or make it writable when I go to save it instead of automatically checking it out as it seems to be doing in your situation.
I have tried maps, meshes, skeletons and physics assets and the behavior is the same. If I click the Save button on the toolbar in the editor associated with the asset, the file changes on disk even though I have not made any changes to the asset itself (as indicated by the absence of an asterisk next to the asset’s name).
I am using Git for source control at the moment but that is somewhat irrelevant. I shouldn’t have to rely on the source control system to protect me from the Unreal Editor creating phantom revisions. I can understand having the ability to force a save but if the asset has not changed, the file after the forced save should be identical to what is was before.
Our organization is evaluating Unreal at the moment and one of the things we are trying to figure out is what our workflow would look like. As it stands, it seems that the advice we would have to give artists, designers, etc. is to:
Avoid using Save buttons at all. Use File->Save All instead. (Of course that may result in saving files that have what are meant to be temporary changes.)
If you want to save a specific asset, double check to make sure there is an asterisk next to its name before clicking Save.
Try to remember what assets you have actually changed and make sure you revert any phantom changes before committing to source control.
Good luck if changes to one asset propagate to another asset. (I am not familiar enough with Unreal to know if that ever happens but I can think of several cases where it could.)
Be aware that source control changelists may not accurately represent the changes meant to be captured by the commit.
Buy extra drives for servers to store what are basically duplicate copies of assets.
I understand your frustration, but the average workflow couldn’t possibly result in changes to files that you don’t intend unless you’re being reckless and making massive commits, which at that time it would be time consuming to find out what you want to omit.
When using source control, I’ll leave all assets checked in unless I wish to edit them. When they are edited and I’m ready to save my changes, I’ll use save all and let all of those changes save and checkout anything else that I may have missed if I believe it may be relevant. When going to do my checkin, I’ll look through the list of assets that are about to be submitted. This is the point at which you would cull the assets that are not relevant to the change and leave them out of the commit.
To answer your specific concerns:
The specific save buttons, as previously stated, are for direct and forced saving, so that even if something hasn’t been changed in the editor, you can save it. This causing the asset to be updated according to source control isn’t something specific to the Unreal Editor as this is how Windows works. The asset’s date modified will be updated and the Source Control program will pick up on that.
If you would like to save a specific asset, you can right-click said asset in the Content Browser and select Save. Please keep in mind that this is also a forced save option and will require checkout despite any changes.
The assets that are being submitted will be shown in a list when the commit is made, during the point where you enter your comment (assuming you’re selecting Submit to Source Control from inside of the engine). This will allow you to check/uncheck any files you wish to include/exclude from this particular commit. You can revert any changes afterwards.
I’m assuming you’re talking about assets that reference one another; If you edit asset A which is being referenced by asset B, both will need to be saved and submitted.
If the correct assets were selected as mentioned in #3 and an appropriate comment has been added for the commit, this shouldn’t be a concern.
I can’t speak for your server space, but there shouldn’t be any unnecessary duplicates if there are no unnecessary changes submitted.
The point of my original post is that forced, asset specific saves (using either the Save button of the Content Browser context menu) work against effective use of source control. I would call that a bug. Many of the steps you describe in the “average” workflow either avoid or intentionally protect against problems caused by this behavior. You wouldn’t have to be careful about which files you check out or have to scan assets before checking in if you could depend on Unreal not making assets look like they have changed when they really haven’t. (Scanning changes before submitting is still good practice but looking for bogus changes shouldn’t be one of the reasons you do it.) Plus, Git doesn’t have the concept of explicit file checkout so that protection goes away if you are using Git.
You said that the behavior is not specific to the Unreal Editor but is the result of the way Windows works. While Windows will change the file’s timestamp, the content of the file is completely controlled by the Unreal Editor. Git looks at content, not its timestamp to determine if a file has changed. The only time Perforce cares if a file has changed is when you try to revert unchanged files. It detects changes by diffing content, not by looking at timestamps. The problem is with Windows, it is that the Unreal Editor changes file contents even though the user hasn’t changed the asset.
In summary, having a well-disciplined workflow is good but I shouldn’t have to worry about accidentally clicking the big save button at the top of the window or complicate the workflow to detect, that then fix things, if I did.
This is not a bug with the editor and it is intended functionality. If items that are not being changed are getting marked as changed, it means that you have intentionally hit save on these objects directly. If you accidentally hit save, the editor is going to ask you if you would like to check it out so it being an accident isn’t that much of a possibility. There isn’t much more we can do to safeguard against accidental saving than having you confirm your decision. There is also the option to revert any changes you’ve made if you do accidentally save something.
After some additional testing, it seems that the difference in Source Control method is relevant. When using Perforce as your source control method, this is what happens whenever you try to save an asset:
After testing with Git source control, I see that it doesn’t do this and just checks out the asset without asking. While the save button saving the asset despite it not being changed isn’t a bug, this is a missing feature that should be added. I apologize for not checking this sooner, I assumed that all source control methods had this checkout step as I mainly use Perforce.
As such, I’ve placed a bug report in [over here][2] for this functionality to be added to the Github source control plugin.
Thank you for investigating further and submitting the bug report; although, I am not sure how the change you suggested could be made. Git simply does not have the concept of checking out files. But then Git is also not really built to work with binary data so choosing to use Git for assets will come with extra responsibilities for the user.
But this all misses the point of the issue I was trying to raise. If the behavior is the intended functionality then, in my opinion, the intention is wrong. Why is changing the content of a file when, as far as the user is concerned, the asset has not changed intentional? The crux of your responses is that “Perforce helps protect against the Unreal Editor changing your data.” And “Oh, Git doesn’t help protect against the Unreal Editor changing your data. That is a bug in Git.” My response is “If the Unreal Editor didn’t change my data when I didn’t tell it to, I wouldn’t have to rely on source control to protect me.”
If you define a bug as a case where the software doesn’t behave as it was designed, then this is not a bug. If you define it as a case where the software doesn’t behave as it should, then this is a bug.
I don’t really expect a response but I would appreciate it if you could bring the issue up with a group that can do something about it. This is really a matter of design philosophy. Your engineers need to ask “what IS an asset?” and only store that in the file that represents an asset. I ran into a similar problem yesterday when I discovered that setting a breakpoint in a blueprint modifies the file. Why? Different versions in source control should only represent real changes to a file. I shouldn’t have to jump through a bunch of hoops to make sure that is the case because the Unreal Editor is cavalier in its attitude towards changing the content of files. This is important because it has a huge impact on usability and productivity.
“If the Unreal Editor didn’t change my data when I didn’t tell it to, I wouldn’t have to rely on source control to protect me.”
The problem with that is that the only time you’re experiencing this issue is when you have told the editor to do so by hitting the asset-specific Save button since the Save All button wouldn’t save anything that hasn’t been edited.
I have brought this to the appropriate team as I wouldn’t feel comfortable making claims without making sure and their response was that we would like to keep this functionality.
Hopefully, even if it isn’t a prompt asking to check the asset out, a feature to prompt for confirmation can be added, even if it is an optional prompt that is enabled. If you would like to keep track of this, while we do officially support the Github source control plugin, it is developed by a member of our community and I’ve made him aware of this here (Please be aware that you may need to be signed into Github or this may 404.)
Thank you once again for following up on this issue and passing it on. Just to be clear, relying on a prompt from source control is a work-around to adapt to an underlying problem in the Unreal Editor. Attempting to make Git work the same way as Perforce simply expands the reach of the work-around. It is not a solution to the problem.
At least there is a work-around for the problem with asset specific Saves. The similar problem I mentioned where setting breakpoints modifies files is much, much more significant and I don’t see any real good work-around for that. I would appreciate it if you could make sure the appropriate team is aware of my concern, I would be happy to engage in a discussion with them to explain why I believe this is such a big problem.
I use “save all” which is described as saving all unsaved assets and levels to disk, but the level should already be saved if I’m not making changes to it, yet it constantly shows up as altered in source control when I haven’t done anything to the level at all. When I’m working on multiple blueprints it’s good to hit save all before closing or after making important changes before testing in case something blows up in my face. However it constantly marks the level as newly saved when it shouldn’t be. The tooltip on that save option does not lead me to believe that it should be forcing a save on something that’s already saved.
