CRYENGINE 5.2's source code is now available from GitHub!

After some final work being done, users can now grab the full engine source code for CRYENGINE 5.2 from our GitHub page . Going forward, we hope to deliver source code day-and-date with the release of new engine versions to give you everything you need to dive into a new build straight away.

In the interest of transparency, we have some more information about the delay and its cause below.

What happened?

Our GitFusion server stopped updating the CRYENGINE repository, likely due to a process on the server being killed, resulting in a problem that needed a manual solution. We tried to fix this by recreating the repository.

However, certain files in the repository, like console-related code (which we are not allowed to redistribute to unlicensed developers) is masked out via virtual streams. The specifics of which data to mask gets updated over time as the repository gets changed. When updating a GitFusion repository, the latest streams is being used.

Sadly, in this case the file sets and commit IDs did not match due to the stream specification changing, triggering the aforementioned issue.

Sounds bad- how did you fix it?

We customized GitFusion by adding a feature that checked each change list against the stream definition at the time the change list was submitted. The upshot of this change is that the repository can now be consistently recreated at any time.

Thanks, but why did it take so long?

As always, we wanted to minimize the effect and disruption for our users, and recreate as much of the previous history as possible with identical commit IDs. This required careful selection of the new parameters, and some experimentation with the new GitFusion feature.

Unfortunately, we did not manage to achieve a perfect 1:1 conversion; while we did the best we could, it was not possible to achieve 100% consistency across all the files and commit IDs in the repository.

What should I do now?

Depending on the extent of your changes, the best solution could be:

1)  For small changes, apply a patch directly to a new clone of the repository

2)  For larger changes, split your changes out into a new repository, then import them into a fresh clone. Two helpful links for this are:

   GitHub: Splitting a subfolder out into a new repository.

   Greg Bayer: Moving files from one Git repository to another, preserving history

3) Update the 5.1.0 and 5.1.1 tags to the new versions (these commit IDs couldn't be preserved) by deleting the tags, then re-fetching the tags from GitHub.