Fix GUE media imports from absolute paths#64
Draft
CoreyRDean wants to merge 2 commits into
Draft
Conversation
Pin the path extraction and copy-decision rules for GUE media imports so later fixes can preserve the intended behavior for project-local and external selections.
Route mesh, texture, sound, and music imports through the shared media-import helper so project-local selections are recognized correctly and external absolute paths still copy into the chosen media folder.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Non-technical summary
This fixes a reliability bug in the GUE media import flow. Adding meshes, textures, sounds, or music now correctly recognizes files that are already inside the current project's
Data/...tree even when the file dialog returns an absolute path, and it still copies truly external selections into the chosen media folder.This matters now because the existing code was slicing paths with hardcoded
Data\\...offsets, which could mis-handle absolute selections and produce the wrong imported filename. After this change, project-local picks resolve to the expected relative media path instead of being treated like arbitrary external files.Technical summary
src/Modules/MediaImport.bbto centralize slash normalization, absolute-vs-relative detection, project-root matching, and relative media-path extractionsrc/Tests/Modules/MediaImportTest.bbto pin behavior for project-relative selections, absolute project-local selections, external absolute paths, and external folder importssrc/GUE.bbso mesh, texture, sound, and music imports all use the shared helper instead of duplicated string slicingData\\Meshes,Data\\Textures,Data\\Sounds, orData\\MusicValidation
git diff --check./compiler/BlitzForge/compile.sh, but the pinned BlitzForge submodule failed on this macOS host before producingcompiler/BlitzForge/bin/blitzcc(windows.h/_declspec/std::clogbuild errors in the dependency)blitzccwas not produced,./test.shcould not be run in this environmentAdditional notes
Trade-off: I kept the fix scoped to the GUE media-add flow instead of widening it into a repo-wide path-policy refactor.
Deferred follow-up: once the pinned BlitzForge macOS build is healthy again, the new Blitz test should be compiled as part of the normal
./test.shsweep to convert this from static proof plus targeted test coverage into compiler-backed validation.Remaining gap: this change does not alter runtime media loading or Project Manager publishing behavior; it only fixes the import-path boundary in GUE.