You could optimize things a lot by fixing cp_sunshine
Upvote
Upvoted
33
Downvote
Downvoted
Feedback from people who don't use mastercomfig
posted in
Customization
Your work is amazing mastercoms, really well readable and very well explained. And as it stands for me it has no flaws.
Your work is amazing mastercoms, really well readable and very well explained. And as it stands for me it has no flaws.
mastercomsHey 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.
Honestly I think a new UI installer would help which automatically moves the user files to the right directory on the first installation, and allows for customization at three levels: preset > module selection > individual setting selection. You already have existing documentation for each of these customization levels which you can add to help users make the right choices for themselves. In this way, users can customize their config up to the level that they feel comfortable with while still allowing them to tweak little details if they have the need to do so.
Edit: I'm already a user though and I personally have no problems with the way it works now.
[quote=mastercoms]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.[/quote]
Honestly I think a new UI installer would help which automatically moves the user files to the right directory on the first installation, and allows for customization at three levels: preset > module selection > individual setting selection. You already have existing documentation for each of these customization levels which you can add to help users make the right choices for themselves. In this way, users can customize their config up to the level that they feel comfortable with while still allowing them to tweak little details if they have the need to do so.
Edit: I'm already a user though and I personally have no problems with the way it works now.
Honestly I think a new UI installer would help which automatically moves the user files to the right directory on the first installation, and allows for customization at three levels: preset > module selection > individual setting selection. You already have existing documentation for each of these customization levels which you can add to help users make the right choices for themselves. In this way, users can customize their config up to the level that they feel comfortable with while still allowing them to tweak little details if they have the need to do so.
Edit: I'm already a user though and I personally have no problems with the way it works now.
hamahamits 1 cfg file with comments on what each command does, no aliases, everything sorted after category (mat commands in mat category, r commands in r category, seperated by //------------------)
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?
scrambledKeep in mind that a lot of people who are interested in custom configs already have one and know how it works, roughly. Releasing one comfig.cfg for people to plonk in /custom and add exec comfig and preset=medium to their autoexec.cfg that they're already familiar with and comfortable using might be preferable to some random file that changes everything they're used to using. The zip package is not branded as a functional install but more of a here's the code for nerds to look through, useless to the end user.
A power user could go to /tf/mastercomfig and run a script that clones and makes the comfig to their settings (presets etc.)
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.
cellBring back Mastercomfig 7
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).
[quote=hamaham]its 1 cfg file with comments on what each command does, no aliases, everything sorted after category (mat commands in mat category, r commands in r category, seperated by //------------------)[/quote]
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?
[quote=scrambled]
Keep in mind that a lot of people who are interested in custom configs already have one and know how it works, roughly. Releasing one comfig.cfg for people to plonk in /custom and add exec comfig and preset=medium to their autoexec.cfg that they're already familiar with and comfortable using might be preferable to some random file that changes everything they're used to using. The zip package is not branded as a functional install but more of a here's the code for nerds to look through, useless to the end user.
A power user could go to /tf/mastercomfig and run a script that clones and makes the comfig to their settings (presets etc.)[/quote]
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.
[quote=cell]Bring back Mastercomfig 7[/quote]
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).
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?
[quote=scrambled]
Keep in mind that a lot of people who are interested in custom configs already have one and know how it works, roughly. Releasing one comfig.cfg for people to plonk in /custom and add exec comfig and preset=medium to their autoexec.cfg that they're already familiar with and comfortable using might be preferable to some random file that changes everything they're used to using. The zip package is not branded as a functional install but more of a here's the code for nerds to look through, useless to the end user.
A power user could go to /tf/mastercomfig and run a script that clones and makes the comfig to their settings (presets etc.)[/quote]
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.
[quote=cell]Bring back Mastercomfig 7[/quote]
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).
seems to me that a simple 5 minutes youtube tutorial showing how to install it would fix the majority of accessibility issues. for a lot of people text is really scary but when you just actually show how it's done it it becomes really easy to follow along especially if they can see it's a 5 minute video and won't take long at all. ps I love your work and have mad respect for how clean, thorough and diligent you are with this project.
seems to me that a simple 5 minutes youtube tutorial showing how to install it would fix the majority of accessibility issues. for a lot of people text is really scary but when you just actually show how it's done it it becomes really easy to follow along especially if they can see it's a 5 minute video and won't take long at all. ps I love your work and have mad respect for how clean, thorough and diligent you are with this project.
an exe installer to help with installation and customisation would actually be sick
in the installer you could have a box for the players own custom shit that would get loaded after everything
an exe installer to help with installation and customisation would actually be sick
in the installer you could have a box for the players own custom shit that would get loaded after everything
in the installer you could have a box for the players own custom shit that would get loaded after everything
mastercomshamahamits 1 cfg file with comments on what each command does, no aliases, everything sorted after category (mat commands in mat category, r commands in r category, seperated by //------------------)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?
ye but an actual config
[quote=mastercoms][quote=hamaham]its 1 cfg file with comments on what each command does, no aliases, everything sorted after category (mat commands in mat category, r commands in r category, seperated by //------------------)[/quote]
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?
[/quote]
ye but an actual config
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?
[/quote]
ye but an actual config
Yeah echoing everyone else and installer or video would be really nice, even for someone who has messed around with a lot of configs (and is studying cs lol) it was pretty difficult for me to figure out and I didn't get around to it for a long time. I don't think most people understand what a vpk even is not to mention how to use it, so making a more simplified text version that maybe updates less often would be good. If you want one that is dynamic and can update each module when it needs then you should be able to get that, but having a simpler way would definitely go along way for the average user. Mad props for all the work you've done and how clean it is.
Yeah echoing everyone else and installer or video would be really nice, even for someone who has messed around with a lot of configs (and is studying cs lol) it was pretty difficult for me to figure out and I didn't get around to it for a long time. I don't think most people understand what a vpk even is not to mention how to use it, so making a more simplified text version that maybe updates less often would be good. If you want one that is dynamic and can update each module when it needs then you should be able to get that, but having a simpler way would definitely go along way for the average user. Mad props for all the work you've done and how clean it is.
I think the video suggestion is the best cost-effective.
Two issues I had from moving from 6 to 7:
1. I was used to having my own text file, so I would only compare it to yours upon updates, rather than using yours. I liked my custom settings, organization etc.
2. Sometimes the changelog would have vague information (e.g. "increased amount of time spent on panels") and I'd like to see the actual number.
Some suggestions:
1. Bring the documentation as forward as possible. At least when version 7 was the current one, I had to dig into GitHub to find the raw version of the vpk file. Sure, I could open the vpk, but it didn't have the comments, as already brought up by others.
2. Centralize the resources on one place. I'm a Discord user. I'm used to browse GitHub. I browse webpages (duh). But not many players are used to these different tools, so it can be a bit overwhelming as well. "You can download it here, ask questions there and browse the documentation over there". I know you use GitHub for hosting and Discord makes conversations quicker than a forum like tf.tv, but I believe it even burdens you to keep so many resources up to date with the changes. I think you can structure Discord to act as everything, with their fancy tree server structure and bots, and leave GitHub as nothing but backend.
3. Parallel to the suggestion of dropping the site, for example, while at it, the landing page is beautiful. Not the quickest of tours, but it does have its goals: to sell the product, I get it. But when you go to the docs (https://docs.mastercomfig.com/en/stable/) the information feels cramped. Sure, there's the left bar menu, but doesn't look inviting to skim through each item.
4. One tiny complaint I have: whenever there's an update, if I feel like there's a small chance of it affecting a specific optional file, I just redownload them all. So having a "last updated:" to the right of each module would be great.
I think the video suggestion is the best cost-effective.
Two issues I had from moving from 6 to 7:
1. I was used to having my own text file, so I would only compare it to yours upon updates, rather than using yours. I liked my custom settings, organization etc.
2. Sometimes the changelog would have vague information (e.g. "increased amount of time spent on panels") and I'd like to see the actual number.
Some suggestions:
1. Bring the documentation as forward as possible. At least when version 7 was the current one, I had to dig into GitHub to find the raw version of the vpk file. Sure, I could open the vpk, but it didn't have the comments, as already brought up by others.
2. Centralize the resources on one place. I'm a Discord user. I'm used to browse GitHub. I browse webpages (duh). But not many players are used to these different tools, so it can be a bit overwhelming as well. "You can download it here, ask questions there and browse the documentation over there". I know you use GitHub for hosting and Discord makes conversations quicker than a forum like tf.tv, but I believe it even burdens you to keep so many resources up to date with the changes. I think you can structure Discord to act as everything, with their fancy tree server structure and bots, and leave GitHub as nothing but backend.
3. Parallel to the suggestion of dropping the site, for example, while at it, the landing page is beautiful. Not the quickest of tours, but it does have its goals: to sell the product, I get it. But when you go to the docs (https://docs.mastercomfig.com/en/stable/) the information feels cramped. Sure, there's the left bar menu, but doesn't look inviting to skim through each item.
4. One tiny complaint I have: whenever there's an update, if I feel like there's a small chance of it affecting a specific optional file, I just redownload them all. So having a "last updated:" to the right of each module would be great.
Two issues I had from moving from 6 to 7:
1. I was used to having my own text file, so I would only compare it to yours upon updates, rather than using yours. I liked my custom settings, organization etc.
2. Sometimes the changelog would have vague information (e.g. "increased amount of time spent on panels") and I'd like to see the actual number.
Some suggestions:
1. Bring the documentation as forward as possible. At least when version 7 was the current one, I had to dig into GitHub to find the raw version of the vpk file. Sure, I could open the vpk, but it didn't have the comments, as already brought up by others.
2. Centralize the resources on one place. I'm a Discord user. I'm used to browse GitHub. I browse webpages (duh). But not many players are used to these different tools, so it can be a bit overwhelming as well. "You can download it here, ask questions there and browse the documentation over there". I know you use GitHub for hosting and Discord makes conversations quicker than a forum like tf.tv, but I believe it even burdens you to keep so many resources up to date with the changes. I think you can structure Discord to act as everything, with their fancy tree server structure and bots, and leave GitHub as nothing but backend.
3. Parallel to the suggestion of dropping the site, for example, while at it, the landing page is beautiful. Not the quickest of tours, but it does have its goals: to sell the product, I get it. But when you go to the docs (https://docs.mastercomfig.com/en/stable/) the information feels cramped. Sure, there's the left bar menu, but doesn't look inviting to skim through each item.
4. One tiny complaint I have: whenever there's an update, if I feel like there's a small chance of it affecting a specific optional file, I just redownload them all. So having a "last updated:" to the right of each module would be great.
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.
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.
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.
Personally my biggest gripes based on past experience with your comfig some of which may not be true anymore
1. If you want to make any changes you have to crawl through ~20+ cfg files (granted a handful probably will not be touched at all)
2. Figuring out what an alias does and where to find said alias is a nightmare.
Ex. sniper.cfg within the vpk has this
pred_opt_full
snapshots_safe
snapshots
exec comfig/game_overrides
class_config_sniperOff the top of my head I have no idea what these do or where to find them other than the exec line, deductive reasoning (if you think from the standpoint of someone who's never gone through these) should narrow this down to these cfg files.
cfg/autoexec.cfg
cfg/comfig/comfig.cfg
cfg/comfig/game_overrides.cfg
cfg/comfig/modules_run.cfg
cfg/comfig/select_modules.cfg
cfg/presets/medium-low.cfgSo I have to go through 6 cfg files in 3 different directories how bad could it be?
autoexec.cfg just references other cfg files so that's ruled out.
comfig.cfg ~500 lines of aliases with no comments some of which reference other aliases... Well I think I found most of them... ctrl+f save me now
alias pred_opt_full "cl_pred_optimize 2"
alias snapshots_safe "cl_interp_ratio 2;setinfo cl_interp_ratio 2;interp_safe"
alias snapshots
alias class_config_sniper "exec user/sniper"cool I found them right. but now I'm left scratching my head as to what "snapshots" does since it's alias references nothing
Wait... another alias "interp_safe"
ctrl+f here we go again
I find that the alias interp_safe is set UNDER A DIFFERENT ALIAS
comfig.cfgalias packet_rate_congestion_aliases "alias interp_unreliable interp_congestion_unreliable;alias interp_safe interp_congestion_safe;alias interp_balanced interp_congestion_balanced;alias interp_lan interp_congestion_lan"
alias packet_rate_cons_aliases "alias interp_unreliable interp_cons_unreliable;alias interp_safe interp_cons_safe;alias interp_balanced interp_cons_balanced;alias interp_lan interp_cons_lan"
alias packet_rate_balanced_aliases "alias interp_unreliable interp_balanced_unreliable;alias interp_safe interp_balanced_safe;alias interp_balanced interp_balanced_balanced;alias interp_lan interp_balanced_lan"
alias packet_rate_standard_aliases "alias interp_unreliable interp_standard_unreliable;alias interp_safe interp_standard_safe;alias interp_balanced interp_standard_balanced;alias interp_lan interp_standard_lan"
Awesome interp_safe could be 4 different possible aliases that I don't know the settings for...
interp_congestion_safe
interp_cons_safe
interp_balanced_safe
interp_standard_safeHope I'm near the end of this chain...
alias interp_congestion_safe "cl_interp .060606;setinfo cl_interp .060606;cl_smoothtime .060606"
alias interp_cons_safe "cl_interp .05;setinfo cl_interp .05;cl_smoothtime .05"
alias interp_balanced_safe "cl_interp .0333333;setinfo cl_interp .0333333;cl_smoothtime .0333333"
alias interp_standard_safe "cl_interp .030303;setinfo cl_interp .030303;cl_smoothtime .030303"Finally...
Wait how do I know which one I'm using...
screaming in agony intensifies
That's for just trying to make changes for 1 class config. Looking at that though that's not necessarily 100% optimal because I can choose to run huntsman which means I wouldn't want those net settings. Yes, I do know how to find which interp settings I'm using in the files but imagine this is someone literally just switching from my cfg or chris's or some other one and they're going through all of this for the 1st time.
3. The setup for your config assumes a lot.
Users will never/rarely want to change literally any specific details about their cfgs while keeping 99% of it the same.
Ex. See point #2
Users who select specific quality presets probably want x, y and z. So why not bundle them together under multiple aliases?
Ex. I have a 240Hz monitor, and I play classes that see maximum benefits from the highest possible fps. I also have a GPU that's far more than capable of handling TF2's higher settings that don't really impact CPU utilization. However to get the settings that maximize FPS with a CPU bottleneck without buggy issues I have to use medium low which has a lot of lower quality texture settings which are generally bundled into various aliases with other settings. I'm pretty sure you have this removed by now but you used to have "mat_texture_limit" as a setting within Low and Medium-Low iirc which would cause really bad issues if you changed picmip values.
Users who selected lower presets probably have weak GPUs in general thus we should put more load on the CPU.
1 such example from your github
mastercomfig/config/mastercomfig/cfg/comfig/comfig.cfg
//r_occlusion 1 // Use CPU to have the GPU skip rendering models/props you cannot seeGiven your note people with better GPUs should probably set this to 0 for slightly more FPS. Now technically you have this commented out so it's not being set to 1 by your config, but given your installation recommendation this means users are probably using the default value of 1. Low and Medium-Low both definitely would end up with people having this value at 1.
4. Certain optimizations are only found in the low-preset but the low preset also has less than optimal choices elsewhere...
Default Low Preset sound settings
Show Content
[code]
snd_disable_mixer_duck 1
snd_pitchquality 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 3
dsp_room 0
dsp_facingaway 0
dsp_speaker 0
dsp_water 0
dsp_spatial 0
snd_defer_trace 1[/code]
snd_disable_mixer_duck 1
snd_pitchquality 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 3
dsp_room 0
dsp_facingaway 0
dsp_speaker 0
dsp_water 0
dsp_spatial 0
snd_defer_trace 1[/code]
Default Medium-Low Preset sound settings
Show Content
[code]
snd_disable_mixer_duck 0
snd_pitchquality 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 1
dsp_room 0
dsp_facingaway 0
dsp_speaker 50
dsp_water 0
dsp_spatial 40
snd_defer_trace 1[/code]
snd_disable_mixer_duck 0
snd_pitchquality 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 1
dsp_room 0
dsp_facingaway 0
dsp_speaker 50
dsp_water 0
dsp_spatial 40
snd_defer_trace 1[/code]
Neither preset is really optimal for competitive use. Medium-Low has more latency with dsp_spatial, and Low has more latency with snd_spatialize_roundrobin 3. I don't remember if dsp_speaker 50 causes latency or not, probably trivial anyway. There's many other similar examples of less than optimal choices from a competitive aspect or from a performance aspect.
Final Thoughts:
I do really appreciate what you've done and I understand why you made a lot of the choices you did that contributed to the above gripes I have. You have to make those safer assumption for lower presets because not everyone has great GPUs or Quad-core+ CPUs and the people that do will gravitate to those lower presets. Having that many CFG files allows you to split some things up and prevents certain commands from getting exec'd over and over, as well as making your setup more modular and flexible for you to develop thus saving time (which I'm fully aware how much this can eat up...).
Personally my biggest gripes based on past experience with your comfig [b]some of which may not be true anymore[/b]
1. If you want to make any changes you have to crawl through ~20+ cfg files (granted a handful probably will not be touched at all)
2. Figuring out what an alias does and where to find said alias is a nightmare.
Ex. sniper.cfg within the vpk has this
[code]pred_opt_full
snapshots_safe
snapshots
exec comfig/game_overrides
class_config_sniper[/code]
Off the top of my head I have no idea what these do or where to find them other than the exec line, deductive reasoning (if you think from the standpoint of someone who's never gone through these) should narrow this down to these cfg files.
[code]
cfg/autoexec.cfg
cfg/comfig/comfig.cfg
cfg/comfig/game_overrides.cfg
cfg/comfig/modules_run.cfg
cfg/comfig/select_modules.cfg
cfg/presets/medium-low.cfg
[/code]
So I have to go through 6 cfg files in 3 different directories how bad could it be?
autoexec.cfg just references other cfg files so that's ruled out.
comfig.cfg ~500 lines of aliases with no comments some of which reference other aliases... Well I think I found most of them... [i][u]ctrl+f save me now[/u][/i]
[code]
alias pred_opt_full "cl_pred_optimize 2"
alias snapshots_safe "cl_interp_ratio 2;setinfo cl_interp_ratio 2;interp_safe"
alias snapshots
alias class_config_sniper "exec user/sniper"
[/code]
cool I found them right. but now I'm left scratching my head as to what "snapshots" does since it's alias references nothing
Wait... another alias "interp_safe"
ctrl+f here we go again
I find that the alias interp_safe is set UNDER A DIFFERENT ALIAS
[quote=comfig.cfg]alias packet_rate_congestion_aliases "alias interp_unreliable interp_congestion_unreliable;[u]alias interp_safe interp_congestion_safe[/u];alias interp_balanced interp_congestion_balanced;alias interp_lan interp_congestion_lan"
alias packet_rate_cons_aliases "alias interp_unreliable interp_cons_unreliable;[u]alias interp_safe interp_cons_safe[/u];alias interp_balanced interp_cons_balanced;alias interp_lan interp_cons_lan"
alias packet_rate_balanced_aliases "alias interp_unreliable interp_balanced_unreliable;[u]alias interp_safe interp_balanced_safe[/u];alias interp_balanced interp_balanced_balanced;alias interp_lan interp_balanced_lan"
alias packet_rate_standard_aliases "alias interp_unreliable interp_standard_unreliable;[u]alias interp_safe interp_standard_safe[/u];alias interp_balanced interp_standard_balanced;alias interp_lan interp_standard_lan"[/quote]
Awesome interp_safe could be 4 different possible aliases that I don't know the settings for...
[code]interp_congestion_safe
interp_cons_safe
interp_balanced_safe
interp_standard_safe[/code]
Hope I'm near the end of this chain...
[code]
alias interp_congestion_safe "cl_interp .060606;setinfo cl_interp .060606;cl_smoothtime .060606"
alias interp_cons_safe "cl_interp .05;setinfo cl_interp .05;cl_smoothtime .05"
alias interp_balanced_safe "cl_interp .0333333;setinfo cl_interp .0333333;cl_smoothtime .0333333"
alias interp_standard_safe "cl_interp .030303;setinfo cl_interp .030303;cl_smoothtime .030303"
[/code]
Finally...
Wait how do I know which one I'm using...
[b][i]screaming in agony intensifies[/i][/b]
That's for just trying to make changes for 1 class config. Looking at that though that's not necessarily 100% optimal because I can choose to run huntsman which means I wouldn't want those net settings. Yes, I do know how to find which interp settings I'm using in the files but imagine this is someone literally just switching from my cfg or chris's or some other one and they're going through all of this for the 1st time.
3. The setup for your config assumes a lot.
Users will never/rarely want to change literally any specific details about their cfgs while keeping 99% of it the same.
Ex. See point #2
Users who select specific quality presets probably want x, y and z. So why not bundle them together under multiple aliases?
Ex. I have a 240Hz monitor, and I play classes that see maximum benefits from the highest possible fps. I also have a GPU that's far more than capable of handling TF2's higher settings that don't really impact CPU utilization. However to get the settings that maximize FPS with a CPU bottleneck without buggy issues I have to use medium low which has a lot of lower quality texture settings which are generally bundled into various aliases with other settings. I'm pretty sure you have this removed by now but you used to have "mat_texture_limit" as a setting within Low and Medium-Low iirc which would cause really bad issues if you changed picmip values.
Users who selected lower presets probably have weak GPUs in general thus we should put more load on the CPU.
1 such example from your github
mastercomfig/config/mastercomfig/cfg/comfig/comfig.cfg
[code]
//r_occlusion 1 // Use CPU to have the GPU skip rendering models/props you cannot see
[/code]
Given your note people with better GPUs should probably set this to 0 for slightly more FPS. Now technically you have this commented out so it's not being set to 1 by your config, but given your installation recommendation this means users are probably using the default value of 1. Low and Medium-Low both definitely would end up with people having this value at 1.
4. Certain optimizations are only found in the low-preset but the low preset also has less than optimal choices elsewhere...
Default Low Preset sound settings
[spoiler][code]
snd_disable_mixer_duck 1
snd_pitchquality 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 3
dsp_room 0
dsp_facingaway 0
dsp_speaker 0
dsp_water 0
dsp_spatial 0
snd_defer_trace 1[/code][/spoiler]
Default Medium-Low Preset sound settings
[spoiler][code]
snd_disable_mixer_duck 0
snd_pitchquality 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 1
dsp_room 0
dsp_facingaway 0
dsp_speaker 50
dsp_water 0
dsp_spatial 40
snd_defer_trace 1[/code][/spoiler]
Neither preset is really optimal for competitive use. Medium-Low has more latency with dsp_spatial, and Low has more latency with snd_spatialize_roundrobin 3. I don't remember if dsp_speaker 50 causes latency or not, probably trivial anyway. There's many other similar examples of less than optimal choices from a competitive aspect or from a performance aspect.
Final Thoughts:
I do really appreciate what you've done and I understand why you made a lot of the choices you did that contributed to the above gripes I have. You have to make those safer assumption for lower presets because not everyone has great GPUs or Quad-core+ CPUs and the people that do will gravitate to those lower presets. Having that many CFG files allows you to split some things up and prevents certain commands from getting exec'd over and over, as well as making your setup more modular and flexible for you to develop thus saving time ([i]which I'm fully aware how much this can eat up...[/i]).
1. If you want to make any changes you have to crawl through ~20+ cfg files (granted a handful probably will not be touched at all)
2. Figuring out what an alias does and where to find said alias is a nightmare.
Ex. sniper.cfg within the vpk has this
[code]pred_opt_full
snapshots_safe
snapshots
exec comfig/game_overrides
class_config_sniper[/code]
Off the top of my head I have no idea what these do or where to find them other than the exec line, deductive reasoning (if you think from the standpoint of someone who's never gone through these) should narrow this down to these cfg files.
[code]
cfg/autoexec.cfg
cfg/comfig/comfig.cfg
cfg/comfig/game_overrides.cfg
cfg/comfig/modules_run.cfg
cfg/comfig/select_modules.cfg
cfg/presets/medium-low.cfg
[/code]
So I have to go through 6 cfg files in 3 different directories how bad could it be?
autoexec.cfg just references other cfg files so that's ruled out.
comfig.cfg ~500 lines of aliases with no comments some of which reference other aliases... Well I think I found most of them... [i][u]ctrl+f save me now[/u][/i]
[code]
alias pred_opt_full "cl_pred_optimize 2"
alias snapshots_safe "cl_interp_ratio 2;setinfo cl_interp_ratio 2;interp_safe"
alias snapshots
alias class_config_sniper "exec user/sniper"
[/code]
cool I found them right. but now I'm left scratching my head as to what "snapshots" does since it's alias references nothing
Wait... another alias "interp_safe"
ctrl+f here we go again
I find that the alias interp_safe is set UNDER A DIFFERENT ALIAS
[quote=comfig.cfg]alias packet_rate_congestion_aliases "alias interp_unreliable interp_congestion_unreliable;[u]alias interp_safe interp_congestion_safe[/u];alias interp_balanced interp_congestion_balanced;alias interp_lan interp_congestion_lan"
alias packet_rate_cons_aliases "alias interp_unreliable interp_cons_unreliable;[u]alias interp_safe interp_cons_safe[/u];alias interp_balanced interp_cons_balanced;alias interp_lan interp_cons_lan"
alias packet_rate_balanced_aliases "alias interp_unreliable interp_balanced_unreliable;[u]alias interp_safe interp_balanced_safe[/u];alias interp_balanced interp_balanced_balanced;alias interp_lan interp_balanced_lan"
alias packet_rate_standard_aliases "alias interp_unreliable interp_standard_unreliable;[u]alias interp_safe interp_standard_safe[/u];alias interp_balanced interp_standard_balanced;alias interp_lan interp_standard_lan"[/quote]
Awesome interp_safe could be 4 different possible aliases that I don't know the settings for...
[code]interp_congestion_safe
interp_cons_safe
interp_balanced_safe
interp_standard_safe[/code]
Hope I'm near the end of this chain...
[code]
alias interp_congestion_safe "cl_interp .060606;setinfo cl_interp .060606;cl_smoothtime .060606"
alias interp_cons_safe "cl_interp .05;setinfo cl_interp .05;cl_smoothtime .05"
alias interp_balanced_safe "cl_interp .0333333;setinfo cl_interp .0333333;cl_smoothtime .0333333"
alias interp_standard_safe "cl_interp .030303;setinfo cl_interp .030303;cl_smoothtime .030303"
[/code]
Finally...
Wait how do I know which one I'm using...
[b][i]screaming in agony intensifies[/i][/b]
That's for just trying to make changes for 1 class config. Looking at that though that's not necessarily 100% optimal because I can choose to run huntsman which means I wouldn't want those net settings. Yes, I do know how to find which interp settings I'm using in the files but imagine this is someone literally just switching from my cfg or chris's or some other one and they're going through all of this for the 1st time.
3. The setup for your config assumes a lot.
Users will never/rarely want to change literally any specific details about their cfgs while keeping 99% of it the same.
Ex. See point #2
Users who select specific quality presets probably want x, y and z. So why not bundle them together under multiple aliases?
Ex. I have a 240Hz monitor, and I play classes that see maximum benefits from the highest possible fps. I also have a GPU that's far more than capable of handling TF2's higher settings that don't really impact CPU utilization. However to get the settings that maximize FPS with a CPU bottleneck without buggy issues I have to use medium low which has a lot of lower quality texture settings which are generally bundled into various aliases with other settings. I'm pretty sure you have this removed by now but you used to have "mat_texture_limit" as a setting within Low and Medium-Low iirc which would cause really bad issues if you changed picmip values.
Users who selected lower presets probably have weak GPUs in general thus we should put more load on the CPU.
1 such example from your github
mastercomfig/config/mastercomfig/cfg/comfig/comfig.cfg
[code]
//r_occlusion 1 // Use CPU to have the GPU skip rendering models/props you cannot see
[/code]
Given your note people with better GPUs should probably set this to 0 for slightly more FPS. Now technically you have this commented out so it's not being set to 1 by your config, but given your installation recommendation this means users are probably using the default value of 1. Low and Medium-Low both definitely would end up with people having this value at 1.
4. Certain optimizations are only found in the low-preset but the low preset also has less than optimal choices elsewhere...
Default Low Preset sound settings
[spoiler][code]
snd_disable_mixer_duck 1
snd_pitchquality 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 3
dsp_room 0
dsp_facingaway 0
dsp_speaker 0
dsp_water 0
dsp_spatial 0
snd_defer_trace 1[/code][/spoiler]
Default Medium-Low Preset sound settings
[spoiler][code]
snd_disable_mixer_duck 0
snd_pitchquality 0
dsp_slow_cpu 1
snd_spatialize_roundrobin 1
dsp_room 0
dsp_facingaway 0
dsp_speaker 50
dsp_water 0
dsp_spatial 40
snd_defer_trace 1[/code][/spoiler]
Neither preset is really optimal for competitive use. Medium-Low has more latency with dsp_spatial, and Low has more latency with snd_spatialize_roundrobin 3. I don't remember if dsp_speaker 50 causes latency or not, probably trivial anyway. There's many other similar examples of less than optimal choices from a competitive aspect or from a performance aspect.
Final Thoughts:
I do really appreciate what you've done and I understand why you made a lot of the choices you did that contributed to the above gripes I have. You have to make those safer assumption for lower presets because not everyone has great GPUs or Quad-core+ CPUs and the people that do will gravitate to those lower presets. Having that many CFG files allows you to split some things up and prevents certain commands from getting exec'd over and over, as well as making your setup more modular and flexible for you to develop thus saving time ([i]which I'm fully aware how much this can eat up...[/i]).
i switched from a custom comanglia cfg and all the graphics settings are buried somewhere in my config.cfg, so when i used mastercomfig everything looked different, and it seemed less effort to uninstall it than to look up what all the settings were
i switched from a custom comanglia cfg and all the graphics settings are buried somewhere in my config.cfg, so when i used mastercomfig everything looked different, and it seemed less effort to uninstall it than to look up what all the settings were
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.
quintoshi switched from a custom comanglia cfg and all the graphics settings are buried somewhere in my config.cfg, so when i used mastercomfig everything looked different, and it seemed less effort to uninstall it than to look up what all the settings were
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?
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 [url=https://github.com/mastercoms/mastercomfig/blob/release/config/mastercomfig/cfg/comfig/comfig.cfg]here[/url].
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.
[quote=quintosh]i switched from a custom comanglia cfg and all the graphics settings are buried somewhere in my config.cfg, so when i used mastercomfig everything looked different, and it seemed less effort to uninstall it than to look up what all the settings were[/quote]
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?
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 [url=https://github.com/mastercoms/mastercomfig/blob/release/config/mastercomfig/cfg/comfig/comfig.cfg]here[/url].
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.
[quote=quintosh]i switched from a custom comanglia cfg and all the graphics settings are buried somewhere in my config.cfg, so when i used mastercomfig everything looked different, and it seemed less effort to uninstall it than to look up what all the settings were[/quote]
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?
mastercomsHi @Comanglia! Thanks for the feedback.
1&2.-snip- you could have used the framework for changing interp (snapshots_balanced) in user/sniper.cfg, as in the documentation.
Ok so I have some problems with this "user/CLASSCONFIG.cfg" instructions.
1. The installation guide for mastercomfig doesn't mention this at all.
2. There's no documentation that comes with the VPK that explains this.
3. The documentation that does exist is in this directory and file mastercomfig/docs/customization/custom_configs while none of the other documentation tells the user to make a new folder under steamapps\common\Team Fortress 2\tf\cfg called "user".
On top of that most of the readme and useful information are in a different directory entirely.
The clean up instruction that are with the installation instructions part of the recommended installation actually tells people to delete said cfg folder.
There's nothing about it in the troubleshooting section, the main readme, etc.
If I go through the trouble of going to your github to the specific sniper.cfg (or the directory that contains the class files) I find there's nothing in there telling me for custom class configs see X file or the instructions themselves.
4. The barrier to entry here is absolutely massive. Yes you thoroughly documented basically everything but you did it so well it became hard to find. Which even then expecting users to read 1 README file is already a fairly high barrier to clear for a lot of people...
mastercomsAnd just FYI, you can access the commented version of comfig.cfg here.
I'm aware.
https://cdn.discordapp.com/attachments/469529966950744064/675461850925760539/unknown.png
I look forward to the manual installation release!
mastercoms3. 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.
3. Was more about the assumptions in general I felt you made. I think I have misunderstood the comment you had left for r_occlusion.
//r_occlusion 1 // Use CPU to have the GPU skip rendering models/props you cannot see
I took this as meaning the CPU had to do extra rendering, but now I think this actually means the CPU just tells the GPU to not do unnecessary things.
Also wasn't necessarily asking for anything related to that texture limit command it was just an issue I ran into once when benchmarking your CFGs and I had decided to try out higher texture quality with benchmarks after loading the very-low, low and medium-low ones. But again it's 1 of those things that had me feeling like you assumed that people would never change those settings.
mastercoms4. 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.
I this would greatly benefit a lot of people, especially those curious about what looks like what. However that's probably going to be quite tedious especially since different combinations of commands have different results for the same thing.
[quote=mastercoms]Hi @Comanglia! Thanks for the feedback.
1&2.-snip- you could have used the framework for changing interp (snapshots_balanced) in user/sniper.cfg, as in the documentation.[/quote]
Ok so I have some problems with this "user/CLASSCONFIG.cfg" instructions.
1. The installation guide for mastercomfig doesn't mention this at all.
2. There's no documentation that comes with the VPK that explains this.
3. The documentation that does exist is in this directory and file mastercomfig/docs/customization/custom_configs while none of the other documentation tells the user to make a new folder under steamapps\common\Team Fortress 2\tf\cfg called "user".
On top of that most of the readme and useful information are in a different directory entirely.
The clean up instruction that are with the installation instructions part of the recommended installation actually [url=https://github.com/mastercoms/mastercomfig/blob/release/docs/setup/clean_up.md]tells people to delete said cfg folder[/url].
There's nothing about it in the troubleshooting section, the main readme, etc.
If I go through the trouble of going to your [url=https://github.com/mastercoms/mastercomfig/blob/release/config/mastercomfig/cfg/sniper.cfg]github to the specific sniper.cfg[/url] (or the directory that contains the class files) I find there's nothing in there telling me for custom class configs see X file or the instructions themselves.
4. The barrier to entry here is absolutely massive. Yes you thoroughly documented basically everything but you did it so well it became hard to find. Which even then expecting users to read 1 README file is already a fairly high barrier to clear for a lot of people...
[quote=mastercoms]And just FYI, you can access the commented version of comfig.cfg [url=https://github.com/mastercoms/mastercomfig/blob/release/config/mastercomfig/cfg/comfig/comfig.cfg]here[/url].
[/quote]
I'm aware.
[img]https://cdn.discordapp.com/attachments/469529966950744064/675461850925760539/unknown.png[/img]
I look forward to the manual installation release!
[quote=mastercoms]
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.[/quote]
3. Was more about the assumptions in general I felt you made. I think I have misunderstood the comment you had left for r_occlusion.
//r_occlusion 1 // Use CPU to have the GPU skip rendering models/props you cannot see
I took this as meaning the CPU had to do extra rendering, but now I think this actually means the CPU just tells the GPU to not do unnecessary things.
Also wasn't necessarily asking for anything related to that texture limit command it was just an issue I ran into once when benchmarking your CFGs and I had decided to try out higher texture quality with benchmarks after loading the very-low, low and medium-low ones. But again it's 1 of those things that had me feeling like you assumed that people would never change those settings.
[quote=mastercoms]
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.
[/quote]
I this would greatly benefit a lot of people, especially those curious about what looks like what. However that's probably going to be quite tedious especially since different combinations of commands have different results for the same thing.
1&2.-snip- you could have used the framework for changing interp (snapshots_balanced) in user/sniper.cfg, as in the documentation.[/quote]
Ok so I have some problems with this "user/CLASSCONFIG.cfg" instructions.
1. The installation guide for mastercomfig doesn't mention this at all.
2. There's no documentation that comes with the VPK that explains this.
3. The documentation that does exist is in this directory and file mastercomfig/docs/customization/custom_configs while none of the other documentation tells the user to make a new folder under steamapps\common\Team Fortress 2\tf\cfg called "user".
On top of that most of the readme and useful information are in a different directory entirely.
The clean up instruction that are with the installation instructions part of the recommended installation actually [url=https://github.com/mastercoms/mastercomfig/blob/release/docs/setup/clean_up.md]tells people to delete said cfg folder[/url].
There's nothing about it in the troubleshooting section, the main readme, etc.
If I go through the trouble of going to your [url=https://github.com/mastercoms/mastercomfig/blob/release/config/mastercomfig/cfg/sniper.cfg]github to the specific sniper.cfg[/url] (or the directory that contains the class files) I find there's nothing in there telling me for custom class configs see X file or the instructions themselves.
4. The barrier to entry here is absolutely massive. Yes you thoroughly documented basically everything but you did it so well it became hard to find. Which even then expecting users to read 1 README file is already a fairly high barrier to clear for a lot of people...
[quote=mastercoms]And just FYI, you can access the commented version of comfig.cfg [url=https://github.com/mastercoms/mastercomfig/blob/release/config/mastercomfig/cfg/comfig/comfig.cfg]here[/url].
[/quote]
I'm aware.
[img]https://cdn.discordapp.com/attachments/469529966950744064/675461850925760539/unknown.png[/img]
I look forward to the manual installation release!
[quote=mastercoms]
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.[/quote]
3. Was more about the assumptions in general I felt you made. I think I have misunderstood the comment you had left for r_occlusion.
//r_occlusion 1 // Use CPU to have the GPU skip rendering models/props you cannot see
I took this as meaning the CPU had to do extra rendering, but now I think this actually means the CPU just tells the GPU to not do unnecessary things.
Also wasn't necessarily asking for anything related to that texture limit command it was just an issue I ran into once when benchmarking your CFGs and I had decided to try out higher texture quality with benchmarks after loading the very-low, low and medium-low ones. But again it's 1 of those things that had me feeling like you assumed that people would never change those settings.
[quote=mastercoms]
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.
[/quote]
I this would greatly benefit a lot of people, especially those curious about what looks like what. However that's probably going to be quite tedious especially since different combinations of commands have different results for the same thing.
mastercomsmastercomfig updates very frequently
who here as a player goes through the hassle of updating a graphics cfg?
Isnt it like with huds when you update when an update broke it?
As a satisfied mastercomfig user I didnt update it for like 2 years (and used chris wayyy after it was unsupported too lol)
mastercoms It has lots of other modifications within TF2's script files which can only be loaded in the custom folder
but at its root it's still commands in some cfg files isn't it?
I agree with the others asking for text files and no config_c.cfg. What you do with the VPK and class configs renamed, etc.., reminds me of people at work making wrappers above open source libs and scripts above buildsystems "to make it simpler", when all it does is obfuscating things away.
[quote=mastercoms]mastercomfig updates very frequently[/quote]
who here as a player goes through the hassle of updating a graphics cfg?
Isnt it like with huds when you update when an update broke it?
As a satisfied mastercomfig user I didnt update it for like 2 years (and used chris wayyy after it was unsupported too lol)
[quote=mastercoms] It has lots of other modifications within TF2's script files which can only be loaded in the custom folder[/quote]
but at its root it's still commands in some cfg files isn't it?
I agree with the others asking for text files and no config_c.cfg. What you do with the VPK and class configs renamed, etc.., reminds me of people at work making wrappers above open source libs and scripts above buildsystems "to make it simpler", when all it does is obfuscating things away.
who here as a player goes through the hassle of updating a graphics cfg?
Isnt it like with huds when you update when an update broke it?
As a satisfied mastercomfig user I didnt update it for like 2 years (and used chris wayyy after it was unsupported too lol)
[quote=mastercoms] It has lots of other modifications within TF2's script files which can only be loaded in the custom folder[/quote]
but at its root it's still commands in some cfg files isn't it?
I agree with the others asking for text files and no config_c.cfg. What you do with the VPK and class configs renamed, etc.., reminds me of people at work making wrappers above open source libs and scripts above buildsystems "to make it simpler", when all it does is obfuscating things away.
Comanglia
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.
Twiggymastercomsmastercomfig updates very frequentlywho here as a player goes through the hassle of updating a graphics cfg?
Isnt it like with huds when you update when an update broke it?
As a satisfied mastercoms user I didnt update it for like 2 years (and used chris wayyy after it was unsupported too lol)
mastercoms It has lots of other modifications within TF2's script files which can only be loaded in the custom folderbut at its root it's still commands in some cfg files isn't it?
I agree with the others asking for text files and no config_c.cfg. What you do with the VPK and class configs renamed, etc.., remind me of people at work making wrappers above open source libs and scripts above buildsystems "to make it simpler", when all it does is obfuscating things away.
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.
[quote=Comanglia][/quote]
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 [url=https://docs.mastercomfig.com/en/stable/setup/install/]page[/url] 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.
[quote=Twiggy][quote=mastercoms]mastercomfig updates very frequently[/quote]
who here as a player goes through the hassle of updating a graphics cfg?
Isnt it like with huds when you update when an update broke it?
As a satisfied mastercoms user I didnt update it for like 2 years (and used chris wayyy after it was unsupported too lol)
[quote=mastercoms] It has lots of other modifications within TF2's script files which can only be loaded in the custom folder[/quote]
but at its root it's still commands in some cfg files isn't it?
I agree with the others asking for text files and no config_c.cfg. What you do with the VPK and class configs renamed, etc.., remind me of people at work making wrappers above open source libs and scripts above buildsystems "to make it simpler", when all it does is obfuscating things away.[/quote]
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.
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 [url=https://docs.mastercomfig.com/en/stable/setup/install/]page[/url] 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.
[quote=Twiggy][quote=mastercoms]mastercomfig updates very frequently[/quote]
who here as a player goes through the hassle of updating a graphics cfg?
Isnt it like with huds when you update when an update broke it?
As a satisfied mastercoms user I didnt update it for like 2 years (and used chris wayyy after it was unsupported too lol)
[quote=mastercoms] It has lots of other modifications within TF2's script files which can only be loaded in the custom folder[/quote]
but at its root it's still commands in some cfg files isn't it?
I agree with the others asking for text files and no config_c.cfg. What you do with the VPK and class configs renamed, etc.., remind me of people at work making wrappers above open source libs and scripts above buildsystems "to make it simpler", when all it does is obfuscating things away.[/quote]
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.
mastercomsquintoshi switched from a custom comanglia cfg and all the graphics settings are buried somewhere in my config.cfg, so when i used mastercomfig everything looked different, and it seemed less effort to uninstall it than to look up what all the settings wereSo 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?
iterate over the existing config file and port every custom graphics settings over to your config generator
[quote=mastercoms]
[quote=quintosh]i switched from a custom comanglia cfg and all the graphics settings are buried somewhere in my config.cfg, so when i used mastercomfig everything looked different, and it seemed less effort to uninstall it than to look up what all the settings were[/quote]
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?[/quote]
iterate over the existing config file and port every custom graphics settings over to your config generator
[quote=quintosh]i switched from a custom comanglia cfg and all the graphics settings are buried somewhere in my config.cfg, so when i used mastercomfig everything looked different, and it seemed less effort to uninstall it than to look up what all the settings were[/quote]
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?[/quote]
iterate over the existing config file and port every custom graphics settings over to your config generator
mastercomsYeah, I learn more about the game, listen to feedback, test things, etc that make the config better with updates.
All of those are good things, and you should definitely keep on doing that as long as it is your interest.
However, as an average joe, my train of thought is simple : game runs like shit without your config -> game runs fine as soon as I install your config -> no more problem -> no need to update
mastercomsAlso could you go into more detail about what's being obfuscated here
You said most of the config is commands. But if I wanna read what it is doing, I must either use GCFScape or browse your files on github (+ figuring out which are actually used in the preset I chose). So if for whatever reason i want to tweak a setting it gets a bit more complicated than just opening a text file.
mastercomUltimately, 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.
This is exactly what I'm talking about and witness at work. You create something really complicated (vpk + knowing the framework) so that the user does not have to edit one text file.
Also, online documentation is a good thing, but the regular user downloads the vpk thing, and then relies on your website to figure out how that works. compare that to an archive with a readme file, or text files with comments.
Last point, in https://docs.mastercomfig.com/en/stable/customization/custom_configs/, there are bits about a tf/cfg/user folder I believe is obsolete.
If so, there you get a prime example of the hassle of maintaining separate doc and code that can lead to discrepancies (and also more work for you)(Comanglia talked about that
PS : I didnt read all the replies on this thread, apologies If I made a mistake or stated smth already said
[quote=mastercoms]Yeah, I learn more about the game, listen to feedback, test things, etc that make the config better with updates.[/quote]
All of those are good things, and you should definitely keep on doing that as long as it is your interest.
However, as an average joe, my train of thought is simple : game runs like shit without your config -> game runs fine as soon as I install your config -> no more problem -> no need to update
[quote=mastercoms]Also could you go into more detail about what's being obfuscated here[/quote]
You said most of the config is commands. But if I wanna read what it is doing, I must either use GCFScape or browse your files on github (+ figuring out which are actually used in the preset I chose). So if for whatever reason i want to tweak a setting it gets a bit more complicated than just opening a text file.
[quote=mastercom]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.[/quote]
This is exactly what I'm talking about and witness at work. You create something really complicated (vpk + knowing the framework) so that the user does not have to edit one text file.
Also, online documentation is a good thing, but the regular user downloads the vpk thing, and then relies on your website to figure out how that works. compare that to an archive with a readme file, or text files with comments.
Last point, in https://docs.mastercomfig.com/en/stable/customization/custom_configs/, there are bits about a tf/cfg/user folder I believe is obsolete.
If so, there you get a prime example of the hassle of maintaining separate doc and code that can lead to discrepancies (and also more work for you)(Comanglia talked about that
PS : I didnt read all the replies on this thread, apologies If I made a mistake or stated smth already said
All of those are good things, and you should definitely keep on doing that as long as it is your interest.
However, as an average joe, my train of thought is simple : game runs like shit without your config -> game runs fine as soon as I install your config -> no more problem -> no need to update
[quote=mastercoms]Also could you go into more detail about what's being obfuscated here[/quote]
You said most of the config is commands. But if I wanna read what it is doing, I must either use GCFScape or browse your files on github (+ figuring out which are actually used in the preset I chose). So if for whatever reason i want to tweak a setting it gets a bit more complicated than just opening a text file.
[quote=mastercom]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.[/quote]
This is exactly what I'm talking about and witness at work. You create something really complicated (vpk + knowing the framework) so that the user does not have to edit one text file.
Also, online documentation is a good thing, but the regular user downloads the vpk thing, and then relies on your website to figure out how that works. compare that to an archive with a readme file, or text files with comments.
Last point, in https://docs.mastercomfig.com/en/stable/customization/custom_configs/, there are bits about a tf/cfg/user folder I believe is obsolete.
If so, there you get a prime example of the hassle of maintaining separate doc and code that can lead to discrepancies (and also more work for you)(Comanglia talked about that
PS : I didnt read all the replies on this thread, apologies If I made a mistake or stated smth already said
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.
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.
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.
too hard to edit shit, would much prefer just one txt called "graphics" that has everything in it and i can just edit the stuff i want to
too hard to edit shit, would much prefer just one txt called "graphics" that has everything in it and i can just edit the stuff i want to
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.
As [url=https://www.teamfortress.tv/42867/mastercomfig-fps-customization-config/?page=67#1986]announced in the main thread[/url], mastercomfig 8.3.8 comes with the aforementioned [url=https://docs.mastercomfig.com/en/stable/setup/install/]documentation updates for installation[/url], which are linked to from the [url=https://www.mastercomfig.com/download]download page[/url] 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.
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.
I've been wanting to use your thing for years but I hate that I can't modify it or even look at all the changes without an outside program, if you made a cfg you would get a lot more users as you can see by this thread.
I've been wanting to use your thing for years but I hate that I can't modify it or even look at all the changes without an outside program, if you made a cfg you would get a lot more users as you can see by this thread.
I think you keep doing a good job and the current instructioins are all very clear.
mastercomsI 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.
Is that part of the new doc?
I was thinking it could be another page under 'Customizations'
I think you keep doing a good job and the current instructioins are all very clear.
[quote=mastercoms]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.[/quote]
Is that part of the new doc?
I was thinking it could be another page under 'Customizations'
[quote=mastercoms]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.[/quote]
Is that part of the new doc?
I was thinking it could be another page under 'Customizations'
Just an update on this: I have added a new customization UI to the website so that it is easier to customize mastercomfig. This will be a replacement for the app moving forward. Check it out! https://mastercomfig.com/download
These also include some backend changes which allow more of the config to be generated dynamically, opening up the door for the config file to come in several different varieties.
In the future, I plan to add offline support to the download page, so that it can be used as a full replacement to the app. Then, I will add more advanced scripting features like binds, per console variable documentation and toggles, and more. After that, I may bring the download page out of the browser into a local app so that it can also help with putting the files where it needs to, like the old app.
We're also still working on the video, but given how things are changing, we are kind of holding off on most of it for now.
Just an update on this: I have added a new customization UI to the website so that it is easier to customize mastercomfig. This will be a replacement for the app moving forward. Check it out! https://mastercomfig.com/download
These also include some backend changes which allow more of the config to be generated dynamically, opening up the door for the config file to come in several different varieties.
In the future, I plan to add offline support to the download page, so that it can be used as a full replacement to the app. Then, I will add more advanced scripting features like binds, per console variable documentation and toggles, and more. After that, I may bring the download page out of the browser into a local app so that it can also help with putting the files where it needs to, like the old app.
We're also still working on the video, but given how things are changing, we are kind of holding off on most of it for now.
These also include some backend changes which allow more of the config to be generated dynamically, opening up the door for the config file to come in several different varieties.
In the future, I plan to add offline support to the download page, so that it can be used as a full replacement to the app. Then, I will add more advanced scripting features like binds, per console variable documentation and toggles, and more. After that, I may bring the download page out of the browser into a local app so that it can also help with putting the files where it needs to, like the old app.
We're also still working on the video, but given how things are changing, we are kind of holding off on most of it for now.
????? This config is easier to install than any other config. You download files and then drag and drop them into your custom folder. No messing around with config.cfg, no learning to save files as .cfgs, there's fucking nothing to it. My grandmother could do that shit
????? This config is easier to install than any other config. You download files and then drag and drop them into your custom folder. No messing around with config.cfg, no learning to save files as .cfgs, there's fucking nothing to it. My grandmother could do that shit
A few updates on this since the last one.
For those of you who were looking for a new app, there now is a full mastercomfig web app, redesigned for better usability here: https://mastercomfig.com/app. It can be used offline/standalone, allows you to customize the config easily, and on Chrome based browsers, supports directly installing to your TF2 folder. In a near future update, I plan to add quite a few new scripting options for binds, class configs, weapon scripts and more, which should make the app a one stop shop for customizing TF2.
For those of you looking for a more traditional setup, in 9.7.0 I've released a full autoexec (you can find it listed on the "Other downloads" link in the app or here). It provides a low quality level by default and while it is not as featureful as mastercomfig presets, it provides a familiar setup that can be used as a stepping stone to mastercomfig. And in a previous release, I started making ZIP packages available for mastercomfig, which provides an editable fully featured setup without VPKs, which can help for moving to full mastercomfig setup, while still being decently familiar and manually editable.
As for documentation/installation instructions, that's still been an ongoing process. I've made quite a few improvements to the documentation to make it clearer and more practical. On our Discord, I've improved the support process with a ticketing approach which gets you help faster than ever in your own automatically made thread.
And lastly, for update frequency: as planned in #41, we now have two release channels, being the typical versioned releases, and the dev build, which recently got improved support within the app.
If you have any questions about the new release, the new autoexec.cfg, or want to give feedback, don't hesitate to reach out! I'm happy to help and make things better.
A few updates on this since the last one.
For those of you who were looking for a new app, there now is a full mastercomfig web app, redesigned for better usability here: https://mastercomfig.com/app. It can be used offline/standalone, allows you to customize the config easily, and on Chrome based browsers, supports directly installing to your TF2 folder. In a near future update, I plan to add quite a few new scripting options for binds, class configs, weapon scripts and more, which should make the app a one stop shop for customizing TF2.
For those of you looking for a more traditional setup, in 9.7.0 I've released a [b]full autoexec[/b] (you can find it listed on the "Other downloads" link in the app or [url=https://github.com/mastercomfig/mastercomfig/releases/latest]here[/url]). It provides a low quality level by default and while it is not as featureful as mastercomfig presets, it provides a familiar setup that can be used as a stepping stone to mastercomfig. And in a previous release, I started making ZIP packages available for mastercomfig, which provides an editable fully featured setup without VPKs, which can help for moving to full mastercomfig setup, while still being decently familiar and manually editable.
As for documentation/installation instructions, that's still been an ongoing process. I've made quite a few improvements to the documentation to make it clearer and more practical. On our Discord, I've improved the support process with a ticketing approach which gets you help faster than ever in your own automatically made thread.
And lastly, for update frequency: as planned in #41, we now have two release channels, being the typical versioned releases, and the dev build, which recently got improved support within the app.
If you have any questions about the new release, the new autoexec.cfg, or want to give feedback, don't hesitate to reach out! I'm happy to help and make things better.
For those of you who were looking for a new app, there now is a full mastercomfig web app, redesigned for better usability here: https://mastercomfig.com/app. It can be used offline/standalone, allows you to customize the config easily, and on Chrome based browsers, supports directly installing to your TF2 folder. In a near future update, I plan to add quite a few new scripting options for binds, class configs, weapon scripts and more, which should make the app a one stop shop for customizing TF2.
For those of you looking for a more traditional setup, in 9.7.0 I've released a [b]full autoexec[/b] (you can find it listed on the "Other downloads" link in the app or [url=https://github.com/mastercomfig/mastercomfig/releases/latest]here[/url]). It provides a low quality level by default and while it is not as featureful as mastercomfig presets, it provides a familiar setup that can be used as a stepping stone to mastercomfig. And in a previous release, I started making ZIP packages available for mastercomfig, which provides an editable fully featured setup without VPKs, which can help for moving to full mastercomfig setup, while still being decently familiar and manually editable.
As for documentation/installation instructions, that's still been an ongoing process. I've made quite a few improvements to the documentation to make it clearer and more practical. On our Discord, I've improved the support process with a ticketing approach which gets you help faster than ever in your own automatically made thread.
And lastly, for update frequency: as planned in #41, we now have two release channels, being the typical versioned releases, and the dev build, which recently got improved support within the app.
If you have any questions about the new release, the new autoexec.cfg, or want to give feedback, don't hesitate to reach out! I'm happy to help and make things better.
Please
sign in through STEAM
to post a comment.