[Bug]: NormalizeVector returning a false vector length

[mariokeks]

Prerequisites

• [x] I have checked that my issue doesn't exist yet in the issue tracker

Operating System and Version

Debian GNU/Linux 12 (bookworm)

Game / AppID and Version

240 (Latest)

SourceMod Version

1.13.0.7215

Metamod:Source Version

1.12.0-dev+1217

Version Verification

• [x] I have updated SourceMod to the latest version and the issue persists
• [x] I have updated SourceMod to the latest snapshot and the issue persists
• [x] I have updated Metamod:Source to the latest snapshot and the issue persists

Updated SourceMod Version

1.13.0.7219

Updated Metamod:Source Version

No response

Description

The NormalizeVector function doesn't work correctly with zero vectors in latest CSS versions (64 bit linux). Instead of returning a zero length and a zero vector, it returns a very small, but incorrect, non-zero length.

This is different from how it behaves in the previous CSS version, where it correctly returns a zero length.

I guess a simple solution would be to implement an explicit check for zero vectors and returning a zero length instead of the VectorNormalize value.

Steps to Reproduce

#pragma semicolon 1
#pragma newdecls required

public void OnPluginStart() 
{
	RegAdminCmd("sm_test", Command_Test, ADMFLAG_ROOT, "Test command ( ͡° ͜ʖ ͡°)");
}

Action Command_Test(int client, int args)
{
	float fAngles[3];
	float fLength = NormalizeVector(fAngles, fAngles);
	ReplyToCommand(client, "Length: %f", fLength);
	return Plugin_Handled;
}

Relevant Log Output

Result (Latest CSS version)
sm_test
Length: 0.000009

Result (Previous CSS version)
sm_test
Length: 0.000000

[Headline]

What we've used here hasn't changed, are you sure this is something recent?

@psychonic it's going to be this I'm sure, it's dodging a div by zero. What's the move - hack a check in the native? dev-users are welcome to check small floats themselves, but the api should probably just ret 0

https://github.com/alliedmodders/hl2sdk/blame/5aae5d9c3b8aaddd1730fa02cd16c5b49cfd8f2c/public/mathlib/vector.h#L2220C36-L2220C41

[mariokeks]

Incase the question was directed at me, tested it a few minutes ago again with SourceMod Version: 1.13.0.7254 Metamod:Source version 1.12.0-dev+1219 still Debian GNU/Linux 12 (bookworm) and still happens with test script.

Everything worked as expected before the CS:S update on 2025-02-18. After that update, the behavior changed, no other modifications on my side besides updating MM:S/SM to their latest builds.

[Kenzzer]

What we've used here hasn't changed, are you sure this is something recent?

This would coincide with the update we performed on the sdks. And as you've pointed you likely found the culprit.

If behavior consistency is the goal here, I would argue we should forward port whatever was the math before and hardcode it into SM rather than depending on SDK definitions.