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

[vicente]

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

WR? Вроде говорилось про зеленый...

Ждём уточнений, короче.

[КЕ]

Там стоит T_Signal_Small_GR.s - неправильно, это тупиковая станция, должен быть маневровый К-Б.
T_Signal_Small_GR.s имеет одну голову:

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

SCRIPT T_Small_GR

extern float block_state ();
extern float route_set ();
extern float next_sig_lr ();
extern float next_sig_mr ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float enabled;
extern float sig_feature ();
float next_state;

state = 1;
if (enabled && (block_state() == BLOCK_CLEAR))
{
next_state = next_sig_lr (SIGFN_NORMAL);
if ((next_state == 0) || ((next_sig_mr (SIGFN_NORMAL) == 1) && (next_state == 2)))
{ state = 2; }
else
{ state = 7; }
}
draw_state = def_draw_state (state);

В этой горловине все - карлики T_Signal_Small_GR. Но их там не должно быть, дальше движение только маневровое (в тупик или на подъездные пути).
И этот светофор не даст зайти под состав. Он открывается, только если БУ свободен (поэтому вообще непонятно, зачем в его скрипте прописан маневровый аспект, хотя в конфиге геометрических параметров белого огня нет).
И опять как всегда, в логе - ошибки сигнализации.

[vicente]

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

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

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

Немного оффтопа в теме по сигнализациям MSTS - "закончу" тему по С# скриптам в Open Rails - два дня штудирую Шарп и источники кодов и ещё кучу всего. Пока, по крайней мере относительно меня - отбой и "обе машины - стоп". Сыро. Разработчики вставляют только тот функционал, который они считают нужным для целей, для которых и переводят сигналку на С#. Большинство функций sigscr.dat , насколько я врубился в это дело, в С# будут недоступны.
Но, Шарп буду продолжать изучать

[КЕ]

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

... переводят сигналку на С#. Большинство функций sigscr.dat , насколько я врубился в это дело, в С# будут недоступны.

Но тогда смысл?..
_________________
Короче - выкинуть нафиг оттуда эти светофоры, и установить маневровые К-Б.
И выпустить патч.

[vicente]

Я уже писал: кое-кому из разрабов не хватает сообразительности... терпения... знаний С/С++ ... желания программить в sigscr.dat аспектов и ещё, там, разные отмазки были

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

Мы разрабатываем некоторые сценарии сигналов для воссоздания испанских систем сигнализации, и мы обнаружили, что SIGSCR немного ограничивает. (...) Вот некоторые из причин, по которым, по нашему мнению, может быть полезен C #:

*** 8 аспектов MSTS недостаточно для представления всех аспектов сигнала (например, в Испании у нас есть до 16 различных аспектов). Каждый сигнал показывает подмножество общих аспектов, поэтому обходным путем является повторное использование одного и того же аспекта MSTS для разных аспектов. Однако это вызывает проблемы с продвинутыми системами управления поездом, такими как ETCS, которые будут предпринимать разные действия в зависимости от аспекта сигнала. (...)

*** Сигналы трудно отлаживать людям, не знакомым с кодом OR. Использование C # позволяет использовать Console.WriteLine (), что полезно для простой отладки логики.

*** Нет связи между сигналом и последующим. В испанской сигнализации есть одна конкретная ситуация, когда второй сигнал должен быть ограничен до тех пор, пока первый сигнал не будет очищен более 10 секунд, когда эта функция требуется. Я добавил вызов функции SendSignalMessage, который отправит строковое сообщение требуемому сигналу.

*** Работа с глобальными переменными утомительна, потому что их нужно читать и сохранять при каждом обновлении.


*** Некоторые из проблем могут быть решены с помощью существующего интерфейса SIGSCR (например, количество доступных аспектов может быть расширено, как это делается с помощью определений SIGFN_ и SIGSUBT_), но другим потребуется уделить много времени синтаксическому анализатору SIGSCR.

[КЕ]

Ну понятно, там свои запросы. Но sigscr.dat останется?

[vicente]

Да, конечно.
Более того, в С# можно будет писать отдельно-взятую сигнальную голову. Сим будет прежде всего проверять наличие скрипта в С#, если не найдёт - sigscr.dat в папке OpenRails , если и там нет - в корневой папке MSTS . Вот такой, вот, геморрой

[КЕ]

То есть какой-то субобъект можно описать отдельным скриптом на С#, а все остальное в sigscr, так?

[roman5]

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

И опять как всегда, в логе - ошибки сигнализации.

А речь про какой лог, в скрипте не вижу debug_out2 функций, сам msts вроде лог не делает. Или это про OR ?

[vicente]

Они говорят о Signal Type. Получается - так. Сначала программа ищет его в С#, причём, компилируется это дело в реальном времени - в процессе запуска игры. Если в скрипте на С# есть ошибки или нет такого скрипта для одноименного типа, заявленного в sigcfg.dat, тогда программа обращается к sigscr.dat .
Мне тоже многое пока непонятно. Как быть с заявленной конфигурацией в sigcfg.dat ? С буржуйскими дополнительными аспектами тоже не всё так просто. 8 "родных" MSTS -овских аспектов остаются. Они "двигают" поезда AI (трафики), они выводятся на CabSignal дисплей и т.д. То, что они придумали - некий "текстовый" аспект (обзывай, как хочешь) и этими аспектами светофоры обмениваются как сообщениями. Бррр...
Говорю же, ПОКА, повторюсь, ПОКА, функционал разнообразием не блещет, а класс "наследуется" из нового файла source - ещё вопрос или я могу "снимать" нужные мне внешние функции через включение соответствующего совершенно другого *.cs -файла. Если да - можно будет подумать о каких-то отдельных, особых головах в С#. Но, вряд ли, в том виде, в котором оно сейчас. Но, поиграться можно на досуге (пока этого длсуга у меня нет).

[КЕ]

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

А речь про какой лог, в скрипте не вижу debug_out2 функций, сам msts вроде лог не делает. Или это про OR ?

Да, лог OpenRails или RTrainSim - удобно "косяки" искать.

[roman5]

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

То, что они придумали - некий "текстовый" аспект (обзывай, как хочешь) и этими аспектами светофоры обмениваются как сообщениями.

Ну это удобно для расширения функционала, отладки.

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

класс "наследуется" из нового файла source - ещё вопрос или я могу "снимать" нужные мне внешние функции через включение соответствующего совершенно другого *.cs -файла.

По идее да, но разве они недоступны в классе, от которого наследуешь свой класс ?

[vicente]

Нет. Там урезано "под разработку". В смысле, им не нужна зависимость от next_sig_lr (SigFn_Type) - к этой функции не привязаться. Можно давать каждому аспекту "параллельно" ещё и текстовый аспект и сделать зависимость от этого текста, но преимуществ в этом я не вижу. Есть переменные в sigscr.dat . Но, это пока. Преимуществом может быть функционал С#, какие-то вещи, которые в sigscr.dat нельзя делать... Но, посмотрим. Пока что, программирование на С# даже в тестовые релизы не включено.

[Predator]

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

Хм... похоже, маневровый NORMAL WR (?) . У него есть одна интересная деталь. А можно скриншот редактора сценариев и на нем указать место, на котором сделан предыдущий скрин и как-то выделить/обозначить PATH этого сервиса. Сразу обозначу подозрение. Если светофор - тот, о котором я говорю и дальше есть противошерстная стрелка не по марщруту - будет красный

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

Ждём уточнений, короче.

Пара скринов из редактора сценария:
Скрин № 1:

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

Скрин № 2:

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

Проблемный светофор:

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

[КЕ]

Светофоры не те расставлены. Нет смысла биться об эту "стену" - надо заменять светофоры и выпустить патч. Я серьезно.