Remove rcon freezehammer command

[l-ouis]

Seems to be very unused

[heinrich5991]

Sounds good to me.

[ChillerDragon]

no fun zone, but yea seems consistent

[ChillerDragon]

This will create git conflicts in FireWeapon() btw @Kaffeine #9836 (comment)

[Kaffeine]

This will create git conflicts in FireWeapon() btw @Kaffeine #9836 (comment)

I haven't see your planned changes, I don't see the patch for this issue, and I don't see why it would touch the last five lines in (where you could overload the timer behavior).

void CCharacter::FireWeapon()
{
	// skipped code
	// ...
	if(!m_ReloadTimer)
	{
		float FireDelay;
		GetTuning(m_TuneZone)->Get(38 + m_Core.m_ActiveWeapon, &FireDelay);
		m_ReloadTimer = FireDelay * Server()->TickSpeed() / 1000;
	}
}

Here are so many options but it is difficult to understand what exactly you want or planned to do. IMO hacks here are not any worse than abusing SetReloadTimer() behavior but without the code this discussion is pointless. Also, subclassing is the easiest approach to many changes.

[ChillerDragon]

@Kaffeine I was just responding to your doubt that FireWeapon() changes.

[Kaffeine]

@Kaffeine I was just responding to your doubt that FireWeapon() changes.

Sorry if I didn't make it clear. In the comment I meant exactly those cited five lines of code, which set m_ReloadTimer, and which I described as "only you and I changed those over last years" (okay, there is HammerHitFireDelay above with similar 'blame' info).

It is understandable that lines above those five are changed more often than once a few years.

I still think that subclassing opens room for many deeper changes with a small conflict surface, yet it keeps the code clear (compared to hacked setters).

// Probably someone else's issue is not the best place to chat tho 😄 we could talk in your PR to not disturb l-ouis (but unfortunately still make noise for other ddnet devs)