another Bin request: Signal waiting cycles

[geepster775]

One thing I wish Bin could address is the instantaneous throwing of the switchpoints for AI traffic after a meet.

Would it be possible to add code for a delay subroutine to the program which would keep the switch from throwing for 5 to 10 seconds after one train clears a switch before the switch throws the other direction and the signal clears for the opposing traffic?

Generally its not all that realistic that an opposing train gets the switch thrown and its signal cleared before the train it is meeting makes it fully past the interlocking.

[geepster775]

Player train in the siding, AI passing on the main. Signal for player train is red.

http://home.earthlink.net/~sd45/scrgrb123.jpg



As the helper loco on the AI train clears the switch, the switch points throw and the signal clears for the player train. Unfortunately, the AI train hasn't even exited the interlocking limits. The switch is moving and signal is clearing TOO SOON. Is there a way Bin could address this, by implementing a delay of some sort?

http://home.earthlink.net/~sd45/scrgrb159.jpg



It would be better to have a 5 to 10 second delay, which would allow the AI train to progress farther before the switch throws and the signal goes green. This looks a bit more realistic.

http://home.earthlink.net/~sd45/scrgrb161.jpg

[Turbo Bill]

A work around it for now would be to take an invisicar and remove the sound section from it and add about ten of them to the rear of that AI. The invisicars would hold the signal red until the visible portion of the train clears the interlocking.

We use invisible engines with preset max speed ratings to control AI's to specific speeds in yards or meets in slow orders, etc in the C&NWvr's activities. What I also use them for is when I have a activity start similating an immediate meet wiht an AI, I'll add as many a as 10 to 20 of the things to the head end of that AI so it starts a ways out and rolls by the player instead of starting right next to the player. I do this to avoid needed RP's in the player's path to cover to go once the AI leaves. Works like a charm.

[roeter]

Hello Geepster775,

there is no need for a change in MSTS-bin to solve this problem.
I ran into a similar problem many moons ago, and posted a threat on the MST Route Desing forum.
It's still there - under no. 59287, called "Clearance Problem".

The problem I had : AI train colliding with my rear wagon which fauled the points, but signal was cleared regardless, would not be solved by a time delay.

The problem, however, can be solved by defining the correct clearance area in the definition of the point in the tsection.dat file.

'Standard' points and switches are not defined correctly.

Regards,

Rob Roeterdink

[OTTODAD]

This may sound like a silly suggestion, but seeing that the player train's path is still blocked by the AI when the signal changes to green, then wait until the AI has cleared the switch !

May not be prototypical but easier than doing a lot of work fixing it in the code or elsewhere ! ;-)

O t t o

[GaryG]

Hi Otto,

Your suggestion works fine for the player but for times you are controlling the moving train and an AI is the stopped one there can be problems.

If your speed is slow, the AI will ram your tail end in its rush to move as soon as the signal is Green. I've had it happen a few times when my speed was 7 MPH or slower on the Tehachapi Pass II route. This was a real problem because that was almost my maximum speed on the grade!

A cure might be to make the switch node look like it's 50M (or so) long in all directions for the signals logic. Another option would be a long, invisible car tacked on the end of the train but definitely not a great fix. If you're expecting to do some switching, that last invisible car is part of the consist and must be handled during the switching, sort of like the 'Fred" car ;-)

GaryG

[geepster775]

To me, both of the suggestions (adding invisicars, or changing the clearance points) are more stop-gap measures.

Invisicars have the downside of adding to the length of consists, which in some cases already are at their max point of tradeoff between realism and FPS stability. Any longer, and FPS nosedives.

Increasing clearance points have the ill effect of requiring the player train to hold way back from signals as well, doesn't it?


What Im looking for is more of a replication of realism, where switches throw and signals change after the rear of the train has already passed the player locos. Sending CTC codes to the field in the real world are not instantaneous, nor do they happen before the rear of an opposing train passes the head end of a train in the siding.

[NS Ed]

Although invisible cars work, if they were on the rear of the player's train, the AI in the siding (if that were the case) would still collide with them if moving too slowly as others have hinted to. Even though you can't see 'em, you can still hit 'em as they are still occupying MSTS space.

You could possibly use a waiting point which now works. The only challenge would be a timing issue since if an AI was in the hole for the players' train, no two people would arrive and clear the switch at the exact same second. But a 60-180 second (or longer if desired) waiting point for the holding train would add a bit more to the realism factor.

Yes, both the signals and switch would change, but at least the train would sit tight for a bit.

[rdamurphy]

Move the signal. Put the "trigger" where you want it to change, then move the mast itself further up the track. They should be done placed that way in the first place. (The "trigger" is the triangle phantom shape that sits on the track.)

Robert

[Turbo Bill]

I wouldn't add the invisicar to the player train but to the AI train to give the desired delay to the signal and switch change. I fyou remove the sound association with the invisicar, they donot use up barely any resources. I find it to be an easier fix then going into every route you have and editing every switch point zone. That would take forever where adding five invisible cars to the rear of your AI's takes about 2 to 4 seconds.

[GaryG]

Hello Robert

I started to try your idea but there appears to be a limitation of how far away the signal can be from the Red trigger. Also, once I started tinkering I realized that method probably wouldn't solve these problems.

I'm pretty sure that the Red "trigger" marks the location you must not pass rather than the point the other train must clear.

What is really needed is to make the entire distance between a set of signals that protect a switch a sort of no-man's land that can't be occupied at any time by a second train. Currently the no-man's land is marked clear as soon as the first train passes the switch node. We need a new "between signals no-man's land" test for the signal logic to test; if the test is false, all signals facing that area must indicate Stop, otherwise the normal signal logic would control the signals.

Another way might be to change all signals protecting a switch so they would show a most-restrictive indication as soon as any of the legs are occupied and to stay at that indication until all the legs are clear again. Once all legs are clear then the normal signal logic test would again control the signals. This might actually be the best way as I can't think of any "normal" way a second train would be allowed in the "no-man's" area between absolute signals protecting switches.

I don't think that even George 'The Miracle Worker' would be able to implement this with the only method that's available to him (legally).

Another problem (in hindsight) is visualize the Red shape for the single track facing a switch with a signal on both tracks. On which of the two tracks would you plant it?

GaryG

[geepster775]

Dispatchers cannot instantaneously throw switches and signals. In reality, it takes a minimum of a minute or so to transmit the desired commands to the field.

What is needed is a solution that is independent of route building techniques, independent of the type of switch or track material used on any given route, and overall is independent of routes being played. I'm looking for one solution which applies to all power "CTC" switches (as classified such by the game during an activity) without having to make unique mods or special placements at each switch to achieve the desired effect.

For realism, the signal should not clear until the rear end of the opposing train has passed the head end of the player train. If the AI train is moving track speed down the main, then its possible that the rear of the AI train could be half a mile of more past the head-end of the player train before the player's signal changes.

And that needs to be the signal delay scenario regardless of whether the player train holds the main or the siding (the solution cannot be "hard coded" for sidings or main tracks only).

The only way I see doing this is for the activity execution part of the code go into a delay loop of some sort before allowing the execution of the code which changes the position of the switch points or signal display.

[buttercup]

It would appear that an alteration in the signal scripts would be ideal. Maybe at some future time George might look at the script variables to see if there are some unfinished or incomplete parts that can be altered to add a timer that can be included in the script to delay the signal change.

Regards,

Eric

[mauried]

>Dispatchers cannot instantaneously throw switches and
>signals. In reality, it takes a minimum of a minute or so to
>transmit the desired commands to the field.
>
>What is needed is a solution that is independent of route
>building techniques, independent of the type of switch or
>track material used on any given route, and overall is
>independent of routes being played. I'm looking for one
>solution which applies to all power "CTC" switches (as
>classified such by the game during an activity) without having
>to make unique mods or special placements at each switch to
>achieve the desired effect.
>
>For realism, the signal should not clear until the rear end of
>the opposing train has passed the head end of the player
>train. If the AI train is moving track speed down the main,
>then its possible that the rear of the AI train could be half
>a mile of more past the head-end of the player train before
>the player's signal changes.
>
>And that needs to be the signal delay scenario regardless of
>whether the player train holds the main or the siding (the
>solution cannot be "hard coded" for sidings or main tracks
>only).
>
>The only way I see doing this is for the activity execution
>part of the code go into a delay loop of some sort before
>allowing the execution of the code which changes the position
>of the switch points or signal display.


Dispatchers certainly can clear signals and points almost instantaenously otherwise events like running crosses could not occur.
It doesnt take minutes to send data to the field, more like a few seconds, but you can send the data long before the events occur.
CTC systems simply take data from the Dispatchers Control Console and send it to the trackside interlocking, which then decides whether its safe to implement the requested change.
So a Dispatcher can set up a meet at a crossing loop long before it happens simply by sending all the commands and then go and have a cup of coffee, and the trackside interlocking will do the rest.
MSTS isnt quite realistic as the signals clear before the opposing train has cleared the switch, but thats only because the MSTS switch model has the wrong clearance , and you can easily fix this.

[rdamurphy]

How do you fix that?

Robert

[OTTODAD]

Reading this thread again and having just added another thread's suggestion to my "To Do" list for George, to have a look at after he has dealt with current tasks, I have added a link to this thread to it as it contains a lot of useful suggestions he could perhaps implement in a future MSTSBin patch ?

I am sure that it will not be easy to synchronize the action of signals so that they will suit both player and AI trains running, but with George you never know ! ;-)

Take care, O t t o.