The 'default' way of using Perforce with Unreal Engine 4 projects is a bit harsh. Having to remember to check out source and binaries might drive you crazy very quickly and is not a good idea if you work in a team. It so happens that it's not that hard to customize the process. So... if you ever wondered how you could automate your pipeline with Unreal Engine 4, Perforce and Visual Studio not to be worried about checking out specified files, I might have a simple solution for you.

Check out automation

Disclaimer: tricks listed below might require some basic knowledge on how things work under the hood. I've tried to link as many resources as needed to get the knowledge, so if something doesn't work for you, first try to read linked articles and dig a bit into the subject. I promise, especially if you're new to the topic, it might only help! This is just a #protip for people new to gamedev and software engeneering - always try to understand what you're about to do before following the knowledge from the Internet, so you will spend way less time on potential troubleshooting. Anyways, if you're sure you've done everything right and it still doesn't work for you, I'm here to help.

Source

Visual Studio doesn't check out modified files by default, so it would be lovely to automate this first. So... if you haven't yet installed P4VS, you would probably like to do so. The only thing you'd need to do after installing it is to set your connection. More info on this in an apropriate section of the official Perforce guide.

Typemap

Don't forget to follow this guide and set up your Perforce typemap.

Disclaimer 2: remember that for sharing with artists you need only Development Game binaries (UE4Editor_YourProject.dll and optional for better troubleshooting - UE4Editor_YourProject.pdb), YourProject.target and UE4Editor.modules (last two should have filetype text+w in your Perforce typemap. Also... you still need to Add all these files to your source control through the Perforce client. Same rules apply to your custom Plugins.

My typemap looks like this:

# Perforce File Type Mapping Specifications.
#
#  TypeMap:	a list of filetype mappings; one per line.
#		Each line has two elements:
#
#  		Filetype: The filetype to use on 'p4 add'.
#
#  		Path:     File pattern which will use this filetype.
#
# See 'p4 help typemap' for more information.

TypeMap:
	binary+w //depot/....exe
	binary+w //depot/....dll
	binary+w //depot/....lib
	binary+w //depot/....app
	binary+w //depot/....dylib
	binary+w //depot/....stub
	binary+w //depot/....ipa
	binary //depot/....bmp
	text //depot/....ini
	text //depot/....config
	text //depot/....cpp
	text //depot/....h
	text //depot/....c
	text //depot/....cs
	text //depot/....m
	text //depot/....mm
	text //depot/....py
	binary+l //depot/....uasset
	binary+l //depot/....umap
	binary+l //depot/....upk
	binary+l //depot/....udk
	text+w //depot/....target
	text+w //depot/....modules

Here I've added rules for *.targets and *.modules files to the listing from the guide.

Feel free to use this typemap in your project.

Auto-handling binaries

Let's now deal with the most important part here - automatically checking out all your binaries before the build. These short steps will lead you through a simple solution. This might extend your build times a little bit depending on your internet connection, Perforce server specs and other conditions - like wether your Workspace is on SSD or HDD.

*.uproject file

First add this anywhere in you *.uproject file:

"PreBuildSteps": {
    "Win64": [
        "echo Checking out binaries from Perforce",
        "p4 -q set P4CONFIG=\"$(ProjectDir)\\.p4config\"",
        "p4 -q edit \"$(ProjectDir)\\Binaries\\$(TargetPlatform)\\*\"",
        "p4 -q edit \"$(ProjectDir)\\Plugins\\*\\Binaries\\$(TargetPlatform)\\*\"",
        "echo Finished checking out binaries from Perforce"
    ]
},

What it does, is basically calling a checkout (p4 edit) command on all your binaries before the build. For the connection it uses data in your .p4config file that should be placed next to your *.uproject file.

Perforce commands are called with -q (quiet) flag. It means that they won't output to the log anything but warning and errors. If you want to see what p4 commands are called, simply remove all occurances of -q from the snippet.

.p4config file

Now you just need to add the .p4config file in your project's root directory and set it's contents as follows:

P4USER=perforce_username
P4PORT=server_address.com:1666
P4CLIENT=workspace_name

Ofc, don't forget to replace perforce_username, server_address.com:1666 and workspace_name with your data.

Remember: don't add this file to your source control - every programmer needs to add it manually to their root folder.

Auto-revert unchanged files

Here we are introduced to another problem - now we have the whole source and all binaries checked out and submitting more files than necessary might take a bit longer than you'd like it to. To this, I've learned a quick fix. Just go to 'Advanced' tab of your Workspace settings (View->Workspaces or CTRL+5, and doubble click your Workspace) and set 'On Submit' to 'Revert unchanged files'. A screen for reference:

Huge thanks to @JustKrishna_ for showing this trick to me!
Huge thanks to @JustKrishna_ for showing this trick to me!

If for some reason you prefer to revert unchanged files on every build, try adding this (remember - this will extend your build times, usually it's better to use the previous trick):

"PostBuildSteps": {
    "Win64": [
        "echo Reverting unchanged files",
        "p4 -q revert -a",
        "echo Finished reverting unchanged files"
    ]
},

Sum up

I hope you've learned a bit of new tricks you might use to improve your workflow. They should improve your workflow and are way safer to use when working in a team - you will never forget to Submit everything you need again and therefore you will probably dodge a lot of problems connected to this. Just remember that some of the tricks might have side effects - like extending your build times a little, but it all depends on your setup and usually should be easy to fix.

Thanks for reading. If you have any feedback, I'd be glad to hear it. There is a comment section below the article. Also, feel free to ask questions if something is not clear. It will help me to improve how I write and decide what should I include in my future blog posts.