https://github.com/mastercomfig/team-comtress-2/releases/tag/0.0.17

Yeah, it doesn't affect anything graphically. It does cause the same reload that mat_antialias does though, but I haven't blocked it because HUDs don't use it.

Usually HUDs will have a wait command which delays toggling mat_antialias, and this causes a material system reload. This is usually to force removing the dimmer on the main menu, which is not worth the material system reload, which causes unoptimal reinitialization and some rendering/HUD bugs. For example: https://github.com/n0kk/ahud/blob/master/cfg/valve.rc#L22

You can disable this behavior for HUD editing by adding alias block_antialias in your autoexec.cfg, or you can use mat_aaquality.

It's not substantially different, but it will increase water quality at a distance, lighting detail extremely slightly, sound quality, and contains system optimizations which don't affect quality which may increase FPS/prevent drops.

Got rid of a huge bottleneck for particle simulation!

https://github.com/mastercomfig/team-comtress-2/releases/tag/0.0.16

We're playing on connect tf2.mastercomfig.com!

Because the only thing carrying the iron bomber to total domination of the GL meta is this one unintended stat (not any sort of interesting new mechanic), and if it was fixed, then we could see more variety based on the mechanics of different rollers. These weapons you mentioned are completely different classes of utility versus the stock (especially the melee weapons), so I find it misleading to mention these examples.

I mean within the context of changing/keeping ONLY the Iron Bomber being our sole balancing tool, which is what I understood #92 to be saying. Being that if we think Demoman needs a nerf, nerf the Iron Bomber, if we think Demoman is fine, keep the IB how it is.

But the balance is much more complicated than that. I see this more of a discussion about GL balance as whole, rather than just about the Iron Bomber. At this rate, Demoman is going to become an IB only class, so talking about the IB in vacuum vs the other grenades is not useful. I think the two valid sides to this discussion are either you think what the IB has in radius is good for the game, and should be applied to the other GLs, because it makes no sense to force everyone to pick a single GL when there would be some valid choices all other things held equal. Or you can think the IB radius is bad for the game, and in that case, it should be the same as stock.

I don't think there is a valid argument for keeping them different, but hopefully recontextualizing the debate into two sections: should they be different, and then if not, should we use the stock or IB hitbox, will produce better discussion.

I think people are more concerned that because IB is just better for directs, when it shouldn't be, people are going to have no choice but to go with it in most situations because of the hitbox. Whereas it shouldn't be the hitbox size that determines what to pick, but the behavior of the rollers. And now that this is becoming common knowledge, IB is just going to become the definitive pick rather than something most people use because it feels better but they don't exactly know why they use it.

Veering off into discussion about base Valve balance and if it's legitimate is irrelevant in this discussion. The fact is Valve did add a hidden stat to the IB which makes no sense for it to be different and on its own, isn't an interesting part of the unlock, and isn't intended. The discussion is purely about the existence of a difference, not if the base value is good or bad. There unequivocally should not be a difference in hitbox size for stock and IB. The base value can be up for debate.

So, this discussion about demoman buffs or nerfs is kinda irrelevant. Pick which one you want, and make the rest of the GLs on the same level as the IB, or the IB the same level as the rest of the GLs.

Kisak is not affiliated with Valve. They are a community moderator for the GitHub Issues. Don't just see that the issue is on GitHub, and decide that's good enough. Please email the TF Team and Eric Smith directly with your feedback about this issue and illustrate how important it is to you that this gets fixed. This helps the TF Team see how important an issue it is to people. It is a surprise to many how few people and how few issues actually get reported to them, because of assumptions that the team has already seen some issue because of this or that.

Here are links for your convenience.

https://www.valvesoftware.com/en/contact?contact-person=TF%20Team
https://www.valvesoftware.com/en/contact?contact-person=Eric%20Smith

1. Do you keep -dxlevel 80 in your launch options? Forcing dxlevel also forces settings associated with a dxlevel. After you set your dxlevel with the launch option, you should remove it from your launch options again.
2. You may be using a preset which enables shadows. You can customize presets using modules, which bundle up recommended settings to accomplish a certain configuration. I wouldn't recommend using random commands copy and pasted from elsewhere for this purpose, as they could be incorrect and reduce performance. https://docs.mastercomfig.com/en/latest/customization/modules/#shadows. Gist of it is to write shadows=off in a new file called modules.cfg in tf/cfg/user or (tf/custom/my_custom_stuff/cfg/user).

There is a static base respawn time, which is based on a static death time of 2 seconds + the time for the freeze frame (0.4 travel time + 4.0 freeze time).

On top of this base, the non-scaled respawn wave time is added, which is 10 seconds by default, and can be changed per team by an input which happens upon capturing a control point, which adds or subtracts from a team's base respawn wave time.

Then, the game checks the time for the next respawn wave, and compares it to the time for the base respawn time. If the base respawn time occurs after the next respawn wave, the scaled respawn wave time is added on top of the next respawn wave to get the wave after the next, and so on until a respawn wave is found that occurs after the base respawn time.

The scaled respawn wave time is the non-scaled respawn wave time, except with the following extra logic: if the respawn wave time is above 5 seconds, then scale it by a number between 0.25 and 1.0, linearly scaled by the number of players (1 to 8). Then this value is capped to a maximum of 5.

This logic happens during any PvP game, tournament mode or not, with the exception of robot destruction, which has its own logic for customizing the respawn time on top of this. There are a few exceptions outside of normal PvP play, like if you are a Scout in MvM or in between rounds during Competitive Mode, you respawn with your static base respawn time, and in pre-game for tournament mode, there are no respawn times.

It's a pretty straightforward fix: https://github.com/mastercomfig/team-comtress-2/pull/63/files

I don't have much experience with SourceMod but from what I have seen it shouldn't be too hard there either.

https://github.com/mastercomfig/team-comtress-2/releases/tag/0.0.15

This one is a banger and I highly recommend testing it!

8.105.2 released with bug fixes.

Changelog
Support me

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

@springrolls @Kermit Could you share OS/system specs?

Congrats! (but is there any way you can see, it would be really helpful)

It did not crash on 8.104.2?