HydraIssues

Hi Tommaso,

Good news: this was not your setup. The project as it stood in Perforce could not be built on any machine, so you were chasing something that was genuinely broken on our side. I have fixed it in the depot (changelist 94). Two things were wrong:

1. When we cleaned compiled build output out of the depot back in July, the sweep went too far and also removed 27 NVIDIA DLLs that ship with the DLSS and Streamline plugins. Those are not compiler output, so no amount of rebuilding could ever have regenerated them. They are restored.
2. All nine plugins were flagged as "Installed", which tells Unreal to treat them as pre-built and NOT compile them from source. Combined with the missing binaries, that is exactly the failure you saw. They are now set to build from source.

Two of your findings, resolved:

• VictoryBPLibrary is Win64-only, not MacOS-only. Its plugin descriptor allows Win64 and nothing else, and the full source is in the depot. There is nothing to convert, and no line-ending change is needed.
• You were right to ask before deleting. Deleting .sln, .vs, Intermediate and Binaries is completely safe. None of them are tracked in Perforce, so they cannot conflict with anything when merging. They are local build output and get regenerated. Go ahead.

Also worth knowing: this project is Blueprint-only. There is no RupelmondeUE/Source folder and the .uproject declares no modules of its own, so there was never a project .sln to find. All the C++ comes from plugins, and Unreal builds those itself. You do not need UnrealBuildTool or a hand-made solution file at any point.

What to do now

1. In P4V, Get Latest Revision on the stream. About 306 MB will come down (the restored plugin DLLs plus nine small descriptor files).
2. In your workspace under RupelmondeUE\, delete Rupelmonde.sln (and UE5.sln if it is there), .vs\, Intermediate\, Binaries\, and Saved\ / DerivedDataCache\ if present.
3. Open RupelmondeUE\Rupelmonde.uproject directly by double-clicking it. Unreal will offer to build the missing modules. Accept, and let it finish. The first build takes a while.

Do not check out or delete anything under Content/, Config/, Plugins/ or SourceArt/ while troubleshooting. Those are tracked, and binary assets use exclusive check-out.

One thing still to check on your machine

The warning you hit, Platform 'Win64' referenced in the project file 'UE5' cannot be found, is separate from the depot problem and will still bite after the re-sync. It almost always means Visual Studio is missing the Unreal bits. Please open the Visual Studio Installer, click Modify on VS 2022, and confirm:

• the "Game development with C++" workload is ticked (this is the usual culprit)
• inside that workload's optional components on the right, "Unreal Engine installer" is ticked
• under Individual components, "MSVC v143 - VS 2022 C++ x64/x86 build tools" and a Windows 10 or 11 SDK are ticked
• the ".NET desktop development" workload is installed

Reboot after any change. Also please confirm your Unreal is exactly 5.5 and installed from the Epic Games Launcher rather than built from GitHub source, since mixing a source engine with launcher-generated project files causes this same class of error.

If it still fails after all that, send over Rupelmonde.log and the three Rupelmonde-backup-*.log files and we will take it from there. Sorry for the detour, and thanks for flagging it clearly enough that we could find the real cause.

Best,
Cederik

New feedback from Tommaso (email, 2026-08-11)

Transcribed from his mail:

• Followed all instructions from the 2026-08-05 reply, three attempts. The project still does not open or build.
• Visual Studio 2022 workloads and components checked and complete. All missing modules installed and double checked.
• VS 2022 Community version is 17.14.37, the latest. He notes Microsoft documentation says UE5 needs 17.7+, so he does not think the version is the problem.
• All plugins synced correctly from Perforce. CL 94 came down.
• Unreal Engine is 5.5.4, Epic launcher install. Correct.
• Errors in the log still look plugin related, but he cannot decipher more.
• Attachments in the mail: a screenshot of the VS version dialog, and one .log file from the latest attempt. He deleted Saved\ between attempts, so earlier logs are gone. NOT yet attached to this issue.

Working hypothesis: MSVC toolset 14.44 is too new for UE 5.5

VS 17.14 ships the MSVC 14.44 toolset. UE 5.5 does not fully support it:

1. UnrealBuildTool in UE 5.5 prefers MSVC 14.38.33130 (the VS 17.8 toolset). Toolsets 14.40 and newer cause known compile failures in UE 5.4/5.5 code. Epic added 14.44 support in 5.6, not 5.5.
2. The "17.7+" figure Tommaso quotes is the minimum, not a statement that every newer toolset works. For UE 5.5 the safe path is to pin 14.38.
3. This fits the history: his very first error message asked for "Visual Studio 2022 17.38", which is UnrealBuildTool asking for the 14.38 toolset. And VictoryBPLibrary is old community code, exactly the kind of source that stops compiling on a newer, stricter MSVC while the eight NVIDIA plugins may pass.
4. It also fits "errors still linked to plugins misbehaving": with CL 94 in place the DLLs and sources are present, so what remains is the local compile of the plugin modules.

Confidence: high on the mechanism, but not confirmed until we read his .log file. The log will show the exact toolset UBT picked and the first real compile error.

Next steps

• Get the .log file and the screenshot from the mail and attach them to this issue. Confirm in the log which MSVC toolset UBT selected (search for "Visual Studio 2022 compiler" / "14.44" / "14.38") and capture the first error.
• Tommaso: install the pinned toolset and retry (instructions in the reply mail):
  1. VS Installer > Modify > Individual components > tick "MSVC v143 - VS 2022 C++ x64/x86 build tools (v14.38-17.8)". Keep everything else as is.
  2. Create %APPDATA%\Unreal Engine\UnrealBuildTool\BuildConfiguration.xml with:

     <?xml version="1.0" encoding="utf-8" ?>
     <Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
       <WindowsPlatform>
         <CompilerVersion>14.38.33130</CompilerVersion>
       </WindowsPlatform>
     </Configuration>
     

  3. Delete Intermediate\, Binaries\, .vs\ and any .sln again, then open Rupelmonde.uproject directly and accept the module build.
• Ask Tommaso to keep Saved\Logs\*.log from every attempt from now on (copy them out before cleaning).
• If it still fails with 14.38 pinned, read the new log before deciding anything else.

Note for the record: this is a machine independent problem. Any contributor on VS 17.10+ will hit it, so the BuildConfiguration.xml pin (or a Rupelmonde.uproject level fix) should become part of the onboarding runbook agentcodex/docs/runbooks/rupelmonde-perforce-onboarding.md once confirmed.

Update 2026-08-11: repro plan on our own hardware, plus findings

Tommaso's follow-up mail (partial): he had Gemini condense his findings into three options. Only option 3 survived the copy: replace the local VictoryBPLibrary with a fresh pre-compiled binary release built for UE 5.5. Options 1 and 2 are cut off; full text still needed. This confirms the failure centers on VictoryBPLibrary compilation, which fits the MSVC 14.44 hypothesis from the previous comment.

Log fragments (attempts of 08/05 16:29 and 08/07 11:15): both show only the harmless startup preamble (aqProf.dll, VtuneApi.dll misses are normal). Important detail: both logs show Running engine for game: Rupelmonde, so the editor process did launch on those attempts. The real error is further down; full log files still needed.

Depot check blocked: wanted to grep Content/ for VictoryBPFunctionLibrary references (to judge whether disabling the plugin is even an option). Blocked: hydra_admin tickets are expired everywhere (local and on the perforce node). hydraperforce_svc has a valid long-lived ticket but its protections line reads //rupelmondecastleviewer without /..., so it can read nothing under the depot. Fix when hydra_admin is next logged in: edit p4 protect, change the line to read user hydraperforce_svc * //rupelmondecastleviewer/....

Build validation machine approved (Cederik): fluffy-dumpling-87 (node-11da9ea3, RTX 5070 Ti, bxl1, online).

• 1.0 TB free on C:
• Epic Games Launcher installed, UE 5.7 present, UE 5.5.4 must be added (launcher install needed)
• VS 2022 BuildTools with exactly one toolset: MSVC 14.44.35207, the same as Tommaso's VS 17.14. Exact repro of his environment.
• p4.exe present. WDAC is enforced (CodeIntegrityPolicyEnforcementStatus=2): compiling is fine, but locally built unsigned DLLs may be blocked from loading, so the pass/fail signal is the UBT compile, not editor launch.

Plan:

1. Install UE 5.5.4 via the launcher on fluffy-dumpling-87.
2. Sync //rupelmondecastleviewer/main (needs a p4 user; hydra_admin login required first).
3. Run UnrealBuildTool against Rupelmonde.uproject with the stock 14.44 toolset. Expect the same plugin compile failure Tommaso sees. Capture the exact errors.
4. Add the 14.38 toolset headless: vs_buildtools modify --add Microsoft.VisualStudio.Component.VC.14.38.17.8.x64.x86 --quiet, pin via BuildConfiguration.xml, recompile. Expect success.
5. If 14.38 also fails on VictoryBPLibrary, fix the plugin source in the depot (small patches, submitted as a CL) rather than swapping in a foreign prebuilt plugin version, which risks Blueprint node mismatches.

On Gemini's option 3 (replace Victory with a prebuilt 5.5 binary release): hold. A different plugin version can change or drop BlueprintCallable signatures and silently break every Blueprint node that calls into it. Decide only after step 3 shows the real errors.

ROOT CAUSE CONFIRMED AND FIXED: CL 95 (2026-08-11)

Tommaso's full mail arrived with the exact error: C4335 'Mac file format detected', thrown only while compiling VictoryBPLibrary sources. His Gemini-assisted diagnosis pointed at line endings and Perforce translation. That was the right neighborhood, and inspecting the depot directly confirmed a variant of it:

What was actually wrong

• The plugin sources are Perforce filetype text+x (NOT binary, so Gemini's option 1 as stated did not apply).
• But the stored bytes contained literal CRLF. Perforce stores text canonically as LF; the CL 78 import bypassed translation and stored CRLF raw.
• On sync, a Windows client with LineEnd: local (Tommaso's setting, correct) expands every stored LF to CRLF. Stored \r\n therefore arrives as \r\r\n: a stray CR on every line of every file. MSVC sees the stray CRs and reports C4335 Mac format.
• Scan result: 150 of 151 live compiled-source files (.h/.cpp/.c/.cs/.inl) under RupelmondeUE were stored CRLF-literal, including all NVIDIA plugin sources. The single clean file was SJoyColorPicker.h, which is why the failure looked Victory-specific.
• This was a depot-wide import defect, machine independent, exactly as Tommaso feared. Nobody hit it before because until CL 94 no one ever compiled these plugins from source (they shipped prebuilt).

Fix

CL 95 (hydra_admin, 2026-08-11): all 150 files re-stored with canonical LF line endings, content otherwise unchanged. Verified at head: zero CR bytes in the stored content. Windows clients now receive clean CRLF on sync; Linux/Mac clients receive LF.

Also fixed while in there: the hydraperforce_svc protections line was //rupelmondecastleviewer (missing /...); now //rupelmondecastleviewer/....

Corrections to earlier analysis on this issue

• The 2026-08-05 reply told Tommaso 'nothing needs converting'. That was wrong: his first mail's line-ending observation was correct, only the MacOS-only reading was off.
• The MSVC 14.44 toolset hypothesis (previous two comments) is demoted from root cause to open risk. C4335 was the real blocker. Whether VictoryBPLibrary compiles cleanly under 14.44 is still unproven; if the next attempt fails with real C++ errors, the 14.38 pin instructions from the earlier comment are the next step.
• Gemini's options are all superseded: no retype needed (already text), no /wd4335 workaround needed, no plugin swap needed.

Instructions for Tommaso (reply mail drafted)

1. In P4V: Get Latest Revision on the stream. 150 small source files come down (CL 95).
2. Delete local Intermediate\, Binaries\, .vs\, and any .sln under RupelmondeUE\.
3. Open Rupelmonde.uproject directly and accept the module build.
4. If it fails again, send the new Saved\Logs\Rupelmonde.log; next suspect is the MSVC 14.44 toolset (pin instructions already on this issue).

Still open

• Tommaso confirms build success. Close the issue then.
• If 14.44 errors appear, apply the 14.38 toolset pin.
• fluffy-dumpling-87 build-machine validation is ON HOLD; only needed if the retry fails.
• Consider a Perforce typemap/lineend convention note in the onboarding runbook so future imports store text canonically.

Fix validated on our own Windows hardware (fluffy-dumpling-87, 2026-08-11)

Ran the before/after test on the approved build machine, which has the SAME MSVC toolset as Tommaso (14.44.35207 from VS 2022 BuildTools). Test file: VictoryBPFunctionLibrary.cpp (2407 lines). Windows p4 client, LineEnd: local, exactly like Tommaso's workspace.

Pre-fix (synced at CL 94):

• Bytes on disk after sync: CR=4814, LF=2407, CR-followed-by-CR=2407. Every single line arrived as \r\r\n. The corruption is total and deterministic.
• cl.exe /Zs output, line 1: warning C4335: Mac file format detected: please convert the source file to either DOS or UNIX format. Reproduces Tommaso's exact diagnostic. (C4335 is a warning at the raw compiler level; the UE build chain escalates it, which is why it blocked his build.)

Post-fix (synced at head, CL 95):

• Bytes on disk: CR=2407, LF=2407, CR-followed-by-CR=0. Clean CRLF on every line.
• cl.exe /Zs: no C4335.

Temp workspace and files removed from the machine afterwards.

Conclusion: the depot fix is confirmed working for Windows clients with default line-ending settings. Remaining risk before closing: whether the plugins fully compile under Tommaso's 14.44 toolset once UBT actually builds them (the 14.38 pin instructions earlier in this issue remain the fallback). Awaiting his re-sync and rebuild.

Reply sent to Tommaso (2026-08-11):

Hi Tommaso,

You found it. Your line-ending diagnosis was correct, and the fault was in our repository, not on your machine. My earlier reply dismissed the line-ending lead, and that was wrong. Thank you for persisting with it.

The detail is slightly different from Gemini's theory: the files are stored as text in Perforce, not binary. But they were imported with Windows line endings baked into the stored data, where Perforce expects to store plain LF. Your workspace setting "local" was correct, and that is exactly why every sync added an extra CR to every line. The compiler then read the files as Mac-format and refused. This affected 150 source files across all plugins, so it would have broken every Windows developer, exactly as you feared.

I have fixed the repository itself (changelist 95) and verified the fix on one of our own Windows machines with the same compiler version as yours: before the fix it reproduces your exact C4335 error, after the fix it does not. None of Gemini's three options are needed: no re-typing, no compiler flag, no plugin replacement.

What to do now:

1. In P4V, Get Latest Revision on the stream. About 150 small source files come down.
2. Under RupelmondeUE, delete Intermediate, Binaries, .vs\ and any .sln one more time.
3. Open Rupelmonde.uproject directly and accept the module build.

If it fails again, please send the new Rupelmonde.log. The next suspect would be your compiler version (VS 17.14 ships a newer toolset than UE 5.5 was built against), and I have instructions ready for that. But try the plain rebuild first.

Best,
Cederik

Final reply sent to Tommaso 2026-08-11 (short version, supersedes the draft two comments up):

Subject: Fixed — sync and rebuild

Hi Tommaso,

We found the core issue, thanks to your input. Your line-ending diagnosis was right: the repository stored the source files with broken line endings, so every sync on Windows corrupted them. It affected 150 files across all plugins and would have hit every Windows developer. It is now fixed on the server (changelist 95), and we validated the fix on our own machine with your exact compiler version: your C4335 error is gone. None of the three options from your mail are needed.

To get going:

1. In P4V, Get Latest Revision.
2. Delete Intermediate, Binaries, .vs\ and any .sln under RupelmondeUE.
3. Open Rupelmonde.uproject and accept the module build.

Let me know how it goes, either way. If anything still fails, send the new Rupelmonde.log.

Thanks for the clear reports. They led us to the real cause.

Best,
Cederik