Оба видео - ОР.
У в старой версии горят впереди поезда по SNCA, ререкрываемый после проезда поезда горит красным по не свободному блоку, потом он "желтеет" , а уже затем - гаснет. Но, что-то там начало "глючить" и, нет-нет, предвходные горели желтым даже против движения.

[SPOILER]Блин, "затягивает" сигналка... :confused:
Хотел сценарий в Timetable "продвигать" , а "увяз" здесь. [/SPOILER]

Я поставил на маршруте новые светофоры, которые разоаботал , пришлось "полетать" в редакторе и добавить на двухпутной односторонней АБ обратно-глядящие головы на проходных , чтобы маневровые работали, потому что я манёвры всегда в сторону перегона на правильный путь строю. Потом подумал про однопутку, да и на двухпутном, в случае , когда сервис по неправильному пути, я так понял, правильное направление надо гасить.

[size="1"][color="Silver"]Добавлено через 6 минут[/color][/size]
Кроме "глюка" с желтым предвходным на двухсторонней АБ и того, что всё направление не горит (хотя, в принципе, длинных перегонов таких у меня нет), меня не устраивает, что, когда на перегоне никого нет и никто не расчищает себе маршрут, проходные не горят ни в одном из направлений.
Вот я и подумал: раз теперь есть функция запоминания, поправить саму работу светофоров и даже запомнить последнее рабочее направление

[size="1"][color="Silver"]Добавлено через 1 час 10 минут[/color][/size]
Короче...
Направление запоминать я их "научил" (чуть позже будет ролик). В смысле, остаётся гореть то направление, по которому прошел последний сервис. Но, проблем осталось - вагон и маленькая тележка!
Во-первых, "изначально" , то есть, в начале сцены, пока ни один поезд не прошел, горят оба направления.
Во-вторых, когда происходит смена направления, от открытия выходного и пока сервис не заходит за обратный маневровый, также горят оба направления - тоже не айс.
Но, если эти два пункта ещё можно решить, то с третьим - ума не приложу: что делать. Дело в том, что...
В-третьих, чертов Open Rails учитывает пути сервисов и длину поездов. Таким образом, скажем, при выезде локомотива в маневровом режиме и смене направления его движения между входным и маневровым, симулятор может вполне выпустить встречный сервис до входного. Я тестил этот момент когда SNCA проходных был 4 - скрипт "ловил" направление выезжающей ЧМЭ-ухи и гасил направление и перед встречным горели только 4 светофора. Ночью я "добил" запоминание, в частности, изменив параметр SNCA на "-1" . Что сейчас со встроенным направлением происходит в этом случае, пока не тестил. Возможно, придётся на этот случай разрабатывать блокировку.
Костя, ты работал с функцией [B][I]dist_multi_sig ()[/I][/B]? Знаешь как она [B]точно[/B] работает в конце участка проверки? Если я буду проверять весь перегон до маневрового, "повесив" ограничитель на него, проверка будет включать сам маневровый?

[QUOTE=vicente;593148]...Костя, ты работал с функцией [B][I]dist_multi_sig ()[/I][/B]? Знаешь как она [B]точно[/B] работает в конце участка проверки? Если я буду проверять весь перегон до маневрового, "повесив" ограничитель на него, проверка будет включать сам маневровый?[/QUOTE]
Что-то пробовал давно; но сейчас не помню ничего...
А что за ограничитель?

В эту функцию вводится два параметра [B]SigFn_Type[/B]
Классическим вариантом по докумнтаци Kuju MSTS является [B]dist_multi_sig_Xr*(SigFn_NORMAL, SigFn_DISTANCE)[/B] . Дословно это работает, как "ищи наиболее/наименее ограничивающий аспект сигнальных голов первого указанного типа , пока не встретится сигнальная голова второго типа". Это и есть ограничитель. Функция возвращает соответствующий аспект на заданном участке пути.

Вспоминаю... я так понял, что если, например, я эту проверку сделаю в первом проходном, то она вернет аспект входного светофора (стоящего перед узлом) в конце всей цепочки проходных. Так?

Если проверять [B][I]_mr[/I][/B] и перегон свободен - то да. Но, я запутался. Нельзя так делать. Нельзя вмешиваться в уже готовый маршрут скриптом. Вообще, там бред какой-то происходит. [B]Сигнал должен блокироваться симулятором[/B]! Я там в мини сцене своей начудил и свёл сим с ума :crazy:
Сервис игрока стартует на пути трафика "лоб в лоб". Из-за того, что у игрока - точка разворота за маневровым, сим пытается "разрулить" патовую ситуацию и "протолкнуть" манёвры перед идущим навстречу поездом. А, бред заключается в том, что вместо того, чтобы остановить маневровый на выходном, а поезд на входном на "вечный красный", сим выпускает игрока при любом раскладе. В последних ночных тестах маневровому вообще горел красный 0. Я включал автопилот и ЧМЭ-уха преспокойно этот красный проезжала.

[size="1"][color="Silver"]Добавлено через 3 минуты[/color][/size]
Мне кажется, что если я поставлю поезду альтернативный [B]path[/B] по станции, всё заработает и маневровый будет стоять у заблокированного выходного.

[size="1"][color="Silver"]Добавлено через 7 минут[/color][/size]
Через пол-часа расчехлю ноут и попробую.

[size="1"][color="Silver"]Добавлено через 51 минуту[/color][/size]
[IMG][URL=http://piccy.info/view3/13793512/317d6e77046f1cf7c085f3f7b01ea5ce/orig/][IMG]http://i.piccy.info/i9/a10e0acc87381ebfaf57aa08997ed1d8/1588852096/92888/1373151/RunActivityLAA_2020_05_07_14_27_04_54_800.jpg[/IMG][/URL][URL=http://i.piccy.info/a3c/2020-05-07-11-48/i9-13793512/763x559-r][IMG]http://i.piccy.info/a3/2020-05-07-11-48/i9-13793512/763x559-r/i.gif[/IMG][/URL][/IMG]
Да, с блокировкой нормально всё. Неправильный старт сервиса. Я уже писал об этом. Правильно стартовав,описанных мной прежде ситуаций можно и нужно избегать.

[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].

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

Под очисткой понимается возможность сигнала "открыться". Повторюсь, его терминология немного отличается от нашего понимания. У нас на пустом перегоне проходные сигналы в обоих направлениях "открыты" по умолчанию. Он пишет что они "не очищены"? Ну, так... пусть. Что для нас важно в вопросе [B][I]enabled ()[/I][/B]? Что эта функция работает отлично от того, как она работает в MSTS! Что бы он не писал, я на тестовом своём отрезке поставил семи проходным [B]SNCA = 4[/B], сам сигнал прописал "горит", коглда он [B][I]enabled[/I][/B] и у меня было ровно 4 горящих сигнала перед поездом. Отличие от [B]MSTS[/B] по самой [B][I]enabled ()[/I][/B] заключается в том, что в [B]Open Rails[/B] функция распространяется [B]только[/B] на сигналы [B]впереди[/B] сервиса. В [B]MSTS[/B] есть ещё два направления относительно сервиса, где светофоры [B][I]enabled[/I][/B]: позади сервиса и впереди сервиса сигналы в противоположном направлении . Я тестил это ещё 9 лет назад. Скрины, к сожалению, не сохранились, но почитать можно [URL="http://forum.zaborin.ru/topic.php?forum=20&topic=3&postid=1313577347#1313577347"]здесь[/URL].

[size="1"][color="Silver"]Добавлено через 5 минут[/color][/size]
Демонстрация работы выходного сигнала в зависимости от пути сервиса с использованием функции [B][I]train_requires_next_signal ()[/I][/B]
[YOUTUBE="state = train_requires_next_signal(sigid, position)"]0M5j9LMtjoM[/YOUTUBE]

train_requires_next_signal () - какие есть примеры использования в скрипте?

[URL="http://www.trainsim.ru/forum/showpost.php?p=592736&postcount=435"]Здесь[/URL] под спойлером.

Как-то так
 

[YOUTUBE="Двухсторонняя АБ"]4jZKQkQiMEQ[/YOUTUBE]
:cool:

Подскажите пожалуйста! Как правильно прописать в скрипте сигнализации, строчки: [COLOR="Lime"][B]BACK_FACING[/B][/COLOR] и SignalFlags ( [COLOR="lime"][B]OPTIONAL BACK_FACING[/B][/COLOR] ), чтобы можно было развернуть маркер дополнительной повторительной головы выходного светофора? Чтобы дополнительная голова сигнализировала против направления движения.

[IMG]http://scbist.com/photoplog/images/4574/small/1_4086.jpg[/IMG]

Ну, я в ЛС ответил. Здесь, правда для меня удобнее.
Единственное дополнение - когда развернёшь шейп и будешь устанавливать - маркер должен стоять [B]перед[/B] маркером выходного. А потом уже двигать голову, чтобы она "села" на мачту.

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
Мачта повторитеотного убирается в опциях в редакторе маршрутов.

[size="1"][color="Silver"]Добавлено через 12 минут[/color][/size]
[QUOTE=Forsayth]Спасибо огромное)
Только маленький глюк произошел и линза зеленого огня не развернулась([/QUOTE]
Линзу надо "подгонять" в конфигурации.
В блоке
[QUOTE] SignalLights ( 2
SignalLight ( 0 "Green Light"
Position ( 0 7.475 0.01 )
Radius ( 0.28 )
)
SignalLight ( 1 "No Light"
Position ( 0 -1 0 )
Radius ( 0.01 )
)
)[/QUOTE]
поиграй с координатами

[size="1"][color="Silver"]Добавлено через 4 минуты[/color][/size]
А, вот, как сделать, чтобы оно в другую сторону светило... надо подумать :confused:

[QUOTE=vicente;596056]

поиграй с координатами

[size="1"][color="Silver"]Добавлено через 4 минуты[/color][/size]
А, вот, как сделать, чтобы оно в другую сторону светило... надо подумать :confused:[/QUOTE]

Линза по координатам правильно расположена. Но, она светит в противоположную сторону. Сейчас сам голову ломаю. :confused:

А, если так попробовать?
Замени блок шейпа в sigcfg.dat на вот это:
[QUOTE] SignalShape (
"T_Signal_Head_G.s"
"Repeater Signal G"
SignalSubObjs ( 5
SignalSubObj ( 0
"SIGNAL" "Default Main Track Signal"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "T_Head_G" )
)
SignalSubObj ( 1
"Footing_metal" "Metal footing"
SigSubType ( DECOR )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 2
"Footing_concrete" "Concrete footing"
SigSubType ( DECOR )
SignalFlags ( OPTIONAL DEFAULT )
)
SignalSubObj ( 3
"Stairway" "Stairway"
SigSubType ( DECOR )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 4
"SIGNAL" "Optional Back Facing Signal"
SigSubType ( SIGNAL_HEAD )
SignalFlags ( OPTIONAL BACK_FACING )
SigSubSType ( "T_Head_G" )
)
)
)[/QUOTE]
Поставь сигнал (надо удалить старый и поставить его снова после редактирования конфигурации) и посмотри, появилась ли вторая линза

[QUOTE=vicente;596061]
Поставь сигнал (надо удалить старый и поставить его снова после редактирования конфигурации) и посмотри, появилась ли вторая линза[/QUOTE]

Линза вторая появилась. Только в ту же сторону. Не меняет направление. Видимо нужно менять координаты в самом шейп-файле. :confused:

Да, похоже, надо в шейпе ковыряться. Старый блок сохранил? Бэк фэйсин не нужен тогда

[QUOTE=vicente;596063]Да, похоже, надо в шейпе ковыряться. Старый блок сохранил? Бэк фэйсин не нужен тогда[/QUOTE]

Старый сохранил. Думаю, что проблема при компрессии. Так как выдает ошибку, но маркер разворачивает.

Вот оригинальный шейп:
[QUOTE] SignalShape (
"T_Signal_Head_G.s"
"Repeater Signal G"
SignalSubObjs ( 4
SignalSubObj ( 0
"SIGNAL" "Default Main Track Signal"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "T_Head_G" )
)
SignalSubObj ( 1
"Footing_metal" "Metal footing"
SigSubType ( DECOR )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 2
"Footing_concrete" "Concrete footing"
SigSubType ( DECOR )
SignalFlags ( OPTIONAL DEFAULT )
)
SignalSubObj ( 3
"Stairway" "Stairway"
SigSubType ( DECOR )
SignalFlags ( OPTIONAL )
)
)
)[/QUOTE]

[QUOTE=vicente;596065]Вот оригинальный шейп:[/QUOTE]

Этот вариант пробовал. Безрезультатно. Сейчас попробую любой светофор конвертировать. Посмотрю на результат.

[size="1"][color="Silver"]Добавлено через 4 минуты[/color][/size]
Попробовал три светофора. Результат тот же. Возможно проблема в самой программе, так как она выдает ошибку.

Нет. У меня не выдаёт никакой ошибки, тем не менее, линза тоже не разворачивается
[IMG]https://i.ibb.co/swcZ6Sf/train-2020-10-09-01-41-23-79.png[/IMG]

Возможно, нужно новую модель светофорной головки делать.:(

[size="1"][color="Silver"]Добавлено через 10 минут[/color][/size]
Скачал другую версию программы. Компрессия прошла без ошибок, но проблема не разворота линзы осталась. Думаю, что проблема в самом файле sigcfs.dat
Хотя не уверен.

[QUOTE=Forsayth;596069] Думаю, что проблема в самом файле sigcfs.dat
Хотя не уверен.[/QUOTE]
Думаю, sigcfs.dat ни при чем. Надо в шеёпе самом направление света править.

Естественно там ничего не понять. Смотрю сам шейп файл, там практически 0 и 1. Что и где поменять нужно, не понять. :confused:

Всё. Я - спать!

Кое что нашёл. Пока оставлю это здесь
[QUOTE]В TSRE5 вы можете переворачивать (переворачивать) сигналы (размещая) вместе с формой, если вы установили крючок на «Отразить фигуру» слева в окне Object :, если нет, вы перевернете только красную пирамиду ...

Есть разница между MSTSRE и TSRE5 размещением сигналов:
MSTS: если вы повернете форму сигнала более чем на 180 градусов, красная пирамида автоматически перевернется в другом направлении дорожки.
TSRE5: вы можете вращать и перемещать форму сигнала в любом направлении, которое вам нравится (с помощью «R», затем Numpad или мыши), красная пирамида остается в направлении размещения.
Чтобы повернуть красную пирамиду, вы должны выбрать Shae или красную пирамиду и использовать функцию FLIP в меню «Объект» слева (с или без выбора формы отражения).


[/QUOTE]

Проверил. Разворачивается только в TRSEE, когда заходишь снова в стандартный редактор, все возвращается к исходной проблемы.

[size="1"][color="Silver"]Добавлено через 1 час 8 минут[/color][/size]
Проблема в не развороте линзы, может быть, в том, что линза привязана к самому маркеру, а не к объекту. Поэтому, как ни крути объекты, а линза будет все равно на одном месте.

Странно , что [URL="http://www.trainsim.ru/forum/showpost.php?p=596061&postcount=548"]здесь[/URL], ты говоришь, что вторая линза в ту же сторону смотрит. Линза - это конфиг - 100%. Как доберусь до компьютера - сам попробую back-facing "прикрутить". На USA2 они же смотрят в другую сторону. А там - по тому же принципу сделано.