OpenBVE
OpenBVE copied to clipboard
leezer3
[Question] Front direction fault of SwitchT and unused value of Switch
Description
After the train passes forward through SwitchT, the train does not reach the first track, but runs on the void track extended by the last section of the breakpoint track, and the frame rate drops.
I'm going to name a switch, I need to write it this way. Track.Switch 0; 3; 0; ~Unused~; Crossover Down; Main; To Down Track.SwitchT 0; 2; 0; ~Unused~; Crossover Up; Main; To Up I'm not sure if the unused value was intentionally reserved or an error?
Related information
- OpenBVE Version: Build 2024-02-17
That was intended to control spring return switches. Haven't implemented it yet as it got a little complex. to make work correctly.
Must update the documentation, thanks....
This interesting, just like the derailment.
The SwitchT and tracks were placed according to the docs instructions and the train looked correct after driving forward. I wanted to make compact switches and didn't want to extend the tracks. So I undid the extension and placed the SwitchT in the same position as the RailEnd. Then the train started a strange deviation after passing forward, entering the void track.
-
As I drove backwards through the SwitchT in the void track.
- SwitchT's position is after or equal to RailEnd, the train can only go to the second track, the source track of the void track.
- SwitchT's position precedes RailEnd for the switch to work properly. This is of course for trains travelling on the void track.
-
In any case, the train travelling forward past SwitchT goes to the void track until it encounters the same RailStart at the index of the void track again.
-
I reversed my train from the other track back to the main track and drove backwards past SwitchT as if SwitchT didn't exist. And I heard the Switch Sound twice.
- At least Switch is normal, enabling me to do this.
-
I think it's the strange SwitchT implementation method, the one through the void track.
-
I want to add the track index where the player train is located in the debug interface, and I want to know which track the train is actually traveling on.
-
It seems that SwitchT has the first and second track names reversed?
Reproduction
Route
Here is my route files. Switch Test Routes.zip
Made a couple of changes which will help a bit. Essentially, was only changing the index of the front axle follower accidentally on trailing switches,
However, ending the track at the same point you place a switch isn't really supported. This is a design flaw with the track element setup. For the minute, I've added a workaround for this one.
After passing through SwitchT, it will still go to the void track. Require adding a track index in the debug interface.
I am waiting...
@leezer3 Add track index in the debugging interface. I said it three times.
Again, there is only one of me, and I've got limited free time to work on this......
I haven't got as far as investigating the void track issue properly yet, but will try and do so.
Made a few changes for the current build.
I think this probably fixes what you were seeing (running through a reverse switch with the 'wrong' direction set could get into an invalid element).
The train still went to the void track:<
But I will open some large issues...
The problem with the direction from the first track to the first track has been fixed:) Observe the direction issue from the second track to the first track.
The recent build has not resolved, and the train located on the second track still went to the void track.
Current build makes most things OK.
However, the use of the .Turn command and the .Switch / .SwitchT command in a routefile are no longer supported, and an error will now be generated to that effect. TLDR: The .Turn command rotates the entire world, and messes with track lengths (by inserting additional elements). Please use the .Curve command instead.
Got it.
The Importance of Mathematics Education... Headache I need a ratio and curve radius conversion or graphical line editor to obtain the radius.
I tried moving RailEnd forward one block before I found out about it. The from second track to void track issue only fixes the last SwitchT in the same second rail index. This is not conducive to the reuse of rail indices.
It seems that except for the SwitchT on rail 0, the initial setting of SwitchT on other tracks is opposite.
I wouldn't reccommend re-using rail indicies at all where switches are concerned- Keep anything drivable completely separate.
Track elements are a linear array, which really doesn't work too well for stopping / starting them. It's on the list to re-do this (essentially, a track element should only link to the previous / next).
Looking into the SwitchT reversal too.
I don't like it, reusing the track index is convenient for me to layout.
I don't care about how these track starts and ends. For switch issues, in my opinion, a switch behavior is roughly like this.
When driving in the direction of convergence.
.PlayerPath ST;FT, .PlayerPath FT;FT
When driving in the direction of separation.
$If(Switch), .PlayerPath FT;ST, $EndIf()
Because I think PlayerPath is more reliable than the current switch.
I am also considering using PlayerPath to solve the problem.