[drsnuggles8]

…th validation

Summary by CodeRabbit

• New Features
  • Added an in-app file picker for choosing the asset pack output path, with smarter default folder selection and path validation.
  • Added a new “Open Output Folder” action that opens the built output location in the system file manager.
• Bug Fixes
  • The output folder action is now disabled when no built pack exists, preventing dead-end clicks.
  • Canceling the file picker now leaves the current output path unchanged.

[coderabbitai]

Warning

Review limit reached

@drsnuggles8, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 52 minutes and 21 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: e7b817d8-64d6-47c2-893a-212706025e3f

📥 Commits

Reviewing files that changed from the base of the PR and between 7ab8720 and 878aa25.

📒 Files selected for processing (3)

• OloEditor/src/Panels/AssetPackBuilderPanel.cpp
• OloEditor/src/Panels/AssetPackBuilderPanel.h
• OloEngine/src/Platform/Windows/WindowsPlatformUtils.cpp

📝 Walkthrough

Walkthrough

The asset pack builder now opens a save dialog for output selection, validates the chosen pack path, tracks whether the built pack exists, and conditionally reveals that output in the system file manager using new Linux and Windows support.

Changes

Asset pack output and reveal flow

Layer / File(s)	Summary
File manager reveal API and platform implementations OloEngine/src/OloEngine/Utils/PlatformUtils.h, OloEngine/src/Platform/Linux/LinuxPlatformUtils.cpp, OloEngine/src/Platform/Windows/WindowsPlatformUtils.cpp	FileDialogs::ShowInFileManager is declared in the utility header and implemented on Linux with detached xdg-open launching and on Windows with ShellExecuteW directory selection.
Build settings output-path picker OloEditor/src/Panels/AssetPackBuilderPanel.cpp	The build settings panel opens a *.olopack save dialog, derives an initial directory from the project asset path or current buffer, normalizes the extension, and updates the buffered output path after validation.
Build results open-folder control OloEditor/src/Panels/AssetPackBuilderPanel.cpp	The build results panel computes outputExists once and only enables the open-folder action when the built output pack exists, then calls FileDialogs::ShowInFileManager for that path.

Sequence Diagrams

sequenceDiagram
  participant AssetPackBuilderPanel
  participant FileDialogs_SaveFile as FileDialogs::SaveFile
  participant ValidateOutputPath

  AssetPackBuilderPanel->>FileDialogs_SaveFile: SaveFile("*.olopack", initialDirectory)
  FileDialogs_SaveFile-->>AssetPackBuilderPanel: selected path or cancel
  AssetPackBuilderPanel->>ValidateOutputPath: validate selected path
  ValidateOutputPath-->>AssetPackBuilderPanel: accepted path or invalid

Loading

sequenceDiagram
  participant AssetPackBuilderPanel
  participant FileDialogs_ShowInFileManager as FileDialogs::ShowInFileManager
  participant LaunchDetached
  participant xdg_open as xdg-open
  participant ShellExecuteW

  AssetPackBuilderPanel->>FileDialogs_ShowInFileManager: ShowInFileManager(m_LastBuildResult.m_OutputPath)
  alt Linux
    FileDialogs_ShowInFileManager->>LaunchDetached: launch xdg-open target
    LaunchDetached->>xdg_open: execvp target
  else Windows
    FileDialogs_ShowInFileManager->>ShellExecuteW: explore or /select
  end

Loading

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title matches the main change: improved asset file dialog behavior with initial directory and output path handling.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@OloEditor/src/Panels/AssetPackBuilderPanel.cpp`:
- Around line 150-187: The Asset Pack output-path handling duplicates the same
normalization, buffer copy, and validation flow in both the dialog branch and
the InputText handler. Refactor the repeated logic in
AssetPackBuilderPanel::ValidateOutputPath and the output-path update path into a
small shared helper such as ApplyOutputPath(std::string path), then call it from
both entry points so .olopack normalization, m_OutputPathBuffer writes, and
m_BuildSettings.m_OutputPath updates stay consistent.
- Around line 179-186: The output path handling in AssetPackBuilderPanel is
silently truncating long paths, which can leave the displayed buffer out of sync
with the validated/stored value. Update the logic in the output-path update
paths (including the handler that writes m_OutputPathBuffer and the manual-entry
path) to reject any selected input that does not fit in m_OutputPathBuffer
instead of memcpy’ing a truncated string. Ensure ValidateOutputPath and
m_BuildSettings.m_OutputPath only accept the same exact, non-truncated path that
m_OutputPathBuffer.data() will later provide to StartBuild().

In `@OloEngine/src/Platform/Linux/LinuxPlatformUtils.cpp`:
- Around line 292-304: LaunchDetached currently hides grandchild execvp failures
because the intermediate child exits 0 as soon as the second fork succeeds, so
the caller can’t tell when the actual launch fails. Update LaunchDetached in
LinuxPlatformUtils.cpp to propagate the grandchild’s exec result back to the
parent, for example by using a close-on-exec pipe or another status handoff
between the intermediate child and the grandchild. Make sure ShowInFileManager
can observe a failed launch so its error path for xdg-open can fire when execvp
fails.

In `@OloEngine/src/Platform/Windows/WindowsPlatformUtils.cpp`:
- Around line 102-113: The Windows file-manager launch paths in
WindowsPlatformUtils::OpenInFileManager (the ShellExecuteW calls for opening a
directory or selecting a file) ignore launch failures, so add return-value
checks for both calls and emit a diagnostic when the HINSTANCE result is <= 32;
keep the existing directory-vs-file behavior, but surface a warning/error
consistent with the documented contract and the Linux backend when Explorer
cannot be launched.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 0985a97a-f435-4437-83a5-c0ee5051df17

📥 Commits

Reviewing files that changed from the base of the PR and between 82a04b8 and 7ab8720.

📒 Files selected for processing (4)

• OloEditor/src/Panels/AssetPackBuilderPanel.cpp
• OloEngine/src/OloEngine/Utils/PlatformUtils.h
• OloEngine/src/Platform/Linux/LinuxPlatformUtils.cpp
• OloEngine/src/Platform/Windows/WindowsPlatformUtils.cpp

[drsnuggles8]

🤖 Self-review (finish-pr) @ 878aa25312df39c921269c5fccc6b06d9d91e969

Reviewed the full PR diff against master at high effort (8 finder angles + verify), independent of CodeRabbit.

Findings: 1 critical (new, not flagged by CodeRabbit) + the 4 CodeRabbit threads.

Fixed:

• CRITICAL — Windows absolute paths rejected: ValidateOutputPath's invalid-char regex [<>:"|?*…] rejected the drive-letter :, so every path the new Browse/SaveFile dialog returns on Windows (C:\…\AssetPack.olopack) failed validation → canBuild went false → the new feature was unusable on Windows. Now strips the path root-name before scanning. Proven with a standalone MSVC std::filesystem snippet: C:\… now accepts, C:\foo\ba<r>.olopack still rejects.
• CR thread (dup logic): extracted ApplyOutputPath(std::string) shared by the text field and the Browse dialog.
• CR thread (buffer truncation): the helper now rejects over-long paths instead of truncating, so the validated/stored path can't desync from the buffer StartBuild() reads.
• CR thread (Windows ShellExecuteW): both calls now warn when (INT_PTR)rc <= 32.
• Hardening: exists(parentDir) uses the error_code overload so it can't throw out of the ImGui render loop.

Dismissed:

• CR thread (Linux LaunchDetached hides execvp failure) — intentional fire-and-forget; the common failure (xdg-open absent) is already pre-checked via IsExecutableInPath; a close-on-exec pipe handoff is disproportionate (CodeRabbit rated it Trivial / Low value / "acceptable for fire-and-forget").
• Per-frame exists()/file_size(), lpstrDefExt pointing at the pattern, InputText append-on-every-keystroke — all pre-existing, not in this PR's diff, out of scope.

Build/test: OloEditor + OloEngine-Tests build clean; suite 3512 passed / 2 skipped. The lone failure (FogVisualEvidenceTest.DistantGeometryFogsNearStaysClear) passes in isolation — pre-existing GL-state-ordering flake, unrelated to this non-rendering diff.