That custom configs page you referenced is actually meant to be part of the installation steps, but also a reference. I'm not sure how you installed mastercomfig or found the GitHub readme to be the place to go but on the download page, the docs site is linked. There are next buttons on the page which are intended to lead you to the next page in the install process. This is what I was saying earlier about making the current pages reference only and making a dedicated installation guide page, so that there aren't these buttons to find and everything is a clear step rather than being descriptive.

The whole config is made to be changed, unfortunately there was one case where I didn't know the full extent of the texture limit command, and have since removed it. If I knew what it did entirely and kept it, I would have added it to the modules so that it isn't incompatible.

Yeah, I learn more about the game, listen to feedback, test things, etc that make the config better with updates. I don't think updating a config should be a hassle.

I would say most of the config is commands, yes.

Also could you go into more detail about what's being obfuscated here? It's not a wrapper for simplicity, these were meant to solve real problems with the config that came up over time.

Hi @Comanglia! Thanks for the feedback.

1&2. Ultimately, I think this is a mindset issue with how the config is currently structured. For your example, your first instinct was to dig through the VPK in order to change the interp for sniper, where you could have used the framework for changing interp (snapshots_balanced) in user/sniper.cfg, as in the documentation. Now, I understand that people have that instinct now, and that's why I will be making a manual package version so that you don't have to change your mindset when approaching these issues. And just FYI, you can access the commented version of comfig.cfg here.

Additionally, I'm currently testing hitscan with balanced, so that projectiles and hitscan have the same settings as they did a few months ago.

3. I feel like this is a misconception. You'd never want to disable occlusion. If you have a weak GPU that needs to do more work on the CPU, then you'd be using bad GPU. If you don't match the description for bad GPU, you don't need to change those sorts of things.

As for texture bugs, only very low used the texture memory limit for a very short time. Additionally, in the future, this is the benefit to the modules system. It changes settings together so everything stays compatible. Maybe I'm misunderstanding what you're asking for though.

4. I've been planning to do a repass on the modules and presets soon, and will probably be condensing and simplifying them to match use cases better with less analysis paralysis by having less meaningless choices which barely make a difference and screenshots/better explanations which demonstrate the changes made by each.

So is your feedback saying that I should make the graphics similar to Comanglia? If not, customizing the graphics would always require looking stuff up, unless I'm not getting something?

Hey all! Thanks for all the great suggestions and feedback. I was actually nervous about posting this and felt it might have been taken the wrong way, but thank you all for being really helpful and starting a productive conversation. At this point, I think I have a way forward to solve these issues, broken up into individual phases.

Short term, I will be working to make the existing documentation devoid of all instructions and rather make it a descriptive reference for the config. This will help focus the current pages to cover all features of the config (along with their reasoning), rather than being a confusing and awkward mix of both instructions and reference. To replace the instructions, I will be making a new page with a step by step guide, accompanied by a GIF for each step, as well as a full video tutorial on how to install the config. The steps themselves will also be revised, removing things like the clean up step which seems to be most daunting step (also ironically the first). Next, I will be adding migration guides from Comanglia, cfg.tf and tf2mate which should cover the vast majority of config usage and similar variants.

Longer term, I will be reworking how I release the config. There will be two release channels, stable and pre. Stable will be a more tested and less frequently updated version of the config released around every month. Pre will continue the sometimes daily updates that mastercomfig currently provides, where I may test things and revert them the next day. Pre will be the default. In addition to new release channels, there will be two mastercomfig packages. One will be as it exists currently, and called auto. This will be the default. The new package being added will be manual. This one will have to be manually set up from your own configs, so you use what you want and don't have sudden breakage. All these switches will be provided on the download page, with an explanation of the differences between each, plus a link on how to install either package.

After that in the future, I will be releasing the new app. This one will have a smoother installation proccess than the previous one. Additionally, it will have a flexible and advanced scripting backend which will allow me to better manage how the app generates configs and for you to customize the entire generation process (through the app's menus or by writing code yourself). This was a problem in 7 and ultimately made it too hard to maintain.

Again, thanks so much for taking the time to share your thoughts. I really enjoyed it and hope to continue conversing with the TF2 community to keep on improving mastercomfig together. If you have any further suggestions, the discussion is completely still open so feel free! I'd love to hear your thoughts on these plans and any other remaining concerns.

Look for Download user/autoexec.cfg template file in advanced files here: https://www.mastercomfig.com/download

Is that what you want? Or the defaults uncommented?

Ok, that explanation is good. I'll look into that, sort of two "modes" for the config. Auto and advanced, where you fully control mastercomfig within your own configs in the advanced version, and the auto version works similar to how it works now.

I am working on a new app, but I want to make a full language for generating config values so the backend is easier for me to manage and scale up over time (for things like keybindings, class configs, etc).

I'm having a hard time understanding what the difference would be vs a VPK in that case. There's still extra setup of adding exec gfx. It's just the other way around in the VPK, the config exec user/autoexec (and for class configs, too). If it was the opposite way, people would have to edit each of their class configs as well. Why should one be preferred over the other in your opinion?

Wouldn't that be more complicated? Then you have to edit a bunch of files, set up a bunch of execs, and then package it using scripts. (btw, I already release a zip package which is what the VPK is based on). In any case, it is a bunch of work that one would have to redo every time they update. Can you go more into why this would be preferable to some people and how they would use it so I can set it up properly?

Could you go into more detail about how you use a .cfg file to be more easily customizable than mastercomfig is?

Depends on what you mean by simple

Hey all, love the feedback so far but could you help me figure out solutions to what I outlined in #10? I'm really having trouble thinking of a solution and I'd really appreciate your help.

8.3.7 released with FPS improvements and bug fixes.

Changelog
Support me

This release took 7 hours to produce. If you like the work I do, consider supporting me!

remove checks and balances to own the libs

And to describe how I understand the responses so far, essentially these are the following problems:

* Installation instructions are too verbose, overwhelming, have too many steps and have a lot of text with no examples, easy to follow guides or actual steps. Instead, they read more like descriptions of the process rather than the actual process. The steps themselves are still too overwhelming even if there were clear instructions.
* It isn't clear where to go for support or help with issues.
* The config does things or requires things that have no explanation as to why that happens.
* The VPK can be very hard to figure out and is very different from how people are used to using configs. There are many advantages to text files, and those things are hard to let go of.
* Previous config setups are hard to move/confusing to move over.
* Some settings are unconventional, not explained and hard to understand what the meaning or purpose of specific settings are.

Could you elaborate on how you determined the net settings were weird? I'd love to address specific problems you encountered with hitreg or any other networking issue. Is it a specific value or behavior that is messing it up for you?

Ok, thank you for the responses so far. All very good and useful feedback, but I want to start a conversation for some of these topics so we can get the best result possible. So, just to share some of my views with you all to show you what problems I was solving with each aspect of mastercomfig, just so you can maybe think of another solution or compromise, or at least become more sympathetic to what I'm trying to do. This isn't me trying to convince you or change your mind, only to share with you my perspective so that we can better communicate the way forward to solve these issues you guys brought up so far.

mastercomfig updates very frequently. It can be hard to keep up if the update process is anything other than drag and replaces the VPKs in your custom folder because you have to redo your changes every time you update. I thought it would be a worthwhile compromise to have an initial long context switch to VPKs from cfgs and a very low barrier to updating so that people wouldn't be inclined to stay on a super old version of mastercomfig. Additionally, mastercomfig is not just an autoexec config. It has lots of other modifications within TF2's script files which can only be loaded in the custom folder. For example, I unlock usually hidden/protected commands for disabling sound DSP, disabling ropes completely, decreasing water splash particles, and more, as well as adjusting what content is preloaded to have memory be used better. Finally, lots of people would complain that they didn't know how to switch between presets easily or remove the config back when it was text files, and now it's a simple VPK removal process. But even with all of that, I have actually started to release ZIP packages of the config, you can find them in the advanced downloads section, for those who don't mind what I think is a headache, and they include comments.

Now, about comments... Comments are all still there, on the GitHub page as well as in the ZIP package. They're only removed from the VPK since there's no reason to open up the VPK, and to save space. Comments were doubling or tripling the size of the VPKs and given that most people aren't even going to open them and there isn't a reason to just to check comments, they're stripped out there.

mastercomfig uses class configs due to a bug or feature in the Source Engine which does not execute game.cfg on map joins in multiplayer clients. Maps have some entities in them sometimes which set values of console commands which mastercomfig sets: detail prop distance values, and water distance values. The class configs are meant to be a workaround to set these settings to get more FPS by setting them to the config values after the map sets them. Additionally, they do some memory cleanup commands so that the game doesn't get bloated over time on long running games. I've tried making this process easier, by making it so you only need to create a user folder where your class configs are and then drag them all in there, instead of making it renamed.

mastercomfig has a modules system which is completely optional, you can use the autoexec in a user folder to use individual commands. With VPKs, the values in the config are static. Modules are used so people can get around having to set a command to a different value from the config, which may cause a system reload and thus longer startup times. Modules are able to replace what the config runs, so that you only run the command once.

Thank you for reading :) I hope to see your thoughts soon on how we can address some of these things in a way that makes everyone happy.

Hi! I'm committed to making mastercomfig the best possible config, and that includes making the config more appealing to those who have decided not to use it or continue using it. If there's any aspect of mastercomfig that you feel could be changed or improved that is making you currently not use it, please let me know! I'd love to address it and make the config better for the TF2 community.

If you're reading this and are a mastercomfig user, but are annoyed by something, feel like you need to change a mastercomfig default as soon as you install the config, or really anything else, I'd love to hear from you too!

Thanks all!

8.3.6 released with bug fixes and quality of life improvements.

Changelog
Support me

This release took 4 hours to produce. If you like the work I do, consider supporting me!

This will be fixed in mastercomfig 8.3.6.