How can I make signals from different users communicate with each other?

[janathan]

(I apologize for this wall of text)
For context, here's a video of me testing the signals (skip to around 38:00): (https://www.youtube.com/watch?v=raBggAu15LA)
I'm making a large route that's a replica of Amtrak between New York and Philadelphia and NJ Transit from Hoboken to Avenel and from Cranford to Hoboken. (I might extend the NJ Transit routes later.) My problem is this route uses lots of different kinds of signals from different users and sometimes, they can't communicate with each other when one displays a "complicated" aspect. For example, when testing the signals at Hunter Interlocking, where NJ Transit switches off of Conrail's Lehigh Line, then enters a temporary siding, where it waits for Amtrak to give it access towards Newark Penn Station, I encountered a problem with the last G-style signal right before the NEC-style signal. The NEC-style signal at the entrance to the siding, made by rrsignal would display medium-approach, but the G-style signal right before it, made by ryanstrains would display a strange aspect with two reds over a dark. When hovering the mouse over it in driver, it said, "the state of the next signal is unknown. Unfortunately, the A.I. treats these signals like a stop signal, and won't go through them when this happens. I managed to "fix" this problem by putting a more "simply-scripted" invisible signal, i.e. one that just uses the game's built-in scripting in-between the G-style signal and the NEC-style signal. The problem with this is, it causes the G-style signal to display a "simple" aspect, that wouldn't be prototypical for that scenario. When riding in the cab car of NJ Transit trains, I've noticed they normally get medium-speed indications when going over an interlocking, but the invisible signal displays "approach," which causes the G-style signal to display "clear," which isn't very prototypical when using an interlocking. This issue is also why I can't use the signal offset <kuid2:45324:24900:5> in front of NEC-style signals, so the A.I. trains would stop at a prototypical distance instead of unrealistically crowding the signal, which, just why?. In testing, the A.I. would sometimes stop at the signal offset, even when the NEC-style signal changes because of the "the state of the next signal is unknown" glitch. The signal offset seems to work pretty well with ryanstrains's signals, but not too well with rrsignal's signals. Is there a way to make these signals communicate?

 

[justinroth]

Different scripts always don't communicate well with each other, there is no "standard" signal scripting and I'm not sure why at this point. Given that there are many different signal rules across the world the general basic aspects could or should be a function. As someone who has made many signals and focuses on signalling this has been an issue for me. I am currently making a few different signals, at the moment US&S R2 signals. I don't know how to script so I use existing scripts but even then, scripts from the same author don't always work with each other. My work-around is "blending in" or "crossfading" the different scripts. It seems basic aspects like clear, approach and stop will convey between different signal scripts so I use this method to change signal types. This doesn't always work, especially at interlockings and in that case I'll make a signal that uses the script I want but has the meshes of other signals.

 

[janathan]

That's a bit of a shame. They should have a built in attachment-based script, like the one for train cars. It could be set up so the top aspect would have "a.red1" for the red light, "a.yellow1" for the yellow light and "a.green1" for the green light. For the aspect below it, the attachment points could be "a.red2," "a.yellow2" and "a.green2" and so on. Either way, it's quite a shame that the signals can't talk to each other.