Looks like we have a problem here. Apparently in the Morrowind.ini ESX files that are dependencies of other listed ESX files, don't need to be listed; while in openmw.cfg they do need to be listed. That means for certain configurations of Morrowind.ini the -g option will not work.
But we can address that another time. I asked pvdk to enhance the launcher, so that it offers to run the ini importer the first time the launcher is run (a more elaborate launcher integration will follow later).
@pvdk: When implementing this feature, please don't use the -g option.
Write an Morrowind.ini to openmw.cfg converter
Re: Write an Morrowind.ini to openmw.cfg converter
About the fallback task:
There are many settings in Morrowind.ini that belong into ESX records instead, so they can be changed by modders without them having to drag along a modified ini file.
We will look into this after OpenMW 1.0. But we can implement these settings now in a way that will make it easy to make these enhancements later.
There are several distinct steps to this task:
1. Add a fallback key-value pair collection to World. Strings should do the job well enough. What ever subsystem is using the fallback values, can turn them into numerical value (if needed).
These fallback values should be passed in at construction of World. World also needs a function to look up fallback values by key. This function should be error-tolerant, i.e. silently return an empty string, if the key is not there.
2. Add a new --fallback switch to the command line. This should take a key, value pair (look up the boost program options documentation about how to do that). The storage used should be a vector of string pairs and it is important to use the composite feature.
Note that keys can appear several times, if they appear in multiple sources (e.g. user openmw.cfg file and global openmw.cfg). In this case only the source with the highest priority should be considered, which means that duplicate keys need to be removed (look up in source/boost documentation, if the highest priority is listed first or last).
To make clear that we don't have any misunderstandings here: In this case multiple keys are not allowed. This is a different case than what we discussed about openmw.cfg keys.
3. Import usable fallback values from the Morrowind.ini file. Just use the combined section/ini-key as a fallback key. There is a twist though. These keys must work as a part of a boost program option value, from the command line as well as from an openmw.cfg file. That means at least no spaces, but some other special characters might cause problem too. You will have to encode these keys in some way, but make it obvious and easy to use. For example you could replace spaces with underscores.
4. Actually decide that some ini settings are usable fallback values and implement them in OpenMW.
A prime candidate are the questions asked during character creation. After that have a go at weather settings.
There are many settings in Morrowind.ini that belong into ESX records instead, so they can be changed by modders without them having to drag along a modified ini file.
We will look into this after OpenMW 1.0. But we can implement these settings now in a way that will make it easy to make these enhancements later.
There are several distinct steps to this task:
1. Add a fallback key-value pair collection to World. Strings should do the job well enough. What ever subsystem is using the fallback values, can turn them into numerical value (if needed).
These fallback values should be passed in at construction of World. World also needs a function to look up fallback values by key. This function should be error-tolerant, i.e. silently return an empty string, if the key is not there.
2. Add a new --fallback switch to the command line. This should take a key, value pair (look up the boost program options documentation about how to do that). The storage used should be a vector of string pairs and it is important to use the composite feature.
Note that keys can appear several times, if they appear in multiple sources (e.g. user openmw.cfg file and global openmw.cfg). In this case only the source with the highest priority should be considered, which means that duplicate keys need to be removed (look up in source/boost documentation, if the highest priority is listed first or last).
To make clear that we don't have any misunderstandings here: In this case multiple keys are not allowed. This is a different case than what we discussed about openmw.cfg keys.
3. Import usable fallback values from the Morrowind.ini file. Just use the combined section/ini-key as a fallback key. There is a twist though. These keys must work as a part of a boost program option value, from the command line as well as from an openmw.cfg file. That means at least no spaces, but some other special characters might cause problem too. You will have to encode these keys in some way, but make it obvious and easy to use. For example you could replace spaces with underscores.
4. Actually decide that some ini settings are usable fallback values and implement them in OpenMW.
A prime candidate are the questions asked during character creation. After that have a go at weather settings.
Re: Write an Morrowind.ini to openmw.cfg converter
just to make clear I understand everything:
* use the ini importer to import fallback values to a cfg file and flag them as such (prefix or sth)
* merge the fallback values from all cfg files and from the command line
* provide an interface for World subsystems to receive the values
right? (I bet I'm wrong again
)
* use the ini importer to import fallback values to a cfg file and flag them as such (prefix or sth)
* merge the fallback values from all cfg files and from the command line
* provide an interface for World subsystems to receive the values
right? (I bet I'm wrong again
)Re: Write an Morrowind.ini to openmw.cfg converter
Not exactly. That was my first thought too, but it would just lead to a huge load of new command line switches. Instead I propose to use a single option --fallback which takes key-value pairs and can be appear more than once. Basically let the fallback management be completely agnostic about specific keys.use the ini importer to import fallback values to a cfg file and flag them as such (prefix or sth)
That happens automatically. You only need to handle the case when the same fallback key appears more than once.* merge the fallback values from all cfg files and from the command line
Correct.* provide an interface for World subsystems to receive the values
Re: Write an Morrowind.ini to openmw.cfg converter
Zini, please take a look at the code https://github.com/swick/openmw/tree/initocfg
Re: Write an Morrowind.ini to openmw.cfg converter
Not entirely sure. Would have to do some testing. But these are the things I noticed:
- Having the fallback importing optional is kinda pointless, because this is the one part of the importing process that is mandatory
- The fallback table in importer.cpp table could be implemented by a single string per fallback value, if you just replace all unacceptable special characters with underscores. Less to write and less opportunities to make mistakes.
- I do not like the = syntax you have implemented. It is confusing and could possibly cause problems when used from the command line. Alternatives could look like this:
(key, value)
or this:
key, value
or even this (since we made sure that there are no spaces in fallback keys):
key value
- Boost program option should be able to do most of what you implemented on its own and has the advantage that you have better syntax checking for cfg files and the command line. See boost program option custom validators (never used them myself, but they looked like the right tool for the job).
- Having the fallback importing optional is kinda pointless, because this is the one part of the importing process that is mandatory
- The fallback table in importer.cpp table could be implemented by a single string per fallback value, if you just replace all unacceptable special characters with underscores. Less to write and less opportunities to make mistakes.
- I do not like the = syntax you have implemented. It is confusing and could possibly cause problems when used from the command line. Alternatives could look like this:
(key, value)
or this:
key, value
or even this (since we made sure that there are no spaces in fallback keys):
key value
- Boost program option should be able to do most of what you implemented on its own and has the advantage that you have better syntax checking for cfg files and the command line. See boost program option custom validators (never used them myself, but they looked like the right tool for the job).
Re: Write an Morrowind.ini to openmw.cfg converter
should be fixed now.
Re: Write an Morrowind.ini to openmw.cfg converter
github seems to be down right now (wow; that is rare). Will have a look at it later.
Re: Write an Morrowind.ini to openmw.cfg converter
That looks okay-ish. But there are still a few things that could be improved:
1. Your custom validator doesn't do any error checking. It silently discards syntactically invalid --fallback parameters. Not so good.
2. I accidently found an equivalent of our --nosound option in the ini file. that should be added (as a regular option, not a fallback).
3. The command line syntax is awkward to use. Can we streamline it a bit? getting rid of the -i, -c and -o options would do the job. The new syntax could look like this:
mwiniimporter <options> inifile cfgfile (in this case input and output ini files would be the same)
or
mwiniimporter <options> inifile cfginputfile cfgoutput file
The rest looks good. I think once these issues have been addressed, you can start with adding the remaining fallback values and implementing their use.
1. Your custom validator doesn't do any error checking. It silently discards syntactically invalid --fallback parameters. Not so good.
2. I accidently found an equivalent of our --nosound option in the ini file. that should be added (as a regular option, not a fallback).
3. The command line syntax is awkward to use. Can we streamline it a bit? getting rid of the -i, -c and -o options would do the job. The new syntax could look like this:
mwiniimporter <options> inifile cfgfile (in this case input and output ini files would be the same)
or
mwiniimporter <options> inifile cfginputfile cfgoutput file
The rest looks good. I think once these issues have been addressed, you can start with adding the remaining fallback values and implementing their use.
Re: Write an Morrowind.ini to openmw.cfg converter
I can't find a nosound (or sth. like that) option in my ini file. The remaining things should be fixed. Also, I'm not sure if it is the best to go threw the whole code and replace the fixed with the fallback values since the code is not that small. Maybe it's better if a person who knows a subsystem can do the job for it.
Just a thought...
Just a thought...