Система сигнализации sU и система маршрутизации zxPath
Сигнализация, в котором отсутствуют какие-либо "автоматические" или "полуватоматические" открытия светофоров. То есть светофоры должны открываться либо вручную, либо маршрутизациями zxPath или RE sU DSP. Варианта данной сигналки под а-ля дефолтное управление реализовываться не будет.
Условие наличия кодов на стрелках при движении по горловие при приёме - "кодирование от светофора" во входном + "кодирование съездов" на выходных прямого и обратного направлений этого пути. Условие наличия кодов на стрелках при отправлении - "кодирование съездов" на выходных прямого и обратного направлений + "кодирование до светофора" на входном.
Преимущества:
1) динамический розжиг (на светофоре можно развесить практически любой набор линз в любом порядке)
2) возможность копи-паста скоростных ограничений из светофора в светофор
3) опциональная установка маршрутного указателя и стрелок короткого блок-участка (в том числе одновременно) на любой из доступных мачтовых светофоров
4) отсутствие станционных контроллеров - все настройки производятся непосредственно в светофоре
5) возможность вращать головку и её крепление на любой угол
6) регулируемое расстояние до оси пути и высоты над уровнем головки рельса (в широких пределах)
7) выкалывание любых линз у мачтовых светофоров (ограничение - в 3-линзовой головке можно выколоть только одну из линз)
8) шрифт табличек светофоров создан на основе трафаретов, приведённых в "Руководстве по эксплуатации щитков (литерных табличек)"
9) При подписывании карликовых светофоров скрипт автоматически отделяет номер пути в нижнюю строку табличек
10) высокая степень оптимизации, на порядок превосходящая таковую у z7
11) все типы комбинаций линз, указанные в "типовых проектах", добавлены в стандартные наборы розжигов светофоров
Преимущества маршрутизации zxPath
1) автоматизирует замыкание маршрута - перевод стрелок, открытие сигналов и изменение направления перегона происходят автоматически
2) возможность работы на станциях любой сложности
3) снятие некоторых ограничений, которые имела z7-xPath (например теперь возможна работа перегона на петле вокруг станции)
4) три типа поездных маршрута-
а) "стандартный" - маршрут будет замкнут как только освободятся все рельсовые цепи и установлено необходимое направление перегона, разбирается при проследовании поезда
б) "очередной" - маршрут будет замыкаться так же как и "стандартный", но только после того, как замкнётся предыдущий маршрут по этой же станции
в) "авто" - маршрут, самовозобновляющийся после проследования поезда (эмулирует "автодействие" светофоров)
5) возможность замыкания маневровых маршрутов путём ввода названий светофора начала и конца маршрута, в пределах парка станции или до ближайшего светофора соседнего парка
6) "маневровый маршрут на свободный путь" - маневровый маршрут не строится, если на пути, к которому он должен быть построен, есть ПС
7) набор правил и команд и автоматического выбора и замыкания маршрутов поездам
8) система приоритетов поездных маршрутов, позволяющая автоматически выбирать путь приёма из числа свободных с учётом категории прибывающего поезда
9) значительно более высокая, чем у z7-xPath, стабильность работы
Исходники моделей светофоров старого образца - https://yadi.sk/d/n6PSaij330Uea (автор исходных моделей - Rokky)
О настройке розжига:
В качестве примера, убирание зелёной линзы из 5-линзовика...
1) выставляем режим, наиболее близкий к необходимому (чтоб потом меньше мучаться)
2) нажимаем на "линзовый набор". Появляется строка розжига.
3) поясняю что здесь что. В строке, по порядку, задаются расположение линз:
первый символ в строке соответствует краной линзе. В данном случае этот символ - цифра 2, это значит что красную линзу надо повесить в 3е гнездо на светофоре, начиная от верха мачты (тут нумерация не с 1, а с 0, поэтому 2+1 = 3 ), что мы собственно и видим - красная линза под 3им козырьком
второй символ соответствует основной зелёной линзе. Это цифра 1, то есть линзу вешать во второе гнездо от верха мачты.
третий соответствует дополнительной зелёной линзе, используемой в сигнале "два зелёных" - в этом розжиге не вешается ни в какую ячейку, так как символ - прочерк.
четвёртый соответствует основной жёлтой линзе. Это 0, то есть линза в самом верхнем гнезде.
пятый соответствует дополнительной жёлтой линзе (нижняя для сигнала Жм-Ж). Это цифра 3, то данная линза в 4ом гнезде.
шестой соответствует второй дополнительная жёлтая линза (для сигнала три жёлтых). На светофор эта линза не вешается.
седьмой соответствует основной белой линзе (которая зажигается для маневров). Это 4, то есть линза вешается в 5ое гнездо сверху.
восьмой соответствует белой линзе повторительной головки (если используется и основная, и повторительная линзы на одном светофоре, то светофор будет давать сигнал "два белых".) Там прочерк, то есть линза не ставится.
девятый символ соответствует синему огню, на светофоре его тоже нет.
И последний, десятый символ указывает на расположение зелёной полосы (да, система могла бы повесить полосу в любое гнездо на светофоре ), но пока что светофоры для неё и она сама не готовы .
Итак, мы хотим убрать из нашего светофора зелёную линзу. Это значит в её символе строки розжига (тоесть втором) надо указать прочерк.
Указали, теперь можно подтвердить строку розжига и проверить результат (после установки розжига светофор светит всеми линзами). Зелёная линза пропала вместе со своим козырьком.
Остаётся добавить в опции галочку "выходной" и светофором можно пользоваться...
Информация
после задания нестандартного розжига заново выставляйте назначение светофора
Совмещение "выходного" и "не участвует в рельсовых цепях" используется, если нужно сделать невидимый выходной из парка с групповым светофором и повторителями.
Использование опции "не участвует в рельсовых цепях" вместе с "автооткрытие" нужно для повторительного, предупредительного, либо для светофора, в точности повторяющего показания невидимых светофоров.
Для маршрутного с синим (и жёлтым, зелёным) нужна опция "маршрутно-разделительный".
Для заградительных (кроме совмещённых маневровых с заградительными) и совмещённых предупредительных с заградительными нужны опции "не участвует в рельсовых цепях", "автомат без маневрового режима" и "заградительный".
Для маневрового с розжигом БСК нужна опция "выходной/маршрутный" либо, если это совмещение маневрового с заградительным, опции "маневровый без поездного режима" и "заградительный".
Опция заградительного "перекрывает соседние светофоры" убирается в том случае, если его закрытие не приводит к перекрытию предыдущего поездного светофора. Например, для ограждения переезда на перегоне с ПАБом.
Информация
Если светофоры расположены в слое карты, при изменении настроек перезаписывайте карту, а не сессию.
Информация
На кольцах , где нету входных и выходных светофоров (только маневровые, либо только проходные) обязательно расставлять маркеры-прерыватели автоблокировки.
Информация
Маневровые маршруты из одного парка в другой не строятся. Необходимо строить маршрут до ближайшего светофора соседнего парка и только затем от него до конечного светофора.
Информация
Для ограждения переезда в пределах горловины станции рекомендуется применять невидимые заградительные, либо совмещённые маневровые с заградительными.
Использование букв в МУ.
В маркеры с опцией MRN допустимо заносить арабские цифры и следующие значения в качестве номера пути:
Буквы:
А А
Б B
В V
Г G
Д D
Е E
Ж J
И I
К K
Л L
М M
Н N
О О
П P
Р R
С S
Т T
У U
Ф F
Х H
Ц C
Ч Q
Ш X
Э e
Ю Y
Я Z
Римские цифры:
I a
II b
III c
IV d
Положения:
\ l
/ r
| f
- h
Э e
Пример подключения обработчика проездов светофоров поездами
вариант 1
Код:
include "Trackside.gs"
include "zx_specs.gs"
class sUsniffingObject isclass Trackside, zxExtraLinkBase // унаследоваться и от класса zxExtraLinkBase
{
public void Init(Asset asset)
{
inherited(asset);
zxExtraLinkContainer contaner = new zxExtraLinkContainer();
contaner.extra_link = cast<zxExtraLinkBase>me;
GSObject[] GSO=new GSObject[1];
GSO[0] = cast<GSObject>contaner;
KUID sUcoreLibKUID = asset.LookupKUIDTable("sU_core_lib");
World.GetLibrary(sUcoreLibKUID).LibraryCall("add_extra_obj_base",null,GSO);
}
public void UpdateSignalState(zxSignal zxsign, int reason, int priority)
{
// и при проездах любых изостыков/светофоров будет вызываться аналогично вызову UpdateState() в светофоре/изостыке, сразу после исполнения этого вызова в самом светофоре + передаётся этот светофор
Interface.Print("signal "+zxsign.privateName+"@"+zxsign.stationName+" changed for "+reason+ " priority "+priority);
}
};
вариант 2
Код:
include "Trackside.gs"
include "zx_core.gs"
class sUsniffingObject2 isclass Trackside, zxExtraLinkBase // унаследоваться и от класса zxExtraLinkBase
{
public void Init(Asset asset)
{
inherited(asset);
KUID sUcoreLibKUID = asset.LookupKUIDTable("sU_core_lib");
Library lib = World.GetLibrary(sUcoreLibKUID);
lib.LibraryCall("",null,null); // для возможного запуска
(cast<zxLibruary_core>lib).AddExtraLink(cast<zxExtraLinkBase>me);
}
public void UpdateSignalState(zxSignal zxsign, int reason, int priority)
{
// и при проездах любых изостыков/светофоров будет вызываться аналогично вызову UpdateState() в светофоре/изостыке, сразу после исполнения этого вызова в самом светофоре + передаётся этот светофор
Interface.Print("signal "+zxsign.privateName+"@"+zxsign.stationName+" changed for "+reason+ " priority "+priority);
}
};
Последний раз редактировалось TRam_; 22.02.2022 в 01:40.
Меня всё более занимает идея внешней СЦБ. Мало того, что в таком виде легче реализовывать сложные специфичные зависимости, так ещё и внутри трс оптимизация будет работать так, как этого хочет Ауран.
Может кто-нибудь потыкать в них палочкой, чтобы они протокол открыли?
kemal, а что с подгрузкой карты? Ибо что-либо делать с тем, что даже не подгружалось с жёсткого диска, невозможно, не говорю о сохранении свойств.
P.S. аурановцы были почти готовы передать расчёты физики состава, через TrainzNativeInterface, но отклика от нас не последовало, ибо непонятно что они готовы были дать. С СЦБ будет аналогичная ситуация (ну допустим дадут доступ к графам путевых объектов, к событиям проезда поездов, но без доступа непосредственно к путевым объектам это ж ничего не даст)
Последний раз редактировалось TRam_; 25.05.2019 в 01:02.
Тут немного другой подход.
Вообще, изначально это задумка для мультиплеера. Чтобы один из игроков подключался с альтернативного клиента и брал на себя реализацию логики ЭЦ. Потому что, например, пытаться реализовать ДК или ГИД средствами только ТРС - тщетная затея. А тут такой потенциал! При этом, события проезда объектов и, возможно, даже контроль свободности останутся в ТРС.
С доступом к графу сложнее. С одной стороны, мне, со своей степенью задротства, не влом спроектировать каждую станцию отдельно и увязать с ТРС по именам объектов. С другой стороны, граф достать можно из файлов trk и obs. Могу написать прогу, которая что-нибудь достаёт. Надо? Более того, можно оставить расчёт маршрутов как сейчас и экспортировать уже готовый суп.
С доступом к не загруженным объектом, я считаю, у нас неправильный подход. Мы не так ставим вопрос. Важно не почему нам не подходит такая модель оптимизации (а она очень хорошая, сама по себе), а почему в неё не укладываемся мы. Этот подход подразумевает, что то, чего никто не видит - не существует. И это правильно. Проблема в том, что "наблюдателями" считаются только машинисты. У нас же есть ещё ДСП (в лице живых игроков или правил/команд) - он может совершить действие, когда поезд ещё только далеко на подходе. Поэтому и имеет смысл считать СЦБ отдельно - там, где она будет существовать всегда. Вопрос как быть с тем, что объекты не загружены. А никак! Они нам не нужны. Нужен ли нам сам светофор или левер при задании маршрута? Нет, нас интересует только положение стрелок и наличие открытия светофора. Если в момент задания маршрута объекты существуют - мы применим к ним действие, если нет - то ничего не делаем. А вот когда к этому месту приедет машинист, светофор подгрузится и запросит у ЭЦ своё состояние.
А вот когда к этому месту приедет машинист, светофор подгрузится и запросит у ЭЦ своё состояние.
Перед светофором должна подгрузиться стрелка, которая должна после этого перевестись, и только после этого подгрузится светофор (или же опять же ещё стрёлки). Ну а вообще нечто подобное я представлял в виде очередей команд, которые у объектов накапливаются, пока они выгружены, и при подгрузке обрабатываются.
Но для того, чтобы это всё работало, в СЦБ уже должен быть свой собственный независимый граф всех требуемых объектов карты со всеми необходимыми свойствами. А с его прогрузкой и/или скоростью обработки будут проблемы опять же с таймаутами.
И вопрос с получением такого графа опять же никуда не делся.
---------- Сообщение добавлено в 02:20 ---------- Предыдущее сообщение размещено в 02:04 ----------
Сообщение от kemal
Могу написать прогу, которая что-нибудь достаёт.
хотелось бы прогу, которая достаёт абсолютно все зависимости карты и сессии
а круче если ещё и тип объектов, чтобы подменные куиды выявлять
Последний раз редактировалось TRam_; 25.05.2019 в 02:06.
Я давно высказывал мысль. Попробую ещё раз донести.
Есть два постулата, при которых не возможна работа основных принципов ZxPath, это:
1) Большая часть объектов на карте, в один конкретно взятый момент времени, не существует
2) Нельзя ни узнать состояние, ни поменять состояние, объектов, которых нет.
Не может маршрутизация работать с тем, чего нет. Что мы можем с этим сделать? С тем, что не существует, мы ничего не можем сделать, но мы можем заменить не существующие, чем то своим, тем, что всегда будет доступно. Необходимо создавать некий кэш, с которым и будет работать маршрутизация. В кэше хранить некую схему всех станций и перегонов, какая стрелка за какой следует, набор стрелок между каждой парой маршрутных светофоров, между какими стрелками находится каждый маневровый светофор и т.д.
И работать маршрутизация должна с этим кэшем. Смотреть, какие маршруты на данный момент построены, строить новые, разбирать старые. Т.е. маршрутизация не должна в режиме машиниста, нуждаться в получении информации от светофоров и стрелок. Маршрутизация должна работать только с кэшем.
А вот дальше, каждый светофор при подгрузке должен смотреть в кэше, какой у него будет сигнал, и дальше мониторить кэшь раз в секунду, и менять своё состояние в соответствии с кэшем. Со светофорами вообще никаких проблем нет, у светофоров есть скрипт, который можно научить работать с кэшем. Остаётся вопрос что делать со стрелками.
Можно сделать отдельное правило, которое будет заниматься переводом стрелок. Каждый светофор, при подгрузке на карту будет отсылать сообщение этому правилу, что мол, я подгрузился. Ну и простая логика, если прогрузился светофор, значит прогрузились и все стрелки до него. Значит можно их переводить в соответсвии с кэшем.
Ну а с отслеживанием движения ПС проблем быть не должно. ПС не движется по не существующим стрелкам, вокруг движущегося ПС, существуют и стрелки и светофоры. Можно сделать отдельное правило, которое будет отмечать в кэше положение ПС.
Общая схема вырисовывается такая:
- Маршрутизация работает только с кэшем, схема/объекты в котором создаются один раз в редакторе и не меняются в режиме машиниста, меняется лишь их состояние.
- Каждый светофор отслеживает кэш, и соответственно меняет своё состояние
- Стрелки переводит отдельное правило. О подгрузке стрелок правило узнаёт от светофоров, по логике, подгрузился светофор, подгрузились и стрелки до него.
- Реальное положение ПС и отмечание его в кэше, производит ещё одно правило.
Как то так. Да, это уже абсолютно новая маршрутизация. Да, кажется лютым гемором и одними большими костылями. Но она сможет жить и работать при двух вышеизложенных постулатах.
Последний раз редактировалось Volaner; 25.05.2019 в 12:37.
Volaner, выше ж уже написал, что проблема в загрузке/сохранении кэша. Итак уже kemal предлагал децентрализацию маршрутизации, только чтобы уложиться в приемлемое время прогрузки/сохранения данных (которые trainz умеет хранить только в текстовом виде), хотя я храню только штук 6-7 свойств самих стрелок и имена ближайших к стрелке объектов. А в предлагаемой тобой конструкции нужно хранить не только это, но и "к какому следующему светофору стрелка ведёт", такую же базу данных для светофоров и ограничений скорости. Ну и как искать... Если у нас всё оставлять в текстовом виде (чтоб проще сохранять) - уйдём в таймауты при постоянном преобразовании текста в данные и обратно. Если сделаем в виде структур - таймауты будут при загрузке/сохранении.
Продолжаю осигналивать карту "Череповец - Вологда". Дело идёт медленно.
Вот такой вот затык:
Светофор НД, на мой взгляд близковато к ящику СЦБ(Вроде так это называют). Но фокус в том, что я не могу подвинуть его в редакторе, двигается только объект рядом, а светофор никак.
И туда же (на зелёный маркер) кликать для просмотра настроек. В ТАНЕ и 19ке кликать по тому месту, где появляется надпись названия этого светофора (как правило в том месте, где была мачта светофора в несмещённом состоянии).
---------- Сообщение добавлено в 18:49 ---------- Предыдущее сообщение размещено в 18:48 ----------
И да, "сквозь провода" клик может не сработать, нужно нажимать над или под сплайном проводов.