Signals & Problems

I cannot pin this problem on any one in particular, except Microsoft itself. Years ago, when I was more conversant with signals, when we would go through a clear medium signal, or a clear slow signal, the rule was to go the slow speed through the interlocking, switch or other plant at the specific speed, then when clear, resume speed. I also remember when going through an approach signal, and having the next approach signal clear up, the speed limit was back to track speed. With the MSTS, this isn't true. I first noticed it with the NEC, when clearing up blocks ahead of me, I naturally began to take the train to track speed, only to get penalized. The second instance of it was the O&WV signals, offering a clear slow, restricting the speed top 40. There is no way to get the track speed up, once the switch was cleared. Now my question is a couple of facets. One, does the original programmers (MS) group know anything about this little bug? Two, is there anything I can do to remedy this program.Thank you for your time.Eddie

Alert | IP

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

RE: Signals & Problems, dvdhoven, Dec-26-02, 03:09 AM, (1) RE: Signals & Problems, bobs, Dec-26-02, 06:13 PM, (2) RE: Signals & Problems, dvdhoven, Dec-27-02, 02:16 AM, (3) RE: Signals & Problems, bobs, Dec-28-02, 06:47 PM, (9) RE: Signals & Problems, Vince, Dec-28-02, 02:13 AM, (4) RE: Signals & Problems, dvdhoven, Dec-28-02, 02:41 AM, (5) RE: Signals & Problems, roeter, Dec-28-02, 06:28 AM, (6) RE: Signals & Problems, dvdhoven, Dec-28-02, 09:34 AM, (7) RE: Signals & Problems, Vince, Dec-28-02, 01:08 PM, (8) RE: Signals & Problems, bobs, Dec-28-02, 06:57 PM, (11) RE: Signals & Problems, roeter, Dec-29-02, 05:50 PM, (16) RE: Signals & Problems, Vince, Dec-29-02, 07:07 PM, (17) RE: Signals & Problems, Signalmaster, Dec-29-02, 08:31 PM, (18) RE: Signals & Problems, bobs, Dec-30-02, 01:43 AM, (22) RE: Signals & Problems, goonybird, Jan-03-03, 00:14 AM, (36) RE: Signals & Problems, bobs, Dec-28-02, 06:52 PM, (10) RE: Signals & Problems, buttercup, Dec-28-02, 07:36 PM, (12) RE: Signals & Problems, Vince, Dec-28-02, 11:46 PM, (13) RE: Signals & Problems, Vince, Dec-29-02, 00:09 AM, (14) RE: Signals & Problems, buttercup, Dec-29-02, 04:45 PM, (15) RE: Signals & Problems, Brad 110, Dec-29-02, 09:18 PM, (19) RE: Signals & Problems, bobs, Dec-30-02, 01:31 AM, (21) RE: Signals & Problems, Brad 110, Dec-30-02, 03:01 AM, (23) RE: Signals & Problems, roeter, Dec-30-02, 03:47 AM, (24) RE: Signals & Problems, Signalmaster, Dec-30-02, 09:47 AM, (25) RE: Signals & Problems, jkcooney, Dec-30-02, 10:53 AM, (26) RE: Signals & Problems, Signalmaster, Dec-30-02, 02:11 PM, (28) RE: Signals & Problems, bobs, Dec-30-02, 01:28 AM, (20) RE: Signals & Problems, Vince, Dec-30-02, 01:24 PM, (27) RE: Signals & Problems, bobs, Dec-30-02, 02:41 PM, (29) RE: Signals & Problems, roeter, Dec-30-02, 03:38 PM, (30) RE: Signals & Problems, Vince, Dec-30-02, 03:56 PM, (31) RE: Signals & Problems, bobs, Dec-31-02, 02:01 AM, (32) RE: Signals & Problems, rjdiii, Dec-31-02, 05:14 PM, (33) RE: Signals & Problems, bobs, Dec-31-02, 10:04 PM, (34) RE: Signals & Problems, rjdiii, Jan-01-03, 05:41 PM, (35)

Conferences | Topics | Previous Topic | Next Topic

Hi,As far as I have understood the quircks of the signalling and speed limits in MSTS, you can limit a speed by signalling or by speed signs.
And speed by signal is maintained until the next signal that shows a better speed.
It seems that speed by signalling goes over speed by speed signs, so putting a speed sign after the switch won't help.
The only thing that will help is putting a signal somewhere behind the switch. I know that is odd, compared with realworld railroads, but IMHO, that can cure the problem.
Eventually the signal can be buried. The GermanRailroad package nr 1 has done this.
The only odd thing that remains, is the track monitor showing a signal that isn't there.Dick van den Hoven

Alert | IP

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

I don't think that what you are seeing is a bug, but more of a design issue. I don't think the guys who designed the signaling capabilities in MSTS really understood how signals worked in the real world.If the signal has a speed limit associated with it, that speed limit will be in effect until the next signal is reached. There is no capability to display a speed limit that pertains to a switch, like what you want. I suppose you could set up a very short temporary speed restriction for a switch, but that wouldn't be using it for its intended purpose.In the sigcfg.dat file, where the signals are defined, you will see some aspects with a flag value of (ASAP). When that is present, it allows you to pass the signal above the speed limit set by the signal, but says you must slow down to that limit as soon as you can. It does not enforce this however. Without the ASAP flag, the speed limit takes effect right away and you get a penalty. Out west, using GCOR rules, speed limits through switches are determined by the timetable, not by signal indication, so for western routes this isn't a problem. But for eastern routes where NORAC is used and the indication shows a speed through a turnout, the signal system can't track that for just the length of the train. It will hold you to it until you reach the end of the block.Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

>I don't think that what you are seeing is a bug, but more of
>a design issue. I don't think the guys who designed the
>signaling capabilities in MSTS really understood how signals
>worked in the real world.
>
>If the signal has a speed limit associated with it, that
>speed limit will be in effect until the next signal is
>reached.Bob,That is not the case here in the Netherlands. Here the signals works in conjunction with the speed limit signs.
And here in the Netherlands the signals controll the speed, you're running on the switch.
But after the switch, it is possible to have a speed sign with a better speed then the signal gave and you can speed up to that speed.
And that is what -IMHO - is not possible in MSTS.
But correct me please if I am wrong.

Dick van den Hoven

Alert | IP

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

Dick, you are right, there is no way to do this with the signal functions we have available in MSTS, at least that I've been able to figure out.Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

LAST EDITED ON Dec-28-02 AT 02:14 AM (EST)

I encountered this problem as I am in the final phase of the NEC version 4 route, placing signals.Hank 'Signalmaster' Sundermeyer has built a set of custom signals for the route but they have exactly the same limitation as any of the Trainsin signals, ie; Not being allowed to resume track speed after getting a signal speed restriction.When you pass a restrictive speed signal, for example, NORAC Rule 283, Limited Clear (Red over Flashing Green) States:
"Proceed at Limited Speed until the entire train clears the interlocking then proceed at normal speed."Limited Clear speed is 45 MPH (70 MPH for NEC high speed switches).
So in the real world I slow to 45 MPH for a crossover, watch for last car to clear the switches and then resume normal speed.
In the Sim I am held to 45 MPH until I get to a signal with a less restrictive speed.
I did NOT like this at all. Soooo. I went into the sigcfg.dat file and removed all speed restrictions for signals except absolute Stop.I have had long discussions with Signalmaster Hank and the CEO of the NEC Track team on this issue but I see no other way to fix this built in design problem.
The Sim SHOULD reset the signal speed limit after the last car of the train passes the switch the signal is linked to, but that is not to be. Sigh....I have charts of NORAC rules and when I see a signal aspect that says I must slow through a crossover, I do just that. Then when my train clears the switches, it's back up to track speed. Just like the real world mates.
Yes, I know, I wont get dinged and time stamped if I exceed signal speed limits because there are none set for the NECv4 signals but I KNOW I screwed up.Let's hear your thoughts on this. (removing signal speed limits)
I may have to distribute NORAC signal charts when I release the route to aid those who don't know the rules.
I go by what Al Krug says; "Know your route."

Regards,
Vince Cockeram
NEC Track Team
http://hometown.aol.com/nectrackteam/main.html
E-Mail me at vcockeram@lvcm.com

Alert | IP

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

Hi,As I said before, an extra signal after the switch can cure this. The signal can eventually be buried. Burying gives a quirck in the Track Monitor, but you get used to it.Dick van den Hoven

Alert | IP

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

Hi,there's another way of more proper use of speed restrictions around switches. You can set up the signal (in sigcfg.dat) in such a way that the signal itself does not impose a speed restriction. Then, you can place speed-signs around the switch (buried, if you like). The speed restriction will now only apply for the switch itself. In the track monitor, you will hardly see the difference.
A similar method can also be used for speed reduction related to restrictive aspects. By adding 'ASAP' to the speed-restriction this becomes an 'advisory' speed, not compulsory. So, if the aspect clears, you can increase speed without being punished.
Admittedly, you need to know how to change 'sigcfg.dat' in order to apply these changes.Regards, Rob Roeterdink

Alert | IP

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

Hi,Thanks Rob, never too old to learn Dick van den Hoven

Alert | IP

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

Hi Rob,The problem with placing buried speed posts is you need a speed post on the crossover track itself, the section between the two switches, and thats kind of tough to place.
I had also tried the 'SignalFlags ( ASAP )' parameter in the sigcfg.dat file but but the problem with this is you only get one choice of speed. The NEC as example has need of two different speed limits for crossovers, 45 mph for the 10 degree x-overs and 70 mph for the high speed 2.5 degree x-overs. No way to have a single signal, Red over Flashing Green Limited Clear aspect deal with both speeds. So I think I will have to deliver the route sans signal speed limits and depend on the engineer to know his signal speeds.On a different subject Rob, let me again thank you for solving the broken coupler problem. There were three areas on the Amtrak mainline and one on the CSX Philadelphia subdivision where the distance between track nodes were causing coupler bounce. Placing a siding or a crossover between these problem nodes completely cured the problem.

Regards,
Vince Cockeram
NEC Track Team
http://hometown.aol.com/nectrackteam/main.html
E-Mail me at vcockeram@lvcm.com

Alert | IP

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

Rob, the problem I see with the burried speed limit signs is the way speed limits are set up across tracks. When you put a speed limit marker down, it automatically adapts itself to up to 3 more tracks in the vacinity. You need to get some distance away from another track to establish the speed limit for just one. So, if you set the limit for the switch, it will apply to both legs, which isn't correct if you are going straight. The limitation would only apply if you take the turnout.This is a design problem, because real RRs can have different speed limits on adjoining tracks at the same time, but MSTS can't. The speed limit sign needs an option that can be checked that says it applies to this track only, disabling the automatic adaptation.Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

Hi there,First of all, I hang my head and apologize. Bob, you're right - you cannot place speed-limit signs on cross-overs. It works - with a bit of fiddling with the position - for turn-outs, but, indeed, not for cross-overs between tracks.Next, in one of these posts it was mentioned you can add additional signal-types. You can indeed, but beware : when you define more than 20 signal-types, you get into troubled waters (read : MSTS crashes). I find that whenever I surpass this number and have, for instance, 21 signal-types, MSTS will crash on exit. So 20 seems to be the maximum. By the way, the number of maximum signal-shapes is about 80, but nobody is really sure about this number. It is one of those things MS forgot to tell us.Now, a bit more complicated signal-lure. Apart from having different signal-types for signals with or without speed-restriction, it is also possible to set this option using the 'User Attributes' which can be defined for a signal.
These 'User Attributes' can be defined as options in a signal-shape. They are processed in the signal script, so they also relate to the signal-type.
Let's take the shunt-signal as example. This signal normally has only two possible states : 'STOP' or 'CLEAR' (either 'CLEAR_1' or 'CLEAR_2'). However, there are 8 states available so you can add one more.
In the signal-type definition (in sigcfg.dat), you can set one clear to unrestricted, the other to speed restriction.
This would then look like this (only the relevant lines are shown):SignalAspect ( CLEAR_1 "Green" SPEEDMPH (40) )
SignalAspect ( CLEAR_2 "Green")CLEAR_1 is the restricted aspect, CLEAR_2 the unrestricted.
Make sure to adjust the number of SignalAspects!Now, you must add the user-attribute to the signal-shape (still in sigcfg.dat) in which you use the signal-head you have just altered.
In the signal-shape definition, add the following lines as SignalSubObj :
SignalSubObj ( n // remark : n is the next sub-object index!!
"SPR"
"Speed Restriction"
SigSubType (USER1)
SignalFlags ( OPTIONAL)
)Again, make sure that n as well as the total number of SignalSubObj is correct.
Note : the second line ("SPR") normally defines the signal-head to which the definition applies. For user attributes, this field is not used.Finally, you must alter the processing-code in the script for the signal-type. This is in the sigscr.dat file - the script has the same name as the signal-type.
At the top of the script, add the declaration for the sig_feature function :extern float sig_feature ();Now, search for the line in which the state is set to 'CLEAR'. Change this line as follows :state = SIGASP_CLEAR2;if (sig_feature(SIGFEAT_USER1))
{
state = SIGASP_CLEAR1;
}If you place the signal in your route, open the signal object attribute box (just as you set a link). You will now see the additional entry 'Speed Restriction'. If you enable this field, the signal will clear to CLEAR_1, with speed restriction. If not, it will clear to CLEAR_2.So is it all that simple?No. There are a few if's and but's to remember :
User attributes always apply to ALL heads on a signal. So, if you have multiple heads of the same type, any options will apply to all these heads. If you have multiple heads of a different type, you must take care not to define conflicting user attributes.For the rest, it seems to work quite well. And it does offer a lot of additional possibilities!Sorry for the length of this post.Have fun! Rob Roeterdink

Attachments

http://www.train-sim.com/dcforum/User_files/3e0f7a4b37c61ace.gif

Alert | IP

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

Rob Roeterdink writes:<<snip>>..............
Next, in one of these posts it was mentioned you can add additional signal-types. You can indeed, but beware : when you define more than 20 signal-types, you get into troubled waters (read : MSTS crashes).
I find that whenever I surpass this number and have, for instance, 21 signal-types, MSTS will crash on exit.
So 20 seems to be the maximum. By the way, the number of maximum signal-shapes is about 80, but nobody is really sure about this number. It is one of those things MS forgot to tell us.
...........<<snip>>Rob, is it the "SignalTypes ( nn ......." parameter you are writing about?
Because if it is, Hank 'Signalmaster' Sundermeyers set for the NEC has
twenty two (22) defined in that parm and I have not had ANY crashes using his scripts, either in the editors or the Sim.
Could you clarify further? Thanks much.

Regards,
Vince Cockeram
NEC Track Team
http://hometown.aol.com/nectrackteam/main.html
E-Mail me at vcockeram@lvcm.com

Alert | IP

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

LAST EDITED ON Dec-29-02 AT 08:33 PM (EST)

>Next, in one of these posts it was mentioned you can add
>additional signal-types. You can indeed, but beware : when
>you define more than 20 signal-types, you get into troubled
>waters (read : MSTS crashes). I find that whenever I surpass
>this number and have, for instance, 21 signal-types, MSTS
>will crash on exit. So 20 seems to be the maximum. By the
>way, the number of maximum signal-shapes is about 80, but
>nobody is really sure about this number. It is one of those
>things MS forgot to tell us. I have used more than 20 without this effect. I can't speak to the case where at least one instance of each of the 20+ signals are used in the route.Is it the fact of the index being 20+ or all instances existing in the route causing the crash?
>Let's take the shunt-signal as example. This signal normally
>has only two possible states : 'STOP' or 'CLEAR' (either
>'CLEAR_1' or 'CLEAR_2'). However, there are 8 states
>available so you can add one more.
>In the signal-type definition (in sigcfg.dat), you can set
>one clear to unrestricted, the other to speed restriction.
>This would then look like this (only the relevant lines are
>shown):
>
>SignalAspect ( CLEAR_1 "Green" SPEEDMPH (40) )
>SignalAspect ( CLEAR_2 "Green")
>
>CLEAR_1 is the restricted aspect, CLEAR_2 the unrestricted.
>Make sure to adjust the number of SignalAspects!
>The techdocs say that you need to have SIGFN_NORMAL inorder to add game control by a signal. To me that includes setting speed. So a signal declared as SHUNT or DISTANCE, etc., will have zero effect on any train that passes it. This is my understanding and conclusion through usage.Hank

Alert | IP

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

(snip)
>Now, you must add the user-attribute to the signal-shape
>(still in sigcfg.dat) in which you use the signal-head you
>have just altered.
>In the signal-shape definition, add the following lines as
>SignalSubObj :
>
>
>SignalSubObj ( n // remark : n is the next sub-object
>index!!
> "SPR"
> "Speed Restriction"
> SigSubType (USER1)
> SignalFlags ( OPTIONAL)
>)
>
>Again, make sure that n as well as the total number of
>SignalSubObj is correct.
(end snip)
You have to be really, really careful with this. If you modify an existing SignalShape where that signalshape has been placed on the route already, you run the risk of corrupting the route and/or crashing. You can't change the order in which the signal sub objects are defined for an existing signal and you can't redefine an existing sub object as something else. You can't delete an existing sub object, whether it was selected on any of the existing signals or not. About all you can do is ADD a sub object at the bottom of the list of objects, and even that I'm not sure I would do. As for the number of signal types...as Vince and Hank have indicated, we've gone higher than 20 without problems. The signal files for MP3 had 35 signal shapes and 20 signal types as finally released, but I had more than that in there in the development. More likely, you got a typo or something else wrong with the 21st signal and that is what caused the crash.Working with these signal files is very tricky because they don't tolerate typos or missing parenthesis very gracefully, nor do you get much help in finding the offending lines of code.

Alert | IP

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

I have 66 signal types (and 130 signal shapes), and haven't had a crash yet.

Alert | IP

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

Vince,In developing the scripts for the GCOR signals I used on Marias Pass, I had this same situation and opted not to restrict the speed via the signals, but via the timetable.There are, however, a couple of cases where the signal shows a speed limit that does continue in effect once the back end is clear of the switch. Those are sidings and yard entrances where the speed limit goes to 20 or 15 mph and stays there if you take the switch. For those, I set a speed limit via the signal and it works fine.Also, at all places except for Glacier Park, the BNSF TT says the train can increase speed to 35 once the engines have passed a controlled switch with a slower restriction. Those would be switches for crossovers or single to double track transitions. There's no way to indicate that speed limit via the signals.Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

HiLet me start out by saying I know very little about signal scripts, but is it possible to have more than one set of identical signals that have scripts that are identical except for the speed labels? Then you would have the choice of more then one speed for the same signal indication.Eric

Alert | IP

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

Eric,It certainly is possible to do that. You can have multiple types of signals as proved by Signalmasters heroic effort in building the custom set for the new Northeast Corridor route. He has built five different types of signals combined into one set and they all can interact with each other.

To have different speeds associated with the same signal type would mean adding a signal type with a different speed restriction to the sigcfg and sigscr.dat files.For example he has a dwarf signal with a speed of 15 mph called PLDwarf and shows up in the object select window as PLDwarf. If another dwarf was desired with no speed restriction you would add another signal type to the scripts and call it, maybe PLDwarfNospeed or something like that. It would use the same shape file but would be defined in the scripts without speed limits.The signal scripts Hank sent me are VERY complex and I know it took a lot of work to build them so I'm not going to impose on him to fix something that ain't broke.
Do you REALLY need the Sim to tell you what the signal speed is?
Would it not be better to learn the aspects like a real engineer is required to do? On the Northeast Corridor version 4 when you get a restricting aspect you will be expected to hold that restrictive speed until your train clears the interlocking. This is prototypical railroading.
True, the Sim wont ding you if you exceed signal speed but watch out!!! The man may be lurking behind those bushes with a radar gun.

Regards,
Vince Cockeram
NEC Track Team
http://hometown.aol.com/nectrackteam/main.html
E-Mail me at vcockeram@lvcm.com

Alert | IP

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

LAST EDITED ON Dec-29-02 AT 00:10 AM (EST)

Bob,You wrote:There are, however, a couple of cases where the signal shows a speed limit that does continue in effect once the back end is clear of the switch. Those are sidings and yard entrances where the speed limit goes to 20 or 15 mph and stays there if you take the switch. For those, I set a speed limit via the signal and it works fine.I had thought of using your method but instead have placed speedposts at all siding entrances and exits. This allows use of same type signals throughout the route and the player will still be held to speed limits in yards and sidings.Matter of fact I just now finished signaling a long industry/passing siding near the Ragan Interlocking in Delaware.
At the point end of the switches at either end of the siding the player gets a restricted aspect if the switch is set for diverge into the siding BUT NO signal speed limit. There is a speed post at the siding entrance set for 15 mph. So the player MUST proceed at restricted speed on the siding or he gets dinged by a TRACK speed limit violation. At the siding exit there is a dwarf showing restricted speed but again, NO Signal Speed Limit. NORAC rules state the engineer must hold this restricted speed until clear, in this case, of the siding switch. As soon as the players engine passes onto the main there is another speedpost ALLOWING track speed but the player is SUPPOSED to hold restricted speed until the rear of his train clears the siding switch.So on the NECv4 you are trusted to obey signal speed rules and BUSTED if you break track speed rules.

Regards,
Vince Cockeram
NEC Track Team
http://hometown.aol.com/nectrackteam/main.html
E-Mail me at vcockeram@lvcm.com

Alert | IP

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

Vince,Thanks for the reply. I said I didn't know very much about how the sim signals work. I agree with you it's far better to know the speed restrictions on the route you are on. I only wondered if it was possible to do something like that if you wanted to show the correct restricted speed at the different turnout types. Personally I think it's better to show the correct signal aspect without the speed.I wait with anticipation for the NECv4 to be released.Eric

Alert | IP

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

LAST EDITED ON Dec-29-02 AT 09:19 PM (EST)

I'd like to thank eveyone on this thread. I have increased my knowledge of signals 600% (at least!) just from following it. Although I wouldn't wish these problems on anyone, it sure is nice to look at all the information being exchanged to address one when it crops up. Thank again!!Brad "A smart dog can hunt anywhere, given he keeps his nose to the wind" Meyer

Alert | IP

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

Brad, this is nothing. You should have seen some some of the discussions when we were trying to figure out how the stuff worked in the first place!There are still one or two parameters that we know of that are legal in the signal files but where we have no idea what they do!Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

>Brad, this is nothing. You should have seen some some of
>the discussions when we were trying to figure out how the
>stuff worked in the first place! I can well imagine! I haven't go far enough along on route building to even thing about signalling (yet!).>There are still one or two parameters that we know of that
>are legal in the signal files but where we have no idea what
>they do!It seems to me the same could be said for almost any aspect of the discipline. I don't yet think there is a full understanding of all the parameters in the eng/wag files, for instance. Signals, though, strike me as being especially obscure. I know nuke-ing it out is supposed to be part of the charm, but I guess I wish signal God could have been able to put his whole effort into design and not had to have diverted some of it to figuring out what the Hades MS was trying to do.Brad Meyer

Alert | IP

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

Hi again,as requested, some more info on the problems I had with the signal-types.
The crash occurs when I have more than 20 signal-types defined in the sigcfg.dat. All types are used in one or more signal-shapes, but they were not placed in the route (in fact, as it was an experiment, the route only contained two signal-types!). It did not matter what the 21st signal was, so it can not have been an error in the file. This was my first guess as well, but it made no difference as to which signal-type I removed!
As mentioned, the crash occurs when exiting MSTS. It always occurs when working in 'Explorer' mode, but is less consistent when running an activity. Perhaps it has something to do with available memory?As for changing signal-attributes when signals are already placed: this can indeed be a little tricky. I found, however, that if you ADD a signalsubobj (and thus leave existing items in their place), there is no problem. And, obviously, you should back-up the signal-files before even opening them!
Anyway, changing sigcfg.dat or sigscr.dat is always tricky. Error reporting is minimal, and finding out why something does not work (or, sometimes, why something DOES work) takes a lot of time and effort. But, I must admit, the scripts offer a great number of possibilities!As for Hank's remark on the signal-type : I agree that a signal must be of type SIGFN_NORMAL in order to affect the running of a train. Confusion was caused by the use of the term 'Shunt Signal': I referred to a signal used to indicate shunt routes (as, for instance, the search-light dwarf signal), as in real life. This is usually defined as a SIGFN_NORMAL in MSTS. I did not mean an MSTS SIGFN_SHUNT signal.Thanks all for your reaction, Rob Roeterdink

Alert | IP

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

Rob>consistent when running an activity. Perhaps it has
>something to do with available memory?
I've consistantly maintained the 8 out 10 sim crashes is a memory allocation problem. Crash on a save and you're dead.>As for changing signal-attributes when signals are already
>placed: this can indeed be a little tricky. I found,
>however, that if you ADD a signalsubobj (and thus leave
>existing items in their place), there is no problem. And,
>obviously, you should back-up the signal-files before even
>opening them!
>Anyway, changing sigcfg.dat or sigscr.dat is always tricky.
>Error reporting is minimal, and finding out why something
>does not work (or, sometimes, why something DOES work) takes
>a lot of time and effort. But, I must admit, the scripts
>offer a great number of possibilities! I totally agree with this. These subobjects are entered into the worldfile and DAT files as individual items WITH INDEX numbers. If one gets out of place or fails to save, the file goes corrupt. Rebuilding the DB may fix it, but most times doesn't. At the very best, you have to reset the links. I haven't been able to figure out what makes the difference other than luck. If the 'bad' signal was the last one placed, you may succeed. Anywhere else and everything falls out of sequence. Kiss goodbye to the interactive objects because you're going to have to strip them out. You can alter the sigscr file with signals in place if you're careful not to add or delete SIGASP tokens or USERx tokens in signal head script block.If you come to the conclusion you have to edit the sigcfg file with signals in place, rename copies of the S/SD files of the signal you want to edit and build a new SignalShape item.Hank

Alert | IP

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

Hank....... "Kiss goodbye to Interactive Objects" brings back such horrible memories. You are absolutely correct of course... you know this signaling sys. backwards and forewards. One additional question, does the number or shapes used on a route cause problems or only the aspect designations? I use a combination of your Searchlight (Erie RR route), CLV and LQ Semaphores (NYO&W) and experience no problems. Keep up the great work and Happy New Year.
Joe Cooney, Ocala,FL; Middletown, NY

Alert | IP

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

Hi, JoeWe need more work on that '20' number for SignalTypes discussed here. The members of the SignalTypes block are actually the definitions for each signal head. I've run with more than 20 with out the catastrophy mentioned. But, of course, that doesn't mean it can't. I guess I have to find a way to be more economic in head use.I've combined over 4 different signal styles in one set of sig files.But for the adventuresome , while there can be only one sigcfg file per route, you can have more than 1 sigscr file. For testing purposes and keeping sometimes nightmarish script organized, I may run 3 or 4 sigscr's per route.This can be done by referencing the added sigscr files in the last block of the sigcfg file per this example:This is the normal line-ScriptFiles (
ScriptFile ( sigscr.dat )
)Modified for more scripts-ScriptFiles (
ScriptFile ( sigscr.dat )
ScriptFile ( sigscr_SL.dat )
ScriptFile ( sigscr_CPL.dat )
)Another nutty obsevation here is that no index is needed. All other blocks in the sigcfg do and it better be right(except the SignalAspects index doesn't seem to matter).Hank

Alert | IP

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

Vince, yes that will work, provided you can get the speed limit post to only apply to the siding track and not to the adjacent mains. But I don't think it is prototypical. At least, not in the west.Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

Bob, it's quite easy to do this.First, I establish a Rule: Maximum speed on sidings and yards on this route are 15 mph.OK, now that the Rule is stated (published?) I enforce it with a speedpost that only affects the sidings/yards. It can be visible or it can be buried, no matter, it's only there to enforce the Rule Book and it is placed so it will only affect the siding track.
Siding and yard exits will have a speedpost that resets the player speed limit back to whatever the local track speed is. A signal at a yard exit will indicate an approiate aspect (without a speed limit) telling the player he must maintain a certain speed until his train clears the yard (or siding). This is not enforced but the player will know if he breaks the rules regarding signal speeds.

The player will know that siding/yards have a speed limit before ever running the route if he/she reads the rules.
The speedposts are just a not so gentle reminder.

Regards,
Vince Cockeram
NEC Track Team
http://hometown.aol.com/nectrackteam/main.html
E-Mail me at vcockeram@lvcm.com

Alert | IP

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

I tried something like that on MP in the Whitefish area. It bugged me that, when you start an activity in the yard, it shows a current speed limit as the maximum allowed on the route...most of the time. I played around, buried some speed posts, but couldn't get it quite to where I wanted it.What I REALLY want is for MSTS to allow an option in the speed limit properties that disables the multiple track default and would let you assign speed limits one track at a time. Then you could easily handle things like this, bury the post and everything would work just the way you want it In my dreams!Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

Hi Bob,to have the speed-limit in a yard set to the restricted speed when starting an activity in that yard, I think you have to set a speed-sign at the end (or better said, beginning) of every dead-end track (or at least the track where the activity starts).
This sign must be directed to apply to 'inward' trains. Ever tried this?Good luck, Rob Roeterdink

Alert | IP

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

Rob,This is exactly what I have done in every yard and siding. Speedpost placed at every buffer AND at the entrance/exit of a restricted speed area.

Regards,
Vince Cockeram
NEC Track Team
http://hometown.aol.com/nectrackteam/main.html
E-Mail me at vcockeram@lvcm.com

Alert | IP

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

Not exactly. I've tried it at the yard throat. My results in doing that were inconsistent...some tracks were at 20, which was the speed limit on the mains, some were at the default. I didn't look into it very far, just decided it wasn't something I was going to worry about just then, especially because of the overlap on adjacent tracks.Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

For Bob or Hank,Are the searchlight and colorlight scripts compatable with each other? I ask because I have searchlight and CLV and CLR signals on my route (complain to UP not me) and all I get now are red lights anywhere and everywhere once I move from a block with one signal type to another. All I did was concatentate the scripts and delete the redundancies so the scripts were "technically" OK if not logically OK. The scripts themselves are still magic to me.Also, did one of you guys say you were thinking about producing a hooded version of the CLV signals? That's all UP seems to be using so if they're in the works cool.ThanksRichard

Alert | IP

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

I haven't produced a set of scripts that would allow for both types to work together, and I don't think Hank has either, although we've talked about it. As you found, you can have both types in the same config and script files and they will coexist, but they may not work together.Bob Siederer
Co-author of Marias Pass 3.1

Alert | IP

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

Argh,Guess I'm gonna to dig into these scripts more then. ThanksRichard

Alert | IP

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