New: Running on other Rails (WIP)

[leezer3]

This is a followup to #326 , and introduces the ability for the player's train to run on other rails within the world.

Heavily WIP.

Current Usage:

Track.Switch firstRail; secondRail; initialSetting; switchName; firstTrackName; secondTrackName
Creates a standard facing switch.

• FirstRail : The rail the switch is placed on.
• secondRail : The rail that may be switched to.
• initialSetting : The initial setting for the switch.
• switchName: The display name for the switch in the menu etc. (e.g. Yard Entry Switch)
• firstTrackName: The display name for the first track (e.g. Mainline)
• secondTrackName: The display name for the second track (e.g. Yard)

Track.SwitchT firstRail; secondRail; initialSetting; switchName; firstTrackName; secondTrackName
Creates a trailing switch.

• FirstRail : The rail the switch is placed on.
• secondRail : The rail that is joined to.
• initialSetting : The initial setting for the switch. Note: To set the trailing switch to start in a position where we can run through it, this must be set to the rail which it is placed upon.
• switchName: The display name for the switch in the menu etc. (e.g. Yard Entry Switch)
• firstTrackName: The display name for the first track (e.g. Mainline)
• secondTrackName: The display name for the second track (e.g. Yard)

Flaws:

N.B. These will change, just need the correct code implementing & thinking about.

• Only works for branching switches.
• No direction detection.
• Running past a .RailEnd command is likely to crash.
• 3 way & greater switches not supported by the current command structure. Need to think about how we could structure this.....
• Needs a way to change switches. (Leverage New: add touch elements #317 to highlight the switch?)
• Needs sprung return points adding (simples....)
• Point sound events are not generated at the minute on other tracks.

To Test:

• Check all combinations.
• Check for conflicts with New: the Another Trains #326

[leezer3]

The current test route (Highly stripped down version of Odaykufan's test route):

With Route

With Train
	.Folder(cl104)
	.Run(0) 0,
	.Run(1) 0,
	.Run(2) 0,

With Options
	.ObjectVisibility(1)

With Structure
	.Ground(0).Load(OdakyufanAtsTestRoute\Grass.csv)
	.Rail(0).Load(OdakyufanAtsTestRoute\Rail.csv)
	.Rail(1).Load(OdakyufanAtsTestRoute\Rail_L_329.csv)
	.Rail(2).Load(OdakyufanAtsTestRoute\Rail_R_329.csv)
	.freeobj(45).Load(OdakyufanAtsTestRoute\Grass.csv)
With Texture.Background(1)
	.Load(OdakyufanAtsTestRoute\Background.png)
	.Aspect(1)
	
With 

With Track



0
	.Height(0.5)
	.Sta(Station A; 09.5955; 10.01)
25
	.Stop(1)
250
	.Railstart(1;0;0;0)
	
275
	.Switch(0;1;1)
300
	.rail(1;4;0;0;-200)
325
	.rail(1;8;0;0;-200)
500
	.railend(1)
2100
	.Sta(Station B; 10.0300; 10.0330)
2245
	.Stop(1)
2275

This will switch the player's train onto Rail 1 at 275m, and correctly derail it at 500m when the track ends.
Next step will be to add and test 2 more switches so that Rail 1 can continue into a siding, whilst we turn back to Rail 0.
Once this is complete and tested to work with no glitches, I'll think about reversing over switches so we can run backwards over Rail 0 to complete the loop.

[leezer3]

This test route implements a switched passing loop, changing first to rail 1, then to rail 2, before finally back to the first rail.

Reversing through the switches also works correctly now. (N.B. Needs the three commits on the master branch from today, but these aren't directly relevant to the switch logic, more to multiple rails)

With Route

With Train
	.Folder(cl104)
	.Run(0) 0,
	.Run(1) 0,
	.Run(2) 0,

With Options
	.ObjectVisibility(1)

With Structure
	.Ground(0).Load(OdakyufanAtsTestRoute\Grass.csv)
	.Rail(0).Load(OdakyufanAtsTestRoute\Rail.csv)
	.Rail(1).Load(OdakyufanAtsTestRoute\Rail_L_329.csv)
	.Rail(2).Load(OdakyufanAtsTestRoute\Rail_R_329.csv)


	.freeobj(45).Load(OdakyufanAtsTestRoute\Grass.csv)
With Texture.Background(1)
	.Load(OdakyufanAtsTestRoute\Background.png)
	.Aspect(1)
	
With 

With Track



0
	.Height(0.5)
	.Sta(Station A; 09.5955; 10.01)
25
	.Stop(1)
250
	.Railstart(1;0;0;0)
	
275
	.Switch(0;1;1)
300
	.rail(1;4;0;0;-200)
325
	.rail(1;8;0;0;-200)
400
	.railstart(2;8;0;0)
	.switch(1;2;2)
425
	.rail(2;4;0)
450
	.rail(2;0;0)
	.switcht(2;0;2)
475
	.railend(2)
500
	.railend(1)
2100
	.Sta(Station B; 10.0300; 10.0330)
2245
	.Stop(1)
2275

[leezer3]

Need to finish and merge this, but shouldn't be difficult. Will look again this week.

The new imagebox menu additions should allow us to implement a nice GUI, which was the primary reason this stalled.
We also need to add a final parameter to the .Switch command, to allow for a switch name.

[leezer3]

Switch icon for overlay (scanned and edited model railway track!)

Couple of nice colored arrows to show switch direction:

Will need to deal with a full rebase before trying to get this done, but nothing has really actually changed other than a few file locations.

WRT to switch menu, should have the following:

• Picture of switch (rotated appropriately)
• Arrow overlay showing currently set direction
• Switch name
• Distance to switch
• Currently set rail (Highlight in different color if this is a trailing switch and is set to derail us)
  Unsure if we can get two switches (in front and behind) on a single screen, or whether we'll need two. Test when implemented.....

[leezer3]

If the Change Switch menu key is set, this branch now functions properly, and our run-round loop above can actually be used.
It's still a little clunky, but this has massive potential.

TODO:

• Menu needs to refresh when a switch is changed to reflect the new setting.
• Implement visual switch indication into the menu, icons above.
• Add switch names and path descriptions to the routefile command.
• Add switch info to F10 debug screen.
• Add translations for new menu commands.

FLAWS:

• Derailments not yet added.
• Switches are currently calculated from the front car for both locations. This allows splitting of a switch if you're not careful, probably wants the previous switch calculating from the driver car (??)
• Route map doesn't show any other tracks, how difficult would this be to add?
• Menu layout needs thinking about / improvements somehow?
• No point sounds for switches on secondary tracks at the minute. Possibly just trigger a Point Sounds event from the switch? (think about this- could also automagically add one if none exists in the block??)

FUTURE??:

Would be interesting to see what adding an auto-generate option did, as per BRR. Could probably do something along these lines:

• If a track intersects with Rail 0 exactly (e.g. generates a point sound event), assume that this track is drivable.
• Keep a record of these, and any tracks which intersect with these then are also drivable.
• Possibly creates backwards issues, in that we'd need to read back to see what's available in reverse if we switch onto a new track??
  This should be a completely separate PR though.

[leezer3]

After some fiddling, it seems that a working map will be an absolute PITA, without some serious refactoring in the main parser.
This is primarily because it skips large amounts of stuff in preview (map / gradient) generation, including oddly enough secondary track positions.
Changing this requires a complete refactor in places, as it generates the track objects here too.....

[ginga81]

I think the UI you showed is really great!
In the UI candidate image you provided, I thought the route author needed an option to restrict arbitrary switching.
The reason for this is that if the user wants to move the TFO at an arbitrary time and distance, but the user changes the course, things will go wrong.
If you are planning to be overtaken and the data is designed to move onto the side track, but the point is switched to the main track, you will collide with the TFO.

[leezer3]

This is now usable with the proposed dialog above if built from this branch, but requires a lot of polish to look nice.
Please set the command ChangeSwitch to an appropriate key and play around with the examples above to see it in action.

I've settled on blue for the player rail highlight at the minute, as it needs to be nicely distinct from the normal track. Did try black, but that wasn't distinct enough.

TODO:

• We need a way to set the cant of secondary tracks. Proposed command: Track.Cant RailIndex; CantAmount
• TrackEndEvent doesn't seem to be working on a secondary track- Needs investigation.
• Add title and close button to the switch change dialog. (Needs a dedicated button class creating, similar to the picturebox)
• ?? Change the switch to a different shape- triangle or square ??
• Fix the behaviour if we split a switch. (Need to think about this, but probably if the difference between the FrontAxle follower & the RearAxle follower is greater than the length of the car, derail?)

Some of these, and behaviour altering the signalling system may well get implemented at a later date after merging, just need to keep on noting them down so I don't forget them.....

[leezer3]

https://youtu.be/r9mByy3_qQE

UI is now working relatively nicely.
Still need to look into things like adding a title, but the public concept seems to be nearly ready for other people to break it....

[ginga81]

I watched the video and understood what it meant.
Since it is dangerous on Shinkansen trains, etc., I think it is necessary to decide in advance which track the train will run on, and to provide a lock command to prevent switching while driving.

[leezer3]

Not sure, I'd have to think about that.
Changing whilst driving shouldn't be an issue if you only setup the appropriate switches in your routefile though? Anything else just remains a dummy.

It sounds more like what you want is a speed parameter for switches, which sets the max allowable speed per route.
Starting to wonder about an XML file containing switches, but I quite like the simplicity of the current command.....

[ginga81]

If we change the 70km/h limit turning machine suddenly while traveling at 320km/h on a Shinkansen, the train will derail and overturn.
To avoid this, we have to use ATC to lower the time to 70km/h before switching, but there is a risk that the driver will intentionally change the timetable at the last minute even though the timetable is supposed to pass.
To avoid this, we should use route command in advance such as this.
Route.Switchlock 1;
I think a command is needed to prevent the driver from switching points without permission while driving.

[leezer3]

Now that's an interesting idea, but I think to be implemented a little later- At the minute, this is just trying to get some of the basic mechanics working.

I think in that case, you'd probably want a speed lock and a position lock.
We probably also want an event passed to plugins when a switch is changed, but that's possibly the sort of thing that needs to be thought about in conjunction with a v2 of the plugin interface.

[ginga81]

The ATC example is an example of the concern that this could happen if the driver were allowed to change the route freely.

Simply, in addition to a function that allows route creators to drive on designated routes, I believe it is necessary to implement a command that prohibits to drivers from changing points by route builder.

[leezer3]

The UI is essentially finished now I think, although I'm considering using a multi-line textbox for the labels on the left, along with a 'No switch selected' message.

Other thoughts:

It's clear (unless we introduce textual rail labels with this) that just the rail number isn't the best thing for showing the current setting of the switch. Easiest way to handle this is likely to add two additional optional parameters to our switch command, with textual descriptions in them. Either immediately after the rail index or together at the end- Will add these probably tomorrow.

Station names probably need hiding in favour of track distances, so we have the distance at the top and bottom.
(Same style as station names?)