Mixed Signals

[Approach_Medium]

Hi;
I've been playing Trainz since TS2004, and have been working with signals since 2006, then 2009 and finally 2010 (sp2). I have found a very annoying problem with the way Trainz handles signaling at multiple junctions.

I set up a test route and tried a couple different US signal types, but always get the same results.
I tried this setup with the USA 02 signals, as well as the Safetran 06 right-diverging at junction 0, and a left-diverging at the distant end of the siding.
There was no difference in the indication between the two types of signals (the USA 02, non-scripted or the Safetran, scripted).

Here are three screen shots that will help to illustrate what I am talking about.

1. Junctions are lined for train to proceed on main track.
Signal indication is correct

2. Junctions are lined for "in and out" of siding. Train will proceed into siding, then out again without stopping.
Note that junction 4, the spur is lined to left (non-diverging) position.

In this situation, the signal should indicate RED on top, and GREEN or flashing GREEN on the bottom. This would indicate that the train is to take the diverging route at a speed slower than normal speed for the main line.
But instead, the signal is the same as it was for the main line route.

3. Junction 0 and junction 4 are both set to diverging.
The next signal (on the spur) is red.
The signal now indicates correctly, showing the top aspect RED and the bottom YELLOW for the approach on the diverging route.

What is happening is that the signals in Trainz read only the position of the last (furthest from signal) junction when displaying an indication.

The same thing happens if the USA 01 signal is used. The only difference is that the 01 has three heads instead of two. The bottom head remained red for all positions of the junctions in my test.

What we need is a method to program the signals, using the properties of the signal, or to allow junctions to be set to "ignore" where they will be ignored for signal indications.
The ignore rule would be useful for unsignaled turnouts at industries, etc.

I understand that USA signals are not intended to indicate route, but they should certainly indicate reduced speed through turnouts. In the current scenario, they do not.
This is because of an issue with Trainz itself, not the creator of the signal.

I know I'm not the only one who has had this issue, and won't be the last.
Does anyone have a work-around?
Do you think Auran will listen if I post this in Suggestion Boxcar?

One note: I have done some beta testing for Norfolksouthern37 on a new version of Safetran "08 interlocking" signals. I don't know if he has released this new version yet, but it appears to solve this junction issue by allowing you to set the conditions for the junctions using properties of the signal in Surveyor.

FW

 

[JCitron]

I surely hope this issue gets resolved at some point. The signalling is better than it was in earlier versions, but it's not there yet. The ability to program signals would be very helpful.

John

 

[Approach_Medium]

I surely hope this issue gets resolved at some point. The signalling is better than it was in earlier versions, but it's not there yet. The ability to program signals would be very helpful.

John

If I knew more about Trainz Scripting language, and how Trainz works with signals, I would create a little controller for signals, similar to the Junction Controller by mizi <kuid:122381:10005>
It's a nice little gadget that works extremely well.. just make sure you save the sessions with the routes...

FW

 

[JCitron]

If I knew more about Trainz Scripting language, and how Trainz works with signals, I would create a little controller for signals, similar to the Junction Controller by mizi <kuid:122381:10005>
It's a nice little gadget that works extremely well.. just make sure you save the sessions with the routes...

FW

I'm not much better with the scripting. I can fix hardware any day, but programming never stuck even way back when I was a lot younger.

It's too bad this type of information can't be saved with the route instead of the sessions, unless of course TS2010 works a little differently. I haven't done a lot of session setup with TS2010 - I've been Surveying a lot instead lately.

John

 

[DaveW]

Hi fwassner

If you place a signal just before junction 4, this should solve your problem.
If this does not look prototypical then use a invisible signal.
Hope this helps,

DaveW

 

[norfolksouthern37]

not to keep saying this without actually showing or sharing the results, but i have fixed this, and you helped. i just never added the code to those types of signals until recently. the other thing that holds me back from releasing those signals is that they do not save the configuration information to the route files, but rather to the sessions. so when you set the signal programming in the properties it only saves that data in the session. to me this is pretty close to a deal breaker.

 

[Approach_Medium]

not to keep saying this without actually showing or sharing the results, but i have fixed this, and you helped. i just never added the code to those types of signals until recently. the other thing that holds me back from releasing those signals is that they do not save the configuration information to the route files, but rather to the sessions. so when you set the signal programming in the properties it only saves that data in the session. to me this is pretty close to a deal breaker.

Hi Justin;
I have always thought of this as a Trainz problem, not a cc problem. The fact that your signals do function properly is to your credit, and I appreciate that, and being a part of that development.

The fact that config info is saved to session rather than route is a problem for a lot of cc's. I have several times lost setup for the Mizi Junction controller, and Boat's ATLAS system.
I have gotten around that problem by always working in sessions, and now, even merging session layer with route layer regularly in TS2010. I don't know whether merging the layers will preserve config info, but I'll do some experimentation to find out.

FW

Edit: Tried merging session layer with route layer before saving in TS2010 (SP2). No difference. The config info is still in the session, not the route. Someone at Auran listening?

 

[Approach_Medium]

Hi fwassner

If you place a signal just before junction 4, this should solve your problem.
If this does not look prototypical then use a invisible signal.
Hope this helps,

DaveW

Actually, that will not work. Reason being that the signal at junction 00 will then read one aspect less restrictive than it should when there is a train on the passing track, allowing another train to enter with an approach signal.

FW

 

[norfolksouthern37]

well, i guess if they do not bother people as much as they bother me for doing that... release should be soon.

in your situation mentioned above, you will get this:

 

[Approach_Medium]

This situation also exists when there is a switch (junction) facing against the direction of the signal. Even though the points are facing in the "wrong" direction, it counts as a diverging junction for the signal.

FW

 

[strench707]

Those signals would work fine for me! I like how you also added the aspect when you hover over it! Great addition I must say! Is there any way by chance you could make a signal with a lunar lens for displaying a restricting aspect which i guess you could code in as Trainz's stop and proceed.

Here is a good pic:

Your two cents Justin on if that could work?

Davis

 

[norfolksouthern37]

the three head signal already has the restricting aspect programmed into it as an option in its settings. i have no promises whether there will be one like your image but maybe sometime in the future.

oh, and the restricting aspect on my signals actually works. it will allow more than one train into the block if there is a certain distance to the next train and if it is traveling away from the signal (they dont allow head ons!). the aspect also limits the speed to 15 mph. the AI obeys it as well.

 

[Lots_Trains]

NS37

They these are really nice signals, however the one problem I have is that with the yellow flashing yellow you get on the signal you get before you get to a full yellow, causes the train to slow to half speed, this is not the way I see them operate, Having a train travel for 2 blocks at half speed is just not right.

This a bug in the signalling system in my opinion but the powers at be will not fix. Is there anyway around this

Cheers

Lots

 

[norfolksouthern37]

it could be masked as another hard coded aspect i suppose, all of my 'imposed' aspects are done this way, in order for the AI to understand what the signal is 'saying'. i will further consider this as it would require the signals to have even more code in the script when the real fix as you said would be for auran to fix the original aspect.

in my tests i have only noticed that the AI will slow to an advance caution until the lead traincar passes it, then it returns to track speed. i do not recall anything in previous versions on this, but these new signals are too advanced to be used in anything below TS09.

 

[Lots_Trains]

NS37

When 09 was 1st been developed the yellows were perfect, trains did not slow to half speed, however when 09 SP2 came along that was re introduced, and Auran have stated on the Train Dev site that it has to stay like that as it would break all the sessions so guess we have to live with it.

However what you say about the train slowing to half speed then resuming normal speed is a bug they have not fixed yet

Hope you can do something it really detracts from the game. Again superb signals and Gantries

Cheers

Lots

 

[Approach_Medium]

IMO, Auran is way behind in fixing bugs with signaling. C'mon Auran; We've been through enough SP's and version releases that this should be fixed.
If you don't want to "break" older sessions by changing signaling code, then why not provide the player with an option to turn on advanced AI signal capability?

The ball is really in Auran's court. If something doesn't change drastically between now and the next full version release of Trainz, I've finished upgrading and will remain with TS2010 until someone else comes out with a better product.

I am sorry to rant here, but it is frustrating to be playing a game that is still running on code that was written 6 years ago. It must be even more frustrating for CC's.

FW

 

[jkinzel]

First I would like to thank Justin for all his work to create these fine signals, they are amazing to say the least.

I live in Washington State and I'm only familiar with the signal system on the BNSF/UP joint tracks and I know that on the mainlines when there is no traffic the signals go dark, i.e. no lights. The question I have, and I assume it be true, is: In other areas of the US, when there is no traffic, do the signals go dark? This seems to be case for "most" mainline signals in CTC areas, yard and interlocking signals seem to stay lit regardless of traffic volume.

While the "going dark" characteristic might be prototypical, it might not be desirable for Trainz.

 

[norfolksouthern37]

at this time there is a approach lit option for intermediate signals only. they do not activate until a train is getting near them and deactivate when a train is a few blocks past them.

 

[RRSignal]

That's called "approach lighting" and, as you noted, it's used on all but the busiest lines. Offhand, the NEC is the only U.S. route that does not use it on automatic signals, and in many places, interlocking signals are approach lit as well, depending on how busy they are.

 

[Approach_Medium]

at this time there is a 'dark' option for intermediate signals only. they do not activate until a train is getting near them and deactivate when a train is a few blocks past them.

Which are the "intermediate" signals? I have been using the Safetran Clight 05 as intermediate, but where is the option to set the signal to dark?

FW