What version of mastercomfig are you on? If you are on 8.3.8, does this still happen on 8.3.5? If it does, does it happen on 8.3.4?

What's your config?

You can enable sprays by entering this into your modules.cfg file:

sprays=on

This will run the settings needed to enable sprays (as you say, there are some that break sprays -- this module fixes them), though keep in mind that because sprays are decals, you will need to enable decals as well, which you can do by entering this into your modules.cfg file for a low amount of decals:

decals=low

For more information, you can check the modules page in the mastercomfig docs:
https://docs.mastercomfig.com/en/latest/customization/modules/#general-decals

I think this pack fixes pyro flames: https://github.com/agrastiOs/Ultimate-TF2-Visual-Fix-Pack

As announced in the main thread, mastercomfig 8.3.8 comes with the aforementioned documentation updates for installation, which are linked to from the download page at "Initial Setup Instructions"

I'll be adding GIFs to these steps soon, and then the video tutorial and then finally add transition guide after that.

I'd like to hear everyone's feedback about these changes before I fully commit to the GIFs and video though.

8.3.8 released with documentation updates, performance improvements, and quality of life enhancements.

Changelog
Support me

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

This will be fixed in the next release.

tf/cfg/user folder is not obsolete. We keep the documentation up to date for every release.

I understand that you want to dig into the files but most users do not. But I'm still going to be releasing a manual package for those who do.

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.