[Suggestion] Comment faulty lines instead of erasing it in openmw.cfg

Feedback on past, current, and future development.
Post Reply
User avatar
Kloppix
Posts: 32
Joined: 24 Mar 2014, 14:41

[Suggestion] Comment faulty lines instead of erasing it in openmw.cfg

Post by Kloppix »

Is really confusing to keep track of all the deleted lines. As alternative, something like openmw-<date>.old could be created. (or both 8-) )
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: [Suggestion] Comment faulty lines instead of erasing it in openmw.cfg

Post by scrawl »

Can you provide an example, exactly what you did and what happened?

With syntax errors in the settings file, it might be better to point out the error and refuse to start. I can see that the game does complain about errors, but the launcher may not be. You're using the launcher then, I suppose?

Whatever behavior we decide on, the game and launcher should behave consistently. It was probably a mistake to have the launcher use the QT settings reader.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: [Suggestion] Comment faulty lines instead of erasing it in openmw.cfg

Post by AnyOldName3 »

I was under the impression based on my prior investigations that we'd rolled our own settings reader for the launcher (although it did use the Qt version of various data types, so maybe that's what you meant). It's not impossible for it to be ported to Boost like the actual engine uses, though.

As for this specific idea, we may hit a hurdle because whenever the launcher edits the config file, it has a chance to remove any comments that are near lines it changes (so any broken lines that get commented out may just disappear anyway). At one point I did suggest that we could adjust things to allow comments to be more actively preserved, but someone (I'm assuming Zini) said that as it's a file that is edited by a program automatically, we don't want to offer any guarantees about comments, as a program can't really know what they're for, and what interactions may cock them up.
User avatar
Kloppix
Posts: 32
Joined: 24 Mar 2014, 14:41

Re: [Suggestion] Comment faulty lines instead of erasing it in openmw.cfg

Post by Kloppix »

Yes, the problem occurred by clicking on Data Files in the OpenMW Launcher. If the directory or file in “content=<some_path>” or “data=<some_file>” was wrong, the line just vanished. After posting here I also noted it was not possible to write comments in openmw.cfg. The openmw-launcher erased it every time.

Tying to make an example as clear as possible, I deleted everything not necessary from openmw.cfg. Well, guess what? It works now. Malformed “data=” gets ignored and malformed “content=” gets commented with a ## (it seems I was reinventing the wheel).

As I was replied by Scrawl himself, and I don’t want to make a fool of myself in front of the Linus Torvalds of OpenMW, I tried to figure out when a line gets deleted.

It seems it occurs only when the line doesn’t have the form <text><equals sign><text>. For example:

blahblah ←deleted
blahblah= ←deleted
blahblah=yadayada ← not deleted

Comment lines are normally not deleted, but when a line gets deleted, all the comment preceding it get deleted as well. For example:

#1 ←not deleted
content=Siege at Firemoth.esp ←not deleted
#2 ←deleted
#3 ←deleted
blahblah ←deleted
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: [Suggestion] Comment faulty lines instead of erasing it in openmw.cfg

Post by scrawl »

Okay, I got confused here. I was thinking of settings.cfg for some reason, but you're talking about openmw.cfg. Then it's 100% a launcher-only issue, because only the launcher touches openmw.cfg, the game just reads it. Anyway, my suggestion to not start the program when the file has errors still stands (that's probably what the game does, too).

By the way, a plain syntax error vs. setting a non-existing path is a different type of error.
As for this specific idea, we may hit a hurdle because whenever the launcher edits the config file, it has a chance to remove any comments that are near lines it changes (so any broken lines that get commented out may just disappear anyway). At one point I did suggest that we could adjust things to allow comments to be more actively preserved, but someone (I'm assuming Zini) said that as it's a file that is edited by a program automatically, we don't want to offer any guarantees about comments, as a program can't really know what they're for, and what interactions may cock them up.
IIRC preserving comments is handled already.
Post Reply