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

[КЕ]

Лучше переустановить, ведь все субобъекты в БД записываюся. И зная глючность МСТС-редактора в этом деле - лучше перестраховаться.

[vicente]

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

Примерно так же пытался делать для манёвров - тоже "фиг вам"!

Да, тоже для манёвров тестил. "Настроил" даух-ходовочку - маркер смртит на входной через opp_sig_lr(SigFn_NORMAL), а маневровый светофор - на маркер через opp_sig_lr (SigFn_DISTANCE), потом - через opp_sig_lr (SigFn_NORMAL). Маневровый ловил аспект функцией без проблем, а вот, маркер...

[КЕ]

То есть получается - маркер за входным на перегоне?

[vicente]

Сообщение от APK-LVDZ

Если имеется ввиду опция opp_sig_xx, то она работает так же как next_sig_xx, только в обратную сторону. Там есть ряд ограничений на тип головы, сейчас точно не помню. Вроде REPEATER не ловил, и можно было использовать не во всех головах. Это актуально для МСТС

В том-то и дело. Там не только тип головы, а ещё ограничения! Я только не могу уже припомнить: что там касается Open Rails , а что - MSTS.

Костя, обсуждения наших мытарств по маневрам тоже а тот период было. Кликни на цитату - попадёшь на нужные страницы темы.

Добавлено через 2 минуты

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

То есть получается - маркер за входным на перегоне?

Да. Идея была в этом. В принципе, "связка" : входной- первый проходной в Иванцево - тоже подходит под определение. Так как их маркеры расположены

[КЕ]

С проходным на тестах в МСТС бывало такое - пока маневровая ездючина проходит горловину, он !enabled (аспект STOP в моем случае, и на выходном, естественно, белый). Но при выходе за последнюю стрелку и проходе за точку разворота этот проходной "включался" и открывался.

[roman5]

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

Прежде чем что-то менять в sigcfg - надо удалить изменяемые светофоры, и только потом их установить заново.

Все удалить проблемно, я ведь не знаю, где автор еще такой же поставил. А мне для теста только 1 из них заменить интересно.

[КЕ]

Можно по имени шейпа в *.w найти место установки.

[vicente]

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

А мне для теста только 1 из них заменить интересно.

Я же написал как делать.
Копмруешь шейп саетофора, переименовав его (файлы *.s
и *.sd, не забывая в редакторе подправить внутри *.sd название шейпа).
Добавляешь в sigcfg.dat тестовый шейп, копируя нужный блок шейпов. Не забыть увеличить на 1 общее количество шейпов в шапке Signal_Shapes.
Также добавляешь 1 в шапке Signal_Heads , копируешь блок головы, которую хочешь изменить в светофоре.
Меняешь в тестовом шейпе головы
Скрипт новой головы добавляешь в sigscr.dat
Меняешь тот светофор, который хочешь тестировать на маршруте на тестовый

Добавлено через 10 минут

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

С проходным на тестах в МСТС бывало такое - пока маневровая ездючина проходит горловину, он !enabled (аспект STOP в моем случае, и на выходном, естественно, белый). Но при выходе за последнюю стрелку и проходе за точку разворота этот проходной "включался" и открывался.

Я не сталкивался с этим, и знаешь почему? А какая мне разница: что происходит с первым проходным после того, как я получил белый на выходгом и выехал к точке разворота? Тем более, если я проехал за неё? У меня и в MSTS и в стабильной версии Open Rails , если помнишь, первый проходной, если был !enabled, давал 2, выходной быд запрограмирован на следующий 2 давать тоже 2. Вот и все манёвры на выходном. Как только я его проехал, в RESTRICTING на первом проходном необходимость - дело пятое. Единственное, когда он RESTRICTING , будет белый на локомотивном, а если проходной станет enabled и изменится на CLEAR_2 , локомотивный сменится на зелёный. Кстати, в реале как АЛСН работает в такой ситуации? Белый до проследования входного, потом что в сторону перегона? Ловит зелёный или нет?

[КЕ]

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

...А какая мне разница: что происходит с первым проходным после того, как я получил белый на выходном и выехал к точке разворота? Тем более, если я проехал за неё?

Я пытался его STOP ловить по opp_sig_lr(), искал условия для манёвров, чтобы зажечь белый на маневровом Б-С, стоящем у первой стрелки. А сейчас просто вспомнил.

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

У меня и в MSTS и в стабильной версии Open Rails, если помнишь, первый проходной, если был !enabled, давал 2, выходной был запрограммирован на следующий 2 давать тоже 2. Вот и все манёвры на выходном.

Олег, а чем лучше на !enabled давать "2", а не "0"?
А, понял, это для ORTS.
Вообще да, при движении по горловине в сторону перегона белый легко зажечь. А вот обратно...

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

Кстати, в реале как АЛСН работает в такой ситуации? Белый до проследования входного, потом что в сторону перегона? Ловит зелёный или нет?

А кто его знает... наверно, зелёный покажет, если проходной открыт.

[vicente]

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

Я пытался его STOP ловить по opp_sig_lr(), искал условия для манёвров, чтобы зажечь белый на маневровом Б-С, стоящем у первой стрелки. А сейчас просто вспомнил.

Хм... Хорошо, но если этот проходной

if (!enabled) {state = SIGASP_STOP;}

и становится в какой-то момент enabled и меняет аспект, как только ты переводишь реверс, он снова должен становиться !enabled ... Даже трафик пройдя точку разворота (правильно для MSTS ), сделает движение в сторону даже закрытого сигнала и "перевернёт" этот проходной снова в !enabled.
С оппозитами есть ещё одна байда - функция делает проблемы, если между соответствующими светоформи находится поезд, насколько я помню.

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

Олег, а чем лучше на !enabled давать "2", а не "0"?
А, понял, это для ORTS.
Вообще да, при движении по горловине в сторону перегона белый легко зажечь. А вот обратно...

Дело не в симуляторе. С выходным в MSTS другая проблема: выход на манёвры "по удалению" невозможен. Откроется поездной сигнал. По этой логике решается только служебным маркером на границе станции, дающим STOP и RESTRICTING . Я ставил его back_facing головой на входном, а выходной на следующий STOP оставался закрытым. Так что, STOP я использовал для этого. Конечно, заманчиво не ставить маркеры в тупиках, но в MSTS катастрофически не хватает аспектов, а информацию от светофора к светофору можно передать только аспектами... ну... кому я рассказываю?
Потому и RESTRICTING.




Насчёт обратной стороны, в MSTS было настроено так:
RESTRICTING давался
1. На занятый путь
2. На свободный путь, если следующий- тоже RESTRICTING
В остальных случаях:
1. На следующий STOP_AND_PROCEED- STOP_AND_PROCEED со скоростью желтого
2. На остальные аспекты следующего светофора - state = next_state;
Показания прописывались отдельно, через draw_state - белый на RESTRICTING , остальные аспекты горели синими.
Конечно, было не идеально, но терпимо.
Если поезд останавливался у красного входного, который был прописан на следующий RESTRICTING давать STOP_AND_PROCEED красный, был виден горящий белым маневровый - это раз. При маневрах на свободный путь с закрытым выходным, маневровый оставался синим при том, что он открывался STOP_AND_PROCEED. Но... Для MSTS , повторяю, было удовлетворительно. В MSTS , напомню, трафики не сцепляются, а игрок на свободный путь, в основном, "обгоняется". Если ехать строго по показаниям, а выходной закрыт из-за блокировки, игрок может и подождать пока выходной откроется RESTRICTING и ему откроется маневровое показание.
Идея с оппозитами заключалась в том, что поезд с перегона - ему обязательно должен открыться входной, прежде чем он проедет его. В MSTS функция block_state () не определяет направление движения поезда, по-любому она вернёт BLOCK_OCCUPIED если блок занят. Поэтому и пытался ловить через оппозит открытый входной. Но, этого не достаточно. Маневровый должен не просто поймать момент, когда входной открыт. Он должен ещё запомнить, что входной был открыт, когда голова поезда проследует этот входной и сигнал перекроется. А это - ой как не просто в статическом скрипте. Мне казалось, что , сегодня, после того как я научился запоминать информацию в Open Rails , мне удастся соорудить что-то подобное для MSTS . Как я уже писал, я собирался написать новую сигналку, которая будет работать в обоих симуляторах, плюс мультиплейер... но... пока жизнь не даёт на это времени.

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

А кто его знает... наверно, зелёный покажет, если проходной открыт.

Мне нужна информация по АЛСН. Маневры на перегон, маневры по станции, потеря кодов в поездном режиме. Когда какие коды. В интернете, что-то, не густо в этом плане...

[КЕ]

Хорошо, но если этот проходной
if (!enabled) {state = SIGASP_STOP;}
и становится в какой-то момент enabled и меняет аспект, как только ты переводишь реверс, он снова должен становиться !enabled ... Даже трафик пройдя точку разворота (правильно для MSTS ), сделает движение в сторону даже закрытого сигнала и "перевернёт" этот проходной снова в !enabled.

Нет, проходной оставался открытым при реверсе.

в MSTS катастрофически не хватает аспектов

Но если б можно было передавать аспекты "вперед" по ходу сервиса.... Мечты!

Насчёт обратной стороны, в MSTS было настроено так:
RESTRICTING давался...

Насколько надежно это работало?

Он должен ещё запомнить, что входной был открыт, когда голова поезда проследует этот входной и сигнал перекроется. А это - ой как не просто в статическом скрипте.

Да, трудновато!)) Я так и не добился надёжного сохранения внутренней переменной. Поэтому и мечтал о передаче "вперёд".

Мне нужна информация по АЛСН. Маневры на перегон, маневры по станции, потеря кодов в поездном режиме. Когда какие коды. В интернете, что-то, не густо в этом плане...

Спросил на форуме http://scbist.com/obschie-voprosy-ek...prosy-632.html?
ЗЫ:
Залез сюда.))

[vicente]

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

Нет, проходной оставался открытым при реверсе.

Да, это так. Подзабыл, прошу прощения. Ровно 10 лет назад я нацарапал на заборе тестил эту функцию "чистым тестом" с блэкджеком и шлюхами с фотографиями (к сожалению, сайты давно почили в бозе, и много материала утеряно). Описание теста прилагаю полным текстом сообщения, за исключением скринов..

Скрытый текст:

Немного о функции*enabled

Данная функция является внешней функцией относительно скрипта. Мы знаем, что в скриптах есть функции внешние, то есть прописаны они в другом месте - ехе-файле симулятора и изменять в работе самой функции мы ничего не можем (см.мануал) и есть функции, которые, теоретически, может прописать разработчик сигнализации внутри самого скрипта (чем и занимаюсь сейчас для создания своего варианта одностороннего пропуска).
Итак, enabled.
Кужувский разработчик пишет:

Код:

Contains TRUE (non-zero) if the current signal instance is enabled to show
its natural state, or FALSE otherwise.


Это значит, что функция возвращает единицу, если светофор включен, чтобы показать его состояние, в противном случае - выдает 0.
То есть не все светофоры на маршруте работают по скрипту, а только те, которые находятся впереди и позади сервиса на определенном расстоянии. Расстоянием здесь является не километраж и не количество узлов, как в подготовке маршрута МСТС, а количество светофоров. Какое кол-во светофоров будут enabled перед сервисом (кстати, не важно сервис ли это игрока или трафик) мы задаем в файле конфигурации сигнала в параметре SignalNumClearAhead. Небольшой тест покажет наглядно как это работает.
Я поставил на перегоне проходные светофоры (модели Тимаса), прописав в них SignalNumClearAhead (2), обычные сигналы проходного 3АБ, а при функции enabled = 0, или правильней - !enabled - синий.

Результат - перед сервисом 2 светофора зеленые, остальные - синие - !enabled. Это понятно. Цель теста - выяснить, что с остальными светофорами на перегоне. У нас еще три направления. На скрине мы видим, что за занятым сервисом блок-участком светофор красный, то есть enabled. За этим светофором, против хода сервиса,как и положено желтый, а уже перед ним - !enabled - синий.
Что происходит с противоположной стороны?


Перед сервисом 2 светофора становятся enabled красный и желтый. Светофоры же позади него сразу же становятся !enabled - синие.
Интересно, что если я возвращаюсь назад, то светофоры по мере удаления от них остаются enabled - зелеными. То есть если я вернусь на 2 блок-участка, то впереди меня будет не 2, а 4 зеленых светофора. В обратном же направлении, направлении движения, ни один светофор enabled не становится.

Нужное место я выделил под спойлером в последнем абзаце

Добавлено через 30 минут

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

Но если б можно было передавать аспекты "вперед" по ходу сервиса.... Мечты!

Ну, с MSTS уже вряд ли что можно сделать. Но, мечты сбываются в наше время в Open Rails , и это дело обещают/сделано уже там. Но, как поётся в песне, "того, что нужно нам, всегда на свете нет..." Прграммировать светофоры для этого нужно с С#, а я вообще не знаю его, и в жизни программированием не занимаюсь.

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

Насколько надежно это работало?

Всегда. Там никакого выпендрёжа нет, на самом деле. Вся цепочка светофоров NORMAL-ы, каждый работает по известным и накатанным функциям и зависит толькоот следующего сигнала. Единственное- пришлось поднять SignalNumClearAhead , а я это очень не люблю. Но, маршрут - мой личный, ворочу чего хочу, в сценариях, естественно, я это учитывал.

[КЕ]

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

Прграммировать светофоры для этого нужно с С#...

В смысле - менять исходный код ORTS?

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

... Единственное- пришлось поднять SignalNumClearAhead , а я это очень не люблю. Но, маршрут - мой личный, ворочу чего хочу, в сценариях, естественно, я это учитывал.

Какое число было необходимым?

[vicente]

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

Да, трудновато!)) Я так и не добился надёжного сохранения внутренней переменной. Поэтому и мечтал о передаче "вперёд".

То, что я хотел сделать и описал выше - наоборот - "ловить" поездной режим, а если не ловится - скрипт маневрового. У меня сейчас так в Open Rails с внешними переменными (в Open Rails можно кидать переменные во внешние регистры и не только запоминать их, но и "снимать" эти переменные с других светофоров. К сожалению, только по аналогии MSTS : next_.. (next_n...) и opp_... . Но, я не удовлетворён его работой - иногда оппозит преподносит сюрпризы (дело в скриптах, нужно переделывать) из-за того, что стрелки в Open Rails остаются в последнем положении и, если кто-то "сбивает" маршрут к светофору, с которого я снимаю данные (перекрёстный маршрут), тупая программа "ловит" переменные, к примеру, не с нужного маркера, а с другого... или из тупика.

[КЕ]

Оег, ты говоришь про это? -

Записывать данные: store_lvar (key, value)
Извлекать их: this_sig_lvar (key)
Передавать: next_sig_lvar (key), и id_sig_lvar (sigid, key)
next_sig_id (SigFn_Type) - функция, которая идентифицирует сигнал для дальнейшей работы с ним по идентификатору, который она возвращает

direction = this_sig_lvar (1);
if (block_state ==# BLOCK_JN_OBSTRUCTED) {state = SIGASP_RESTRICTING;store_lvar (1,1);}
else { store_lvar (1,0);}
Первая цифра в скобках - "разряд", вторая - само значение. Можно запоминать их сколько угодно! Под каждым "разрядом" - своя переменная. В смысле, под (1,Х) - одни переменные, (2,Х) - другие и т.д.

Нашёл интересное замечание в наших давних сообщениях:

opp_sig_x
функция задумывалась как чтение аспекта противостоящего сигнала, контролирующего вход в этот же блок с противоположной стороны. Она читает сигнал за поездом с противоположной стороны, но - выдает только аспекты 0, 7, и -1 (!).

Надо будет проверить.