[QUOTE=vicente;593159]Если проверять [B][I]_mr[/I][/B] и перегон свободен - то да.[/QUOTE]
Именно [B][I]_mr[/I][/B]? А [B][I]_lr[/I][/B] не работает?

Обратите внимание, [B]откуда[/B] встречный заблокировал игрока. он сейчас находится на соседней станции и не проследовал выходной там. Короче, с симулятором всё в порядке.. При правильном обращении...

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
[QUOTE=КЕ;593164]Именно [B][I]_mr[/I][/B]? А [B][I]_lr[/I][/B] не работает?[/QUOTE]
Работает. Но, ты же именно наиболее запрещающий хочешь "через перегон" искать, не так ли?

Я или забыл или не понял еще, как этой функцией правильно пользоваться...

Если верхний ловишь - lr, нижний - mr.

Кажется, понимаю - проходные открыты, входной закрыт, вот он по [B][I]_mr[/I][/B] и определится, так?
А в видео второй раз все было правильно - правый путь трафику был альтернативный?

[YOUTUBE="Запоминают... светофорчики :)"]B3yYT1V-RuY[/YOUTUBE]

[size="1"][color="Silver"]Добавлено через 4 минуты[/color][/size]
[QUOTE=КЕ;593169]Кажется, понимаю - проходные открыты, входной закрыт, вот он по [B][I]_mr[/I][/B] и определится, так?[/QUOTE]
Так. Но, это из раздела "спрашивали - отвечаем". Я её юзать не буду. Блокировки работают, я только что об этом писать. Дополнителльную блокировку скриптом ставить смысла не вижу.
[QUOTE=КЕ;593169]А в видео второй раз все было правильно - правый путь трафику был альтернативный?[/QUOTE]
Конечно правильно. Я "диспетчером" встречному один из проходных перекрыл - вот и "было". Я другое хотел показать в том видео.

После прохода сервиса проходные остаются зелеными - не !enabled?
Запоминание не теряется при прокладке маршрута другому сервису?

В смысле - зелёными??? Когда блок занят, они красные, когда следуюший красный и блок свободен - желтые... Скрипт посмотри.
Они [I]!enabled[/I], естественно. В этом-то и фишка :D
Да, по аспектам проходные по возможности к [I]enabled ()[/I] не привязаны.

[size="1"][color="Silver"]Добавлено через 12 минут[/color][/size]
Насчет запоминания. В данном варианте (он промежуточный и будет дорабатываться) "запоминает" [B]входной[/B]. Проходные тупо проверяют переменную входного по [B][I]next_sid_lvar (X)[/I][/B]. Когда там "единица" , они не горят по [I]draw_state[/I] и "помнят" эту "единицу" даже если на входном её уже нет. Перестают они её помнить, когда проходной становится [I]enabled[/I].

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
Из-за того, что SNCA проходных "-1", [I]enabled[/I] они получают все сразу - вне зависимости от того, сколько их.

Ну в общем-то логично.
[QUOTE=vicente;593173]В смысле - зелёными???[/QUOTE]
После желтого, при удалении сервиса.

Ну, так, так и должно быть, нет?
На двухпутных односторонних АБ они у меня тоже к [I]enabled ()[/I] не привязаны. Автоблокировку можно реализовать либо так, либо повесив сигнальный флаг ABS, как в американском дефолтном Marias Pass. Я давно его не вешаю, а просто не привязываю его показания к этой функции. Поэтому и светофоры зеленые. В противоположном направлении они тоже должны были быть зелёными, но я гашу их через зависимость [I]draw_state[/I] "не горит" от переменной, которую цепочка светофоров запомнила когда есть встречное движение.

Как они определяют встречное движение?

Так же, как первый проходной определят его для противостоящего маневрового. Через [B][I]BLOCK_JN_OBSTRUCTED[/I][/B]. Только, на этот раз, направление ловит противостоящий входной, стоящий перед ним предвходной ловит "единичку" функцией [B][I]next_sig_lvar ()[/I][/B] и запоминает значение в своём скрипте посредством [B][I]store_lvar ()[/I][/B]. Все остальные проходные на перегоне также запоминают переменные: каждый "снимает" показания той же функцией с последующего (скрипт-то один). Проходные хранят информацию пока они не получают TRUE в [I]enabled ()[/I].

Самое гадкое в этом механизме - это то, как в Open Rails перекрывается сигнал! Это просто какая-то жопа! И, я не могу поймать точную закономерность. Но, очень часто он перекрывается с разрешающего на запрещающее показание именно через [B] BLOCK_JN_OBSTRUCTED [/B]!
Когда я разрабатывал маневровый, в тестах было видно по табло аспектов, что с 7 сначала на долю секунды аспект загорался белым 2, и только затем опускался на красный 0. В большинстве случаев это ничего не меняет, даже в случае с маневровым тем - покуда это происходит, когда поезд - по ходу сигнала. Тот же маневровый ловил этот [B] BLOCK_JN_OBSTRUCTED [/B] по оппозиту, то есть , он должен быть [I]enabled[/I] , чтобы ловить оппозит. В том, чем я сейчас занимаюсь - совсем другое дело. Никакого оппозита - проходные снимают данные со следующего сигнала, когда все сигналы - [I]!enabled[/I]! Так что, приходится это всё учитывать. Я думаю, что по-любому входным определять направление я не буду в конце-концов. Перенесу это дело на маркер РЦ. Он будет ловить встречное направление. А, вот со сбросом надо думать. Проходные работают по переменной входного. Нужно найти такую совокупность условий входного, маневрового за ним и маркера РЦ, чтобы это [B] BLOCK_JN_OBSTRUCTED [/B] и близко в этой части скрипта не было

Ещё раз о базовых функциях в Open Rails
 

Очевидно, нужно уточнить.
Сигнал со значением [B]SNCA[/B] [B][I]= -1[/I][/B] с этой функцией работает отлично от остальных. Я говорил о том, что, по определению, такой сигнал "не учитывается" в расчете сигналов впереди поезда, к которым тот "обращается". Количество таких сигналов зависит напрямую от [B]SNCA[/B] . Прописать в такой сигнал что-то, зависящее от [B][I]enabled ()[/I][/B] - дело хлопотное. Не то, что это невозможно [B]вообще[/B], просто нужно быть внимательными и всегда помнить о том, где оно может сработать, а где - нет. С другой стороны, верно и утверждение, что если [B]SNCA[/B] "перескакивает" сигналы с -1, то все запрограммированые зависимости автоматически "передаются" первому сигналу с "положительным" (или "нулевым") [B]SNCA[/B] .
Вот как это объясняет разработчик логики сигнализации Роб Ротердинк:
[QUOTE]Значение [B]SignalNumClearAhead[/B] не имеет ничего общего с [B]enabled ()[/B]. Оно лишь указывает, должен ли быть распространен запрос на очистку сигнала, то есть если он должен распространяться до следующего сигнала. Она [функция] применима только для сигнальных голов типа [I]NORMAL[/I], а значение «-1» указывает, что запрос должен всегда распространяться независимо от значения SignalNumClearAhead для исходного сигнала и количества уже распространенных сигналов.
Другими словами, если сигнал [I]NORMAL[/I] со значением [B]SignalNumClearAhead[/B], равным -1, запрашивается для очистки, и сигнал действительно может очищаться, то он всегда будет распространять этот запрос на следующий сигнал.

Когда сигнал [B][I]enabled[/I][/B] - это означает, что поезд «приближается» к данному сигналу, для этого поезда установлен правильный маршрут, ведущий к этому сигналу, и поезд запрашивает этот сигнал для очистки.[/QUOTE]
Но, это - [B]идеология[/B]. На практике же есть вещи, которые всё же можно прописывать. К чему это я? Я раннее писал:
[QUOTE=vicente;593181] Проходные хранят информацию пока они не получают TRUE в [I]enabled ()[/I].[/QUOTE]
Я не знаю, насколько корректно утверждение "получают TRUE в [I]enabled ()[/I]", Ротердинк, скорее всего, не согласился бы с таким утверждением и написал бы статью в опровержение. Но, факт остается фактом. Такая логика протестирована мной и [B]работает[/B].

Что понимается под очисткой? Сброс аспектов?