defcvars.txt

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: defcvars.txt

Re: defcvars.txt

by Graf Zahl » Wed Nov 27, 2019 8:47 am

The only way this can work is with IWADs that define their own namespace, i.e. the IWAD should contain an IWADINFO which defines a config namespace. All other cases need additional work.

Re: defcvars.txt

by Rachael » Wed Nov 27, 2019 8:40 am

Alright.

Would a better solution be for me to try and figure out how to force it to only load from IWADs then, or should I just blacklist some of the internal namespaces (maybe Doom, Heretic, Hexen, Strife, Chex, Hacx, Harmony)?

Re: defcvars.txt

by Graf Zahl » Wed Nov 27, 2019 8:36 am

The main issue with mods is that this alters the CVAR's default, which means that it makes the settings clash with the base. I think without a different CVAR namespace this is going to cause problems outside of IWADS, not to mention, how does this deal with multiple such definitions loaded on top of each other. The current config system is not equipped for it.

Re: defcvars.txt

by Rachael » Wed Nov 27, 2019 8:20 am

_mental_ brought up some points in the PR that should be considered:
  • He suggested moving the function prototype for this out of c_cvars.h since it's only used once - and mostly I agreed with him because that header file is one of the ones that, if it changes, causes nearly the entire project to recompile. So I opted to do a forward declaration instead.
  • There is the issue of whether this should be compatible with regular mods or should only work in IWADs. I really do not see any issue with it working in regular mods. For instance, Brutal Doom is often someone's first introduction to GZDoom. Let's ignore the politics and drama surrounding that project for just a moment - objectively I don't think it would hurt for a project like this to set its own settings for someone who has never used GZDoom before. There is always the option that they can go to the menu and change those settings to their own liking after they get it, and it's likely that they'll probably stick to the settings they are "used" to, which would likely be the settings they got their first impression from anyhow. I am open to differing opinions on this issue, though.
  • Lastly, and this is the big one: He also believes that the 'version' declaration should be optional at the top of the file. I don't particularly mind it either way, but the reason I opted to leave it required was pretty much to learn from past mistakes and nip the problem in the bud: If you are required to set the version now, then it will always be clear what version of GZDoom that the mod is made for.
These are just points for consideration. If there is no objections to the way it is now, I'll probably go ahead and merge this later on today.

Re: defcvars.txt

by Graf Zahl » Wed Nov 27, 2019 12:45 am

Good thinking with the version directive. Without a strict requirement here this could indeed become a problem, like it has with too many other features in the past that had no versioning at all.

Re: defcvars.txt

by Rachael » Tue Nov 26, 2019 10:05 pm

https://github.com/coelckers/gzdoom/pull/981

Okay, I made this a PR, for now. The biggest issue is, it cannot accept float CVARs for whatever reason. (fixed)

Also, I am not 100% sure on the implementation. Right now it requires a "version" directive at the top of the file. The reason I did this is because frequently, CVARs get renamed or changed or removed, and this is meant to provide a means to account for that so that older mods will always continue to work.

Re: defcvars.txt

by SanyaWaffles » Tue Nov 26, 2019 8:11 pm

I need this. Honestly I've been having to use a gzdoom.ini to enable freelook by default and it's so hacky.

Re: defcvars.txt

by Rachael » Tue Nov 26, 2019 2:56 pm

Well - you're right about some of the ideas being the same, ie you can set user settings in advance and they'll take effect if the user doesn't already have a config file. However, they will not separate out into a separate config file for your mod. So mod namespacing will still be very important.

Re: defcvars.txt

by Caligari87 » Tue Nov 26, 2019 2:05 pm

Understandable, and that's fine. I just wanted to make sure it was seen in this context since a lot of the goals are similar, I believe. (EDIT: Unless I've misunderstood the reason or scope of your idea?)

Looking forward to seeing what you come up with!

8-)

Re: defcvars.txt

by Rachael » Tue Nov 26, 2019 1:53 pm

Caligari87 wrote:I made a suggestion recently that treads some similar ground; I'd like to see some points from that one considered even if the implementation ends up being different.

8-)
Your idea certainly is possible and has some merit, but the actual implementation details of it I think will quickly get very complex. GZDoom loads certain settings in advance, among these at the very least so it can actually find your game data and your mods. It also quite likely loads global config at this time, too. The thing is, as it stands right now, if the user were to change things like their resolution, it would be saved to the new config, and would not take effect on the next launch. Which I think would be a bit of work to change this.

GZDoom would have to fundamentally change how it does user config files in order for this idea to work.

Re: defcvars.txt

by Graf Zahl » Tue Nov 26, 2019 1:36 pm

Uni-000 wrote:
Graf Zahl wrote:Sounds like a good idea - especially when comparing it to the godawful hackery EDuke32 did to achieve the same thing.
I wonder what it looked like? Seeing it would help me figure out what Hackery was done.
EDuke has chosen to use their CON scripts as their universal setup tool. So they added commands to it to alter CVAR values. So far, so good, but the whole thing has zero protection so any mod so inclined can pretty much whack the entire user configuration.

Re: defcvars.txt

by Caligari87 » Tue Nov 26, 2019 1:24 pm

I made a suggestion recently that treads some similar ground; I'd like to see some points from that one considered even if the implementation ends up being different.

8-)

Re: defcvars.txt

by Uni-000 » Tue Nov 26, 2019 12:48 pm

Graf Zahl wrote:Sounds like a good idea - especially when comparing it to the godawful hackery EDuke32 did to achieve the same thing.
I wonder what it looked like? Seeing it would help me figure out what Hackery was done.

But still, Nice Idea Rachael.

Re: defcvars.txt

by Graf Zahl » Tue Nov 26, 2019 10:28 am

Sounds like a good idea - especially when comparing it to the godawful hackery EDuke32 did to achieve the same thing.

defcvars.txt

by Rachael » Tue Nov 26, 2019 10:19 am

This file would override the CVAR defaults (but not actual user settings). Companion to 'defbinds'

The purpose of this cvar would be for .iwad and .ipk3 games to avoid needing a gzdoom.ini packaged in, and it would also affect what the "Reset To Defaults" menu resets to.

Unlike defbinds though I don't think CVAR defaults should be removed from the source entirely - I know I sure would not be willing to put in the work to do that. Just having a defaults override is enough.

I want to see if this idea makes it past the "no way" phase before I invest time into it.

Top