Сигнализация: конфигурация и скрипты

[roman5]

Сообщение от Belka777

У этой сигнализации есть определенная логика как должны работать светофоры. Если не правильно что-то делаете получите такие баги

А можете рассказать более подробно про логику. А что именно неправильно делаю: игрок старт с Демитрова до Бубяково, встречный трафик стартует с Костино до Иванцево. По Драчеево после прибытия встречного всем красный. Где ошибка то, что не учел интересно ведь.

Добавлено через 2 минуты

Сообщение от КЕ

Похоже, там сигналку переустанавливать надо. Пересбор БД пути как проходит, ошибки есть?

Это мне вопрос ? У меня в мстс редакторе БМО 1.8 не хочет открывать почему-то - сбой ПС пишет ошибку. Поставил на чистую МСТС этот маршрут - открывается в редакторе.

[vicente]

Сообщение от 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 - не помню: на каком форуме и в какой теме было обсуждение.

[roman5]

Сообщение от vicente

вообще все станут на запрещающие.

Именно это и просходит, создал тест-сцену: 2 сервиса: Дмитров-Иванцево и Иванцево-Дмитров. По всем станциям разные пути приема, старт одновременно. По Костино оба на путях станции под запрещающие. Попытка загнать невидимку с Иванцево в Костино для подавления маршрутов обоих - еще хуже, попутный не отправляют из Иванцево. Про SignalNumClearAhead знаю, на 1.8 он равен 10 посмотрел.

Добавлено через 25 минут

Сообщение от vicente

стартовать у выходного в противоположном направлении и установить точку разворота в пределах пути станции

То есть за выходным стартовать на встречу игроку, там же реверс без выезда за выходной. Но в таком случае стрелка не будет занята, у Игоря в советах написано, что надо подавляющий сервис делать, чтобы стрелка не по маршруту игроку была.

Сообщение от vicente

светофор после точки разворота не будет "включен" в игру

Как не будет, за ним появился сервис-невидимка ведь.