Move from a node to another of Path2D

Catapult It probably is safe to use. But again, the documentation does not explicitly guarantee it. So we can't be sure. IMHO it should mention how it internally determines if two vectors are equal.

And you're not only an engine user. You're a software developer as well. And every software developer should know how floats operate. That's why the article @Megalomaniak linked is called What Every Programmer Should Know About Floating-Point Arithmetic

Imagine you want to port your code to a different language or need to use a different type of array. In c++ for example, all find() methods for all standard array types always default to using == for comparison.

I did a quick test and it appears that find() in packed arrays indeed uses some epsilon when comparing values. However it can still bite you in the butt when you least expect.
Consider this piece of code:

	# add an integer value to float32 array
	var a = PackedFloat32Array()
	a.push_back(1)
	
	# do some calculations that should result in the same value we started with 
	a[0] -= 1.1
	a[0] += 1.1
	
	# prints true as expected
	print(a[0] == 1)
	
	# prints true as expected
	print(is_equal_approx(a[0], 1))
	
	# prints 0, the value is fond in the array as expected
	print(a.find(1))

Now check this out. Exactly the same code, only that addition/subtraction in our dummy calculation swapped places. The code now behaves differently for seemingly no apparent reason:

	# add an integer value to float32 array
	var a = PackedFloat32Array()
	a.push_back(1)
	
	# do some calculations that should result in the same value we started with 
	a[0] += 1.1
	a[0] -= 1.1
	
	# prints false
	print(a[0] == 1)
	
	# prints true
	print(is_equal_approx(a[0], 1))
	
	# prints -1, the value is NOT found in the array
	print(a.find(1))

That's the kind of gotchas I was talking about.

But there's more If you change 1.1 to 1.2 in the second piece of code, things now again work as expected. But if you change it yet again to 1.4 - the bug is back.
Is my computer possessed by a demon?

Catapult
Oh, but they all do behave in precisely this way if you use floats. You just haven't picked the "right" numbers. This is fundamental to floating point representation of real numbers. Think about it. You have finite number of bits to represent infinite number of decimal places. There's no theoretical way to achieve "total" precision. Hence using == with floating point numbers of any precision always comes with this caveat.

GDScript has nothing to do with this. It happens with floating point arithmetic on the machine code level. So all higher level languages will do the same.

Here are two examples.

Python prints False here:

a = 1
a += 1.11
a -= 1.11
print( a == 1 )

C++ prints zero here, which is equivalent of false:

#include <iostream>

int main() {
   float a = 1.0f;
   a += 1.11f;
   a -= 1.11f;
   
   std::cout << (a == 1.0f);
}

Double precision floats in c++ will produce the same result:

#include <iostream>

int main() {
   double a = 1.0;
   a += 1.11;
   a -= 1.11;
   
   std::cout << (a == 1.0);
}

Well, you can rationalize around it one way or another. The reality is - the approach you've taken has a potential to cause crashes. You can play on the safe side and instead of using find() iterate and call is_equal_approx(). Or don't do that and risk a buggy application. It's your call.

Btw no need to manually calculate a distance between two points. Using Vector2::distance_to() results in much more readable code:

total_pixel_length += p1.distance_to(p2)

Catapult Devs are not visiting this forum afaik

Not a smart move, imho.

Some of them have occasionally popped in here, but naturally most of their free time goes towards actually developing the engine, and there are more engine development focused channels of communication that they'd prioritize over the user forums. Those other channels are still open tho, and users can access them too. Just don't go spamming in there. If a meeting is taking place be patient - you can ask a question after the meeting is over.