And, I have some attachments at each end of the track for the train to go to. These, are easily generated through a script and are therefore not a problem.
Although, I have 2 object values; they are for the Next and Last node.
The question is, how do I get the next and last node?
Kind Regards,
Sasial.
PS: The nodes are the red part in the middle of the tracks.
I’m sorry, but I’m on my phone and can’t quite see the picture clearly. Are all of the node parts physically touching the ones next to them? If so, we can make something work with BasePart:GetTouchingParts()
Because the GetTouchingParts() method is not reliable, I’m afraid I do not currently have a solution to your problem. However, if I think of a solution I’ll be sure to post it.
The only way i can think of right now that you really can get the next nodes whilst being as accurate as possible and while only knowing the end node, start node and the nodes in between( without order) is to compare distances. In theory, we can start at the start node put it in a “closed” list( so essentially we cant go to it again), find the nearest node to it then go to that one and then put that one in the closed list and so on until we reach the end node. So for example:
The way i am describing it makes it sound a lot like A* ( A path finding algorithm), lol
Pseudo Code (theoretical)
local Closedlist = {} -- The list that holds parts that we cannot find/index
local OpenList = Nodes:GetChildren() -- The list that holds parts that we can find/index
local EndNode = --- end node/ last node
for i,Node in pairs(OpenList ) do
local NearestNode = FindNearestNodeinOpenList() --- you can implement a function to find the nearest part that is in the open list from our current
if Node == EndNode and #OpenList < 2 then -- this is checking wether we are at the end of the track
print("The End!!")
return
end
if NearestNode then
table.insert( Closedlist, Node) -- insert the node into the list that hold parts that we cannot find
table.remove(OpenList, i) -- removing it from the list that holds parts that we can find
end
end
The only limitation to this i can think of right now( there are probably more) is if the nodes are perpendicular or side by side which could result in the array “Skipping” nodes ( My best guess to prevent this, is to add in some extra checks pertaining to positioning)
Side Note: if you did do something (the method i mentioned) like this looking into heaps might be a good decision
Something that i would recommend looking into are Bezier curves, it would be better to create a train track using these( or use it with it) , then we could easily find the nodes in between and i am guessing you are asking this question so you can make a train to follow the nodes, so traversing nodes as well.
Generating them is quite similar to what you’ve done, but they are similar width to the sleeper, and thin in the trackside direction to produce gaps between them so a raycast from one to find the next is quite reliable. Putting them inside a folder or model allows whitelisting to avoid picking up anything else from the ray.
I’d like to change it at some point to use non-physical nodes but it’s tricky to find the next/previous without rays. The nodes at junctions contain a junction ID and a direction (Straight or Diverging for a simple junction). I organise these into tables in a script, and when raycasting for the next node, if it finds a junction node it then searches using the correct direction table as the whitelist.
I helped GCR do a slightly more elegant solution of just moving the train by its lookVector and then align it to whatever track is below it. Not sure how they handle junctions though.