This is a problem we haven’t seen before but from your log output either:
The .upayload file is not being written to disk before submission.
The .upayload is being written to the wrong location.
The call to p4 add is failing in an unexpected way that we are not catching.
To help me try to narrow down the problem can you try running the process again then after the error check if the temp workspace mentioned in the log (VASubmission-1500d517-43d8-bc77-dd3b-dd86c943f4c2 in the snippet you posted) actually exists and if so does it have the .upayload in an added state and in that case exactly where is that .upayload on disk?
From your log snippet it does look like the workspace is created and something is in an added state (hence it not being cleaned up) so that should be a good lead.
One final question, is your engine installation in the same disk as your project?
If you feel comfortable you could try running the Microsoft tool Process Monitor (Process Monitor - Sysinternals | Microsoft Learn) to watch for .upayload activity on disk and check if and/or where they are actually being written.
EDIT: You could also try running the editor with -logcmds=“LogVirtualization Verbose” as with verbose logging enabled the virtualization process will log the file paths of each .upayload file written to disk for perforce submission.
After doing a check-in via the Editor, those temporary workspaces are getting created and appears to be in the add state (see attached). When I use the Perforce client to browse the to file, it takes the projects ./Saved/VASubmission/ folder. It appears to be empty.
The log that I have provided do have the Verbose enabled. Do you think there should be more than what I have attached?
Sorry that is my mistake, the snippet you provided does indeed contain all the expected verbose logging for 5.3.
Let me get Process Monitor going and get back to you.
This might be your best bet into identifying the problem at the moment. As far as I can tell from your log snippet and replies, everything is working as it should do up until the point the code tries to submit the .upayload file but cannot find it.
At first I wondered if your antivirus system (if you are running one) had removed the .upayload after it was written, but then you should still see the directory structure under \VASubmission\
It could be possible that something is preventing the file from being written in the first place but our file system code should be checking the error values for creating the subdirectories, opening the file handle, writing and closing the handle which would trigger a specific error in the source control backend we are not seeing.
Lastly, in the editor the relative filepaths are usually relative to the editor exe itself, and the paths you provided line up so if the current working directory at the time of writing the .upayload is ‘C:/Unreal/Engine/5.3/Windows/Engine/Binaries/Win64’ then we should be writing the .upayload to ‘C:/Unreal/Projects/pipeline/Saved/VASubmission/1500d517-43d8-bc77-dd3b-dd86c943f4c2/ce/8b/d3/8622a6cd49bd4561baaa1e74839bfbbbb2.upayload’ so I do wonder if the current working directory has been changed unexpectedly at this point.
But all in all, the easiest way to find out the fate of the .upayload is to run Process Monitor and see what it tells you.
I’m wondering if there was ever a solution found for this issue? I am trying to setup virtual assets for UE 5.3 as well and I’ve run into this exact same issue. The process monitor shows that its creating the .upayload files/folders, but those folders are not actually being created on disk. I’m wondering if this is an issue with folder creation within the Editor?
I wanted to comment in here to update. I solved this issue on my end. It looks like I had the “Saved” folder listed in my P4IGNORE file, so perforce was refusing to add anything in that folder. I removed it from the P4IGNORE file and the virtual assets started working.
So far we’ve identified two different problems that can result in the errors seen in this thread.
a) Some teams wish to store their payloads in a stream based depot, in which case they would need to supply a ‘ClientStream=…’ value when creating the backend in their config file.
b) The P4IGNORE issue that you identified, which can currently be fixed either by adding an exception as you did, using ‘.p4ignore.txt’ as the P4IGNORE value or by informing the backend about the P4IGNORE value by adding ‘IgnoreFile=…’ when creating the backend in the config file.
It seems that our perforce api implementation is not returning proper error strings when files are excluded by the p4ignore file which is making this tricky for teams to debug.
Ideally we will fix this oversight in the api and add the ability for the VA system to be able to poll the P4IGNORE value, so that it can automatically override the file, making ‘IgnoreFile=…’ redundant.
