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?

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.

Changelog
Support me

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.

Changelog
Support me

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

Like in Team Comtress or in TF2?

Could you clarify what you mean?

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 :)

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

Update on the fixed weapon spreads: it resulted in worse play than normal, since the fixed seed for the weapon spread could be terrible to aim with, while a randomized seed plays better, since there's even chances of god spread and bad spread, so you aren't stuck with any one spread. It's pretty hard to find a seed for a pattern that's truly "average", so I think randomization is a better way of averaging this out than a fixed one.

Also about multi-threading, I don't think Source really needs much more multi-threading than it already has