Configuration & Packaging

[pvdk]

When you use spaces in paths you must surround them with double-quotes character (or escape them with backslash, but I don't know if escaping work on Windows) - you can check this behavior in Windows "cmd" shell and in Linux shell.

True, but this wasn't needed before. As such, existing configuration files which contain spaces will fail.

[lgromanowski]

When you use spaces in paths you must surround them with double-quotes character (or escape them with backslash, but I don't know if escaping work on Windows) - you can check this behavior in Windows "cmd" shell and in Linux shell.

True, but this wasn't needed before. As such, existing configuration files which contain spaces will fail.

Previously it wasn't needed because there was used std::vector<std::string> as a path container, now there is Files::PathContainer which is std::vector<boost::filesystem::path>. There is some information why it fails when there is a space in path: http://boost.2283326.n4.nabble.com/prog ... 76490.html . Right now I can't find clean and nice solution for this, but will try to find something.

[lgromanowski]

And I got a bug myself during testing.

Tried to set my data path to

data=?local?data

in the openmw.cfg file, which should point to the data directory in the local directory (alongside the uninstalled binary). But OpenMW can't find this directory.

Yes, this is a bug, because I assumed that the ?tag? path is with "data" suffix, so it will be only data=?local? line in openmw.cfg. I'm workning on this, and I will commit fix today (probably around 23:00).

Fix is commited and pushed.

[Zini]

There is some information why it fails when there is a space in path: http://boost.2283326.n4.nabble.com/prog ... 76490.html . Right now I can't find clean and nice solution for this, but will try to find something.

Okay. I think that can wait until 0.13.0. When migrating from 0.12.0 to 0.13.0 all old openmw.cfg files should be removed anyway. I will adjust the new cfg file accordingly.

[Zini]

Yes, this is a bug, because I assumed that the ?tag? path is with "data" suffix, so it will be only data=?local? line in openmw.cfg. I'm workning on this, and I will commit fix today (probably around 23:00).

Still doesn't work for me.

This is my current user location openmw.cfg file:

master=Morrowind.esm
master=Tribunal.esm
master=Bloodmoon.esm
data=?local?data2

Just for testing purpose.

This is the output I am getting:

Skipping invalid directory: ./data/openmw/
Skipping invalid directory: ./data/openmw/

There are two things wrong here: First we are getting two directories instead of one. Second the names of the directories is not related to the name of the directory in the cfg file.

[Zini]

The error message is a relict from the previous configuration system (it was checking if the directory exists). Since the configuration manager is supposed to sort out all non-existent directories, it should not show up anymore. That it shows up two times, might be caused by accessing the data directories in two different places (so not an error as I originally thought).

However the token-replacement mechanism is definitely not working. The generated tempPath is wrong. I don't have the time to look into this problem myself right now.

I see another problem (unrelated to this bug): The existence of directories is only checked if the data path contains a token. But it should be checked for all data paths.

Edit: A quick look at linuxpath revealed a lot of bad code. The whole LocalDataPath, GlobalDataPath and UserDataPath stuff still hasn't been cleaned out completely. I assume we have similar problems for the other platforms.

[lgromanowski]

However the token-replacement mechanism is definitely not working. The generated tempPath is wrong. I don't have the time to look into this problem myself right now.

I made some test and for your posted openmw.cfg it worked. I will check this again today.

I see another problem (unrelated to this bug): The existence of directories is only checked if the data path contains a token. But it should be checked for all data paths.

Rest of paths are checked when they are inserted into MultiDirCollection, but it's not a problem to add another check in configuration if you say.

Edit: A quick look at linuxpath revealed a lot of bad code. The whole LocalDataPath, GlobalDataPath and UserDataPath stuff still hasn't been cleaned out completely. I assume we have similar problems for the other platforms.

Zini, please be more specific. What do you mean by "bad code" in linuxpath (please show exact places)? How do you want to make this working without *DataPath() methods? You changed/extended meaning of this task few times without concrete description and requirements and I'm a bit confused about how this should look and work.

// EDIT: Added upper part of post.

[Zini]

Really did not have the time to look into it, but did anyway

The situation is getting more confusing the longer I look at it. It seems that linuxpath is trying to store global files in two separate locations. And probably the same for the local files. This is completely incompatible with the design I developed for the new configuration system.

I guess that might be a usual thing on Linux (don't really know enough about these Linux specifics).
But if that is true, in the worst case we need to design/write the whole configuration system from scratch.

I sum up the situation again:

- we have configuration files (can be stored in local/global/user location)
- we have log files (I assume that should be written to user location, but it is the same as above?)
- we have additional resources files (--resources, not handled by the configuration manager; stored in a suitable location)
- we have data directories; these are specified by --data, --data-local and can be anywhere on the filesystem. There are four specific locations that can be specified instead of absolute paths (global, user, local, install). These can be accessed via the "Token"-system and should point to a OpenMW specific location, but without any /data part in it.

I pushed a temporary workaround to my config branch, which should get the configuration at least to a partially working state.

I was about to write the following:

It might be enough for a release, though we definitely have to review to whole thing again.
Could all the packagers please try to build a package based on my config branch and then upload it to a suitable location (github?). Again, this is only for internal testing. Please give the uploaded file a name that makes this clear (alpha or something).

(actually I think my commit made it worse, so we should better forgot about it)

but then I looked into windowspath.cpp and saw more problems. The way boost::filesystem::path paths are composed looks a bit suspicious. And also, the paths seem to mostly point to the wrong location.


Seems like we have driven ourself into an dead end. Or maybe it is just the frustration speaking out of me. Sorry, right now I don't know what to do about the problem.

[Zini]

You changed/extended meaning of this task few times without concrete description and requirements and I'm a bit confused about how this should look and work.

Actually, I did not; with the exception of the token system, which is an idea I came up slightly later than the original design (to save us from having platform specific openmw.cfg files).

But it seems there were many breakdowns of communication and misunderstandings.

[Zini]

Alight. Suddenly had an enlightenment. This might be (at least partially) the source of the confusion:

We have a set of locations that could be called data directory (I didn't use this term before; didn't even think of it that the term could be used this way in this context).
And then we have another set of locations that are called data directory (this is what a meant all the time when I talked about data directories).

The first one (1) is an application and platform specific location where additional application data can be stored). These come in the user, local and global flavour. Usually the path should end with something like /openmw.

The second one (2) are specific directories that take the role of the original "Data Files" directory in MW. These can be located anywhere on the filesystem and can have any name. These are specified with --data and --data-local. We use the "Token" system to offer a way to place these into (1) locations in a platform-independent way.

Does that make any sense?