search

OutpostUniverse / OP2Utility

C++ library for working with Outpost 2 related files and tasks.
MIT License
4 stars 0 forks source link

Fix msvc bug in x file get files from directory #243

Closed Brett208 closed 5 years ago

Brett208 commented 5 years ago

Typing OP2MapImager sgame6.op2 does not work on MSVC. The ResourceManager cannot find any archives because it is passed a relative directory of '/' (not './').

DanRStevens commented 5 years ago

I was looking back at this and trying to figure out what is the nature of the problem being addressed here. It was a little unclear to me what the problem is, and what conditions lead to this problem.

I tried running (on Linux), from the Outpost 2 folder:

$OP2MapImagerPath/OP2MapImager SGAME6.OP2

Using the master version of OP2MapImager, this ran and resulted in a version tag error.

I updated the OP2Utility submodule to it's master branch and rebuilt OP2MapImager. I re-ran the above test, and it produced the error message:

Unable to find the tileset well0000.bmp in the directory or in a given archive (.vol).

I assume this later message is the error this is meant to address.

Brett208 commented 5 years ago

Yes, we have fixed the bug with saved game rendering in other development that has been merged in.

Somewhere along the way, we have introduced or uncovered another directory or filename bug where we are no longer able to locate the tilesets while they are packaged. (I think this is the gist anyways)

I wanted to treat /Test as a relative directory, which I think fixed the issue on MSVC. It sounds like you treat this as an absolute directory? I haven't circled back around to figure out what to do to resolve. I also have not researched what is considered standard. Can I assume that you are certain that /Test/ would indicate an absolute directory to others and not a relative directory?

Thanks, Brett

DanRStevens commented 5 years ago

Clarification:

According to std::filesystem::path::is_absolute,is_relative, the path "/" is absolute on a POSIX OS, and relative on Windows. This statement may be a little misleading though, in that on both systems, "/" refers to the root of the filesystem, and hence is an absolute path within a filesystem. The difference is that on a POSIX OS, there is only 1 root filesystem, where all physical drives (and their local filesystem types: NTFS, FAT32, EXT3, EXT4, etc.) are mounted as folders within that filesystem. In contrast, Windows has multiple filesystems, identified by a drive letter. As Windows has both a current working directory, and a current drive, a path may be relative to either. Hence "/" is not sufficient to mark a globally unique path on Windows since it doesn't specify the drive, and so is still relative to the current drive. It is however absolute within the context of a particular drive. Or, put another way, any path starting with "/" is definitely not relative to the current working directory (on any system).

In summary, I would treat "/Test" as an absolute path, (or something close enough to it, modulo terminology and context). At the very least, it's not relative to the current working directory.

This PR can probably be closed now, as the fix from the other PR has been merged in.

Brett208 commented 5 years ago

Okay, that makes sense. Thank you for explaining what you meant.

-Brett