Source Control with SkookumScript UE4 w/C++

#1

I’m wondering how to setup my project with source control (perforce) so that members on my team won’t have any read-only issues when re-building the game.

Do you have a recommended P4 typemap or advice on how to manage file permissions particularly for the two folders:

  • Plugins/SkookumScript/Scripts/Engine-Generated/
  • Content/SkookumScript

I was thinking that the coders might be in charge of checking out those folders and allowing :sk: to generate what it needs when they’ve added new classes. Or should any of these be treated more like an Intermediate folder and left out of perforce entirely?

#2

The Engine-Generated folder is automatically regenerated by the UnrealHeaderTool (UHT) whenever the user compiles the game with Visual Studio (or directly via UnrealBuildTool (UBT) of course).

The Content/SkookumScript folder is automatically generated whenever a user runs the SkookumIDE (and UE4 launches the IDE whenever it launches which will recompile all scripts).

So neither of these folders should be checked in as long as a user works with both the SkookumIDE and Visual Studio.

The workflow should be as follows:

  • SkookumIDE: Users get latest from Perforce, then press F7 or pick Compile Project (if stale) from the menu. This will regenerate the Content/SkookumScript folder.
  • Visual Studio: Users get latest from Perforce and/or GitHub, then build the game as usual which will also regenerate the Engine-Generated folder if necessary. There is one caveat right now which is if anything changed in the SkookumScriptGenerator module it is not detected by the build system. So you might get the occasional :sk: engine binding related error that you have to remedy by first Cleaning UnrealHeaderTool then building your game once more.

There might be users on a team that do not normally use Visual Studio (e.g. artists, scripters, level designers).

One solution for these might be to have a button on the desktop that they click after the sync from P4 that runs UnrealBuildTool and builds the executable plus regenerates the Engine-Generated script folder. Easy enough to do and keeps the code pipeline simple. That button might even both sync to P4 and rebuild the game in one step. A typical command line for this would be call Engine\Build\BatchFiles\Build.bat UE4Editor Win64 Development.

You could also check the executable plus the Engine-Generated folder into P4 but map it only for artists and for the build engineer. Coders would not have it mapped to not disrupt their workflow.

Btw we are planning to make the Engine-Generated folder that currently contains thousands of files just one packed file since it is not meant to be edited anyway. This will make it faster to load, parse and easier to keep track of in P4.

1 Like
#3

This might be obvious, though also remember to toggle “Use Perforce Version Control” under the “Settings” menu in the SkookumIDE.

1 Like
#4

This will be nice. For now I’ve opted to take the route of having coders check the Engine-Generated folder in. Since they’re the ones that would be adding new bindings, they can deal with keeping it updated.

That totally escaped my notice, thanks for the mention!

#5

I wanted to add one more to this. Now that I’m making my own :sk: scripts, I’ve noticed that :sk: has added a Scripts/ folder to the project:

Scripts/
|-Project/
|-Project-Generated/
|-Skookum-project.ini

It seems pretty clear that I want to keep Project in source control, but unclear if I want to keep Project-Generated

I have the :sk: perforce option enabled but I never see it add anything to my pending change lists. Does it just execute p4 commands in the background? I have a .p4config file in my project root and can run p4 commands from the command line.

#6

The idea with the Project-Generated overlay is to keep it in source control just like the Project overlay (at least those classes actually being used). This is of course tricky since the files are being regenerated as the plugin runs. So you would have to keep them checked out as you work, and occasionally check in/add those classes that are actually used. This is tedious and we are planning on making this easier in two ways:

  1. Automatic source control via UE4Editor so you don’t have to manually keep track of the files
  2. Storing the Project-Generated overlay as a single file that is (also automatically) kept in source control

So please hang in there for now!

1 Like
#7

SkookumIDE calls Perforce (assuming the Perforce option is enabled) using the command line whenever:

  • a new file is created via the Browser “File”->“New Class / Member…” menu option (which is also hot key Ctrl+N or the little + at the bottom of the class hierarchy navigation pane
  • typing in a file that is read only will attempt to check it out via Perforce

Any SkookumIDE calls to Perforce will also be noted in the log pane.

The Perforce integration is pretty simplistic right now and other version control systems are non-existent, though we plan to significantly extend SkookumIDE version control integration in the future.

#8

Curious if there are any short to mid-term plans to support Git / Git LFS as a secondary Source Control option for the SkookumIDE?

Also providing an optional per-project toggle for Git LFS File Locking would be an ideal bonus.

2 Likes
#9

You are the first to have requested SkookumIDE Git support. :madsci: Most game studios we’ve worked with and at use Perforce - even Epic Games uses Perforce internally.

I’ve added SkookumIDE Git support to our official To Do list. We’ll take an initial look to see how much work may be involved and then determine where to put it on our schedule. Hopefully, it will be easy.

[BTW, thanks @BinarySword for your initial suggestions and help when we were setting up SkookumScript on GitHub.!]

This post mostly involves the old pre-Slate UI version of the SkookumIDE.

Until then, here is a write up on a suggested Perforce workflow which still might be relevant to aspects of a GitHub workflow:

These sections in the SkookumScript online docs describe some files and directories that also might be relevant:

2 Likes
#10

Don’t mention it, I was more than happy to help with getting you setup with GitHub :smiley: and thanks for the info :+1:

I am surprised though that I’m the 1st person to suggest Git support as while Perforce is still an industry standard Git LFS for game dev is rapidly gaining market share, especially in the indie scene.

Not to mention there are lots of good features in the Git LFS development pipeline with one of the more recent additions being File Locking support :slight_smile:

P.S. I would highly recommend contacting Sébastien Rombauts the creator of the UE4 Git Plugin for some pointers or perhaps to hire as a sub-contractor to work on adding Git LFS support to SkookumIDE (might help speed up the process).

1 Like
#11

Is this still current? i.e. the only two folders to omit from source control are:
Scripts/Engine-Generated
Content/SkookumScript/

1 Like
#12

That sounds about right.

Also see Set up a UE4 project to use SkookumScript and New Class or Member pane which describe other files that should be included in source control.

2 Likes
#13

I’d also love git/git LFS support in the IDE. We’re looking at moving over to git from perforce on one of our projects and having in IDE support would be great for the non coder types :smiley:

1 Like