Hi I'm making a simple piece of software, that can load models, and textures, I have a default models that can be loaded and then I have models and textures that can be loaded by the user. Whenever a user loads a new model or texture, it switches the file path meaning the default models cannot be loaded.

Before a model and texture gets loaded in by the user, the default file path is simply media/file

Then when a user loads the file then the file directory becomes whatever the user selects.

The only way around this is hardcoding all the file paths instead of media/file it becomes C:/Folder/Folder/media/file

This works fine but if I would ship the software, the files won't be able to open on other computers.

What is a solution to this problem and how do developers avoid this issue?

Thanks

KielanT said:
Before a model and texture gets loaded in by the user, the default file path is simply media/file Then when a user loads the file then the file directory becomes whatever the user selects.

I'm not absolutely sure I understand what you mean. Are you talking about the “working directory"/"current directory", the path the your application resolves all relative file-paths from? And if so, are you talking about this path getting changed after the user opens a file-dialogue? In this case, you have several options to preverse this:

1. You gave no details on how file-loading is done, however I assume you open some kind of file-dialogue. On windows, you have the option of passing “OFN_NOCHANGEDIR” as flags, which will result in the working-directory not being changed
2. Similarily, your OS should have API-functions to directly control those paths yourself. On windows, you have GetCurrentDirectory and SetCurrentDirectory, which you can use to preserve and manipulate the path to your liking, for example storing GetCurrentDirectory and then SetCurrentDirectory after whichever operation changes it to set it back to default.

One more thing that applications do is to assume some paths to not be relative to the current directory at all, but to a specific base directory. Since you mentioned assets/media-files, lets say in my case the base-asset folder is called “Assets”. All asset-files are addressed relative to that folder, ie. “Assets/Textures/Texture.png". What I do then is store the absolute path to that folder at load-time, and then whenever an asset is requested, I eigther construct the absolute path or temporarily change the “current directory” with the API mentioned above to be able to resolve those paths.

Have several paths where you look for stuff. for example, have a “game-owned” directory path for stuff supplied by the game (ie you), and a “user-owned” path for user-supplied stuff.

When you look for something, you first look in the game-owned path, and if not found you look in the user-supplied path.

In such a setup a user cannot override a game-supplied thing. If that is desired, given the user-supplied stuff higher priority (ie look there first).

you can make something like this in Rad Studio (look for avilability of this class of function in other compilers)

1. String appPath; //we create in program this string variable for store the path
2. appPath = ExtractFilePath(Application->ExeName); //now appPath contains the EXE path
3. when you going to load a file relative to harddisk your EXE data folders make like this:
4. const String Pathh = appPath + "folder_models\\" + filename; // filename could be String filename = “file.doc”;
5. then use Pathh where you load the local file

making this way…..always you get the correct path of the EXE application and as supposed the data folders of your “own” files, models, data etc are hanged from that path inside your EXE app then well…..always work without have to hardcode inline manually paths.

Enjoy..

Thank you everyone for your answers, all very helpful

in C++ you have std::filesystem::current_path this will get the current directory where the application is launched from. This is not OS specific.

Everything in the STL is OS specific

The implementation is the interface however is not.