Error in PakTool when generate chunks enabled

Development Programming & Scripting
1

When I try to package my project in the 4.16 preview I get an error stating that it can’t write to the UnrealPak log file, I’ve attached the log with the full exception printed in it. I’ve found that it will succeed if I delete the log folder (AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Program+Files+Epic+Games+UE_4.16) before starting the package process or if I just turn off GenerateChunks in the packaging settings.

I tried packaging ShooterGame with generate chunks because I know that is set up to actually partition its content into different chunks (and is what I based my game’s chunking on) but that worked fine. I’m packaging for Windows 32-bit and have tried both Development and Shipping builds with Full Rebuild turned on.

2

Hello ,

Had you previously been able to package this way successfully in 4.15 or is this the first time you’ve tried this? As mentioned in the error message in the log, the reason the file is not writable is due to being used by another process. Can you ensure that all other instances of UE4 are closed and that no other compilation processes are running? It may be best to use Task Manager’s process tab to check this.

3

I thought it had worked in 4.15 but when I double checked yesterday I did run into the same issue. It also still happened after deleting my log folder, so that bit of info is wrong as well. I checked task manager while it was packaging and didn’t see any extra unreal processes running.

I went back to ShooterGame to see if I could repro it there and I was successful. The steps I took:

  1. Create ShooterGame for 4.15

  2. Duplicate every content item 3 times (so there should be 4 copies of each file)

  3. Modify AssignStreamingChunk in ShooterGameDelegates to the following:

    static void AssignStreamingChunk(const FString& PackageToAdd, const FString& LastLoadedMapName, const TArray& AssetRegistryChunkIDs, const TArray& ExistingChunkIds, TArray& OutChunkIndex)
    {
    const int32 BasePak = 0;

    // Add assets to map paks unless they're engine packages or have already been added to the base (engine) pak.
if (!PackageToAdd.StartsWith("/Engine/"))
{
	if ((LastLoadedMapName.Find(TEXT("_2")) >= 0 || PackageToAdd.Find(TEXT("_2")) >= 0) &&
			!ExistingChunkIds.Contains(BasePak))
	{
		OutChunkIndex.Add(1);
	}
	if ((LastLoadedMapName.Find(TEXT("_3")) >= 0 || PackageToAdd.Find(TEXT("_3")) >= 0) &&
		!ExistingChunkIds.Contains(BasePak))
	{
		OutChunkIndex.Add(2);
	}
	if ((LastLoadedMapName.Find(TEXT("_4")) >= 0 || PackageToAdd.Find(TEXT("_4")) >= 0) &&
		!ExistingChunkIds.Contains(BasePak))
	{
		OutChunkIndex.Add(3);
	}
}
if (OutChunkIndex.Num() == 0)
{
	OutChunkIndex.Add(0);
}

    }

  4. Package the game with the following settings

136662-packagesettings.png
136662-packagesettings.png786×455 10.5 KB

Hopefully that will work for you.

4

Thank you for the information, unfortunately I’m still not seeing any sort of failure. I did have to edit one thing from your reproduction as the code provided didn’t compile successfully. I had to replace the “TArray&” parts of the function signature with “TArray&”. Did you receive the same error when reproducing the issue this way or was the error message different this time?

5

Looks to be the same error; attaching the log from attempting to package ShooterGame with all the duplicated content.

Just to confirm, your build ends up with 4 different pak files? If I have either ShooterGame or my project generate less than that then it succeeds without the “file in use” exception.

6

That’s correct, I receive 4 different pak files. I did just notice that you’re using a source build though, which could have an effect on this. I’ll try using source instead of a binary build and see if I can get the same results.

7

No, I’m using the binary build of 4.15. I do have a source build on my computer but both my project and ShooterGame that I’m using use the binary build.

8

Ah, my mistake. I was able to reproduce the issue however, it seems like it requires packaging a second time, as the first creates the file that the error mentions being open in another process. I’m doing further testing at the moment as it could be related to one of the other settings, such as Blueprint Nativization.

9

I just tried packaging with nativization turned off and it worked multiple times in a row. Not sure why I didn’t think to do that.

10

I was able to reproduce this in a smaller project (makes it easier to use for a reproduction case) and have entered a bug report for it. You can find the bug report here: UE-44709. In the meantime, until this gets fixed, I suggest disabling Nativization since that seems like the simplest workaround.

11

I can confirm this bug is still around, it’s not letting me do a packaged build with pak chunks enabled. Any work arounds? I have nativization disabled and it still doesn’t work :frowning:

12

Can confirm with BioXide, we too have nativization disabled and it started happening last night with 4.16.2

13

Hello BioXide and Pewbot,

I followed the same reproduction that we originally used for this in Shooter Game in 4.16 and I’m not seeing these issues. Is your setup different in any way? If possible, could you provide a project that can reproduce this issue?

14

Hi folks,

we have the same issue on our build server (4.16.3 Prebuilt), but it does not happen every time. As far as I can see, it does not necessarily need a different setup for the issue to show up or not show up. Sometimes just restarting the same job is enough to fix it. Rebooting the machine usually fixes the issue for a day or two until it comes back.
We also use Pak chunks, nativization is off and the server always wipes its workspace before checking out and building the project (the prebuilt engine creates some intermediate files outside of the workspace (like the logfiles) which are not cleaned up).