Команды машинисту. Как они создаются?
 

Всем привет! У меня идея из области написания команд машинисту. Цель - создание некой универсальной команды, с помощью которой можно будет разводить несколько поездов на многопутных станциях по разным путям, которые заведомо неизвестны. Вот, существует довольно таки хорошая вещь как Path Control. Кто знает, тот сразу поймёт о чём речь, а для тех, кто не знает я вкратце поясню его предназначение.
Суть его в том, чтобы как команду машинисту задать в определённый момент команду сборки маршрута на определённый путь станции или с такового. В режиме редактора, в списке правил открывается это правило на редактирование и наглядно, с помощью мышки создаётся, например, маршрут прибытия на станцию. После задания определённого светофора по его идентификатору, например входной светофор как StationIn1? в специальном окне создаётся весь путь стрелок от этого светофора до следующего в соответствии с тем, как стрелки установлены в редакторе по умолчанию. Затем, кликая мышкой по стрелкам можно задать их то или иное положение, в зависимости от того, на какой путь нужно собрать маршрут. Потом этот маршрут сохраняется под определённым названием, например ЧетныйВходящийНа3йПуть. Таким образом программа как бы запомнила какие стрелки в каком положении должны будут быть после того, как будет подана команда Собрать маршрут -> Ждать/не ждать пока он соберётся -> ЧётныйВходящийНа3йПуть. На перегоне, логичнее всего ставить сразу после 3-го светофора от станции при 4-х значной сигнализации и сразу после 2-го светофора при 3-х значной сигнализации, ставится маркер. В командах машинисту ставится команда проследовать этот маркер, а затем вот та самая команда сборки маршрута. Таким образом, поезд прибывает на нужный нам путь.
Так вот у Path Control есть существенный недостаток. Можно задать только один путь прибытия. И если он занят, то маршрут будет пытаться собраться до тех пор, пока он не освободиться. Выглядит это как периодическая сборка и разборка в исходное положение стрелок маршрута на 3-й путь. Так вот есть желание сделать подобную систему, только в настройке маршрута прибытия иметь возможность задать несколько альтернативных путей прибытия - на 3-й или на 4-й или на 5-й или на 6-й ... пути станции. А дальше уже срабатывает логическое Если и ИЛИ. То есть, если занят 3-й путь, собирать следующий из указанных на сборку маршрутов, если и этот занят - следующий и т.д. Можно даже и закольцевать. Есть и ещё один недостаток Path Control. Что как если 3-й наш путь свободен, но на него уже собран маршрут с противоположной стороны под встречный поезд? Особенно это актуально на однопутных участках. Path Control ничenm не смущаясь соберёт обоим встречным поездам маршрут прибытия на одни и тот же путь. Лишь бы на момент сборки 3-й путь был свободен. Поискав на Aurane какое-нибудь подходящее под эту идею правило, я так ничего и не нашёл (зато нашёл много чего интересного другого, но об этом как-нибудь в другой раз). Поэтому возникла идея создать это самому. Но опыта программирования для ТРС у меня нет, то бишь абсолютный 0. Однако опыт программирования на разных языках кое-какой имеется, поэтому, думаю в состоянии освоить и разобраться в языке (скриптов, наверное, да?) для ТРС. А вот в каком направлении двигаться, даже не знаю. Из того, что уже успел почерпнуть на форумах, предполагаю, что для этого есть какое-то отдельное приложение, вроде CMP для, в том числе, импортирования объектов. Если это так, то что это за дополнение такое, где его взять и на каких условиях и, конечно же, мануал. Пусть даже и на английском - разберусь.
Конечно же, в основном это касается разработчиков, RMM, например. Ведь объеты тоже создавались не на коленках и не с потолка, верно? Я имею ввиду стрелки.
В общем, что вы об этом всём думаете и сможете ли помочь, а? Ну пожааалуйста! :o

как известно, скрипт Path Control зашифрованный, а значит смотреть мы его не можем. Поэтому предлагаю начать с описания возможностей, которые удалось реализовать нашему гениальному соотечественнику Евгению Варванину (Varzу) на примере z6, которая почти этим и занимается.

Итак, эта сигналка при "просчёте маршрутов" определяет какие стрелки надо переключать и за какими маркерами следить, чтобы собрать маршрут. Поэтому проверку "а можно ли собрать маршрут от выходного до входного" лучше предоставить ей (в перспективе - з7). Затем нужен глобальный массив, который содержит информацию о занятости (или не занятости) станционных путей (не маневровых), и, дублируя сигналку, проверяет "заявки на создание маршрута". Т.е. должна выполняться одновременно только 1 заявка на 1 путь, если он свободен.

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

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

А вообще всем интересующимся сигналками и маршрутами предлаегается внимательно изучить скрипты Z6 - это полезнее всего.

Чтоб хоть что-то понять, скажу что поток, обрабатываемый функцией "AddHandler" становится "ловителем" всех сообщений, посылаемых объекту, стоящему 1 в аргументах этой функции, с "майорами" и "минорами" (основное и дополн. "имена" сообщения). 4 аргументом является название этого потока

От себя добавлю, что стрелки RМM просто при прохождении любого сообщения, связанного с стрелкой, проверяют её направление (право или лево), и соответственно меняют остряк (и рычаг, если есть), не более...

Напомню, каждая стрека рассылает всем сообщения о том, что

а) на неё наехал поезд
б) её перевели
в) с неё съехал поезд
и что-то ещё. Так что смотрите z6, а в API раздел justion, а также "мультипоточность"(multythreading), "сообщения" (messages) и раздел "хендлеры"

[QUOTE=TRam_;65682]Итак, эта сигналка при "просчёте маршрутов" определяет какие стрелки надо переключать и за какими маркерами следить, чтобы собрать маршрут. Поэтому проверку "а можно ли собрать маршрут от выходного до входного" лучше предоставить ей (в перспективе - з7). Затем нужен глобальный массив, который содержит информацию о занятости (или не занятости) станционных путей (не маневровых), и, дублируя сигналку, проверяет "заявки на создание маршрута". Т.е. должна выполняться одновременно только 1 заявка на 1 путь, если он свободен.
[/QUOTE]
Ну, это сигналка. Там всё несколько сложнее, поскольку в зависимости от того, куда именно собран маршрут загорается тот или иной сигнал. А это слежение за маркерами отклонения или наоборот прямого маршрута или неправильного пути. И в принципе, выход со станции действительно можно доверить и ей, хотя тоже возникает ряд ньюансов.
[QUOTE]
Кроме того, должен быть массив, содержащий ссылки (или идентификаторы) стрелок, а также текущее состояние стрелки (свободна, замкнута в маршруте и "замкнута в маршруте, но поезд проехал"). Всё это необходимо потому, что самый распростанённый метод "не собрался маршрут - жди 5 с" здесь лучше не использовать, т.к. приятнее (и много быстрее) проверять "если часть стрелок маршрута занято, то ждать сообщения о том, что наш поезд съехал со всех стрелок, которые будут использованы в новом маршруте".
[/QUOTE]
А нельзя ли просто проверить на "заблокированность" всех стрелок потенциального маршрута и создавать массив именно заблокированных стрелок и ждать сообщения именно от них? Кстати, здесь ещё один момент. Так называемая "очередь" из маршрутов. В Path Control это каким-то образом работает. Наверное всё же следить нужно за всеми стрелками потенциального маршрута, потому как только что свободная стрелка может стать вдруг заблокированная. Поэтому без метода "не собрался маршрут - жди 5 с" боюсь тут не обойтись.
[QUOTE]
А вообще всем интересующимся сигналками и маршрутами предлаегается внимательно изучить скрипты Z6 - это полезнее всего.
[/QUOTE]
Каким макаром? Где нужно открыть скрипты, чтобы это всё увидеть?
Да и как быть с авторскими правами, хотя тут менять то никто ничего не собирается. А кроме того, z6 всё же не расчитана на работу с дефолтными командами машинисту, поэтому тут несмотря на всю полезность такого мероприятия, много останется невыясненных вопросов.

[COLOR="Silver"]мля народ, ну пожалейте читающих, осилить монолитный текст сложно, глаза по строчкам пролетают. Ну и конкретно спросить нельзя чтоли, зачем строчить километровые посты? И так ясно, что надо читать ССГ, АПИ, смотреть готовые образцы типа з6(7)[/COLOR]

скрипты, если они не зашифрованы, открываются в любом текстовом редакторе (я свои 1000-строчные скрипты до сих пор делаю в блокноте)
Лично с моими авторскими правами скриптов DLC и проч. ты не столкнёшся, так что об этом не беспокойся. И ещё - если ты "втихаря у себя на компе" перерабатываешь чужие скрипты, никто тебя и не заметит. Главное - чтоб при выкладке не забывал указать всех авторов, которые хоть что-то писали в этом скрипте - тогда замечаний ни от кого не услышишь

Привет. Кстати все зашифрованные скрипты открыты в Классик v3.
И упоминавшийся скрипт тоже.

[B]Сергей12[/B] Оппа! а поподробнее с этого места можно? Как вообще скрипты открываются? Вон, TRam говорит, что они открываются в блокноте. А при чём здесь тогда компоновка приложения?
[B]genesis[/B] Перестань, короткими бывают только анекдоты. А если, как известно, хочешь получить вразумительный ответ, задай вразумительный вопрос.
[B]TRam_[/B], я же упоминал, что в скриптах полный ноль. Я могу открыть исходник в С, могу в 1С открыть. Где это файл, который открывается? И самое главное, как понять в том тексте какие процедуры и функции предопределённые, а какие пользовательские; какие аргуметы функций обязательны (и что они означают), а какие "передаваемые"? Плюс работа с объектами: каковы их свойства, как они читаются и меняются ну и т.д.
P.S. Только что по вестям увидел: наши КАМАЗы в 8-й раз стали победителями "Париж-Дакар". С ума сойти! Что-то тут не то. Наверняка там от "Камаза" только название на решетке. :-))

[url]http://www.railunion.net/post155996.html#p155996[/url]

[QUOTE=NickLon;65728]Только что по вестям увидел: наши КАМАЗы в 8-й раз стали победителями "Париж-Дакар". С ума сойти! Что-то тут не то. Наверняка там от "Камаза" только название на решетке. :-))[/QUOTE]

[COLOR="Indigo"][оффтоп]
Ну в общем - да. А побеждают они потому что этот дакар называют "самым престижным ралли-рейдом" чисто за не имением других ралли-рейдов. На самом деле он давно выродился в унылый междусобойчик, к которому участники (и пилоты и команды) относятся скорее как к возможности потусить. А наши там как латышские партизаны: война давно закончилась, но не для них :)
[/оффтоп][/COLOR]