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).
Account Details | |
---|---|
SteamID64 | 76561198046110893 |
SteamID3 | [U:1:85845165] |
SteamID32 | STEAM_0:1:42922582 |
Country | United States |
Signed Up | August 8, 2017 |
Last Posted | May 29, 2025 at 11:21 PM |
Posts | 1557 (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 |
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.
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?
https://github.com/mastercomfig/team-comtress-2/releases/tag/0.0.14
Playtesting on connect tf2.mastercomfig.com
8.105.1 released with bug fixes.
This release took 2 hours to produce. If you like the work I do, consider supporting me!
8.105.0 released with performance improvements, download site redesign, and bug fixes.
This release took 25 hours to produce. If you like the work I do, consider supporting me!
mod_load_anims_async 0
mod_load_mesh_async 0
mod_load_vcollide_async 0
mod_touchalldata 1
mod_forcedata 1
Make sure these are set
Yeah I'd still use null movement, it was just a neat fact I thought I'd bring up in conversation. The amount of input delay it adds is so small compared to the benefits and the possible increase in responsiveness due to brain/finger delay for releasing keys :)