So I finally got around to using URC for a project and I’ve run into some problems with it:
Why are there 8 loading popups when performing actions (like duplicating a level sequence in content browser), which causes the editor to freeze in the meantime?
This is me trying to swap names in files, it takes a ton of time when it should be instant. You are passing all the engine development problems to us and it’s a terrible experience to make content.
I am not an expert, but something tells me that you can mark those assets unusable in the editor while those operations happen, so you don’t have to freeze UEFN 8 times every time there is a change in the repository. That will allow us to work in the meantime. Even if the loading of those actions is short, it’s 8 of them and they happen every time you save or add a new asset in the content browser, which is hundreds of times per project (most of times its less than 8 times, but freezing the editor generally breaks the flow of work, and we already have live edit syncs being annoying, this adds to it).
External repo programs never affect my flow or freeze the editor every couple of seconds, so why should I use URC?
The second issue is that the two ticked boxes inside the repo settings (that are by default) along with onedrive, locks the entire team upon simply opening the project (cause it checks out things, I am not 100% sure how that happens, but its what I was told). Fortnite Projects by default goes to My Documents, which is tracked by Onedrive automatically, so ANY user that gets started and has onedrive will encounter this. And closing Onedrive is not a solution, there should be a better way not to lock these assets (or have URC in a separate folder? idk). Tbh I don’t even think its onedrive, its always the same devices that cause dirty edits (spawn pads, checkpoint pad, bouncer, water volume). If onedrive is the issue, why don’t other actors cause dirty edits, and its only those?
There is no log to know what was committed by others, or the ability to go back multiple versions back (from the editor, I am an artist, not touching consoles)
What happens when I work in live edit and I edit things, while UEFN and URC are saving something in the background (due to autosave)? Live edit doesn’t freeze due to that action, meaning either the files can indeed be corrupted, or there is no point in freezing the editor when saving with URC enabled.
I will switch back to SVN for now, URC is getting there but its not ready yet for large projects.
Thanks so much for this detailed feedback @Wertandrew. We appreciate the time you took to test it out and write out this context to help us improve.
I understand the frustration with so many dialogs for small tasks like this. Our goal is ultimately to move as much of this into the background as possible. I appreciate these concrete examples of workflow painpoints and will coordinate with the team to determine whether we can make any near-term improvements.
Aside from the revision control dialogs, I believe you’ve identified a bug here (which I’ve been able to repro) in which when an asset in the content browser is renamed, the old name does not seem to be properly cleaned up and able to be used again. I’ll get this logged for the relevant team.
I’m going to split this one out into two sections (2A and 2B) because I believe the Onedrive issue and the automatic checking out and locking of key parts of the project are different issues based on other reports at least
2A - Onedrive - it is accurate that using Onedrive and URC on a project simultaneously can cause unexpected behavior and contention since they are essentially two revision control systems. There should be a warning that is displayed to the user anytime we recognize that Onedrive is activated on the folder where a URC-backed project is being stored. Can you confirm whether you or your team saw this message? If not, we’ll need to investigate if it is firing properly in all contexts.
2B - Checkout/Locking - It sounds as though you’re running into one of an understandably frustrating series of similar issues we’ve been working to track down and resolve that are caused by certain assets being dirtied upon opening the project in UEFN, which in turn triggers URC’s automatic checkout and locks the asset(s) to the user who opened the project. We’ll start to work to repro this experience with the list you sent (spawn pads, checkpoint pad, bouncer, water volume), but we may reach out to you for more details if we’re not successful.
Thank you for this callout, the revert functionality reverts all changes made locally since your last sync, so this list is the combination of what’s in the Unsaved Changes dialog and what can be checked in. Its great feedback that this isn’t clear though, so I’m going to explore with the team whether we can make the revert changes confirmation dialog more robust by including the full list of changes.
This is indeed functionality that we were not able to support at launch, but keep an eye out on in the coming months as we have tools in development to provide more visibility and control into your URC history without the use of the CLI.
Can you clarify what you mean by “freezing the editor” and what actions seem to be causing it (and if it is blocking modals, whether they are similar to those you describe in #1)?
One clarification that may help here is that Live Edit and the editor communicate with one another the same regardless of whether/which revision control provider is enabled. Changes made in live edit by anyone connected to the session are propagated to the editor to be saved as the user logged into the editor sees fit. If the user has URC enabled and URC’s auto-checkout/auto-undo functionality turned on, URC will listen for the changes being propagated to the editor and attempt to check out those assets/actors to the editor user, so that another editor user with access to the project who may not be in the live edit session doesn’t make changes to the same content that is being edited in live edit and overwrite the changes or cause conflicts.
I believe this is how Unreal always works because of the redirectors.
If the asset is used by any objects, ‘renaming’ it will just create a new asset with new name and convert the old asset into a redirector, which occupies the old name.
(Interestingly, I noted that the issue is now called ‘Caveats’ in 5.x documents. It was called ‘Gotchas’ in 4.x doc.)
Quick fix is using the Fix Up Redirector option on the folder after renaming an asset.
That will cleanup the redirectors after updating all objects using it so the old name could be used again.
Revision History
For revision history, it is not obvious but file history could be viewed from the context menu in Content Browser.
There is a sync option that allows you to revert back to specific version on one file.
Its the redirector thingy that it was mentioned above. Would be nice to have a toggle in settings to turn that feature off (don’t create redirectors) so its more simple for new users.
I can see the onedrive message, but it didn’t bother me with my other revision control system.
Dirty assets are not only created on opening UEFN, they can be created afterwards too.
Grind rails is also another example.
By freezing, you can see it happen on the video I posted after a rename is complete. The editor wont respond to any input for a few seconds. This happens everytime you save on a large project, and there is also a small jitter on autosave if you are in Creative too (no UEFN), so seems like a hard drive thing.
Reading more about this I don’t expect this will be something that will be supported in the near future, but I’ll do my best to pass along your feedback for future consideration.
Thanks for confirming you can see the warning. We’ll definitely need to continue investigating why OneDrive was causing contention with URC and not when you use SVN. Could you provide a bit more detail about how you’re using SVN?
Thanks for the clarification. There are certain actions that require blocking modals/locking the editor while they complete. I know there is interest internally in moving more of these to the background but I don’t have a clear picture of feasibility and timeline right now.
On 2. I want to clarify that this is on all revision controls. Dirty edits are inherent to specific devices, its not URC specific. I used to get dirty edits on SVN too.
That would be helpful, because the checking out can sometimes take 2 mins, or 20 mins and I need to know which one it is. “Remaining time” would help too
My Unreal Revision Control has been stuck on a frozen screen for two days, Is the Engine Frozen? There is no status bar showing, it showed for the first 5 seconds then the engine is stuck unresponsive without any status bar. I have 13,000 changes i made and need to check in. Is this going to take two days? All the files are foliage instances. this map is gonna be beautiful…
IF I can check in changes on Revision control! PLEASE HELP!
Had the same issue in another project that was 5gb, I couldn’t even check in or sync with others due to how long it took, IIRC I timed it out and I couldn’t work on that project.
How do I know if it is working? will the status bar disappear or will it stay on the screen duing the checkin process? @Wertandrew@pto2k@gxg_work@wobuu
UPDATE: Thank you Guys So much! This Thread Helped me out BIG TIME!
Now 5 minutes and the status bar CAME BACK! Rather than 48 hours of no check in files status bar not showing!
I right clicked every folder in my Content Browser Fixed up Redirects on each folder and BAM! You guys Keep up the amazing work! this fixed my Revision Control Check in Error!
Wendy, Hook, Peter Pan, Crocodile Nurse! Choose your class Uncharted Plunder Mixed with battle field bad company in the Caves beneath! unForted! Plunder the BOOTY.
The only solution: Was to clone the level and duplicate it, then re-load level on installing fab meshes, then clearing out 1000 Validation errors lol . And WAHLAH! It works