The Team Comtress 2 Summer 2026 Update is here!
| Account Details | |
|---|---|
| SteamID64 | 76561198046110893 |
| SteamID3 | [U:1:85845165] |
| SteamID32 | STEAM_0:1:42922582 |
| Country | United States |
| Signed Up | August 8, 2017 |
| Last Posted | July 18, 2026 at 6:10 PM |
| Posts | 1620 (0.5 per day) |
| Game Settings | |
|---|---|
| In-game Sensitivity | |
| Windows Sensitivity | |
| Raw Input | 1 |
DPI |
|
Resolution |
|
Refresh Rate |
|
| Hardware Peripherals | |
|---|---|
| Mouse | |
| Keyboard | |
| Mousepad | |
| Headphones | |
| Monitor | |
9.100.1 released with bug fixes and minor improvements.
This release took 84 hours to produce. If you like the work I do, consider supporting me!
Keep in mind that in some cases, lowering snd_mixahead can actually increase latency because you aren't filling the buffer enough for how much your audio device reads at a time and your own framerate (since the game is not multi-threaded, audio only can write during the frame). Also, I have not investigated if this has changed since the sound system got updated in the 64-bit update, but snd_surround_speakers 7 can also reduce latency due to how it changes how audio is written in the buffer.
It's an issue with the code of the game, fixed in Team Comtress :)
https://teamcomtress.com/patches/2026-02-20
https://teamcomtress.com/patches/2026-03-10
I went through every livestream of Team Comtress for the ozfortress Midsummer Cup, and fixed every issue I could find, made it harder for configs and such to go wrong, and overall made things smoother!
The first official Team Comtress 2 log: https://teamcomtress.com/match/?matchId=3457208472725098496
bit barebones right now, but we're going to get a lot of really interesting stats in the coming days added to matches!
Thank you for reviewing the code and letting me know. I wanted to make a clarification for the ramp up / density system changes, keep in mind that I did change the math in addition to tweaking parameter values. And I did test it and basically measured using +left and cl_yawspeed. I used various different rotations per second that correlate to the tick rate of the flames, to measure if DPS proportionally decreased for reduction in persistent contact in between flame damage ticks. And I tuned it such that you get a nearly proportional increase to your accuracy on the target. So, if you have 50% accuracy, you get 50% DPS. If you have 70% accuracy, you have 70% DPS, etc.
I think the issues were that the parameters were not tuned to be proportional to flame accuracy, so it wasn't very responsive to focus fire, and it was based on lifetime rather than just tracking collision rate. This meant that if you were slightly too far away, each flame collision would not be enough to "fight" against the heat drain rate, and your DPS would decrease, despite being 100% accurate. And small variations in lifetime could cause this problem too even at closer ranges. The lack of parameter adjustment and the way heat decays each tick regardless of a hit or not, and regardless of if you had a chance to fire a flame that tick, meant that it was very slow to get up to 100% DPS, and when it got there, there were times where you simply had no chance to stop the DPS lowering. So, I very intentionally tuned the parameters and the math to counteract this based upon tickrate patterns, contact accuracy proportionality, etc.
Awesome work! You seem very passionate and knowledgeable about the flames. I loved the video you did back in the day which raised a lot of awareness regarding this issue, and this plugin is awesome too! Do you think you could maybe review if the flamethrower fix I did here to the SDK makes sense: https://github.com/mastercomfig/tc2/commit/0435ae3ebd8bb0a3781482501c3d236ce3747a32
Subsequent adjustment commits:
https://github.com/mastercomfig/tc2/commit/0951bc517106822f10dc5b11383df78c4a429dd6
https://github.com/mastercomfig/tc2/commit/783a94cf20875ae0a2ec3ea8f5198090e7304c94
https://github.com/mastercomfig/tc2/commit/fbe48cd6c86fc8e118ea2f44ffd8080f9887bb70