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

[vicente]

В общем, по этому принципу я и переделывал твою делал свою сигнализацию.

И, вот что я думаю.
В симуляции, где поезд сам запрашивает себе маршрут, коей являются и MSTS и OpenRails - это оптимальный вариант. Есть в обоих этих движаах слабые стороны. Кстати, в OpenRails в большей мере, ИМХО, хотя казалось бы... Но, это то, что мы на сегодняшний день имеем. А "выкручиваться" под "наши" показания я учился, в частности, и у тебя. За что, по случаю, огромное спасибо. Ну, и за модели светофоров Тебе и Косте Елисееву (КЕ).

[vicente]

Нет. Что-то не то с этими кроссоверами.
Не на всех путях работает. Видно, напутал с секциями пути.

[Timas]

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

А сколько таких стыков на каждой станции?
И, это мы не дошли ещё до Орехово-Зуево или Инской ...

Стыков раза в полтора больше, чем рельсовых цепей. На сотню РЦ будет примерно полторы сотни стыков. Я не беру во внимание внутренние стыки между остряками и крестовиной стрелочного перевода, которые нужны для организации чередования полярности в РЦ. Только те, которые разграничивают РЦ.

Я тоже совершенно не прочь иметь какую-нибудь залипательную фигню, где всё ездит само, а ты только глядишь. Но описать её достаточно проблематично, причём это гораздо сложнее, нежели описать СЦБ. Слишком много описаний, хотя при поверхностном взгляде оно кажется простым. В основном это связано с выбором вариатного маршрута и первоочерёдностью задания маршрутов.

Даже если это не совместная игра, моё видение СЦБ всё же стремится к реализму. , если выбор правильного варианта маршрута - задача в данной реальности неразрешимая, то, как минимум, работу с охранными стрелками делать надо. Едет ли поезд ИИ или игрок - стрелки должны вставать в охрану. ИИ можно запрограммировать не ехать, игрок может поехать, куда и когда захочет. Ну это, конечно, если не увольнять его. Да и есть ещё аспекты, где проявляется некорректность и негибкость работы СЦБ.

Неисправности - штука хорошая, но они-то как раз не для детей, а для движенцев и СЦБистов. В условиях совместной игры их реализовать-то можно, но корректно отработать выход из них - нет. У ложной занятости может быть с десяток причин, у ложной свободности - поменьше.

[vicente]

То есть, ты считаешь, что описать такое возможно и построить так маршрут длинной в сотни километров с десятками станций и запустить туда трафик в сотни поездов (Я сейчас гоняю 461 поезд, в час пик пригородные с интервалом в 15 минут, скрещения, обгоны, смены локомотивов)?

[vicente]

Интересная вещь. Читал когда-то на форуме elvastower.com о перепитиях организации движения в OpenRails. Как известно, этот симулятор задуман был для того, чтобы поставить MSTS на "новые рельсы" - дать ему второе дыхание. Чтобы не пропали созданые маршруты, сценарии, подвижной состав... Вначале пути организация движения была перенесена "как есть" из MSTS, но немного позднее небезизвестной версии Х1370 всё было переработано чуть более, чем полностью. Именно с этим нововведением наши сигнализации "остались не у дел" в OpenRails. Так вот, автор разработки писал на форуме о причинах, по которым всё это было переделано "с нуля". И, вот, одной из причин было названо "отсутствие автодиспетчера" в MSTS. А, вот, в технической документации к сигнализации MSTS об автодиспетчере говорится прямо и понятно. То есть, явно кто-то напутал с терминологией. Много лет назад долгими ночами мы сидели с Игорем Забориным каждый за своим компьютером и трахались с MSTS, чтобы выяснить: как оно на самом деле работает. Целью.было создание открытой сигнализации, чего в конце концов не случилось. Но, в процессе многое стало понятно (обидно, но те вещи, к которым я приходил, гоняя ездюяины по сотне раз туда-сюда, оказалось гораздо раньше были "разжеваны" буржуями на "Стиме" и trainsim.con). Но, с другой стороны, это и порадовало. В смысле, что я всё правильно понял тогда. Принцип MSTS очень прост и практичен. Каждый поезд имеет своё "задание" - path. Он появляется в начале path и исчезает в конце. Между этими событиями можно задать ему что-то из определённого набора команд, очень ограниченного... точки разворота, точки ожидания, остановки на станциях, альтернативные маршруты и т.д. Если на пути есть узлы - стрелки, поезд "запрашивает" их согласно строго определённому алгоритму, связанному с параметром. SignalNumClearAhead, заданному в файле конфигурации сигнализации маршрута. Если узел не зарезервирован другим поездом, он получает этот узел и через узел строится маршут дальше согласно заданию. Если узел ограждён светофором - светофор откроется в случае если соблюдены остальные условия его скрипта. Если узел зарезервирован другим поездом - светофор будет закрыт через функцию BLOCK_JN_OBSTRUCTED, которая должна быть, опять опять-же, в этом скрипте прописана. На этом - почти всё. Единственное, что, может, следует добавить - если участок однопутный и есть поезд навстречу, а маршрут через узел проложен - неважно: сколько проходных светофоров на участке - поезд зарезервирует себе и следующий узел, чтобы встречный не занял этот совместный участок!
Всё это, включая существование блокировки (deadlock), непонятно и лаконично описано в документе по сигнализации MSTS.
И тут на заре развития OpenRails встаёт себе Роб Ротердинк и заявляет : в MSTS нет автодиспетчера! А он нам нужен! Организация движения - не идеальна. Пользователи "плавают" в сценариях. Нам нужно делать более сложные сценарии. Второй главной причиной вмешательства в механизм MSTS было отсутствие (якобы) возможности делать то, что они называют Call On - проезд запрещающего сигнала на занятый путь. На самом деле красные светофоры в MSTS можно спокойно проезжать даже на дефолтной сигнализации Marias Pass , через условно-разрешающий и маневровый аспекты, заложеные изначально в симулятор разработчиками.
Что в этом всём интересного и как это связано с нашим разговором?
Конечный вариант (а Роб отходит от дел и никто (пока) не решается даже приблизится к этой части кода) сигнализации OpenRails концептуально выглядит с этой точки зрения... примерно так же. Поезд имеет задание и запрашивает себе путь! Да, нюансы там есть, deadlock "отделён от государства", но... стало ли легче делать сложные сценарии (в добавилось множество функций)? Вопрос. У меня были случаи, когда простыми точками разворота deadlock сбивался к чертям и у Роба не было решений, кроме как закончить сервис, и из него создать новый.
Но, по моим понятиям, автодиспетчера как такового как не было - так и нет.

То о чем пишешь ты требует описания диспетчера. В одиночной поездке этот диспетчер должен просчитывать десятки, если не сотни вариантов на каждой станции. А на маршруте? Но, как бы ты не пришел к тому же самому : различать поезда диспетчер-то должен всё равно - по заданию. Или как?

Добавлено через 54 минуты
Всё-таки выставлю ролик, который снимал для себя в рабочем порядке. Прошу прощения за съёмку на телефон. На ролике - открытие светофора с ложным кроссовером. На место установки кроссовера на пути электрички указываю мышкой.

[Timas]

А куда оно денется, если работать не будет. Оно жеж событийное, никаких постоянных расчётов ему там делать не надо, чтобы какие-то сложные циклы крутились и перебирали всю кучу объектов. Друг делал в zzZ'19 СЦБ по моим принципам, но не в виде ООП, а в виде скриптов. Так он при правильном секционировании путей мелкие станции за вечер скриптом описывал. Крупные - да, дольше, но на крупных и я в своём проекте плаваю, бо нет пока автоматизации по их созданию.

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

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

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

Теперь, что касаемо поездной сигнализации. Все эти извращения с описыванием 1234567890 почти одинаковых скриптов, различающихся только разлинзовкой, это реально извращения. Для выбранного типа сигнализации необходимо составить трёхмерную таблицу, в которой упорядочиваются зависимости сигналов на попутных светофоров. Ест-но, с учётом стрелок и скоростей по ним. Одна таблица на всю карту (если неск. типов СЦБ применяется - будет неск. таблиц). Каждый аспект в таблице должен уметь отображаться тем или иным светофором. Собрал таблицу маршрутов - пошёл назначать каждому маршруту алгоритм из таблицы. На этом этапе светофор может сматериться, что у него нет способа отобразить такое-то показание. В этом случае светофор заменить (именно заменой, чтобы не обвалить таблицы маршрутов, которые ведут до или за этот светофор). И всё. Логика описывается один раз, а не таскается из скрипта в скрипт.

Я вот у себя тоже хочу от чисто МПСовской сигнализации уйтить в сторону вариантной. Но не сейчас.

[TRam_]

и то может стать затыком на перспективу

Обход затыков можно внедрять в логику, или (как у меня в маршрутизации) делать два варианта маневровых маршрутов - на занятый путь или только на свободный (во втором случае "кто-то ещё", кому нужен этот же тупик, не поедет, пока данный лок не освободит тупик). Ну и + система разграничений, чтобы с маршрутами работал только тот локомотив, который ближайшим к изостыку стоит.. Выглядит это так - https://youtu.be/kK0-ocptUM4?t=9

составить трёхмерную таблицу, в которой упорядочиваются зависимости сигналов на попутных светофоров

Почему на всю карту? У меня например одна таблица(код) на любые светофоры, с зависимостью кроме вышеперечисленного от наличествующих в светофорах линз... https://github.com/TRam1990/sU-core/...cation.gs#L853

[Timas]

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

Обход затыков можно внедрять в логику...

Можно. Но осторожно. Потому как иногда при поодиночном движении в тупик не хватает пропускной способности тупика. Если в тупике оборачивается два локомотива, то экономится время одной операции на смену кабины. И это ещё не учтены станции стыкования (Я надеюсь, что в МСТСах и проч. научатся секционировать контактную сеть).

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

...Почему на всю карту? У меня, например,...

Из расчётов, что на разных картах может применяется разная сигнализация (МПС СССР, ОСЖД и т.д.) или одна и та же, но в разных временнЫх исполнениях. Для каждого варианта своё исполнение таблицы.

[TRam_]

Timas, да, для разных "эпох" нужны разные исполнения, взять хотя бы эволюцию сигнала желтый-зелёный. Но опять же - тогда и семафоры с дисками нужно там же описывать. Просто имею в виду, что универсальный алгоритм определения показания светофора для современных нормативов сигнализации уже реализовывался.

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

Если в тупике оборачивается два локомотива

В смысле поочерёдно - тогда решение мной указано выше (проверка свободности тупика при попытках сбора маршрута). Если одновременно (т.е. в тупик загоняется по 2 локомотива) - тут уже сложнее.

[vicente]

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

В смысле поочерёдно - тогда решение мной указано выше (проверка свободности тупика при попытках сбора маршрута). Если одновременно (т.е. в тупик загоняется по 2 локомотива) - тут уже сложнее.

В принципе, в Timetable Mode Open Rails такое возможно. Вообще, многое из вышеизложенного возможно уже сегодня в OpenRails. Те же шаблоны скриптов, к примеру. Когда один скрипт можно применять хоть ко всем светофорам на маршруте.И симулятор развивается сразу в нескольких направлениях. Например сейчас анонсирован новый формат файлов составов. Кроме рэндомальной сборки будет ещё и инжикация состава по типу: пассажирский, грузовой и т.д. Надеюсь, что кагда-нибудь займутся и базой данных пути. Хотя, пока, создаётся впечатление, что она всех устраивает.

[vicente]

Вот такие функции:

Activate_Timing_Trigger() : Активирует таймер.
Check_Timing_Trigger(n) : Проверка триггера. Возвращает TRUE, если таймер "досчитал" до числа n

На видео я установил для выходного 45 секунд. Ещё раз прошу прощения за качество. Пока - только так

Таймер на светофоре Open Rails

[roman5]

Сообщение от Сергей1969

В этом Иванцево иногда даже на пустой путь не запускает виртуальный диспетчер...

А как по отлаживать сигналку ? Я нашел функцию в sigscr, а как ее отладить, интересно найти ошибку в сигналке.

[КЕ]

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

А как по отлаживать сигналку ? Я нашел функцию в sigscr, а как ее отладить, интересно найти ошибку в сигналке.

Какая функция?

[roman5]

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

Какая функция?

Например, входной Иванцево со стороны Драчеево. Вот этот сигнал задан этой функцией APK_4AB_YR_GY_I_Kv в sigcfg.dat - состоит из (APK_3AB_YGR_YW_DISTANCE, APK_INFO_CLEAR_2, APK_ALSN_KZ_0_B_0, APK_ALSN_KZ_20_B_20, APK_3AB_YGR_YW_ALSN_Z_40_B_40, APK_3AB_YGR_YW_ALSN_Z_60_B_60, APK_4AB_YRG_YW_ALSN_Zel_B_Z, APK_4AB_YR_GY_Kv ) - скрипты описаны в sigscr.dat в скобках перечисленные.
В одном из сценариев этот сигнал не пускает на главный путь пока на боковом стоит пригород. Какой надо смотреть из скриптов в скобках и есть ли возможность отладить скрипт в игре, то есть добавить в него логи или отладчиком как-нибудь туда залезть и найти ошибку.

[КЕ]

Возможно, надо попробовать переустановить этот светофор в RE. Или даже их все на станции.
Иногда это помогало с зависаниями сигналки.
А так только сам Алексей Фёдоров APK LVDZ сможет разобраться, в его сигнализации слишком много зависимостей.