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

[TRam_]

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

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

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

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

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

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

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

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

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

[NickLon]

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

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

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

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

А нельзя ли просто проверить на "заблокированность" всех стрелок потенциального маршрута и создавать массив именно заблокированных стрелок и ждать сообщения именно от них? Кстати, здесь ещё один момент. Так называемая "очередь" из маршрутов. В Path Control это каким-то образом работает. Наверное всё же следить нужно за всеми стрелками потенциального маршрута, потому как только что свободная стрелка может стать вдруг заблокированная. Поэтому без метода "не собрался маршрут - жди 5 с" боюсь тут не обойтись.

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

Каким макаром? Где нужно открыть скрипты, чтобы это всё увидеть?
Да и как быть с авторскими правами, хотя тут менять то никто ничего не собирается. А кроме того, z6 всё же не расчитана на работу с дефолтными командами машинисту, поэтому тут несмотря на всю полезность такого мероприятия, много останется невыясненных вопросов.