Good afternoon, everyone!
I am brainstorming a few ways to design more efficient exit switches for TR (switches that take trains from two trains and merge to a single track).
I came up with the idea of having rails in which the train glider wheels on one track stays on it’s rails and train glider wheels on the other track stay on their respective rails, but without the rails having to actually “switch”. I intend to use this method in spawn areas where we have multiple spawn tracks merging into one track that goes onto the mainline.
It may be hard to understand in words, and it’s hard to explain, but here’s a diagram of an attempt to explain this:
So basically I’m asking if there’s a way to make one surface of a block cancollide true while having the rest of it cancollide false, only allowing objects to pass in a single direction and not back through the other way.
Think of it as one-way glass but with bricks and objects passing through but not able to re-enter.
In spawn areas, this would eliminate the red blocks that meter trains onto the main, and we don’t have to worry about train collisions now that Terminal Railways’ trains have collision groups!
Probably a bit super old-school and not at all what you want, but I’ve seen this done years in the past by giving a non-CanCollide part velocity such that trying to re-enter from the wrong side just pushes you back out.
I’m sure there’s infinitely better solutions though, but it might suit you for a quick and dirty fix until then? IDK.
One thing you could try to do it cast a ray toward the object, if the ray hits the correct surface put it into a different collision group from the wall so it will pass through, otherwise put it into the same collision group so it hits.
This is unfortunately rather difficult to achieve, I think your best bet may be just to have a local script detect when the train has left th station, and locally set the cancollide to true after its left.
You could set the wheels’ collision group when they get near the merge point, where each track has its own group. You can re-use collision groups for each merge/split so if your biggest merge is 3 tracks, you only need 3 collision groups. When the train gets near the merge, the wheels are set to the collision group for its merge rail, and set back to default after it crosses.
This lets the trains stay on the proper rails and prevents them from moving backwards.
If you have existing collision groups you need to be compatible with, you could have the wheel collision groups have the same collision relations as the existing train/wheel groups, if you have any.
also, I don’t know any train terminology, sorry. my answer should still be understandable
The way I handle junctions in my train system is to just run it in a local script. It does mean that noone else can see where you are going and might look weird seeing trains float on tracks that aren’t there on your screen, but it does prevent this issue (if I’m understanding your post correctly).
I was initially thinking you should use raycasting, but proper implementation would be difficult to achieve without some extra (tedious) math to get the specific surface which the ray hits. If you’re down for some math, go for it - but I think a more suitable solution would be to constantly update a variable with the direction which the train is coming from, and cater to it based on that.
I made an example of what I was talking about. Was a fun mini-project! Super basic “carts” and rails because I know nothing about trains and this is an example, but you should be able to apply the concept if it’s what you’re looking for.
Multiple rails in a single “junction” (sorry, I don’t know terminology)
A junction that you can go backwards on in a certain direction
One-way blockers
Sharing collision groups between each junction
Note that the CollisionGroup triggers can be transparent, and the rails can be a normal color. I have made the triggers visible and the rails colored to visualize how the system works.
You could even expand this to regular junctions and allow users to choose which route to take – which then sets their CollisionGroup appropriately – which means no physical switching ever!
Gfys
Edit: Whoops, just noticed this is in Building Support. This isn’t possible without some level of scripting, so my answer is still useful, but I’ll try to watch the category next time and tailor any responses accordingly.
I’m working on something of similarity of a “one-way cancollide” but running into a small problem of sorts with collision groups. I’m trying to make it so there are essentially invisible walls preventing you from going backwards on a racetrack. The issue I’m running into though is that Section1, Section2, Section3, and Section4 (the invisible walls) have CollisionGroup ID 1-4. They however do not let 0 pass through. Is there a way to change the default CollisionGroup (0) so it can pass through my groups?
As far as the current problem at hand with the train:
Put a script like this in the wheels, and it should work fine(with the naming structures done how I did it.)
Essentially, my script is making it so when the wheels hit the activation blocks, it changes what collision group it can touch. Admittedly like said above, this isn’t support via building, but don’t believe there is anyway to build it so to speak without some scripting.
