E2 mix functions implemented backwards

[Denneisk]

wire/lua/entities/gmod_wire_expression2/core/vector.lua

Lines 524 to 530 in ccfd65e

	e2function vector mix(vector vec1, vector vec2, ratio)
	return Vector(
	vec1[1] * ratio + vec2[1] * (1-ratio),
	vec1[2] * ratio + vec2[2] * (1-ratio),
	vec1[3] * ratio + vec2[3] * (1-ratio)
	)
	end

mix(vvn) is implemented so that mix(vec1, vec2, 0) == vec2. The same applies to all other mix functions (vector2, vector4). This is confusing compared to typical definitions of similar functions.

The expected behavior is mix(vec1, vec2, 0) == vec1.

Not sure how no-one has complained about this before.

Updates:
This thread is now a bit outdated for mentioning vectors specifically, but this still holds true for other types, so those still need to be addressed.
#2895: Deprecated mix(vector, vector, number)

[vurvdev]

With #2721, could probably fix this ordering issue with the color type and deprecate this function. And then maybe add lerp(vvn) too.

[Fasteroid]

Agreed, it's definitely backwards, and I've known for ages. I just never complained because fixing something like this requires either deprecating functions or breaking backwards-compat (lol)

[Hazeofdream]

when e2 literally breaks chips by fixing its self lmao

does this mean e2 functions by being broken

[vurvdev]

Converted to a discussion since this isn't a bug just bad design