Показать сообщение отдельно
Старый 24.04.2020, 17:01   #426
vicente
Заблокирован
 
Регистрация: 06.10.2007
Сообщений: 1,764
Вы сказали Спасибо: 899
Поблагодарили 1,214 раз(а) в 730 сообщениях
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 движется другой сервис

Последний раз редактировалось vicente; 24.04.2020 в 17:06.
vicente вне форума   Ответить с цитированием
Старый 01.01.2007, 12:00  
Яndex
Спонсор
 
 
Регистрация: 01.01.2007
Сообщения: 500


Реклама показывается изредка по случайному принципу
По умолчанию РЕКЛАМА