Archived thread - Read only Previous Topic | Next Topic

OK guys, I've conducted much testing now on the value of SigNumClearAhead and here is what I have found.First, I have a single track mainline with several passing sidings.Each siding exit is controlled by a Single Head Absolute Signal, and each entrance by a DBL Head Absolute. This results in two absolute signals after any siding exit signal to the end of the next siding exit - this is a prototypical absolute block. The single track mainline has Permissive(Interval) signals spaced at an average of 1.5 miles, resulting in a variable number of these relative to the single track length. The activity I have been using to test this stuff has 5 opposing trains to my one player train and all are routed along their relative paths and direction of travel to take a right hand siding. Timing is such that I have a meet at 5 sidings in a row.I started playing with the SigNumClearAhead ("Look Ahead") value for the absolute signals because I was not getting released from the siding to move up when I should have had plenty of time to do so before the next meet. I found that this parameter does in fact define how many blocks ahead of the signal must be clear before it will return a "Clear" indication. Setting this value to (2), equal to the number of abs signals to the end of the next block results in a proper release of the previous block with a "Clear" indication when no trains are occuping the single track mainline within the block directly ahead. Setting this value to look farther ahead than that results in never getting a clear if there is a train within the look ahead distance past the next siding. I tested this by upping the value to (12), where I knew I would have a train on a block within this distance, and sure enough, it would not release me to move up.So I set all absolute signal heads to a look ahead value of (2) and everything indicates and releases as it should, for a full 100 miles of mainline and passing sidings with 5 train meets.Permissives do not seem to care what the value of SigNumClearAhead is and simply cascade their indications back from the next signal ahead, or the first block ahead of them that is occupied. I have not however been able to test whether a look ahead value higher than (1) for a permissive would result in an offset indication from an occupied block since there is no way for me to progress against these signals to see. And in my case it does not matter anyway because my absolute block signals would not let me take the main if a section was occupied.It would also appear to me so far that absolute signals basically ignore the presence of permissives and do not count them in the SigNumClearAhead value. Permissives however do cascade their indications back from an absolute signal. So in my case, adjusting SigNumClear Ahead to equal the number of absolute signals ahead to the end of the next block seems to work and make sense - for this particular installation case.The limitation in this fixed value however, may become apparent when setting up interlocking signals in yards as the same Absolute signal head script is used for interlockings and it may not be desirable in this case to "look ahead" two signals. I have a case where a value of (2) results in a yard signal at a switch showing red when I should have a yellow that would allow me to move up to the next switch/signal - because the next absolute signal past that, protecting the mainline block, is Red due to an oncoming train(2 signal blocks ahead, DUH!). So signal gurus, do we need a seperate script for interlocking absolute signal heads or can we get user definable SigNumClearAhead option box for each signal?Whew! Hope you can follow all that.

Printer-friendly page | Top

SigNumClearAhead, Revelations! [View All], Daylighter, 09:41 PM, Feb-12-02, (0) RE: SigNumClearAhead, Revelations!, Daylighter, Feb-12-02, 09:54 PM, (1) RE: SigNumClearAhead, Revelations!, LawrenceKellie, Feb-12-02, 10:51 PM, (2) RE: SigNumClearAhead, Revelations!, Daylighter, Feb-13-02, 00:11 AM, (3) RE: SigNumClearAhead, Revelations!, LawrenceKellie, Feb-13-02, 01:05 PM, (8) RE: SigNumClearAhead, Revelations!, Daylighter, Feb-14-02, 10:25 AM, (15) RE: SigNumClearAhead, Revelations!, LawrenceKellie, Feb-15-02, 05:27 PM, (26) RE: SigNumClearAhead, Revelations!, bobs, Feb-13-02, 01:47 AM, (4) RE: SigNumClearAhead, Revelations!, lwhelan, Feb-13-02, 02:32 AM, (5) RE: SigNumClearAhead, Revelations!, Daylighter, Feb-13-02, 11:12 AM, (6) RE: SigNumClearAhead, Revelations!, bobs, Feb-13-02, 12:53 PM, (7) RE: SigNumClearAhead, Revelations!, LawrenceKellie, Feb-13-02, 01:10 PM, (9) RE: SigNumClearAhead, Revelations!, lwhelan, Feb-13-02, 04:01 PM, (10) First test results, bobs, Feb-13-02, 05:58 PM, (11) More test results, and another theory shot to @#$, bobs, Feb-13-02, 06:36 PM, (12) RE: More test results, and another theory shot to @#$, sniper297, Feb-13-02, 10:35 PM, (13) RE: More test results, and another theory shot to @#$, Daylighter, Feb-14-02, 10:22 AM, (14) RE: More test results, and another theory shot to @#$, bobs, Feb-14-02, 01:25 PM, (16) RE: More test results, and another theory shot to @#$, Daylighter, Feb-14-02, 07:23 PM, (17) RE: More test results, and another theory shot to @#$, bobs, Feb-14-02, 07:49 PM, (18) RE: More test results, and another theory shot to @#$, Daylighter, Feb-14-02, 09:20 PM, (19) RE: More test results, and another theory shot to @#$, bobs, Feb-15-02, 00:24 AM, (20) RE: More test results, and another theory shot to @#$, Daylighter, Feb-15-02, 02:34 PM, (21) RE: More test results, and another theory shot to @#$, bobs, Feb-15-02, 04:03 PM, (22) RE: More test results, and another theory shot to @#$, Daylighter, Feb-15-02, 04:32 PM, (23) RE: More test results, and another theory shot to @#$, NickF, Feb-15-02, 04:49 PM, (24) RE: More test results, and another theory shot to @#$, Daylighter, Feb-15-02, 05:01 PM, (25) RE: More test results, and another theory shot to @#$, SP9800, Feb-15-02, 07:47 PM, (27) RE: More test results, and another theory shot to @#$, Daylighter, Feb-15-02, 09:04 PM, (29) RE: More test results, and another theory shot to @#$, bobs, Feb-16-02, 00:49 AM, (33) RE: More test results, and another theory shot to @#$, NickF, Feb-15-02, 09:07 PM, (30) RE: More test results, and another theory shot to @#$, Daylighter, Feb-15-02, 09:19 PM, (31) RE: More test results, and another theory shot to @#$, bobs, Feb-16-02, 00:51 AM, (34) RE: More test results, and another theory shot to @#$, oboe, Feb-17-02, 01:54 PM, (38) RE: More test results, and another theory shot to @#$, bobs, Feb-18-02, 10:50 PM, (43) RE: More test results, and another theory shot to @#$, Daylighter, Feb-18-02, 11:39 PM, (45) RE: More test results, and another theory shot to @#$, oboe, Feb-19-02, 01:15 AM, (47) RE: More test results, and another theory shot to @#$, bobs, Feb-16-02, 00:45 AM, (32) RE: More test results, and another theory shot to @#$, lwhelan, Feb-15-02, 08:53 PM, (28) RE: More test results, and another theory shot to @#$, bobs, Feb-16-02, 00:59 AM, (35) RE: More test results, and another theory shot to @#$, lwhelan, Feb-16-02, 04:35 AM, (36) RE: More test results, and another theory shot to @#$, oboe, Feb-16-02, 09:26 PM, (37) RE: More test results, and another theory shot to @#$, bobs, Feb-17-02, 03:23 PM, (39) RE: More test results, and another theory shot to @#$, roeter, Feb-18-02, 05:50 PM, (40) RE: More test results, and another theory shot to @#$, bobs, Feb-18-02, 07:39 PM, (41) RE: More test results, and another theory shot to @#$, roeter, Feb-19-02, 03:34 AM, (49) RE: More test results, and another theory shot to @#$, oboe, Feb-18-02, 09:56 PM, (42) RE: More test results, and another theory shot to @#$, bobs, Feb-18-02, 10:54 PM, (44) RE: More test results, and another theory shot to @#$, oboe, Feb-19-02, 00:23 AM, (46) RE: More test results, and another theory shot to @#$, bobs, Feb-19-02, 01:43 AM, (48)

Conferences | Topics | Previous Topic | Next Topic

PS:I've found no relationship between the SigNumClearAhead value and the timing or priority level of AI trains, or the number of switches set in advance for AI trains. I think that is all governed by timing, paths, and priorities that you define in the activity editor. However, if your spacing of following AI trains is short, increasing the number of permissive blocks will keep them following closer together - but close timing of following AI trains will also tie up the mainline longer as you will have to wait for the progression of oncoming trains to pass before you will be released from a siding.

Printer-friendly page | Top

Is there some reference as to the shape file name for those different types of signals you were using?Thanks for considering this question.Lawrence
Tapiola now NOT here at Train-Sim.com

Printer-friendly page | Top

>Is there some reference as to
>the shape file name for
>those different types of signals
>you were using?
>
>Thanks for considering this question.
No problem, you ole crumudgeon I was primarily experimenting with Single Head Searchlight Absolute signals. The shape file for this is "SLsigabs.s". Signal head sub type for this is "SL3Color" = note that this subtype script is also used for the top of a multi-head absolute signal.For Single Head Searchlight Permissive; SLsigper.s, SL3ColorA And Put Tapiola back, Darnit! I have not had a chance to download it yet.

Printer-friendly page | Top

Are these non-default files? I don't recognize the file names.Lawrence

Printer-friendly page | Top

>Are these non-default files? I
>don't recognize the file names.
>
>
>Lawrence
Yes. These are Hank Sundermeyer's Searchlight signals V2.2.
I don't know anything about the BNSF default signals as I have not tried to use them or figure out there code.

Printer-friendly page | Top

Just noticed this response. Thanks.Lawrence

Printer-friendly page | Top

Hmmm, so this parameter really does what it says it does, but really only counts absolutes? I'll have to experiment some and see what differences this makes with some of the activities I had trouble converting. I went the other direction with the counter because I thought it included permissive blocks in the count.Maybe we've broken the code on another mystery!

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Daylighter,Let me give you something to ponder...................In the doc (How_to_make_Signal_config_and_Script_Files) there is a paragraph that most assume is written wrongly or the author didn't know what he / she was 'talking' about.It is as follows:-"The final part of describing a signal type is to give
the minimum number of signals ahead which would need
to be enabled in order for the player to see the least
restrictive indication (given that the track is clear).
If the player never sees the clear indication,
this is a sign that this value is too low. SignalNumClearAhead ( 4 )"IMHO I personally think it is quite correct.OK, why? Well, firstly the parameter denotes, as stated, the number of signals ahead (all signal types included that are type: SIGFN_NORMAL) that need to be ENABLED (not CLEAR) to see the least...........And the number four (4) is not just picked from the ether either. If you think about it - imagine a consist sitting in a block stationary. As you approach the consist from behind or ahead (doesn't matter) the fourth signal from the consist will be green, the third flashing yellow, the next yellow and the closest / first will be red. Anything less than four and you won't see the green because signals that are not enabled are always red.I have a test track that has a separate player track, which I call an observer track, which has no effect on the main track at all because it is not connected and not signalled as such. The main tracks have about 100 or so signals employed and each and every one of them is always enabled (by script programming) and believe me, IN MY CASE, the NumClearAhead parameter can be any value you can think of and it does not affect the operation of the signals in any manner of fashion. You can run from one end of the track to the other on the observer track and all the signals will display the correct aspect depending upon the layout, switches, end of track etc.
I run AI's both ways and monitor proceedings from the observer track - testing lengths of consists, speeds, timing etc.Anyway, I am still working on the configs and scripts and a host of other things at present and this is what I have found to be the case.Regards,
Laurie Whelan
Brisbane, Australia

Printer-friendly page | Top

Hi Laurie,Well, I read that tech doc as well and found another reference to the SigNumClearAhead value that conflicts with the one you are refereing to. It reads as follows:"SignalNumClearAhead ( n ) - Number of blocks ahead which need to be cleared in order to maintain a 'clear' indication in front of a train (only required for SIGFN_NORMAL signal types)."I read this to say that this value need not be higher than the number of clear blocks that you need, and so far in my testing this value seems most important for absolute signals. If I set this higher than is necessary to cover the absolute block, I will get a red when there is a train further ahead than the absolute block.
>The main tracks have
>about 100 or so signals
>employed and each and every
>one of them is always
>enabled (by script programming) and
>believe me, IN MY CASE,
>the NumClearAhead parameter can be
>any value you can think
>of and it does not
>affect the operation of the
>signals in any manner of
>fashion. I'm not seeing a problem with signals not being enabled either, but this could be because the AI dispather is enabling everything it needs to for my particular scenario.I do however get held up if the look ahead value is too high and there is a train on a block further ahead than the next passing siding (the next absolute block), but within the look ahead range. I just don't find a reason to believe yet that the SigNumClearAhead value has anything to do with enabling signals -the reference is not even named well if it does have this effect. Seems to me there should be a SigNumEnable parameter for that if it is necessary. I still think SigNumClearAhead has only to do with block occupancy, but I'm still testing too. Right now I have the permissive look ahead value set at (1) and the absolute value set at (2) for my block situation. This seems to work properly for every scenario I have thrown at it so far, however, it could be valid only for my particular set up.What is not working for me yet is when you have two absolute blocks on a single track, such as in a yard area. In this particular case, it seems that a value of (2) is too high because I should be able to pass the first signal that should be giving me a yellow, and progress to the second red, but since there is an oncoming train ahead of the second signal and the look ahead value is (2), the first one indicates red as well. So it seems for now anyway. I'm going to explore that situation next .Please let me know what your research turns up. I will do the same.Cheers!

Printer-friendly page | Top

Laurie, in my testing, this parameter definitely did make a difference. That's why I increased it to 6 from 4, as it cleared up a problem I was having with trains waiting on each other.I think that all this work proves that we don't fully understand the interactions between this parameter and the rest of the sim.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Well, I hope this works well for you, because this entire thread is nothing but confusing to me! My understanding of signals is somewhere between birth and one-day old--if even that good. Probably more like preconception. Lawrence

Printer-friendly page | Top

G'Day Highlighter,I had a thought overnight ('tis early morning here down-under), I have a copy (backup - pat on head) of my test route that has everything except the signals - I think I will copy it and fill it with the default BSNF signals as supplied by MS so I have a standard set of configs and scripts to start with again. Put it on a different PC so I can compare the activities between the two systems. As regards to the yard entrance, at the end of every track I use Hank Sundermeyer's - End Of Track Marker - sitting on top of the buffer. I then modified an absolute signal to put at the yard entrance - it disregards the state of any other signal in the yard, if indeed there are any, but just checks for block occupancy, so it just checks for block clear and route set.OK, enough for now - more research............Cheers,
Laurie Whelan
Brisbane, Australia

Printer-friendly page | Top

I built a test set of straight, single track with 5 passing sidings. The passing sidings alternate sides of the single track, not that that should make a difference.I set up a player path in the activity editor that goes west to east with each of the sidings as an alternate path. I set up another path for traffic going east to west, also with the sidings as an alternate path, to be used by traffic. This one does not have the drivable box checked.As you approach a siding (either direction) you face a double headed absolute MP3 signal. At the exit end, there is a single headed absolute MP3 signal on each track.I created 5 traffic trains and spawned them about a minute apart. The first two start before the sim start time, so they are already on the route.With the NumClearBlocksAhead set to 6, I ran throught with no difficulty. The player train is routed onto the sidings in each case, while the traffic trains take the straight path. Most of the time, I am facing a red over yellow going into the siding, meaning the exit signal is red. However, once I enter the siding, the exit signal changes to a proceed indication of some sort, depending on where the next train is. That's to be expected , given the fact that traffic is coming at me, but clearing switches in the process.I then ran the same test, only with NumClearBlocksAhead set to 2. Again, no difficulty, but there were differences. For one, I was able to move faster, as were the AI trains. Thus, I was in the last siding earlier, passing AI #4, with a yellow signal ahead and the switch thrown to allow me to exit the siding. The 5th AI train was spawned. The dispatcher dropped the signal in front of me to red, but didn't reset the switch. The AI train approached the east end of the siding and stopped. Even though I was on the siding and the AI had a clear path ahead, it would not get a proceed signal because of the switch. So, I backed up. Sure enough, AI threw the switch, and the last AI took off. I went forward again, got a proceed after AI cleared, and was done.So, this parameter does have an effect on how far ahead signals were cleared for me.A well written activity would not drop an AI train onto the track that close to the player, but it is interesting that the dispatcher would not clear the switch for that train, even though it could have.More to come.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Same configuration as my last post, only I took out the AI traffic. This will just test the number of enabled signals ahead of the player train.At the beginning of the test stretch, prior to the first siding switch, are three permissive signals. So, the sequence is:Per Per Per AbsDbl Abs Absdbl Abs ...NumClearBlocks is set to 2 for the absolutes, 6 for the permissives.When the sim starts, the three permissives and the first absolute are clear. As soon as the loco starts to move, the first Abs clears. As I pass the first permissive, the next Absdbl clears! So much for the theory that this parameter is meaningless on permissive signals! This continues until I pass the first absdbl. Now, nothing else happens until I get closer to the next red. At that point, when I pass the preceeding abs, both the next abs and absdbl clear at the same time. I didn't expect that! When I pass the next absdbl, no change. Passing the next abs, again the next two clear.Next test. I set the numclearblocks to 2 for the permissives and the absolutes.When the sim starts, the first three pers are green, everything else is red. When I pass the first per, the first dblabs clears. When I pass the next per, the first abs and the second dblabs clear. When I pass the last per, nothing happens and the sequence continues as it did in the first example, with two signals clearing at a time.So, the value in this field on permissive signals DOES matter.I'm writing these sequences down from memory, so I might be off a little, but there was a clear difference in what happened when I changed the value for the permissives.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Wierd. Once I got the blasted things working, I quit worrying about how I did it. But I suspect I'll be trying to optimize them for 6, and do something a little different - Like AI trains running opposing each other. I dunno what that will do to the framerates, I had one where I met a 37 car tank train while a 40 mixed passed over on the bridge above, and I think it dropped to 7 fps.
Laurie, you saying you got BNSF interlockings that the player can drive thru in an activity without being on the path and they still work correctly? (I assume that's what everybody means by that, "absolute"=BNSF interlocking, "permissive"=BNSF interval). That's what I take "always active" to mean, gives correct indications even with no path, reacts to the trains themselves rather than the projected path of the train, if you follow me. The guy who wrote the techdoc about the number clear ahead value couldn't have been more obscure if he tried, so I'm glad you guys are experimenting with it. Hope you have a good mental health plan, Bob!

Printer-friendly page | Top

LAST EDITED ON Feb-14-02 AT 10:38 AM (EST)Bob, TheSigNumClear Ahead value does effect the permissives, it's just that in my set up I don't think this value needs to be higher than 1. Also, an absolute signal will check a permissive status and display accordingly if the absolute block ahead of it is not occupied, but again, in my set up of absolute blocks I cannot enter a mainline that is occupied by an oncoming train from a siding anyway - the exit of which is controlled by an absolute signal - so I can often see a green or a yellow permissive signal on up ahead while my exit signal shows red correctly. This seems to operate correctly as I can watch a permissive ahead on the single track mainline cascade to increasingly restrictive indications as an oncoming train approaches, while I wait behind a red absolute siding exit signal.I did not mean to suggest that the look ahead value was meaningless for permissives, just that an absolute siding exit signal will not let you take the mainline if it sees anything occupied within its' "look ahead" range and therefore the abs seem to ignore what the permissives are displaying in this situation. Also, I don't see why a permissive needs to "look ahead" further than the next signal since it will update based upon the next signal or if the track is occupied between it and the next signal and should therfore cascade indications properly.I am however having all kinds of trouble with absolute signals in a yard that control the divergence of multiple tracks onto the mainline. Think of this situation as a standard passing siding that has a couple of switches in it. If I have an absolute signal along the middle of this section gaurding any of the switches everything goes wacky again, I think because these are looking too far ahead than necessary for this situation. Laurie, I think you are on the right track with a yard signal that ignores all mainline signals. I beleive this will result in a true interlocking signal.Now I have a whole new problem. I think in my removal and replacement of signals I have some how fouled up the system completely because now, no matter what value I put for the SigNumClearAhead I get nothing but green when there should be red, I can run through a red absolute and have a head on collision or no AI trains come down the line at all, and I get held at one siding entrance gaurded by a dblabs showing dbl red which can't be since neither track is occupied. Need new brain pill! By the way Bob, my signal sequence goes: per, per, dblper, dblabs at siding enterance, sglabs at siding exit. These are all Searchlight signals and are arranged this way in both directions.The number of permissives along the single track mainline is dependent upon length between sidings.Sniper, I am using and studying only Hanks Searchlight signals V2.2.

Printer-friendly page | Top

>LAST EDITED ON Feb-14-02
>AT 10:38 AM (EST)
>
>I did not mean to suggest
>that the look ahead value
>was meaningless for permissives, just
>that an absolute siding exit
>signal will not let you
>take the mainline if it
>sees anything occupied within its'
>"look ahead" range and therefore
>the abs seem to ignore
>what the permissives are displaying
>in this situation.

I misunderstood what you wrote then. Coming off of the siding, the absolute should do what you said, but there is no easy way to prove it. I've played around with the tracing facility a lot, but you can only query what the signal ahead shows you, whether it be permissive or absolute. This is where I think a query of that (ABS) flag that is on permissive signals would be helpful. The flag exists, but there is no documented way to see if it exists. Why have it if you can't do anything with it?

>Also,
>I don't see why a
>permissive needs to "look ahead"
>further than the next signal
>since it will update based
>upon the next signal or
>if the track is occupied
>between it and the next
>signal and should therfore cascade
>indications properly.
>

The only reason I can see is to be consistent with the absolutes in enabling the same number of signals ahead of itself.

>I am however having all kinds
>of trouble with absolute signals
>in a yard that control
>the divergence of multiple tracks
>onto the mainline. Think
>of this situation as a
>standard passing siding that has
>a couple of switches in
>it. If I have
>an absolute signal along the
>middle of this section gaurding
>any of the switches everything
>goes wacky again, I think
>because these are looking too
>far ahead than necessary for
>this situation.
>

Yeah, signals in a yard would have a problem like that. You really only want them to show the state of the switch. Otherwise, they will be red if the track is occupied anywhere along the path. It would be next to impossible to ever get a proceed. No matter which track you were switched to off of the lead, if there were cars in it, you wouldn't be able to get to them. Perhaps using a different type (other than normal) would do the trick? Either that, or a totally different script would have to be written.

>Laurie, I think you are on
>the right track with a
>yard signal that ignores all
>mainline signals. I beleive
>this will result in a
>true interlocking signal.
>
>Now I have a whole new
>problem. I think in
>my removal and replacement of
>signals I have some how
>fouled up the system completely
>because now, no matter what
>value I put for the
>SigNumClearAhead I get nothing but
>green when there should be
>red, I can run through
>a red absolute and have
>a head on collision or
>no AI trains come down
>the line at all, and
>I get held at one
>siding entrance gaurded by a
>dblabs showing dbl red which
>can't be since neither track
>is occupied.
>
>Need new brain pill!
>
>By the way Bob, my signal
>sequence goes: per, per,
>dblper, dblabs at siding enterance,
>sglabs at siding exit.

Mine is too, I just didn't distinguish between the single and double per for purposes of the test. But I didn't have any pers inbetween the sidings for this test.

>These are all Searchlight signals
>and are arranged this way
>in both directions.
>
>The number of permissives along the
>single track mainline is dependent
>upon length between sidings.
>
>Sniper, I am using and studying
>only Hanks Searchlight signals V2.2.
>
>
>

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Hey Bob,What does the trace function do in your signals?I just ripped out all mine and started back with yours.

Printer-friendly page | Top

There is a description for the trace stuff in the header area of the sigcfg.dat file. It is another one of those things that they mention in the techdoc but don't show examples of. Took me a while to figure it out, but it was worth it. It is a rather primitive facility in that it can only write out numeric values.What I was able to do with it is to write out values from within a script for a given signal head. The values would depend on where you put the code and what you decide to write out. I couldn't always tell why a signal showed what it did since I couldn't see the next signal, so I figured out how to write out the values for the next signal's aspects, as well as what my script logic said my signal was going to show.The trace code goes into the script and is active for every signal head of that type, anywhere on your route. From within a script, there is no way to id one signal from another, so if left this way, every head would write a trace record every time it was recalculated.What I did was to combine the trace with the USERx values in the script, the ones the techdoc says are there but may not work because they didnt' test them! Well, they work, unlike some of the things they supposedly did test, but don't get me started on that. Anyway, there is now a checkbox on all of the MP3 signals property pop up, third page. If you check it, then that signal ONLY will be traced. In the scripts, I test to see if this user flag is present, and if it is I go through the code that writes the trace records. If not, no trace.The trace data has header records with a time stamp. Unfortunately, it is real time, not sim time, so you have to coordinate the two. I write out three things for the traced signal; is it enabled, is the path clear, obstructed or occupied, and is the switch thrown to enable a train to reach the exit switch for the block. Look at the techdocs for more info on what these values mean. I also write out the most and least restrictive indications shown by the next signal up the path, and the resulting indication value for the traced signal. And I write out a value that helps identify one signal type from another.When you start the sim, or run the activity editor video test facility, you will get a trace file written to the Train Simulator root directory. They don't tell you that, you have to go find it!One word of caution...keep track of any signals where you turn on a trace. If you forget which one you are tracing, the only way to find it is to edit every signal and look at the properties until you find it and turn it off. Guess how I learned this? You can trace more than one signal at a time, but if there's more than one of the same type it is next to impossible to tell which is which in the trace.I couldn't have written the MP3 scripts without figuring out how this worked, and even with it working, it took a while to get the scripts where I wanted them. So, I decided to leave the code for the trace in the scripts so others cjould see it and wouldn't have to go through the same learning process if they wanted to develop their own scripts.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

LAST EDITED ON Feb-14-02 AT 09:26 PM (EST)Thanks for the explanation Bob,I hope I don't ever have to go through all of that 'cause it's way over my head!On to another couple of subjects,1) You had mentioned a compatibility problem with your scripts and the other searchlight signals. Will I have a problem mixing Hanks Dwarf or Distant Semiphores With your MP Searchlights?2) How would you feel about configuring your scripts for the dblpermissive signal to indicate yellow over green when a dblabs ahead is indicating Approach_3 (red over flashing yellow)?
And for Laurie, I am curious about how you wrote your scripts to enable all signals. Are they all enabled full time?
And for both of you, I went back into my route with BOBS' MP Searchlight signals after tearing out all the others. Turns out I had a phantom signal in the yard area of the passing siding, still registered in the .tit file I think, that I had removed from the route once. I think I probably restored a backup that still had this signal recorded and man did it mess about with things. Anyway it's all back together with the new signals and I have still settled on a look ahead value of (2) for the Absolute signals, and (1) for the Permissives - and I am not seeing any update problems. I think this is because of my block set up.By the way Bob, I like the linked dblpermissive a lot better. I was having all kinds of trouble with the other one - in fact, trying to get the other one to update properly is what got me started on all of this in the first place, and was what prompted me to remove the signal that later became a phantom.Anxious to hear what you two have come up with.Cheers!

Printer-friendly page | Top

>LAST EDITED ON Feb-14-02
>AT 09:26 PM (EST)
>
>Thanks for the explanation Bob,
>
>I hope I don't ever have
>to go through all of
>that 'cause it's way over
>my head!
>

It is hard to put into your own scripts, but now that I've got it into the MP3, using it is easy, you just check a box! If you take the explaination and run a short trace test, then look at the results, you will probably figure out what it is telling you.
>On to another couple of subjects,
>
>
>1) You had mentioned a
>compatibility problem with your scripts
>and the other searchlight signals.
> Will I have a
>problem mixing Hanks Dwarf or
>Distant Semiphores With your MP
>Searchlights?
I don't know. Depending on how Hank sets them up they may be fine. I haven't seen his scripts yet. Since I used the SL2.2 scripts as a starting point, there are more similarities than differences, but his are written for a different set of rules than the MPs. You should be able to take a dwarf or semaphore that is equivilent to one of the MP3s in function and change the scripts to match and be OK, but I'd have to see 'em to be sure.

>
>2) How would you feel
>about configuring your scripts for
>the dblpermissive signal to indicate
>yellow over green when a
>dblabs ahead is indicating Approach_3
>(red over flashing yellow)?
>

That would be an Advance Approach indication, proceed prepared to pass next signal not exceeding 50 MPH and to advance on diverging route. Your upcoming switch would have to have a 50 MPH or higher speed limit, and you would probably have to have a special version of the signal prior to the switch capable of displaying y over g instead of y over y. I didn't try to code that up 'cause MP didn't have any such animals on it. I'll take a look and see how easy it would be to do.

>
>And for Laurie, I am curious
>about how you wrote your
>scripts to enable all signals.
> Are they all enabled
>full time?
>
>
>And for both of you, I
>went back into my route
>with BOBS' MP Searchlight signals
>after tearing out all the
>others. Turns out I
>had a phantom signal in
>the yard area of the
>passing siding, still registered in
>the .tit file I think,
>that I had removed from
>the route once. I
>think I probably restored a
>backup that still had this
>signal recorded and man did
>it mess about with things.
> Anyway it's all back
>together with the new signals
>and I have still settled
>on a look ahead value
>of (2) for the Absolute
>signals, and (1) for the
>Permissives - and I am
>not seeing any update problems.
> I think this is
>because of my block set
>up.
>
>By the way Bob, I like
>the linked dblpermissive a lot
>better. I was having
>all kinds of trouble with
>the other one - in
>fact, trying to get the
>other one to update properly
>is what got me started
>on all of this in
>the first place, and was
>what prompted me to remove
>the signal that later became
>a phantom.
>

You might want to double check in the world file that covers that particular piece of real estate to make sure you don't have a left over signal entry too. When those get out of synch, things get weird. I've had it happen where I'm looking at a green light out the window, but the track monitor shows red, and, sure enough, if I try to run it the sim stops. It was an orphaned signal head in the DB that only partially deleted. It took a while to figure that one out.Hank's signals are always red over something if there is an upcoming divergence. The GCOR rules use both lights to indicate some things, and that's why I had to link 'em to the paths. I couldn't get enough info back from the absolute signal to distinguish straight from turn!

>Anxious to hear what you two
>have come up with.
>
>Cheers!

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

>>2) How would you feel
>>about configuring your scripts for
>>the dblpermissive signal to indicate
>>yellow over green when a
>>dblabs ahead is indicating Approach_3
>>(red over flashing yellow)?
>>
>
>That would be an Advance Approach
>indication, proceed prepared to pass
>next signal not exceeding 50
>MPH and to advance on
>diverging route. Your upcoming
>switch would have to have
>a 50 MPH or higher
>speed limit, and you would
>probably have to have a
>special version of the signal
>prior to the switch capable
>of displaying y over g
>instead of y over y.
> I didn't try to
>code that up 'cause MP
>didn't have any such animals
>on it. I'll take
>a look and see how
>easy it would be to
>do.
> OK. That would be interesting to have. I did not realize it was associated with a 50mph limit but I could still use it. What is the proper aspect for a dblperm when the dblabs ahead is showing red over flashing yellow? My rule table does not reference this condition. Probably just dbl yellow eh?>
>You might want to double check
>in the world file that
>covers that particular piece of
>real estate to make sure
>you don't have a left
>over signal entry too.
>That's what I had and got rid of.>
>Hank's signals are always red over
>something if there is an
>upcoming divergence. The GCOR
>rules use both lights to
>indicate some things, and that's
>why I had to link
>'em to the paths.
>I couldn't get enough info
>back from the absolute signal
>to distinguish straight from turn!
> Well, that explains all the trouble I was having. It was not until I tried to get these to work that I started getting so deep into the scripts and config files. I then realized it was going to take a rewrite to get the functionality I wanted and I am not so comfortable yet in writing scripts on my own.I hope you are willing to work with me on all this as I would really like to get the scripts all cleaned up and optimized for the SP Coast Route, and for any other route for that matter that uses GCOR rules. I guess I'm kind of a neatness freak and would like to remove any unneeded references to the BNSF 3light signals and such.Thanks!

Printer-friendly page | Top

There is also an indication called Approach Limited that is the same as Advanced Approach, except the speed limit is 60. It is yellow over flashing green. I've never actually seen one of these, but it is in the signal chart, so it must exist somewhere! I doubt you would find it on the Coast though as I can't imagine there are any 60 MPH turnouts on it.Red over flashing yellow is Diverging Approach Medium. The signal before it would need to show that a divergence was coming up. From what I've deduced, the previous signal would show Approach Medium. In the MP3 signals, I distinguished between an approach medium for a normal path ahead (flashing yellow) and one for a divergine path (double yellow), but in the prototype, both flashing yellow and double yellow mean the same thing.BTW, you say the intermediate signal prior to the absolute, but it doesn't necessarily have to be an intermediate. Take a situation where you have two diverging paths a mile apart and no intermediate signals in between. At the first switch, which we'll assume is in normal position, the signal should show the warning of the upcoming divergence at the next switch, just like the intermediate would.Your best reference for the aspects for the Coast line would be an Altamont Press California Timetable. The BNSF web site also has a PDF document with Signal Aspects and Indications that matches pretty closely. The Altamont pages list the UP and BNSF (and Amtrak) side by side so you can see the differences, mostly things that aren't used by one or the other.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

>I doubt
>you would find it on
>the Coast though as I
>can't imagine there are any
>60 MPH turnouts on it. Nope!
>BTW, you say the intermediate signal
>prior to the absolute, but
>it doesn't necessarily have to
>be an intermediate. Take
>a situation where you have
>two diverging paths a mile
>apart and no intermediate signals
>in between. At the
>first switch, which we'll assume
>is in normal position, the
>signal should show the warning
>of the upcoming divergence at
>the next switch, just like
>the intermediate would. I understand. It just seemed to me that if the divergence was red over flashing yellow, or red over solid yellow for that matter, that the dbl permissive should show something other than dbl yellow as it does when the divergence is red over green. But, I guess it would not matter when the speed through the divergence is always the same.

Printer-friendly page | Top

If you two guys have the chance would it be possible for maybe both of you collaborating on a document written in English that explains basic signal principles? I've read the tech docs on writing signal scrips, and I've read this thread about 6 times, and it might as well be written in Martian, for all the sense it makes to me. I don't know enough about signaling to even know what questions to ask. I feel sort of like a 9th grade science student trying to understand a graduate school level quantum physics textbook.NickF

Printer-friendly page | Top

Here is a start for basic signal usage. It is taken from my SP Coast Route users manual that I am writing.
Prototypical Searchlight Signals are used exclusively throughout this route and are configured to GCOR rules (in other words they display as they should for this route).
The usage is as follows:1. Single Head Permissive - used along single track mainline for train separation. May also be found along passing sidings that are in excess of 1.5 miles long. These signals have a number or gradient board affixed to the mast to discern them from Absolute signals.
Aspect indications and required action are:
a. Green = “Clear” - proceed at prescribed speed.
b. Yellow = “Approach” - reduce speed as prescribed and prepare to stop at next signal.
c. Flashing Yellow = “Medium or Advanced Approach” - be prepared to reduce speed by the next signal that may be displaying “Approach” and a prescribed speed limit.
d. Red = “Stop and Proceed” – Stop and then proceed at prescribed limit. Note that you will not likely receive this indication unless you follow a train ahead of you to closely on a single track mainline2. Double Head Absolute - used to protect a siding entrance and is placed just prior to the switch that splits the mainline into a passing siding - top head linked to straight, bottom head linked to diverging siding.
Aspect indications and required action are:
a. Green over Red = “Clear” - proceed at prescribed speed. Routing is straight through switch.
b. Red over Green = “Diverging Clear” - proceed at prescribed speed. Routing is through turnout.
c. Red over Yellow = “Diverging Approach” - reduce speed as prescribed and prepare to stop at next signal. Routing is through turnout.
d. Yellow over Red = “Approach” - reduce speed as prescribed and prepare to stop at next signal. Routing is straight through switch
e. Flashing Yellow = “Medium or Advanced Approach” - be prepared to reduce speed by the next signal that may be displaying “Approach” and a prescribed speed limit.
f. Red = “Stop” - Route is protected through switch. If both routes are blocked, you must wait for one to clear.3. Double Head Permissive - used in place of signal #1 above if it is the last or only permissive signal preceding a #2 on the single track mainline and indicates the condition of the Double Head Absolute signal ahead that is protecting a passing siding.
Aspect indications and required action are:
a. Green over Red = “Clear” - proceed at prescribed speed. Routing is straight through the switch ahead.
b. Yellow over Red = “Approach” - Proceed prepared to stop at next signal. Trains exceeding 40 MPH must begin reduction to 40 MPH as soon as engine passes signal displaying approach.
c. Double Yellow = “Approach Diverging” - Proceed prepared to advance on diverging route at next signal at prescribed speed through turnout.
d. Yellow over Green = “Approach Diverging” - Proceed prepared to advance on diverging route at next signal at prescribed speed through turnout.
e. Red over Red = “Stop and Proceed” - Stop and then proceed at prescribed limit.4. Single Head Absolute - used at the siding exits to protect the single track block ahead and is placed just prior to the switch that converges a siding back to a single track mainline.
Aspect indications and required action are:
a. Green = “Clear” - proceed at prescribed speed.
b. Yellow = “Approach” - reduce speed as prescribed and prepare to stop at next signal.
c. Flashing Yellow = “Medium or Advanced Approach” - be prepared to reduce speed at the next signal that may be displaying “Approach” and a prescribed speed limit.
d. Red = “Stop”– Stop short of signal and wait for block ahead to clear (Signal will change to green when clear).Hope that helps. I'd suggest you copy and past it into something that you can reformat the tabs in.

Printer-friendly page | Top

>Prototypical Searchlight Signals are used exclusively
>throughout this route and are
>configured to GCOR rules (in
>other words they display as
>they should for this route).
>
I have a scanned copy of the UPRR system special instructions regarding signals. I will comment here according to that document. I think the Altamont Press timetables may have some errors; they are, for sure, harder to understand than the UP document, which takes five or six pages.
>
>The usage is as follows:
>
>1. Single Head Permissive - used
>along single track mainline for
>train separation. May also
>be found along passing sidings
>that are in excess of
>1.5 miles long. These
>signals have a number or
>gradient board affixed to the
>mast to discern them from
>Absolute signals.
>Aspect indications and required action are:
>
>a. Green = “Clear”
>- proceed at prescribed speed.
>
>b. Yellow = “Approach” - reduce
>speed as prescribed and prepare
>to stop at next signal. Freight trains must reduce to 30 mph immediately when on an approach. The limit is 45 for passenger trains. They must be prepared to stop at the next signal.>c. Flashing Yellow =
>“Medium or Advanced Approach” -
>be prepared to reduce speed
>by the next signal that
>may be displaying “Approach”
>and a prescribed speed limit. This indication is called Advance Approach. Freight trains must immediately slow to 40 mph, but passenger trains can proceed prepared to pass the NEXT signal at 40 mph. Here's a bit of possibly irrelevant confusion, though. The instructions for this signal indicate passenger trains may proceed but not exceed 40 mph passing the next signal, but the instructions for Approach indicate 45.>d. Red = “Stop and Proceed”
>– Stop and then proceed
>at prescribed limit. Note
>that you will not likely
>receive this indication unless you
>follow a train ahead of
>you to closely on a
>single track mainline After stopping, trains must proceed at restricted speed, which is a speed not exceeding 20 mph prepared to stop within half the range of vision. All trains must stop and proceed at a signal with a number plate. Most trains will stop and proceed at a grade plate, but trains over a certain weight can simply blow by it at restricted speed.>2. Double Head Absolute - used
>to protect a siding entrance
>and is placed just prior
>to the switch that splits
>the mainline into a passing
>siding - top head linked
>to straight, bottom head linked
>to diverging siding.
>Aspect indications and required action are:
>
>a. Green over Red =
> “Clear” - proceed at
>prescribed speed. Routing is
>straight through switch.
>b. Red over Green =
>“Diverging Clear” - proceed at
>prescribed speed. Routing is through
>turnout. Trains must not exceed the prescribed speed through the turnout.>c. Red over Yellow = “Diverging
>Approach” - reduce speed as
>prescribed and prepare to stop
>at next signal. Routing is
>through turnout. The speed limits here are the same for Approach. Freight trains must slow to 30 mph immediately, prepared to stop at next signal, and passenger trains must slow to 45 mph immediately, prepared to stop at next signal. Trains must also slow to the prescribed speed through the turnout, which is often less than 30 mph.>d. Yellow over Red = “Approach”
>- reduce speed as prescribed
>and prepare to stop at
>next signal. Routing is
>straight through switch
See Approach above.>e. Flashing Yellow = “Medium
>or Advanced Approach” - be
>prepared to reduce speed by
>the next signal that may
>be displaying “Approach” and
>a prescribed speed limit. See Advance Approach above.>f. Red = “Stop” -
>Route is protected through switch.
> If both routes are
>blocked, you must wait for
>one to clear.
>
>3. Double Head Permissive - used
>in place of signal #1
>above if it is the
>last or only permissive signal
>preceding a #2 on the
>single track mainline and indicates
>the condition of the Double
>Head Absolute signal ahead that
>is protecting a passing siding.
>
>Aspect indications and required action are:
>
>a. Green over Red = “Clear”
>- proceed at prescribed speed.
> Routing is straight through
>the switch ahead.
>b. Yellow over Red = “Approach”
>- Proceed prepared to stop
>at next signal. Trains exceeding
>40 MPH must begin reduction
>to 40 MPH as soon
>as engine passes signal displaying
>approach. See Approach above.>c. Double Yellow = “Approach Diverging”
>- Proceed prepared to advance
>on diverging route at next
>signal at prescribed speed through
>turnout.
>d. Yellow over Green =
>“Approach Diverging” - Proceed prepared
>to advance on diverging route
>at next signal at prescribed
>speed through turnout. This signal does not mean necessarily that the next turnout is reversed. This signal is the same as Advance Approach above—the next signal can be either Approach or Diverging Approach. For consistency, you will probably want to change this aspect to flashing yellow. The same speed limits apply as above.>e. Red over Red = “Stop
>and Proceed” - Stop and
>then proceed at prescribed limit. Stop and proceed at restricted speed.>4. Single Head Absolute - used
>at the siding exits to
>protect the single track block
>ahead and is placed just
>prior to the switch that
>converges a siding back to
>a single track mainline.
>Aspect indications and required action are:
>
>a. Green = “Clear”
>- proceed at prescribed speed.
>
>b. Yellow = “Approach” - reduce
>speed as prescribed and prepare
>to stop at next signal. See Approach above.>c. Flashing Yellow =
>“Medium or Advanced Approach” -
>be prepared to reduce speed
>at the next signal that
>may be displaying “Approach”
>and a prescribed speed limit. Same as Advance Approach at the top.>d. Red = “Stop”– Stop short
>of signal and wait for
>block ahead to clear (Signal
>will change to green when
>clear). The signal may not necessarily display a Clear indication. Trains can proceed as long as the signal displays a less restrictive indication, which in this case would probably be Approach.

Printer-friendly page | Top

Here's the link to the SP Signal rules of 1996. http://www.lundsten.dk/us_signaling/aspects_sp1996/index.htmlThis web site also has links to other very informative signal data. I'm hoping to find such information for the late 1940's, as this is the period in which I'm personally interested. I'm also more interested in Streamlined Steam era Passenger service than anything else, though express overnight freight or a reefer block towed by a cab ahead are also at the forefront. I have not actually finished adjusting any speeds if necessary in the signal configs. I also have not finished writing my user manual, not by a long shot, and only posted that portion to help give a general idea of how the different signal types are used.

Printer-friendly page | Top

Regarding double yellow vs. flashing yellow alone or over something...You are correct in that they are exactly the same in the instructions for UP (and BNSF). In MP3, I made it a convention that double yellow was prior to a divergence and flashing was for normal pathing.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Actually that clarifies a number of things; I was beginning to wonder if I was just being stupid. I copied and pasted your whole post into the general MSTS document I'm keeping in Word.Thansk,Nick

Printer-friendly page | Top

LAST EDITED ON Feb-15-02 AT 09:22 PM (EST)>Actually that clarifies a number of
>things; I was beginning to
>wonder if I was just
>being stupid. There are no stupid questions when it comes to signals in MSTS. It seems this is new ground for most and one of the biggest problems seems to be more related to how an activity interacts with them. I've tried to reduce the AI effects to the simplest form to try and make some sense on how things interact, BUT, and this is a big but, What works on my particular route may not work on another because of placement, quantity of signals, and block sequences and sizes.I am glad that my general guidelines were of some help. I wish I had that information when I started as I had no idea of their basic usage either and have spent the past few weeks trying different things to discover their mysteries. An additional tip that was not obvious to me at first: Don't place the sensors directly on a switch as they will trip to red as soon as your train "steps on" it and you will get the end activity message for ignoring a red light - if it happens to be an absolute signal. If it is a permissive, it will not end the activity but may effect the remainig signals and give you all kinds of strange indications on down the line, and you may not have even noticed that it changed prematurely. BOBS is working on an actual signal tutorial that we are all looking forward to. My stuff is pretty much specific to operating the SP Coast Route but probably will help many with similar needs.Cheers!

Printer-friendly page | Top

Nick, just be careful with that description. It describes how things are in GCOR rules/railroads in the west, but not NORAC RRs in the east. They have more indications and more complicated aspects to display them.Just when you thought you were beginning to understand...

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

A VERY interesting threadI use all BNSF Interlocking sigs on my route and have found that the SignalNumClearAhead counts all the sigs in ALL three routes when using a three head sig. It also counts all the sigs in both routes when using two heads. ( for the purpose of indicating the condition for the current sig.) In other words: If you use a three head sig to look at conditions on your main route and two diverging routes, and each of the three routes ahead has 3 blocks with a sig for each block, then the SignalNumClearAhead must be set to 9 (3x3) or the sigs ahead will not all be enabled for the current sig. If you set the number to 8, one of the routes will never give you a clear, if you set it to 7, two of the routes will never clear, and a 6 in SignalNumberClearAhead will never allow more than an approach 2 ( Flashing Yellow ) in this situation.NOTE: I have only tested the standard BNSF Interlocking sigs in this scenario, and it may not pertain to other sigs. I guess you could say the rule here for junction heads is <junction heads x sigs ahead in each junction = Minimum SignalNumClearAhead> for the entire route for that signal type.The sig should only look at the selected route for the count, but instead counts up the sigs in each route. I think the sim programmers missed this one.A crude pic of the route area: oboe

Printer-friendly page | Top

I didn't see this post before. If you are right, that would explain the odd results I got on my tests where the sim was clearing 2 signals as a time ahead of itself. Another theory to test out.If true, it is a big bug.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

>I guess you could say the rule here for junction heads is <junction heads x sigs ahead in each junction = Minimum SignalNumClearAhead> for the entire route for that signal type.
>
>The sig should only look at
>the selected route for the
>count, but instead counts up
>the sigs in each route.
>I think the sim programmers
>missed this one. That is interesting Oboe, and it would seem to coincide with the findings for my setup. I have only two interlocking/absolute signals ahead of my dblhead interlocking/absolute signals, because I have only two routes=paths ahead in my passing siding configuration with one absolute signal protecting each exit/merge back to a single track mainline, and I have found a SigNumClearAhead value of (2) to work properly. Have you found that you get a clear from your triple signal and can move up to the next signal on your path if there is a train on one of the other paths 4 blocks ahead?

Printer-friendly page | Top

Hello BobI have opposing traffic ( 25 trains on two minute headway, each one starting about two miles behind the other. ), but this area is double tracked for almost 10 miles so there is no interference where I was having the problem with the approach_2 reading. I had approach_2 ( see the drawing in previous post )on the three head until I changed the "SignalNumClearAhead" from 8 to 9. I had one other sig in another area that was also a three head, looking at three fully signalled routes, and I had to change the number on that one from 7 to 8 to get a clear. ( It's now at nine ) All of my double heads worked fine at 6, but many gave me Approach_2 at a setting of 4.I'm going to raise the ante to test this further. I've changed the sigcfg for the BNSF3 to include Approach_3, and Clear_1, but I'm having trouble with the sigscr. I don't think that existing sigs like to see a change in the sigscr.dat, but I can't understand why. The thought is to reintroduce the Approach_2 problem at a setting of 9, by increasing the read of the blocks ahead from 3 to 5, I would have to have a setting of at least 13, and properly 15, to obtain a clear_2, but only if my little theory is correct. ( I made clear_1 a "flashing green", and gave every aspect a speed limit so I could tell the difference ) .. I have a new testbed route setup for this, and will do it this week.I am having fun, but this stuff does not always do what I expect, and I have the worst "syntax" eyes on earth. I haven't done "C" in fifteen years, and that's not helping either.BTW, in the "single track with passing sidings" areas of the route, I have never had a problem with opposing traffic since going to 6 ( now 9 ), but I cheat. All single track passing sidings are using left hand #5 switches on both ends. ( This makes it easy to create all of the path(e)s, and assures that opposing traffic will be on your left. ) oboe

Printer-friendly page | Top

I am writing one Nick, complete with pictures which is what's missing from the discussion here. I have the prototype examples pretty much done, but writing up the part on how to translate that into MSTS stuff is going to be difficult.And yes, it is in English!

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Hi Daylighter,"Now I have a whole new problem. I think in my removal and replacement of signals I have some how fouled up the system completely because now, no matter what value I put for the SigNumClearAhead I get nothing but green when there should be red, I can run through a red absolute and have a head on collision or no AI trains come down the line at all, and I get held at one siding entrance gaurded by a dblabs showing dbl red which can't be since neither track is occupied."Unfortunately, this happens!
I have found that after a time, for some obscure reason, mucking about with signal placement, and this includes just moving them not only replacing them, the red triangle thingies on the track get linked up with the wrong signal displays / posts / whatever. And a very nasty off-shoot from this is that you cannot rebuild the track / road database anymore.What you MUST do is have a backup of your route with everything in it except signals. ie the signals are added last. There has been some references to mileposts causing problems too but apart from them 'magically' moving I have found no problem.If you wish to preserve your sanity - well..........If I wish to make a track or signal change sometimes it wiser to start with the backup make the changes, backing up again, then redo all the signals - a lot of work sometimes but safer in the long run.Regards,
Laurie Whelan
Brisbane, Australia

Printer-friendly page | Top

Laurie, if you are fearless, you can recover from the problem you are having, but it takes some editing of a couple of files. If not, a restore to something previous works too.What has happened is somehow a portion of the entries for a given signal were deleted, but not all. It might be a glitch, or you restored something, or changed something in the sigcfg file after a signal was placed that you shouldn't have changed (like adding a feature to a signal...nasty things happen when you do this to signals already on the route)Signal info is stored in two places. One is the world file where the object is placed, the other in the track data base. Somewhere on here there is a thread where some of us walked through this problem in detail a few months ago. In the track database, you have to make two changes. One is to find and delete the signal entry. Actually, you can't delete it, you replace it with an empty entry. But there was a reference to it in the top portion of the file where track objects are tied to track segments. There you have to delete the reference and reduce the counter that says how many subitems are attached.The world files are more straight forward and contain a section for every signal item (each head, marker, etc.). Most likely you have one of these left over. Try to find the other thread, because we went into much more detail than I can recall now.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

G'day Bobs,No - I don't have a problem. That part of my message was copied from one of Daylighter's messages further up the thread.But never fear - as long as Murphy rules the roost - I will fall foul again.............Cheers,
Laurie Whelan
Brisbane, Australia

Printer-friendly page | Top

LAST EDITED ON Feb-16-02 AT 09:29 PM (EST)Hi All:The Sigs are actually put in three files, and all three have to agree. Any dynamic item that is track related is inserted in the World file (*.W ), The Track DataBase ( *.tdb ), and the Track Item Table, ( *.tit ) .... They are tied together by the TrItemId #. ... I believe ( I stress "believe" ) that one of the main reasons for data corruption is the editing of any of these items when you are nearing the memory hole problem, but well before the black screen appears. I have over 600 sigs on my route now, and have found that shutting down the RE, and opening it again, just BEFORE editing sigs or other dynamic items, has pretty much ended my corruption problems with dynamic items. Others may have had a different experience with this.The other thing that I found when these problems occurred, was that most of the time the items had been deleted in the *.tit, and *.rdb files, but were still complete in the world file. I could edit out the sig in the World file, Readjust the item count, and everything would be OK. ... In the *.tit and *.tdb files, the item is usually replaced by an "empty item" field, I believe ( not sure ) so that the uid counter won't get out of sync.Dynamic road items are handled in the same way, only they occur in the *.rit, *.rdb, and *.w files ... The worst offender is the level crossing ... they end up in all five files because they are both track and road related. A level crossing that is a two lane highway crossing double track will have four TrItemID numbers, one for each lane, and one for each track. The "0" and/or "1" that precedes the actual TrItemID in the World files, is not a part of the TrItemId, and should not be used in a search. These are prefixes with the "0" pointing to track files, and the "1" pointing to road files

If you get a sig or other dynamic item out of sync, then all dynamic items can get out of sync, and you can lose your *.rdb as well as your *.tdb ... This is not too hard to fix in a small route once you get use to it, but it is very time consuming in a large route. For me, the easiest way to find the offending code has been to look in the World file where the problem started, get the TrItemId # of the item that you THINK is causing the problem and do a search for it in the other files. ( Search for "TrItemId ( 24 )" if you think that this is the offending object.). 95 percent of the time, a simple edit in the world file has fixed the problem for me, but always check the condition of the item in the other two files first. ( four for level crossings ).BTW ... Dynamic track is a different animal, and it is handled by a call similar to the TrackObj.I think I have all of the above correct, but like the rest of you, I'm still learning, so treat the info as suspect until you find that it works for you.oboe

Printer-friendly page | Top

What you wrote sounds like what I've found. Fortunately, I haven't messed up with any level crossings (yet).I would also agree that most of these problems happen at or near black screen time. As soon as I see that flash, I save and exit and reboot, but once in a while it doesn't get done cleanly. But, there are some other things you can do to cause this sort of problem, such as removing a SignalSubObj from the signal config file for a signal that is on your route. The doc says "don't do that" and this is why! Learned this one the hard way too.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Hello there,this is all very interesting stuff but it takes a long time to read it all.
I have been fiddling with signals myself and I have come accross two errors which may or may not be similar to those described above - I hope someone can throw some light on this.First of all, on a route which I am building bit-by-bit, I install the signals as soon as a part is completed. I then leave track and signals well alone for a long time while working somewhere else. I have recently found that when I return to a signal which was placed 'long ago', It still works, I can still select it but if I try to move it (using F3), it simply sticks where it is. Is this the same semi-disappearing trick as described above?Second problem : when I introduced a large number of signals (over 30 signal types and shapes), MSTS crashed on exiting (!)(well, if it has to crash it certainly is the most convenient moment ...). Some of the signals I added had 5 (yes, five) link-selections, and one signal had an 'INFO' type signal-head - the latter did most damage, I think. Does anyone know about limits to the number of signals, and has anyone used the 'INFO' type with similar negative results?Thank you,
Rob Roeterdink

Printer-friendly page | Top

>I install the signals as
>soon as a part is
>completed. I then leave track
>and signals well alone for
>a long time while working
>somewhere else. I have recently
>found that when I return
>to a signal which was
>placed 'long ago', It still
>works, I can still select
>it but if I try
>to move it (using F3),
>it simply sticks where it
>is. Is this the same
>semi-disappearing trick as described above?

No, I don't think it is the same thing. It has been strongly recommended that signals be placed on the route LAST due to the problems they can occasionally cause when doing track changes and route editing.

>
>
>Second problem : when I introduced
>a large number of signals
>(over 30 signal types and
>shapes), MSTS crashed on exiting
>(!)(well, if it has to
>crash it certainly is the
>most convenient moment ...). Some
>of the signals I added
>had 5 (yes, five) link-selections,
>and one signal had an
>'INFO' type signal-head - the
>latter did most damage, I
>think. Does anyone know about
>limits to the number of
>signals, and has anyone used
>the 'INFO' type with similar
>negative results?
>

You mixed an info-type head with normal-type heads on the same signal? Hmmm. The doc doesn't say you can't, but I suspect it would cause problems. What RR are you simulating that causes links to 5 tracks from one signal? Are your signals prototypical?

>Thank you,
>
>
>
>Rob Roeterdink

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Hello again,>
>You mixed an info-type head with normal-type heads on the same
>signal? Hmmm. The doc doesn't say you can't,
>but I suspect it would cause problems.
The doc refers to 'INFO' with the British route indictor as example - and those are surely placed on the same signal.
In fact, the signal worked correct - except for the crash at the end!

>What RR are you simulating that causes links to 5 tracks from
>one signal? Are your signals prototypical?
>
The 5 links was just a test. The route I'm working on is fictitious - the signals are not, they really are prototypical, and as soon as I get my grips on Abacus' Modeller I hope to create the correct shape and upload the whole lot - provided nobody beats me to it.Thanks all, Rob Roeterdink

Printer-friendly page | Top

LAST EDITED ON Feb-18-02 AT 10:01 PM (EST)OUCH ... After reading your post, I created an info sig out of a BNSF3 - US2Bsigdouble combo, and renamed it all to BNSF6. I created new *.s and *.sd from the copied US2Bsigdouble , and copied and renamed the BNSF3 sig and US2Bsigdouble shape code in the sigscr and sigcfg. ( I've been wanting to make one of these anyway. ) I stuck this mess into my testbed route and entered the route editor.Kapoweee ... Took out my system registry, and I had to reload MSTS. I've created several new sigs and sure had my share of trouble getting them to work right, but nothing like this. I think I probably did something wrong in the sigscr, but it shouldn't have done that much damage. I will try again by just changing the function of an existing unused sig and see what happens.oboe

Printer-friendly page | Top

You said you copied and renamed the .s and .sd files. Did you change the head types on the signal too, or keep the same name and just change it to info. If you did the later, that's probably what got you as you now have the same signal head as both info and normal. I don't know that it says you can't do that, but I'd bet it wouldn't work.See my other post about your earlier "discovery" with the counts and number of heads too.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

Hi Bob: I changed the file name in the SD file, but I have never found one in the s file. ( I had them renamed to "US2crossinterlock.*" ) ( Gee .. Guess what I'm trying to do )
I have created 4 other sigs ( Normal ) this way and they worked OK after I took care of my syntax errors in the sigscr file.I just finished changing the function of the BNSF3 in the sigcfg file from "NORMAL" to "INFO", and then I put about 15 sigs on a previously unsignalled testbed track. I started with the combined USA scripts for this trial. the sigs went into the route fine, but when I opened the activity editor, it allowed me to create a new activity name and as soon as I hit enter, the activity editor quit responding. I could "end task" with no problems. I rebooted the computer, and tried several more times with the same results. I went back and re-edited the sigcfg by replacing the "INFO" call with the "NORMAL" call, and the activity editor came right up. ( Re-edited ??? .. neat new word )I may have to look a little closer and see if the "INFO" call has to be put anywhere else, but I thought that the call stood alone for each sig type. The only other reference that I see for the BNSF3 funtion is the BNSF3 entry in the sigscr.dat where it looks at the next sig in the selected route and will read it only if the function is set for normal. (next_state = next_sig_lr (SIGFN_NORMAL).. The techdoc has a WHOLE line of non-information on the INFO function. I studied that line for the greater part of two minutes
Onwards ... oboe

Printer-friendly page | Top

Info and all the others...there's lots that isn't said! And the syntax is crazy. Make one simple slip up and the best you can get is a blank error message, the worst is a crash. Some diagnostics!The function you quoted should return the least restricive indication currently shown by the next normal signal ahead of you on the switched path. If there is an Info signal in between, it should be ignored.I did some work with two types, normal and one of the other ones, a while ago and found that it worked like it said it should. It didn't help me solve my problem though, so I didn't use it. But I never tried mixing normal and something else on the same signal pole.

Bob Siederer
Co-author of Marias Pass 3.0

Printer-friendly page | Top

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