Like the title says. I have it on x-ray, so it’s not being blocked, and the distance is more that sufficient.
What?
Sounds to me like the ray isn’t actually hitting anything. Recheck your start and end ray positions, as well as your distance and property arguments.
I’ve checked them, no luck.
Here’s a question, if the ray never actually reaches objectTo, does that influence anything? It shouldn’t…
Also:
ray = (self.rayCast(sightPosL ,self ,999999999999999999999999999999999999999.9 ,'wall' ,1 ,1 ))
Also again:
“sightPosL” is working, I checked
If you need to see what’s happening, feed the positions into bge.render.drawline, so you can see where the ray is going. You may be surprised!
And are you getting the right part of output from the ray function? It returns a whole bunch of things.
Thanks! when messing with it, I changed the ‘999999’ ext… (the distance) to something reasonable, (only 9-10 9’s) and that seemed to fix it… weird…
Is there any way to tell the ray to ‘just go forever’? 0.0 doesn’t work in that regard…
How does a ray check whether it hits something?
It starts at one end, works it’s way forwards in tiny increments, and see’s if there’s an object there.
In order to reduce processing time, they divide the maximum distance up and use that as the increment size.
SO let’s say that it uses 10,000 increments for a 1 unit long ray. Now scale that to 10,000 units long and there’s be only a check every unit. Not much chance of it hitting anything really.
In reality, it’s probably a lot more complicated, but that’s why you can’t have infinitely long rays.
What you could do is change the start position;
a 100 unit ray from here to there, and then another from there to the next place until it hits something. Just stick it in a while loop.
But be aware it will eat up processing power.
I just looked this up, and the highest number that can be represented in single-precision floating point(the data type Blender uses for object positions) is roughly 1.710^38 (if I did my math right). Your huge number is about 110^39, which is over the limit. If rayCast does it’s calculations in single-precision, then your number would overflow, causing the calculations to fail.
I just thought that was interesting, lol.
It will return a (None, None, None).
And on that point: you don’t need to put parenthesis around the rayCast call.
By calculating the intersection between a vector and the relevant geometry (just algebra, basically). This calculation is performed for every object within the relevant space, designated with the “from” and “to” coordinates.
I’m pretty sure that “increments” are not involved (that would be ridiculously inefficient, and uncharacteristic of the Bullet physics engine, which is considered to be heavily optimized).
It’s more likely that the number would simply be converted to a maximum float value
Simple raycasting is done by checking each triangle to see if the ray hit it. This check is done by taking an equation for the ray (a line) and an equation for the triangle, setting them equal, and solving. This process is usually optimized significantly by reducing the number of triangles checked. A popular way of doing this is by storing the scene geometry into a more efficient data structure such as a bounding volume hierarchy tree (BVH tree) as Bullet does. This changes having to check all triangles (O(n)) to only checking a number of triangles equal to log base two of the number of triangles (O(logn)) by taking advantage of extra knowledge provided by organizing the triangles into the BVH tree.
In case you were interested in how rays work under the hood 
Ok, you can ignore me in light of those posts by far more knowledgeable people.