And there is a picture showing what we want to achieve
those circles are indicating nodes, and lines are indicating rays.
Question: What judges what direction the ray will be shooting?
Also, could you solve this another way, let’s say using magnitude by looping through the various nodes and attempting to find the closest one? Each node could be given a count of connections it needs in order to properly handle junctions. If tracks will be running parallel to each other very closely you could also give each node a sort of TrackID so it knows which ones to attach to and which ones to ignore the other nodes?
I think you’re wanting the LookVector or RightVector then as the end point. You could try something like below
local o = i.CFrame.LookVector*10
or
local o = i.CFrame.RightVector*10
It’s judged by the orientation of the part that the ray is coming from.
I prefer rays as I know the direction and therefore I know that it’s the next node along.
Alright, so in your picture the green parts are the successful ones, yellow is the current test part, and red is to be be obtained?
Correct.
Yellow is the current part the ray is shotting from.
What is that big green box I see on the rail? Is that where it ended up going?
Mhm.
That’s where the ray ended up going.
It’s a selectionbox for debugging purposes.
Would you want to give this a try?
local hyp=i.Size.X/2
local o = Vector3.new(hyp* math.sin(math.rad(i.Orientation.Y)),0,hyp* math.cos(math.rad(i.Orientation.Y))).unit*100
I’ll try that now. Please standby.
You could then follow what DJX_D was talking about
and use FindPartOnRayWithWhitelist and only include the nodes in the whitelistDescendantsTable argument. I assume the LookVector, RightVector, or UpVector are always pointing near to the next node.
Alright, we will give it a try 
, thank you for your responses.
1 Like
Can you check
local o = Vector3.new(hyp *math.sin(math.rad(i.Orientation.Y)),0,hyp* math.cos(math.rad(i.Orientation.Y))).unit*100
, it’s erroring.
sorry, I left out a part that defined hyp,
local hyp=i.Size.X/2
local o = Vector3.new(hyp math.sin(math.rad(i.Orientation.Y)),0,hyp math.cos(math.rad(i.Orientation.Y))).unit*100
That’s there, it’s the vector3 that’s erroring.
hmm, some multiplies didn’t get copied over. Anyway try now, I hope this works. The *100 at the end is the magnitude of the vector. But, I myself don’t know a lot about rays, I was very interested though.
I would definetly look into this method as well.
yeah the ‘*’ are being formatted out here, if it doesn’t get copied over, put a multiply between each hype and math operation and at the end before the 100.
local hyp=i.Size.X/2
local o = Vector3.new(hyp * math.sin(math.rad(i.Orientation.Y)),0,hyp * math.cos(math.rad(i.Orientation.Y))).unit * 100
4 Likes
Be careful using the Raycast method though, if certain turns are too sharp you won’t get the next node. You can also get weird situations depending on how your nodes were placed:
They both appear to be in the same direction, but the LookVector tells otherwise. If this is an issue, this can be solved by just testing both -LookVector and LookVector and remove ones from the whitelistDescendantsTable as you go through them.
NOTE: I assume that your nodes are aligned ONLY along one vector in this case, the LookVector, if not you’ll have to test RightVector, LookVector, -LookVector, -RightVector, and maybe even UpVector, -UpVector.
3 Likes