So after about five days of figuring this out - 10x testing, I’ve found the reason my project shows approx 2,000 errors after changing the contents of a string is due to Perforce Read-only access. The errors themselves are that a plugin GenericGraph cannot access an engine module.
Today I’ve just found that by removing all read-only properties in WIndows on the entire project, destroying intermediate, .vs, .sln and binaries for both the project and the plugin allows for a successful compile. Documenting all that I’ve tried here, on my twitter: https://twitter.com/Sythenz/status/1070402869663334400
I have set up a Typemap for my Perforce Project, along with a p4ignore file based on the recommendations by Epic.
Folders/Files I have ignored when submitting are .vs, Binaries, Intermediate, Saved, and Intermediate & Binaries on the plugin itself. Below is a screenshot of my depot tree.
Project Link:
I’ve also provided a link to the project itself.
Perforce Version: Rev. P4V/NTX64/2017.3/1582486 P4VS: Latest version (download 5 days ago), can’t find verison number)
P4D on Linux Server: P4D/LINUXX26X86_64/2018.1/1715250
For anyone who is having this problem 5 years later, changing your workspace to “Allwrite” allows you to do the initial build of the project within the perforce project folder regardless. Manually changing the permission settings in Windows doesn’t work.
You can find the setting in Connection->Edit Current Workspace->Advanced
If you keep this on you most likely have to manually check out the files you edit so if you want to turn it back on you will have to configure your ignore list accordingly. These are the settings that worked for me on windows:
Saved/
LocalBuilds/
*.csproj.*
.vs/*
*.vsconfig
*.pdb
*.suo
*.opensdf
*.sdf
*.tmp
*.mdb
*/obj/*
*.vcxproj
*.sln
*-Debug.*
/FileOpenOrder/
*.xcworkspace
*.xcodeproj
./Makefile
./CMakeLists.txt
.ue4dependencies
Samples/*
FeaturePacks/*
Engine/Documentation/*
.git/*
*.csprojAssemblyReference.cache
# Ignore 'Binaries' directories at any level in the directory tree
**/Binaries/
**/Win64/
#Linux Debug Files
*.sym
*.debug
# Engine intermediates
Engine/Intermediate/*
Intermediate/*
# Intermediate folders for programs should not be checked in
Engine\Programs\*\Intermediate\*
# Intermediate folders created for various C# programs
Engine\Source\Programs\*\obj\*
# Saved folders for programs should not be checked in
Engine\Programs\*\Saved\*
Engine\Programs\UnrealBuildTool\*
# Derived data cache should never be checked in
Engine/DerivedDataCache/*
# Ignore any build receipts
Engine/Build/Receipts/*
# Ignore personal workspace vars
p4config.txt
# Ignore Unix backup files
*~
# Ignore Mac desktop services store files
.DS_Store
# Ignore crash reports
crashinfo--*
# Ignore linux project files.
*.user
*.pro
*.pri
*.kdev4
# Obj-C/Swift specific
*.hmap
*.ipa
*.dSYM.zip
*.dSYM
# Ignore documentation generated for C# tools
Engine/Binaries/DotNET/UnrealBuildTool.xml
Engine/Binaries/DotNET/AutomationScripts/BuildGraph.Automation.xml
# Ignore version files in the Engine/Binaries directory created by UBT
/Engine/Binaries/**/*.version
# Ignore exp files in the the Engine/Binaries directory as they aren't C/C++ source files
/Engine/Binaries/**/*.exp
# Ignore Swarm local save files
Engine/Binaries/DotNET/SwarmAgent.DeveloperOptions.xml
Engine/Binaries/DotNET/SwarmAgent.Options.xml
# Intermediary Files
*.target.xml
*.exe.config
*.exe.manifest
# Ignore project-specific files
CHANGETOYOURPROJECTFOLDER/Build/Receipts/*
CHANGETOYOURPROJECTFOLDER/DerivedDataCache/*
CHANGETOYOURPROJECTFOLDER/Binaries/*
CHANGETOYOURPROJECTFOLDER/Plugins/**/Binaries/**
CHANGETOYOURPROJECTFOLDER/Plugins/**/Intermediate/**
CHANGETOYOURPROJECTFOLDER/Intermediate/*
To check what was being added before pushing the project, I had to push my base project’s non-local files (All binaries, intermediate, etc. removed), build the project (I have Allwrite on for diagnosing the issue). Mark for add on the project, check the changelist for what perforce wants to add. It will say “x amount of files marked for add” but it also counts the ones ignored. If there are no files to submit then you should be good. If there are, revert changes, edit your ignore list and try again until it doesn’t want to add anything else after you have built the project locally in vs. Everyone else will have to build locally too so I recommend distributing binaries separately if needed.
Hi @Knooblegooble ! I’m having a problem quasi related to what your describing above and wanted to see if what you are suggesting here could be modified to my issue.
Our UE perforce users are using custom python paths (not everyone uses same paths) and also altering the AA settings on the project per user (which also alters the defaultengine.ini). Is there a way to avoid the users syncing their ini files inside config folder back to the depot? Like i’d like them to be able to DL from the depot if they choose to sync for latest updates, but i don’t want them putting altered config folder INIs back on depot. I can outright block it on perforce admin, but then it throws errors on the submit and doesn’t go through. I kind of want to treat it like a p4ignore function, where even if a file gets updates and submitted, it just ignores it and keeps the original on the server the same, instead of updating, but allows the submit to go through? But my understand is p4ignore only deals with NEW files, not existing files to be synced? Hopefully that makes sense. Any tips appreciated.
@drylightn, One solution is to modify Perforce protect table so that users in general only have read-only access to that file or files. It would work well, but if they had a real positive change that would help the whole dev team, someone else – maybe superuser – would have to submit that.
@The_Boctor Thanks for the tip! Is that similar to what I did above? I basically made those files read only, but then I have the issue of perforce throwing errors trying to overwrite it (and failing) on submit. It’s not the end of the world this way, but it just makes artist freak out when they get errors on submission. I didn’t know if there was a “silent” way to do it that wouldn’t cause the UE perforce submission to throw errors on the submit.
@drylightn, they should not be able to check out if the file is read only. They probably encountered those errors because they already had those files checked out before you changed the protections. If this is true, have the users revert the files one time, and then they’ll never have the issue again.
