Цитата:
Сообщение от КЕ
Вот если бы это было в МСТС - победили бы "вечный красный" в сценариях.
|
Пока что, уже долгое время, "конфликтные" ситуации, которые у меня время от времени возникают, не связаны с самим симулятором. Разработчики 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 движется другой сервис