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

[КЕ]

То есть сим при подсчете светофоров твои маневровые пропускает, но работают они по обычному скрипту?

Добавлено через 20 минут
Нигде не встречал - когда в конфиге указывается число SNCA - учитываем значность сигнализации (3-значная, 4-значная), или это неважно?

[vicente]

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

То есть сим при подсчете светофоров твои маневровые пропускает, но работают они по обычному скрипту?

Именно. Можно, в принципе, сделать отдельный предвходной с большим SNCA, но его точно нужно расчитывать. Потому что "базовая" или "маленькая" станция - это входной, один маневровый перед стрелками и дальше - выходной. Но, у меня есть станции, где между входным и выходным или маршрутным - 4 маневровых. Здесь так просто не отделаться. Для унификации -1 -- самое то.
Есть разные способы. Один из разработчиков на буржуйском форуме писал, что у него все сигналы АБ с -1. То есть, он с выходого "энэйблит" сразу входной следующей станции независимо от количества блок-участков. Мне такой способ неприемлем, ИМХО, для трёхзначки достаточно 3, для 4-х - 4. И то - "с запасом" - из-за этого самого моего первого проходного с 2, когда он !enabled для маневрового на выходном.

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

Нигде не встречал - когда в конфиге указывается число SNCA - учитываем значность сигнализации (3-значная, 4-значная), или это неважно?

В принципе, достаточно и на один меньше, но и так можно. Получается с небольшим запасом - то что надо.
Действительно: скажем - 3-х-значная. Сервис движется, его светофор зелёный, за ним нам нужно 2 сигнала. Первый по ходу будет зелёный, за ним - жёлтый, за ним уже !enabled.

[КЕ]

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

...Один из разработчиков на буржуйском форуме писал, что у него все сигналы АБ с -1. То есть, он с выходого "энэйблит" сразу входной следующей станции независимо от количества блок-участков.

Вот если бы это было в МСТС - победили бы "вечный красный" в сценариях.

[vicente]

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

Вот если бы это было в МСТС - победили бы "вечный красный" в сценариях.

Пока что, уже долгое время, "конфликтные" ситуации, которые у меня время от времени возникают, не связаны с самим симулятором. Разработчики Open Rails очень рьяно работают над исключением ситуации, когда два поезда в противоположных направлениях на одном маршруте не станут друг проив друга на "вечный красный". Например, совсем недавно я по ошибке задал пригородным один и тот же PATH. Разными были только путь приёма и путь отправления на станции, на которой стартовал (хронологически) второй сервис. Так вот, этот "второй" стоял пол-часа и ждал первого. Несмотря на расстояние в почти 30 километров, три станции и с два десятка блок-участков между ними. То есть, блокировки работают по "узлам" (стрелкам, то бишь) пути сервиса - PATH.
С другой стороны, светофоры несомненно учитываются! Поэтому, если скрипт светофора позволяет пропуск на участок, на котором в противоположном направлении другой сервис - бон-войяж. Вчера бился с этой ситуацией на маневровом у себя. На станции в 5 путей из-за того, что режим Timetable Mode и мне не хотелось "прерывать" сервис, при смене локомотива у трафика оба локомотива должны двигаться в противоположных направленияз по одному пути станции. Маневровый сигнал открывает белый на занятый путь, вернее, на "не свободный" поэтому что "несвободность" в Open Rails, как и в MSTS, бывает двух типов: BLOCK_OCCUPIED и BLOCK_JN_OBSTRUCTED. В наших сигнализациях мы привыкли не уточнять эту "незанятость" определением отрицания свободности (block_state() !=# BLOCK_CLEAR). Так оно и определено у меня в скрипте маневрового. И отцепленный лок по белому заходил на путь, по которому на встречу ему двигался сменный.
Справедливости ради, следует отметить, что на тот момент, когда я разрабатывал сигнализацию, этого различия между BLOCK_OCCUPIED и BLOCK_JN_OBSTRUCTED в Open Rails не было. В смысле, не было вообще такого параметра BLOCK_OCCUPIED у функции block_state(). Программа сигнализации в Open Rails писалась "с нуля", так как разработчик не верил в Кужувскую сигнализацию и утверждает, что не было никакой документации на неё (мы знаем, что это не так и все функции расписаны кужувцами в своё время в отдельном документе, не все, правда, работают, но это - другая тема) и в первые годы функция так и работала "да"-"нет". Более того, определение BLOCK_OCCUPIED просто не читалось. С обновлением логики это определение ввели - надо было решать проблему со следованием сервисов, включая трафики на занятые пути, тем не менее, всё, что работало до сих пор, работает и поныне - светофор, который !enabled выдаёт BLOCK_JN_OBSTRUCTED независимо от состояния блока за ним.
Этих тонкостей мы не прочувствовали из-за формы определения зависимости свободности трека block_state() !=# BLOCK_CLEAR, при которой всё, что не BLOCK_CLEAR "подпадает" под определение FALSE. Но, на данный момент, есть большая разница между BLOCK_OCCUPIED и BLOCK_JN_OBSTRUCTED - работа этих параметров приведена, можно так выразиться, в соответствием с документацией самого MSTS:
BLOCK_OCCUPIED - сервис, стоящий неподвижно либо движущийся в том же направлении, что и сервис, для которого "проверяется" светофор.
BLOCK_JN_OBSTRUCTED - положение стрелок не по PATH, то есть сервис не может перевести себе стрелку из-за того, что она заблокирована другим сервисом, а также в случае если в противоположном направлении по тому же PATH движется другой сервис