I’m trying to create a prismatic-based train system based on this video playlist by Gnomecode, but I’m having an issue. I want to be able to have more dynamic tracks (e.g. switching tracks, track elevators, etc). The has to do with identifying “forward” and “backward” on the track. Unlike most train games, which simply use track “parts” that are named after their order in the track, I need to be able to create multiple “paths” which trains can switch between. I’m planning on having sections in my game where tracks will be lifted or rotated, so I’ll need a way of detecting whether tracks are touching or not. I’m kinda stumped as to how I’ll do this. Im not asking for someone else’s code or anything, I just need some help with the concept.
1 Like
by prismatic-based train, is it a train that is running on the physics engine, but restricted by a prismatic constraint that will determine where it’ll go?
yes, a server script would automatically change the attachment0 of the prismatic to an attachment in the next track part whenever the chassis gets within a certain range of the constraint’s end.
My main issue is just determining WHAT the next track would be depending on location etc.
One idea is to divide your network into track segments. These track segments would be represented as tables of attachments (or other tables that include the attachment and other data). The last value of the attachment would include “pointers” to the next track segment table. It can include more than 1 pointer, if the track is spiting instead of merging
In this schema, where the orange segment divides into 2, I made that as 2 pointers in an array, but it would be better probably use a dictionary
{Left = PurplePointer, Middle = nil, Right = OrangePointer}
Then it becomes much easier to determine which track to follow when it splits. It could even use the input from the player rather than the position of the switch if you want to simplify the driving
In cases where tracks merge, only one of the direction will be non nil. If every singe one of them are nil, the track is a dead end. To allow trains to go in reverse, you can add pointers to the start of the table as well
As for what the pointers represent,
you can store every track segment into a table. If the track network doesn’t change during gameplay, it can be an array, but if it they do change, GUIDs and a dictionary would be better
local Tracks = {
["UniqueId"] = PurpleTrackSegment,
}
So here, PurplePointer from earlier would be "UniqueId". The idea is that you can read the pointer, and using the pointer, get the associated track segment from the Tracks table. The pointer is just the index to the next track segment
This system is basically for trains that aren’t physically simulated. In your case, you have a hybrid of the two, where the train is physical, but the mechanism that moves it isn’t. I have a feeling from your replies that you are leaning towards a system that relies on spacial queries to find the next attachment and where to. Such a system could probably work, probably well, potentially simpler, idk. The track segment approach is more systematic and “reliable” in a sense though
2 Likes
This helps a lot! Instead of using tables, I think I’ll use objectValues to store the “next” and “last” track instances, and just use the number based path system inside of individual track models (curved segments, switch segments, etc).
1 Like
This also helps with performance, as constantly checking for the next and previous track parts on the server could create a delay between it and the client. (Server is needed to switch between prismatics, so client-server delay would make the train look horrible and choppy)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.