Цитата:
Сообщение от roman5
А что именно неправильно делаю...
|
Дело в том, что в симуляторе нет (и не может быть) диспетчера. Понятие "автодиспетчер" в Мануале - тоже не более, чем метафора. Под этим термином разработчики подразумевали некий комплекс совокупностей по которым движущиеся по "дорожкам" поезда получали приоритеты в движении по секциям пути. Человеческим языком, каждый поезд "пытается прокладывать себе путь" сам. Поезд который запрашивает себе узел (то есть стрелку) первым - очевидно "получит" его. И никакой другой поезд не будет допущен к проследованию этого узла, пока поезд зарезервировавший его, не освободит узел. Причём симулятор понятия не имеет: где станция, а где перегон. Он работает с секциями пути и узлами. Это называется
блокировкой (Deadlock).Теоретически, светофоры могут и не останавливать сервис перед заблокированным узлом. Я когда-то игрался с сигналкой и убрал запрещающий аспект со светофора. Узел в том случае всё равно остаётся заблокированным, а поезд останавливается перед Track Pin стрелки. Кстати, с этим многие сталкивались в Open Rails выше версии 137х на наших сигнализациях, когда наш запрещающий аспект перестал быть запрещающим.
Далее. Сигнализация.
В какой момент поезд "запрашивает " узел для себя. Оказывается, это напрямую зависит от параметра
SignalNumClearAhead в файле
sigcfg.dat . Узел блокируется для поезда, когда тот находится на расстоянии
SignalNumClearAhead+1 светофор от светофора, ограждающего этот узел. Любой другой сервис, приближающийся к этому же узлу, в момент, когда он будет на том же расстоянии, будет учтён программой и "поставлен в очередь" на проследование этого узла.
Где зарыта собака?
Если кто помнит дефолтные сценарии, во многих из них при появлении игрока, игрок сразу же видел какой-то встречный трафик. Так вот, эти трафики
не имели общих точек с путём игрока. Остальные трафики, особенно имевшие с игроком общие точки ("скрещения") стартуют задолго до встречи с игроком.
SignalNumClearAhead в MSTS , не знаю насчёт дефолта, но в пропатченых это точно есть, имеет баг - сколько не прописывай разных в сигнализации - в игре он один и равняется наибольшему значению, прописанному в sigcfg.dat файле. То есть, если в конфигурации всех светофоров, кроме одного он прописан 3, а в этом последнем - 20, симулятор будет резервировать узлы для сервиса когда он за 21 (!) светофор до узла!
Что происходит, если стартовать сервис (поезд) в пределах уже зарезервированного маршрута другого сервиса? На trainsim.com дают на это вполне определённый ответ: поведение обоих сервисов в этом случае
непредсказуемо. Игорь Заборин на своём сайте очень давно написал статью о яалении, которое назвал "поезд-призрак". Мне это определение нравится, как по мне - оно довольно точно описывает ситуацию. Программа всё равно будет пытаться "разрулить" создавшееся положение. Но тогда счет может идти на секунды в сценарии. То есть, скажем в 9:11:27 приоритет получит игрок, а если он приедет раньше, скажем в 9:11:02 - трафик, или вообще все станут на запрещающие.
Понятно желание сэкономить на ресурсах. Но, представим себе ситуацию, когда поезд находится, например, за пять блок-участков до станции. Потому как SignalNumClearAhead огромен, выходные стрелки уже зарезервированы для него, возможно, что и светофор уже открыт... И тут на перегоне за выходным сценарист стартует какую-нибудь невидимку. Что происходит? Светофор, конечно, перекрывается, так как блок занят теперь, а узел остался зарезервирован... ммм... короче, веселуха.
Какое может быть решение, кроме старта в крайних точках маршрута? Я давно не играю в MSTS , и то, что я делал на своём маршруте тогда - точки старта в строго определённом местах и установка в этих местах нескольких светофоров подряд, то есть разделение на маленькие блоки - не вариант на официальных маршрутах. Но, я бы порекомендовал стартовать на станционных путях с реверсом. То есть развернуть состав, стартовать у выходного в противоположном направлении и установить точку разворота в пределах пути станции. Таким образом, светофор после точки разворота не будет "включен" в игру, а после смены направления Deadlock не должен ломаться. Кстати, такой старт в своё время, был опробован мной именно на сигнализации APK_LVDZ - не помню: на каком форуме и в какой теме было обсуждение.