Why use Vusaline over mastercomfig?

[NekoAlosama]

mastercomfig is much more well known and documented than this enhancer. I noticed there are a few differences between the commands in the decisions page versus mastercomfig's comfig.cfg, and I fail to see why these changes are worth the switch, especially since "How does Vusalo compare to other configs?" in the FAQ doesn't really show a comparison or show why it's better.

I don't see a reason why you couldn't just suggest these changes with an issue in mastercomfig's repo, like the commands and reasons in decisions.adoc or protection.cfg.

[movementplaya]

There is a lot that could be said concerning this topic, however, I will try to be brief.

Firstly, the main thing to consider is the fact that Vusaline is not simply a config file like mastercomfig is. This is because it has fairly different objectives from mastercomfig, which although similar, are achieved using more 'drastic' methods, such as disabling certain modules entirely. Vusaline is not focused on maximising frame rates, instead, it's primary focus is to maximise stability, and as a result, it strives to achieve high frame rates.

Secondly, is that a lot of people don't enjoy using mastercomfig, or have issues with it, a lot of which could be attributed to it's lack of focus on stability.

On top of this, Vusaline attempts to be easier to setup and remove than mastercomfig, with the use of installers and uninstallers.

Another thing to consider, is the fact that Vusaline makes 'bad options' hard to access or outright blocks them off. This may be somewhat questionable, but tampering with a lot of things defeats the purpose of Vusaline

Lastly, I personally enjoy working on Vusaline, which I do during my free time, without any sort of income/donations. With that said, I'd rather work on it myself than find a way to make all my code compatible with someone else's.

As far as comparisons go, I've yet to properly do so, as I personally want to first finish some improvements, which is also why promoting Vusaline isn't a priority. However, I do plan to do so in the near-ish future.

This is may be more subjective, but I personally don't like the way a lot of decisions are taken in mastercomfig, as well as having a better gameplay experience using the original Vusalo than with mastercomfig.

[NekoAlosama]

I can understand that. I'll be waiting for the 1.0 release before I try out Vusaline. For now, I can change my mastercomfig .cfg based off of decisions.adoc and use your launch options.

[mastercoms]

Firstly, the main thing to consider is the fact that Vusaline is not simply a config file like mastercomfig is.

mastercomfig is not a config file either. It's a VPK with a lot of resource customization, and I'm open to more in this area.

This is because it has fairly different objectives from mastercomfig, which although similar, are achieved using more 'drastic' methods, such as disabling certain modules entirely.

Another thing to consider, is the fact that Vusaline makes 'bad options' hard to access or outright blocks them off. This may be somewhat questionable, but tampering with a lot of things defeats the purpose of Vusaline

I've actually considered disabling things. In fact, mastercomfig does disable changing anti-aliasing, and I did float the idea of blocking harmful changes, but am concerned about users being blocked from doing in-game module changes with valid settings.

Vusaline is not focused on maximising frame rates, instead, it's primary focus is to maximise stability, and as a result, it strives to achieve high frame rates.

Secondly, is that a lot of people don't enjoy using mastercomfig, or have issues with it, a lot of which could be attributed to it's lack of focus on stability.

mastercomfig doesn't intend to reduce stability either, and it has many presets which don't maximize framerates (Ultra, High, etc). In fact, many of the defaults in the config aren't set to the highest performance options because they break features or provide a worse user experience. I would be interested in knowing what differences are here, because I couldn't really find anything when I compared the configs. Frankly, what I see a lot of in here is just settings copied from mastercomfig, including old versions, plus a handful of some harmful/useless settings in Vusaline:

• net_blockmsg is a cheat cvar, but is in hidden_cvars
• host_thread_mode is only relevant for local games and breaks them. There's no threaded logic besides the server thread, and it messes up how the client captures input on multiplayer games.
• jpeg_quality 100 I don't think JPEG's really need more than around 86 to 90, maybe for some extremely colorful scenes but even then. Steam compression is pretty bad too.
• mp_usehwmmodels and mp_usehwmvcds are completely unused
• mod_dynamicunloadtime 600 causes stutters when many models are in cache, especially in MvM or on systems with high memory pressure
• net_queued_packet_thread 581304 will forcefully add lag to client packets. There's 1 usercmd (42 bytes) sent every 0.015 seconds. And you basically add an arbitrary 0.5ms delay on top of that + extra context switching/scheduling in the queued packet thread.
• net_compresspackets_minsize 1024 packet compression is pretty much useless, since voice is not compressed and cmd packets are 42 bytes
• mod_load_anims_async 1;mod_load_mesh_async 1;mod_load_vcollide_async 1 causes stutters on many machines. Its CPU and IO requirements are nasty.
• dtwatchent 0 enables it for the 0th entity. -1 disables already, not sure why this is set.
• r_drawopaquestaticpropslast 1 Do you know why this is in here or what it does?
• voice_fadeouttime 0 This breaks audio in some cases. (makes it crackle)
• snd_mix_async 1 does nothing. it's for xbox 360 only
• cl_fasttempentcollision 2147483647 there's no point in setting this high, tempents don't last that long
• tf_dingalingaling_repeat_delay 0.000001 Does this actually work? Block hitsounds in the same frame?
• cl_timeout isn't related to packets, it's the disconnect timer in seconds after you've dropped
• r_overlayfadeenable people really hate this setting, so I wouldn't recommend enabling overlay fades when you enable overlays in general, maybe as an option
• engine_no_focus_sleep 38 why 38?
• rate 1048576 this will indeed kill any PC with internet that can't handle it, which is actually quite a noticeable percentage of config users unfortunately
• -nodns is this needed? what if people connect to a domain?
• -disable_d3d9_hacks did you check to see what AMD driver communication the game is doing and if it reduced FPS or caused instability?
• -nowatchdog only does things on dedicated servers
• -glslcontrolflow -arbmode this cancels itself out (literally game checks if ( CommandLine()->FindParm("-arbmode") && !CommandLine()->FindParm("-glslcontrolflow") )
• -precachefontintlchars this doesn't precache english chars anymore, i guess it's useful since the game already encounters those for the most part, but not sure
• -nocrashdialog is this really needed?
• there might be others

And like, there's some legitimately cool stuff in the config too! I think the dashboard stuff is neat, the playdemo trick is cool though probably slight, some of the distance values seem to be more tuned and I do like some of the customization options too! It's why I still think people ought to collaborate rather than split off, so that we don't make the same mistakes and we can improve things for everyone.

Lastly, I personally enjoy working on Vusaline, which I do during my free time, without any sort of income/donations. With that said, I'd rather work on it myself than find a way to make all my code compatible with someone else's.
This is may be more subjective, but I personally don't like the way a lot of decisions are taken in mastercomfig, as well as having a better gameplay experience using the original Vusalo than with mastercomfig.

This is completely fair! But I'm happy to help with facilitating contributions, it is just some Source files at the end of the day, just need a way to find where things are and then it should be smooth. And if you disagree with some decisions or want to improve things in mastercomfig, I'm totally open to it! In fact, the original creator of this config also contributed things to mastercomfig a few years back. Anyways, if you do wanna have your own config, it's totally fine obviously, but I do think we should at least chat and improve things together!

[movementplaya]

Right, it's time I make a response.

mastercomfig is not a config file either. It's a VPK with a lot of resource customization, and I'm open to more in this area.

Although I haven't kept up with development on mastercomfig in recent times, when I used it as my main performance enhancer, it consisted of multiple cfg files (which yes, were packed in a vpk, which is hardly relevant), but that's not really important at this point in time.

mastercomfig doesn't intend to reduce stability either, and it has many presets which don't maximize framerates (Ultra, High, etc). In fact, many of the defaults in the config aren't set to the highest performance options because they break features or provide a worse user experience. I would be interested in knowing what differences are here, because I couldn't really find anything when I compared the configs. Frankly, what I see a lot of in here is just settings copied from mastercomfig, including old versions, plus a handful of some harmful/useless settings in Vusaline:

I and many others have experienced worse stability using mastercomfig, which was the main reason of resurrecting this whole project by the original author: to increase and focus on stability. Moving on to 'parts copied from mastercomfig', I guess some similarities could arise when tracing back to Chris' config (which this project was intended to replace back in the day, mind you), although that can't be considered 'copying from mastercomfig'.

As for the settings mentioned having issues, I cannot clarify my reasons for all of them right now (mainly because I have either forgotten what their advantage was or never found out what their reasoning was in the first place) but hopefully in the near future I will actually finish the documentation (instead of shoving it all here progressively with edits) (and finish investigating what all the settings actually do (I'm slow at RE)). However, there are a few I can make a say about here and now:

net_blockmsg is a cheat cvar, but is in hidden_cvars

I initially intended to rename this file and have it include all hidden/cheat cvars that could be useful, as making use of them requires...'controversial' methods.

jpeg_quality 100 I don't think JPEG's really need more than around 86 to 90, maybe for some extremely colorful scenes but even then. Steam compression is pretty bad too.

I've actually already thought of reducing this value since it seemed pretty pointless to try get high quality jpeg screenshots when you can just get uncompressed screenshots.

tf_dingalingaling_repeat_delay 0.000001 Does this actually work? Block hitsounds in the same frame?

Yes, yes it does.

rate 1048576 this will indeed kill any PC with internet that can't handle it, which is actually quite a noticeable percentage of config users unfortunately

Not sure what you mean by this. I have literally tested Vusaline with a bitrate limited to 1mb/s (down and up) and have not noticed any issues.

-glslcontrolflow -arbmode this cancels itself out (literally game checks if ( CommandLine()->FindParm("-arbmode") && !CommandLine()->FindParm("-glslcontrolflow") )

I don't actually use Linux for anything currently and Vusaline doesn't actually have proper support for it (yet). However I did look into this, and it checks out.

-nocrashdialog is this really needed?

Crash windows aren't really useful for your average TF2 player.

And like, there's some legitimately cool stuff in the config too! I think the dashboard stuff is neat, the playdemo trick is cool though probably slight, some of the distance values seem to be more tuned and I do like some of the customization options too! It's why I still think people ought to collaborate rather than split off, so that we don't make the same mistakes and we can improve things for everyone.

Thanks(?), although I don't really know what for, since none of this was my idea. I'm just picking up where the original creator left off, so that others can keep using this. As for collaborating, I'm not really convinced of the idea; I like working at my own pace without needing to worry about other people or their development. I genuinely find working on this quite an enjoyable (and educational) experience, and I feel like working with others would ruin it (that, and a couple of other reasons I won't mention here).

This is completely fair! But I'm happy to help with facilitating contributions, it is just some Source files at the end of the day, just need a way to find where things are and then it should be smooth. And if you disagree with some decisions or want to improve things in mastercomfig, I'm totally open to it! In fact, the original creator of this config also contributed things to mastercomfig a few years back. Anyways, if you do wanna have your own config, it's totally fine obviously, but I do think we should at least chat and improve things together!

Acknowledged. I will just say, that, like the creator of Vusalo, I have a slight distaste for mastercomfig and prefer working separately.

P.S. Forgot to say thanks for the feedback!

[mastercoms]

Fair enough, all I have to say in response is that I would have appreciated hearing at some point that the stability was bad :)