If you have an FVector and multiply it by a number, you get the expected results (a new vector scaled by the given number). But if you reverse the order of the arguments (and do number * FVector), the returned vector is garbage.
I verified that ue_py_fvector_mul in UEPyFVector.cpp is being called in both scenarios, but the problem is that that function assumes that the 'self' parameter will always be the FVector object, which is not the case, unfortunately. The Python docs say:
Note Binary and ternary functions must check the type of all their operands, and implement the necessary conversions (at least one of the operands is an instance of the defined type). If the operation is not defined for the given operands, binary and ternary functions must return Py_NotImplemented, if another error occurred they must return NULL and set an exception.
This patch changes the multiplication function to handle either case, and does the same for FVector2D. It's likely that other wrapper objects that implement the Python number protocol will have to change too.
If you have an FVector and multiply it by a number, you get the expected results (a new vector scaled by the given number). But if you reverse the order of the arguments (and do number * FVector), the returned vector is garbage.
I verified that
ue_py_fvector_mulin UEPyFVector.cpp is being called in both scenarios, but the problem is that that function assumes that the 'self' parameter will always be the FVector object, which is not the case, unfortunately. The Python docs say:This patch changes the multiplication function to handle either case, and does the same for FVector2D. It's likely that other wrapper objects that implement the Python number protocol will have to change too.