Продолжаю.
Open Rails мы отбрасываем - не в этой жизни (хотя, я слышал, что Алексей разрабатывает сигнализацию для современных версий), сосредоточимся на MSTS. К сожалению, хостинг картинок, которым мы пользовались десять лет назад, приказал долго жить и форум Игоря Заборина вряд ли читаем без тех скринов и схем, что мы тогда чертили, поэтому придется объяснять "на пальцах" (нет у меня сил делать всё это заново). Мы "сношались" тогда только с сигнализацией MSTS . Так вот, в конфигурации каждой сигнальной головы (а их в светофоре может быть прописано несколько - линки, декоративные невидимые и т.д.) есть параметр SignalNumClearAhead. Не буду вдаваться в подробности: как и что, но опытным путём мы пришли к тому, что светофор, ограждающий узел, на котором срабатывает блокировка (Deadlock), "агрится", когда сервис занимает перегон за SignalNumClearAhead + 1 светофоров до него. Только в этом случае симулятор не "слетит с катушек" и сделает всё поавильно.
Как это применять? Нужно следить, чтобы никогда на расстоянии менее указанного к точке, на которой происходят какие-либо операции, включающие Deadlock, "из ниоткуда" не возникал сервис. Ни с одной из сторон, сколько бы их не было.
Добавлено через 25 минут
Вышесказанное касается также невидимок.
Я дико извиняюсь за кросспостинг,но уже закончу мысль, чтобы никогда больше к этому не возвращаться.
[С телефона оформлять длинные посты очень тяжело]
Проблема с SignalNumClearAhead заключается в том, что MSTS имеет баг именно по этому параметру. А именно, несмотря на то, что он (параметр) задаётся отдельно каждой сигнальной голове, в сценариях есть только один SignalNumClearAhead - наибольший из всех в конфигурации. Учитываются ли при этом другие типы сигналов, отличные от NORMAL, я никогда не проверял. Эта информация, думаю есть на "Стиме", британском "трэйнсиме" или на "trainsim.com". Думаю, что да. Что мы имеем тогда? Если не ошибаюсь, у Тимаса Адамайтиса он равен 4-м, у Славы Усова - 10-ти, а у Кости Елисеева, кажется даже 20-ти (сколько я его не увещевал... ха-ха).
|