cheers leth

Yep

If people generally agree that it is actually "much harder" to see, I would suggest making it known (upfrag Sylent's post) and I'd suggest ETF2L remove this change for now, I have to admit that I have overlooked the visibility aspect as I assumed it would not be an issue, apologies.

The no-spin thing actually affects how pipes travel in the air, as air drag affects their trajectory. I agree that consistent spin would be better than no spin (but I still think no spin is better than random spin), I just have not had the time to make that happen.
The variance you're seeing is the random spread that pipes have. (Yes, that's a thing)

That's if you're in the air, if not, that's closer to 31 damage.

That's not a condition which affects Soldier's base self-damage resistance, the only factor is whether you're in the air or not.

That's not a particularly good reason against trying out changes.

The wiki explains the behaviour, the implementation rather than the intent of the feature, the latter seemed to be "gunboats only apply for rocket jumps", that is quite different. I implemented the change because I feel that situations such as the one described by Kermit feel incredibly absurd - the behaviour is hard to expect, to predict.
I would prefer to have Soldier's base self-damage resistance always apply (as opposed to only mid-air) rather than this, but I've not had the time to develop the change.

I've never understood the point about positioning when it comes to this change, I just cannot envision a situation in which this can be abused and not be reproduced without the plugin. This testing season could show me otherwise. The point about communication makes even less sense, you shoot a rocket, your scout who faces the other way runs into it, you're just never going to be able to prevent that through comms, that seems silly.

Sorry I didn't catch your message earlier. That was a bug in a previous version of the library I depend on, which has been fixed late May, Versions `2.2.0-detours11` and above should work fine. If you could send me the serveme reservation ID, that would be great too. Thanks

Related issue: https://github.com/peace-maker/DHooks2/issues/3

- Fixed the chat window not always being restored to the appropriate place

This forces default position for chat, some custom HUDs move it, practically cant do that anymore
EDIT: seems that you can with workarounds

Hats off to your dedication, that's genuinely inspiring
Do you have any set goals? Is being able to play on a server one of them?
I'd be happy to cover the costs and management of a decent global gameserver infra
I might also try my hand at getting the tf2-comp-fixes plugin features in PRs

Pazer knows how to fix this IIRC, I don't remember what the issue is anymore, but this should be recoverable

IIRC most browsers are framerate limited to 60 and have VSync turned on so you're pretty much encoding for a minuscule minority of users (those who disabled the framerate limit and vsync or those who use a media player to watch streams), moreover, you're fucking over the few that have to rely on software decoding.
Besides that, you're cramming twice the data into the same bitrate limit, making the image quality much worse.
The additional processing will most likely cause intermittent frame drops.
120fps is genuinely barely noticeable compared to 60fps.
Try it out, but there's absolutely no reason to keep it.
Sorry for buzzkill

what the fuck is wrong with you
EDIT: you're also absolutely lying about the b4nny thing

I'm not aware of any North-African TF2 communities, I would assume everyone just plays on ETF2L, you could try doing that as well.
I suggest you start a recruitment post on ETF2L (log in, go to Team Admin, Recruitment, and fill the form) and start playing some lobbies on TF2Center.
82 ping is a bit bad but it's not the worst if it's consistent, you could get used to it.

Good luck

I would like to contest this decision when it comes to the crossbow by providing some insight:

The virtual method `bool CBaseProjectile::CanCollideWithTeammates(*this)` returns the field `m_bCanCollideWithTeammates` which is initialized to false and updated to true during `CollideWithTeammatesThink`.
`CBaseProjectile::Spawn()` schedules this `Think` to execute after `gpGlobals->curtime + GetCollideWithTeammatesDelay()`, the latter returning 250ms by default.
The file concerned is `game/shared/baseprojectile.cpp`.

`CTFProjectile_HealingBolt` overrides `GetCollideWithTeammatesDelay` to always return 0ms,
however the projectile obviously doesn't collide with teammates as soon as it spawns.
I believe this behavior to not be expected, the intent seems to want it collide as soon as possible but it seems that `Think`s are only precise over a few server ticks.

One could argue that developers were aware of the effects of both methods as `CTFProjectile_GrapplingHook`, which is just below and shares its mother class with `CTFProjectile_HealingBolt`, and simply overrides `CanCollideWithTeammates` to always return false.
I don't believe this to be a fair assessment. Grappling hooks were added later on, and the only way to implement the logic to ignore teammates would have been by overriding `CanCollideWithTeammates` (or `CollideWithTeammatesThink`), possibly creating the need for a virtual method altogether.
In this case, as the behaviors are different and as the Crossbow's current implementation was probably not known to be an issue, it was overlooked and was not updated.

The file concerned is `game/server/tf/tf_projectile_arrow.cpp`.

Thank you.

Of course, there are diminishing returns, you can get a map to a pleasant state without perfecting it, in the case of Process, it did actually take only 30 minutes to switch stairs to BLOCK BULLETS and add a few transitions from displacements to brushes

This is true, therefore what I suggested wouldn't make much of a difference considering that most servers would be running TFTrue. The best would be to have TFTrue produce a whitelist file that contains the minimal amount of items possible.

I updated my post, the demo writing actually doesn't affect the server the same way that it does for CSGO because TF2 does not write the entire delay buffer at the end of a recording.
The culprit would therefore be the whitelist reloading, which I have disable on my plugin via

sm_tournament_end_ignores_whitelist 1

which is enabled by default and available on serveme.tf
EDIT: it does make it less noticeable but it's still present :(

Sorry for the bump, putting down some information I've discovered so that it can be found later, it doesn't necessarily concern players directly:

To server hosts:
- "GG Lag" is caused mainly by srcds writing the demo file to disk, which is something like ~1mbps worth of data, it happens in CS:GO as well EDIT: This is wrong, CSGO writes the rest of the delay buffer when stopping a recording, TF2 does not, this is therefore a misconception, my bad.
- "GG Lag" may also be is caused because the whitelist is re-exec'd and it has gotten huge, it happens anytime the tournament mode restarts, I will investigate to see if it can be disabled.

To map makers:
- Splash bugs are entirely mitigable by taking the time to properly clip things with `BLOCK BULLETS`, most of process can be made better by switching some `PLAYER CLIP`s to `BLOCK BULLETS` (should take no more than 20-30 minutes to fix a map)
- The fucky Wrap Assassin ball collision on Gullywash 2nd is caused by the detailing under the planks using func_lod, which should definitely be replaced by func_detail instead

To tournament admins:
- All holidays can be entirely disabled if you have SourceMod and basecommands by using `sm_cvar tf_force_holiday_off 1`
- Regardless, the Birthday ball should be entirely disabled in your tournament config via `tf_birthday_ball_chance 0`, it has a physics model and collides with stickies during rollout
- Considering most servers are able to update whitelist files on the fly, `unlisted_items_default_to` should be set to 1 and the file should only contain the items that are banned, to reduce the processing required.