There seems to be some edge cases with fast trains and nearby slopes that don't work well with the new switch code.

Talk to @purpleposeidon (neptunepink) for more information.

[05 3:37 am] <+neptunepink> There was 1 flat track between the switch and the slope. Now there's two. It still doesn't work at the top speed.
[05 3:39 am] <+neptunepink> 4 track buffer. There was also a control track at the top that I removed. I can't move the hill back any further.
[05 3:49 am] <+neptunepink> Also it seems like the vehicles are doing the vanilla-style track glitch thing
[05 3:49 am] <+neptunepink> where they suddenly change orientation as if they'd entered from the other direction
[05 3:49 am] <@CovertJaguar> hmm....client server sync issues maybe

@ssotangkur poke

The PR's are ready for review. I think everything is fixed. I managed to resolve several corner cases, that were mainly client rendering issues. The change to asking the switch devices what state it is seems to have fixed neptunepink's issue, and that appears to have been the only server side issue that was found.

OK, cool. I should have a few hours to work on the mod today so I can see about pushing a beta with the changes.

Damn, I should have tested slopes too.
On it.

Is the glitching occurring only when the switch is track is powered (trying to divert traffic) and you make the cart go through the opposite direction where the track has to automatically unswitch?

I'll ask for this in IRC too.

I've emailed NeptunePink. I've tried a couple setups with slopes and reinforced switch tracks with booster tracks and locos at full speed and I'm not able to create any serious problems. I did notice the UI glitching, which is a side-effect of the way we provide track metadata to carts individually.
I can't tell for sure, but I believe the clients ask for the track meta w/o passing in a cart in the arguments. This means that it can only get the correct "state" of track, after a cart actually sets the state by entering or leaving the track. My guess is that the client is preemptively asking for the track state, right before the cart enters the track. The client then doesn't ask for the track again until the cart leaves.

Part of my reason for thinking this is that I've also tried doing a client update on every tick just to see if that would resolve it, but it doesn't.

I think though, the glitching can be resolved if I test the UUID sets to see if they are empty to guess what state the track will be in.

The client probably doesn't call the minecartOnTrack() function at all.

I think issue is that its not correctly diverting trains that the routing logic was setup to divert. Apparently switching to Wooden Track resolved the issue, so it must be speed related. I'm not sure how much affect the slopes had, aside from increasing the speed of the train. Simply increasing the size of the detection boxes might improve things. Its also possibly the Routing Switch Motor needs some tweaks.

I kind of want to get 9.5 out today, so I may end up reverting this until we can resolve the issues. Just a heads up.

Should be fixed