Different behavior between “Editor” and “Editor PCBs” under UnrealGameSync > Options > Sync Precompiled Binaries

Development Pipeline & Plugins
, ,
1

(This is a translation of a [Japanese [Content removed] by Kadowaki Yuki.)

Thank you for your continued support.

Currently, I am trying to find if it’s possible to use PDB files included in PCBs that are not stripped by using BuildGraph.

While doing this, I was aware of the difference in behavior between “Editor” and “Editor PCBs” under UnrealGameSync > Options > Sync Precompiled Binaries. So I would like to know about that correctly.

■ Versions I am using

UnrealGameSync Application version: 1.0.0

Horde Server: 5.6.1-0

CL 44394996 + CL 45227533 (Magick.NET VersionFix)

Perforce Server: 2025.1

■ Conditions

- Engine itself is vanilla without any modifications.

- I have not changed the Perforce protect before and after stripping. I am using an account that has read/write access to both the development stream and the PCB storage stream.

- I use Horde authentication with “Anonymous”.

- I create PCBs using Incremental Build (Engine/Build/Graph/Examples/BuildEditorAndTools.xml).

- There are several CLs (169, 173, 174, 175, 177, 223, 227) that have been submitted to the development stream and for which PCBs have been created.

- The PCBs are stored in the PCB storage stream as follows. (“Full size” means the PDBs have not been stripped.)

* I guess the gaps in revision numbers are due to PCBs for same CLs being re-uploaded.

Revision 9: CL169 — Before change (Stripped)

Revision 11: CL173 — Before change (Stripped)

Revision 12: CL174 — Before change (Stripped)

Revision 13: CL175 — Before change (Stripped)

Revision 16: CL177 — Before change (Stripped)

Revision 17: CL223 — Before change (Stripped)

Revision 19: CL227 — After change (Full size)

■ Current behaviors in my environment

[ When selecting “Editor” and syncing the latest CL (227) ]

The PCB for the latest CL (227) was fetched from Perforce with “p4 print”, and deployed to the local workspace based on the zipmanifest. By this, I confirmed that the PDB was full size.

[ When selecting “Editor PCBs” and syncing the latest CL (227) ]

It appears that the PCB for CL (177) was fetched using its Horde ArtifactID and deployed to the local workspace based on the zipmanifest. As the PCB for he latest CL was not fetched, I confirmed the PDB was not full size.

As shown above, I was aware that the fetched PCBs were different depending on whether selecting “Editor” or “Editor PCBs”. Is this the expected behavior?

Also, although they seem to be fetched from different locations, I believe the purpose of fetching PCBs should be the same. Would it be possible for you to explain what is the intention behind the different behavior?

(To be continued)

2

再現手順
Prepare a Horde Server (5.6.1) and a Perforce Server, and install UGS on the client.

Without modifying the engine, create PCBs over several CLs where the PDBs are stripped.

Without modifying the engine, create PCBs where the PDBs are full size.

With UGS, syncing the latest CL by switching between Options > Sync Precompiled Binaries > “Editor” and “Editor PCBs”.

3

(Continued)

(This is a translation of a [Japanese [Content removed] by Kadowaki Yuki.)​

■ About the contents of _archiveToChangeNumberToArchiveKey

There are two lists stored in _archiveToChangeNumberToArchiveKey by GetArchiveForChangeNumber of WorkspaceControl.cs. One is the list containing the Perforce file paths and revisions that should be fetched from for each CL (with “Editor”). The other is the list containing the IDs of Horde Artifacts that should be fetched from for each CL (with “Editor PCBs”).

Also, it appears that during a sync, the paths or Artifact IDs to fetch from are returned based on the specified archiveChannel and changeNumber. However, looking into this in my local environment, for all the CLs associated with “Editor”, the Perforce file path and revision of the latest CL (227) are listed.

(Previously, only the most recent 7 CLs were in the list, but today 11–14 CLs are now added to the list.)

[ Example ]

CL 169 : //stream/hogehoge-binaries/++hogehoge+stream-projectEditor.zip#19

CL 177 : //stream/hogehoge-binaries/++hogehoge+stream-projectEditor.zip#19

CL 227 : //stream/hogehoge-binaries/++hogehoge+stream-projectEditor.zip#19

[Image Removed]On the other hand, with “Editor PCBs”, the ArtifactID of CL (177) was listed for all the CLs.

(I verified this by using the Horde Server API.)

[ Example ]

CL 169 : 68ad***********c52126

CL 177 : 68ad***********c52126

CL 227 : 68ad***********c52126

[Image Removed]I think this list should contain the Perforce file paths and revisions or Artifact IDs corresponding to each CL. However, they all have the same contents. Is this the expected behavior?

4

Hi,

I’m new to UGS/Horde, so I had a quick chat with the responsible UGS/Horde dev, I was get some starting information to figure out the flow, so I’ll try to answer your question, but the dev also just encouraged you to fetch from Perforce since this archive already had the full symbols.

Q: As shown above, I was aware that the fetched PCBs were different depending on whether selecting “Editor” or “Editor PCBs”. Is this the expected behavior?

  • This is unclear, it’s likely that the zip for the Editor PCB’s being published to Horde does not have the full pdb’s within it, most likely due to the build graph configuration.
  • Could you share your UnreaGameSync.ini file you have ${YourGame}/Build/UnrealGameSync.ini, especially the ‘Archives’ settings where you defined ‘Editor’ and ‘Editor PCB’?

Q: Also, although they seem to be fetched from different locations, I believe the purpose of fetching PCBs should be the same. Would it be possible for you to explain what is the intention behind the different behavior?

  • At the moment, I cannot explain it, but I assume that either the archive steps (Perforce vs Horde) that do not archive the same thing or the sync steps doesn’t sync the right thing. I’d say the archive steps is probably the cause.

Regards,

Patrick