Question for track/switch experts

HiOne of the problems with signaling logic is the route_set() function uses switch links to determine if the path is set for that light. The problem is that if there is no link, it returns True.It works fine as a test for diverging switches but for converging switches this test always passes and says yes, the path is set - for both tracks.I know JN_LINK in the sigcfg is one key and yes I did try it and did see the Link option for that signal in the RE but I can't set a path. My question is, "Is it possible to define a switch where links can be defined for all directions?". I am assuming it might be a setting in the switch s or sd file.If the answer is yes, we could then have an interlock when two trains both start about the same time on both tracks approaching a convering switch. Right now, both trains get a Green which isn't quite right I realize the whole route would need links set but this method might be able to simplify or solve some of our signalling problems.GaryG

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

RE: Question for track/switch experts, OkrasaGhia, May-09-04, 03:34 PM, (1) RE: Question for track/switch experts, GaryG, May-09-04, 06:46 PM, (2) RE: Question for track/switch experts, sniper297, May-09-04, 07:18 PM, (3) RE: Question for track/switch experts, Richard, May-09-04, 10:18 PM, (5) RE: Question for track/switch experts, markhyams, May-09-04, 10:27 PM, (6) RE: Question for track/switch experts, markhyams, May-09-04, 10:14 PM, (4) RE: Question for track/switch experts, Richard, May-09-04, 10:27 PM, (7) RE: Question for track/switch experts, markhyams, May-09-04, 10:31 PM, (8) RE: Question for track/switch experts, Richard, May-09-04, 10:47 PM, (9) RE: Question for track/switch experts, GaryG, May-10-04, 00:52 AM, (10) RE: Question for track/switch experts, Richard, May-10-04, 01:48 PM, (11) RE: Question for track/switch experts, GaryG, May-10-04, 02:22 PM, (12) RE: Question for track/switch experts, GaryG, May-11-04, 02:33 AM, (13)

Conferences | Topics | Previous Topic | Next Topic

You are assuming wrong when you think the s & sd files have anything to do with the logic of switches. Those files are only the visual representation of the switch and have nothing to do with how they operate. The file specifying how switches and other tracks work is the tsection.dat file but while I don't quite understand what you're after it does not sound like anything that can be done with what is available. A switch is defined as two selectable paths from the same starting point, there is no defining of links.


//Okrasa
Chief Engineer
okrasa @ xtracks.tk
http://www.geocities.com/okrasaghia
http://www.xtracks.tk

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi OkrasaFirst off thanks for your endless support and work in the rails area of MSTS!Explanation of what I thinking of.When you plant a signal in a route, one of its properties tabs has links buttons which are ghosted unless its facing a diverging switch. If so, you select the track path that particular signal light is showing. Usual setup is straight path for the upper light and diverging path for the next light.For a signal facing the trailing side of the same switch, the links are ghosted as in theory there is only the one path through the switch and the route_set() function will always return a "true", yes, the switch is set right. The problem when trying to create a signal script in this case is the actual path through the switch is untestable via the logic functions provided; the same test for a signal on the other trailing track will also say it's set correctly.For signals, there is no way to determine which way the points are set when looking from the trailing side. What I'm thinking is that if signals on the trailing side of a switch could also have a functional link then the signal logic might be able to determine if the path is set or not. I assume if the points were set for the other path the route_set() function would then return a false. From your comments, yes, it could very well be flags in tsection.dat that allow the signal path links to be available.I think I've figured an alternative way to Interlock the trailing side of a switch but it may create other monsters to kill and does complicate the script somewhat. We do always look to see if there's an easy way out don't we? ThanksGaryG

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Far as I know it's all defined in the sigcfg.dat and sigscr.dat files in each route's main folder. For the BNSF style signals, if I place a signal on the trailing side, whenever the switch is set for the other track that signal will go red, since it's not tracing a clear path to the next signal.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hello GaryG,
I've been playing a little with signals and scripts for my route and have found a function named "opp_sig_lr ()" which checks the signal state of the opposing signal. So far here's what I've come up with:
if opp_sig_lr () #== SIGASP_CLEAR_1 && block_state() != BLOCK_CLEAR, then you do not have a path thru the diverging side of the switch. if opp_sig_lr () #== SIGASP_STOP && block_state() #== BLOCK_CLEAR, then your route should be set. I've just begun playing with this, so I cannot confirm if these ideas truly work. Take care,
Rich S.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

It really is a bit more simple than this. All that needs to be checked is if the block_state() functions returns BLOCK_CLEAR or not. If it does, your route through any trailing points are set and the block ahead is clear, if not, either your route is not set (JN_OBSTRUCTED), or the block is occupied (OCCUPIED); either way the signal goes to red.Mark

Moffat Road Tabernash to Phippsburg
All track complete
Currently working on Mtracks

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

The answer lies in the block_state () function. The three BLOCK_ values are:CLEAR -Block ahead is clear
OCCUPIED -Block ahead is occupied by one or more wagons/locos
JN_OBSTRUCTED -Block ahead is impassable due to the state of a switchUsually in scripting the signals, the standard way of determining if it should show red is this: if ( !enabled ||
block_state() !=# BLOCK_CLEAR ||
!route_set() )
{
state = SIGASP_STOP;
}which means that if the signals is not enabled OR the block ahead is not clear OR the route is not set, then show stop.Using this logic, this takes care of the either when the block_state is OCCUPIED or JN_OBSTRUCTED, and in both cases we would want to show a red signal.The route_set () function has no relevance to trailing point situations, only to facing point, and that is why it returns TRUE when the there are no junction links set up.As said in other responses, the signals in the Marias Pass route are scripted this way, and when there are two signals at a converging point, the one for which the route is not aligned will always show red.Hope this helps. If you need more clarification let me know. I would recommend studying BobS's signal scripts for Marias 3.1 and Bruce Bridges Conrail Indy scripts as well. Very innovative and will definitely help with understanding how scripting works.Cheers,
Mark

Moffat Road Tabernash to Phippsburg
All track complete
Currently working on Mtracks

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Mark,
Thanks for the info, I'd read about the JN_OBSTRUCTED but completely forgot about that one. So I guess if you wanted to test for how the points were set on the switch from the trailing position you could always check:
if block_state ==# JN_OBSTRUCTED
at this point you would know the switch is set against you?Thanks,
Rich S.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Yep. I'm curious, though, as to why you would need to differentiate between the block ahead being occupied or having a switch thrown against you. In both cases you would want a red signal, right?Mark

Moffat Road Tabernash to Phippsburg
All track complete
Currently working on Mtracks

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

If the blocks on signal track are long enough between passing sidings, the block ahead might be clear. If your signal logic does not check the switch, you could end up with a clear signal heading onto single track, then get to the next signal find an approach and end up with a stale mate at the third signal with is still on single track. It seems in MSTS world switches on the trailing point side act like spring switches. So you can actually run a signal thrown against you. But if the signal logic checked to ensure the switch points were truly thrown for you, it may improve activity performance. These are just some ideas I've been kicking around and it seems GaryG might be thinking along the same path, I'm not sure.
Take care,
Rich S.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi all, thanks for your ideas.I have the "standard" three tests as Mark shows. This one seems to be a timing problem as much as a logic problem. From what I'm seeing, some kind of interlocking between the two trailing approaches is needed. In the diagram, the AI train actually started a couple seconds before the Player train.The Player train gets the route through the switch but the AI reaches it first and stops just before the points, blocking the way. The other strange thing with this one is the signal for the AI doesn't drop when it passes, the player one does.If I wait about five seconds before moving the Player train, all is well, the Player gets a Red and then follows the AI.This is the reasoning behind why I'd like to try getting the Junction Link working both ways through a switch. The route_set() would now be valid in both directions unlike now where, for the direction I'm having trouble with, just returns a TRUE. Perhaps MSTS is assuming all trailing movements are through spring switches. Thát's ok for operations but not for signalling.GaryG

Attachments

http://www.train-sim.com/dcforum/User_files/409f07953ccb1afe.jpg

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

"The other strange thing with this one is the signal for the AI doesn't drop when it passes, the player one does."Gary,
That sounds like some type of signal problem. Can you go into the RE and verify the signal in question has a red handle. Sometimes when a handle is selected and the route is saved, the handle gets wiped out, but the actual signal remains. Let us know what you find.Take care,
Rich S.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi Rich SNo problem that way, the handle (Red pyramid) is there. Normally, this signal works fine. This time it appears it's a timing problem. Both the player and AI were placed within a few seconds of each other. I can't understand how that could confuse our AI CTC Moving either train's start time by ten seconds or so will solve it. I just hoped that if a better way of path testing could be figured out, we might be able to improve signalling overall.As far as trying to develop an interlock between these two tracks, I had partial success with this_sig_lr() and using other definitions as well as NORMAL. I think I will just go with a rule that's along the lines; "When starting trains that share a common path, stagger start times by a minute or so" and I think it won't happen again.Thanks allGaryG

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

HiA conclusion to this. Activity writers take note.Both trains in this example popped into existence in the blocks these two signals controlled. The signals were not given a chance to sequence, just pop! here's a train. Normally the first train entering that area would get the Green and the next would get a Red but both of these didn't enter, they popped up. This confirms my old theory that you start AI's about two blocks away from where you actually want them. This allows signals to sequence normally. You also have to consider, in the real world, could a train be in this location following normal signalling rules. If not, expect signalling problems around that train.Thanks for your thoughts/ideas and time. I do hope this bit of info does help your thought processes when creating your killer Activity.GaryG

Alert | IP

[ Home | MSTS Forum | MSTS FAQ | File Library ] Copyright © 2004 by Nels Anderson. All Rights Reserved.