[HL] Crossbow shoots at wrong angle underwater

[Nesciuse]

Haven't seen this mentioned anywhere. When shooting crossbow underwater it fires at wrong angle. Aiming up, down, forward works correctly but aiming at some angle fires the bolt wrongly. See video

https://youtu.be/fzWfx0z0JVQ

[HaajPaaj]

Someone can correct me if I'm wrong, but I believe this is an intentional game mechanic, not a bug. It's supposed to simulate gravity acting differently on the crossbow bolts underwater. This is further supported by the fact that when the crossbow is first obtained in the game, you are immediately dropped into a body of water, so this effect can be observed right away.

[Nesciuse]

That's definitely not the case. The bolt is supposed to simply travel slower underwater not travel in different direction then where you aim. Couldn't figure out why it happens looking at the source code. This code

halflife/dlls/crossbow.cpp

Lines 419 to 428 in b1b5cf5

	if (m_pPlayer->pev->waterlevel == 3)
	{
	pBolt->pev->velocity = vecDir * BOLT_WATER_VELOCITY;
	pBolt->pev->speed = BOLT_WATER_VELOCITY;
	}
	else
	{
	pBolt->pev->velocity = vecDir * BOLT_AIR_VELOCITY;
	pBolt->pev->speed = BOLT_AIR_VELOCITY;
	}

sets up the velocity. Also this works properly in Half-Life Source

[SamVanheer]

Whether it was intentional or not is irrelevant, it's been this way for 26 years. Changing gameplay mechanics after that much time is a bad idea.

You can always fix it in a mod.

[HaajPaaj]

By that same line of logic, can't the broken behavior be restored with mods? I fail to see why fixing this error, if it truly is an error, would be a bad thing. If it goes against the intentions of the designers unintentionally, I would consider that an issue that could do with fixing.

[Nesciuse]

@SamVanheer
It's not a gameplay mechanic but a simple bug that makes crossbow quite bad and unintuitive. Most people don't even know they are missing the ichtyosaurus most of the time because of this. Calling this gameplay mechanic is quite a reach. Did you even know about this if you claim fixing this after 26 years is a bad idea ? Did you even verify if this bug was present at release ?

[HaajPaaj]

If it isn't a gameplay mechanic, then I agree.

[SamVanheer]

The bolt behaves this way because the bolt's origin is changed without also being updated with a call to UTIL_SetOrigin. Toodles2You figured this out and submitted a PR to Half-Life Updated last year: twhl-community/halflife-updated#208

That's definitely not the case. The bolt is supposed to simply travel slower underwater not travel in different direction then where you aim. Couldn't figure out why it happens looking at the source code. This code

halflife/dlls/crossbow.cpp

Lines 419 to 428 in b1b5cf5

	if (m_pPlayer->pev->waterlevel == 3)
	{
	pBolt->pev->velocity = vecDir * BOLT_WATER_VELOCITY;
	pBolt->pev->speed = BOLT_WATER_VELOCITY;
	}
	else
	{
	pBolt->pev->velocity = vecDir * BOLT_AIR_VELOCITY;
	pBolt->pev->speed = BOLT_AIR_VELOCITY;
	}

sets up the velocity. Also this works properly in Half-Life Source

Half-Life Source should not be used as an example for how things should behave in Half-Life. Valve themselves have said that Steam Half-Life is the definitive way to experience the game, while delisting Half-Life Source at the same time. It's also incredibly buggy so the differences could be unintentional.

Additionally the physics engine is responsible for movement so changing engines changes behavior in many ways, and changing the entity origin in Source is done in a way that prevents this particular problem from happening so simply porting the game would "fix" it without anyone realizing:
https://github.com/ValveSoftware/source-sdk-2013/blob/0d8dceea4310fde5706b3ce1c70609d72a38efdf/mp/src/game/server/baseentity.cpp#L5884-L5925

Since you can't set the origin incorrectly any changes in behavior in Half-Life Source can't be taken as evidence that this is the correct behavior.

By that same line of logic, can't the broken behavior be restored with mods?

Yes, as i said. It can be fixed in a mod.

I fail to see why fixing this error, if it truly is an error, would be a bad thing. If it goes against the intentions of the designers unintentionally, I would consider that an issue that could do with fixing.

Because there are 26 years worth of maps and mods using the Half-Life game dlls that would be affected by this change. It also affects multiplayer balance in favor of players using a crossbow. There is also no evidence (that i know) to support the notion that this is a bug.

@SamVanheer It's not a gameplay mechanic but a simple bug that makes crossbow quite bad and unintuitive. Most people don't even know they are missing the ichtyosaurus most of the time because of this. Calling this gameplay mechanic is quite a reach. Did you even know about this if you claim fixing this after 26 years is a bad idea ? Did you even verify if this bug was present at release ?

It doesn't matter what you call it, what matters is that changing it changes game balance. Given that the player is first introduced to the weapon in a situation that practically forces you into underwater combat with this weapon it's pretty obvious that it was intended to behave this way, even if the method used is technically a bug. They may not have known exactly why it did this but deemed it acceptable, since there are no comments to indicate either way we have to assume it was intentional.

I don't know why you're asking if i knew, that has no relevance. But if you look at the link above you'll see i did know about this behavior. Aside from having played the game and thus knowing the crossbow behaves this way underwater i already evaluated this behavior and the changes needed and rejected it for Half-Life Updated precisely because it changes game balance which is what matters.

As for verifying if it was present at release, you can check which changes were made to the crossbow's source code here: https://github.com/twhl-community/HalfLifeSDKHistory/blame/f5933d2880686b06fb82aaf2eccbff9580dc77ef/dlls/crossbow.cpp

To save you a click, the code that causes this behavior has not changed since SDK 1.0. You can always load up a release day WON build to see for yourself if you want to be sure, but the method used to change entity origins dates back to Quake 1 so i would be surprised if it behaved any differently in an earlier build.

Here's an example from the Quake 1 source code where a rocket is spawned and its origin is set:
https://github.com/id-Software/Quake-Tools/blob/c0d1b91c74eb654365ac7755bc837e497caaca73/qcc/v101qc/weapons.qc#L421

(Note: in QuakeC self is an implicit parameter to functions. In this context it's the character that is creating the rocket so the origin being passed in here is that of the character, and it's setting the missile's origin)

Half-Life 2's crossbow bolt does set the origin earlier on than the equivalent HL1 code did, but the bolt in HL2 is physics simulated with gravity so that doesn't say anything about the behavior in HL1.

There are no comments there indicating that the original behavior was a bug and the HL2 crossbow already has the challenge of compensating for gravity so they probably didn't want the added difficulty of compensating for water affecting the direction. There's no way to know without asking whoever was responsible and the recent HL2 documentary makes it clear they don't remember many details, so in the absence of more information and given this change affects game balance leaving this behavior as-is is the better option.

As i said, this is something you can change in a mod. There are several mods that aim to restore broken functionality, you can always ask the authors of those mods to change it. Changing it in a mod won't affect every map and mod that uses the original game dlls.

[Nesciuse]

There is no reason to preserve such an ugly useless bug just because it's 26 year old. Stuff like func_pushables moving super fast when moving with e, grenade throw speed or satchel charge deploy logic were changed in anniversary update which are all quite big gameplay changes and I don't see an issue with it.