ZDoom

[quote="Rachael"]The errors were fatal in an attempt to actually be helpful[/quote]

Understood, and good point actually. Put it that way, the idea is good and I can support that. So it's just a matter of handling the platform specific ones. No need to kill a fly with a rocket launcher. :D

[url=https://github.com/coelckers/gzdoom/commits/f56ad027162bb16c66bbbfa83b07c155672beb1e]Fixed in these top 3 commits[/url]

I'm going to leave the version check as a fatal error. That is a very important one, due to the way CVARs change between GZDoom versions.

But I've demoted other errors to warnings. (Not pushed to the repo yet)

The major concern here is - the more you demote to warnings - the more likely it is that people will use things incorrectly and distribute broken mods. The errors were fatal in an attempt to actually be helpful - the whole issue that spawned from this was merely an oversight on my end, I should have thought of the platform-specific CVARs and accounted for them.

[quote="_mental_"]To solve initial problem, I would rather change all issues encountered during DEFCVARS parsing to be non-fatal. GZDoom does not stop if autoexec.cfg contains unknown commands or variables.[/quote]

I also suggested this to Rachael in DM - I think the game should just start anyway, not fail to start. :D

To solve initial problem, I would rather change all issues encountered during DEFCVARS parsing to be non-fatal. GZDoom does not stop if autoexec.cfg contains unknown commands or variables.

Yes - the ConfigConverter needs to be updated to ignore those cvars, too - but that's not high on the priority list right now. Right now, GZDoom needs to ignore the CVAR list that m8f gave, completely.

One thing that would be useful to me (particularly because I have *no* way to get those CVARs other than "grep"ing the engine files directly) is if someone gave me a default .ini file from a Mac OS system. I'd like to see if there are any hardware-specific CVARs on there that need to be ignored on other platforms - such as Windows.

[quote="SanyaWaffles"]With all due respect Graf, Nash's game is a standalone game. You might not have intended it, but a lot of people are using your engine for things other than "mods" in a traditional sense.[/quote]
Not trying to dog pile here - just pointing out that with this particular use case, there are options available for custom compiled builds which ignore the rules Graf puts in, particularly if they seem to you to be arbitrary. I actually keep a fork somewhat up to date that allows defcvars to be defined in mods directly, among other things, but it has no business being promoted as an official fork on this site to any extent. Another example is that Hedon has a feature (even though it's really just a hack) that allows it to manipulate certain internal CVARs via ACS. The only real caveat is that the source must always be published and freely available, even if it's a minor change, due to the requirements of the GPL license.

However, this particular one is more about safety than mod customization, really. Those CVARs really have no business being changed. If there's a platform specific CVAR that needs to be set using defcvars then I am all ears if you have any good arguments for why.

Yeah, I agree, mods shouldn't be able to set potentially-unsafe defaults for hardware-specific stuff.

Just to be clear (since my game is brought up here), the DEFCVARS lump was [url=https://forum.zdoom.org/viewtopic.php?f=232&t=66811]generated automatically using a tool[/url], based off a clean GZDoom 4.6.1 installation. So it's not like I'm fighting for control over those variables or something. :P

Maybe ConfigConverter can be improved to weed out hardware-specific stuff from the generated output? Not sure if the engine provides enough information for this though.

Standalone game or not, these are mainly hardware configuration settings unrelated to how the game operates. Defaulting them to something improper can actually break proper operation of the engine. Many of them are for enabling hardware that is disabled by default for good reasons (as in, trying to detect it may not work if the hardware does not exist) Such variables should be off-limits to mods at all.

[quote="Graf Zahl"]no mod should have any business defaulting them to something different than the engine's safe default.[/quote]

With all due respect Graf, Nash's game is a standalone game. You might not have intended it, but a lot of people are using your engine for things other than "mods" in a traditional sense.

Needless to say, all of these are also strict user-side configuration variables, no mod should have any business defaulting them to something different than the engine's safe default.

The defcvars parser should just ignore all those. This was a fairly big oversight that I should have thought of before. Thank you for bringing it up.

That being said - there's no need to clutter things up with dummy cvars. The cvars in question should simply be blacklisted and ignored by the parser without putting in placeholders.

I will work on that tomorrow. It's way too late right now.

[quote="m8f"]Third, the most important issue, is that cvars disablecrashlog, gl_control_tear, in_mouse, joy_dinput, joy_ps2raw, joy_xinput, k_allowfullscreentoggle, k_mergekeys, m_swapbuttons, queryiwad_key, vid_gpuswitch, vr_enable_quadbuffered are Windows-only. Having them in ElderJam.ipk3/defcvars.txt causes errors on Linux. This is also a GZDoom problem. Created a [url=https://forum.zdoom.org/viewtopic.php?f=15&t=73240]feature suggestion[/url].[/quote]

Yeah, this is a problem for standalones. :( I've spoken to Rachael about this... let's wait to see if she has any ideas.

so they can be safely defined in DEFCVARS lump.

At the moment, defining platform-dependent CVARs in an iwad makes causes errors when it's loaded on platforms that don't have those CVARs. [url=https://forum.zdoom.org/viewtopic.php?f=19&t=73228&p=1199339#p1199339]Case in point[/url].

This may cause confusion, though, as irrelevant CVARs will be available, and users may start to think about why a CVAR doesn't affect anything, only to realize that it's for another OS.

Another solution is to make error checking in DEFCVARS more lax and skip undefined CVARs. This has a disadvantage: typos in CVAR names won't be reported anymore.

So, I don't really have ideas what a clean solution for this would be.