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

[КЕ]

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

...Один из разработчиков на буржуйском форуме писал, что у него все сигналы АБ с -1. То есть, он с выходого "энэйблит" сразу входной следующей станции независимо от количества блок-участков.

Вот если бы это было в МСТС - победили бы "вечный красный" в сценариях.

[vicente]

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

[vicente]

Жаль, у Игоря Заборина на форуме все картинки потерялись. Там в первых двух темах мы на тестовом участке строили автоблокировку однопутную. Так вот, на "чистом" тестовом маршруте, при правильном старте обоих сервисов в противоположных направлениях МСТС прекрасно блокировал стрелку "скрещения" через светофоры, которые были ещё !enabled ! Да-да. За пределами SNCA. В дефолтных маршрутах обрати внимание как "издалека" стартует трафик. На старте игрока НИКОГДА трафики не пересекают Path игрока. Если и есть трафик на старте сценария, он всегда идёт по параллельному, не имеющему общих точек с игроком пути.

[КЕ]

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

... За пределами SNCA...

И что тогда выяснили - на какое расстояние сим прокладывает маршрут сервису? Это зависит от количества блок-участков, или там километры?

[vicente]

Маршрут сим прокладывает на SNCA, но "агрит" сигнал перед ближайшей "совместной" точкой (стрелкой) за SNCA+1. То есть, кто первый "агрит" один из въездов на "совместное" звено пути, тот "получает" его. Будь то стрелка или перегон. В случае с перегоном количество блок-участков значения не имело. Да, Игорь говорил о расстояниях, но я не проверял как длина полигона меняет суть работы автодиспетчера. Моё мнение - работает всё-таки от светофора к светофору.

[vicente]

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

Вот если бы это было в МСТС - победили бы "вечный красный" в сценариях.

Пока что, уже долгое время, "конфликтные" ситуации, которые у меня время от времени возникают, не связаны с самим симулятором. Разработчики Open Rails очень рьяно работают над исключением ситуации, когда два поезда в противоположных направлениях на одном маршруте не станут друг проив друга на "вечный красный". Например, совсем недавно я по ошибке задал пригородным один и тот же PATH. Разными были только путь приёма и путь отправления на станции, на которой стартовал (хронологически) второй сервис. Так вот, этот "второй" стоял пол-часа и ждал первого. Несмотря на расстояние в почти 30 километров, три станции и с два десятка блок-участков между ними. То есть, блокировки работают по "узлам" (стрелкам, то бишь) пути сервиса - PATH.
С другой стороны, светофоры несомненно учитываются! Поэтому, если скрипт светофора позволяет пропуск на участок, на котором в противоположном направлении другой сервис - бон-войяж. Вчера бился с этой ситуацией на маневровом у себя. На станции в 5 путей из-за того, что режим Timetable Mode и мне не хотелось "прерывать" сервис, при смене локомотива у трафика оба локомотива должны двигаться в противоположных направленияз по одному пути станции. Маневровый сигнал открывает белый на занятый путь, вернее, на "не свободный" поэтому что "несвободность" в Open Rails, как и в MSTS, бывает двух типов: BLOCK_OCCUPIED и BLOCK_JN_OBSTRUCTED. В наших сигнализациях мы привыкли не уточнять эту "незанятость" определением отрицания свободности (block_state() !=# BLOCK_CLEAR). Так оно и определено у меня в скрипте маневрового. И отцепленный лок по белому заходил на путь, по которому на встречу ему двигался сменный.
Справедливости ради, следует отметить, что на тот момент, когда я разрабатывал сигнализацию, этого различия между BLOCK_OCCUPIED и BLOCK_JN_OBSTRUCTED в Open Rails не было. В смысле, не было вообще такого параметра BLOCK_OCCUPIED у функции block_state(). Программа сигнализации в Open Rails писалась "с нуля", так как разработчик не верил в Кужувскую сигнализацию и утверждает, что не было никакой документации на неё (мы знаем, что это не так и все функции расписаны кужувцами в своё время в отдельном документе, не все, правда, работают, но это - другая тема) и в первые годы функция так и работала "да"-"нет". Более того, определение BLOCK_OCCUPIED просто не читалось. С обновлением логики это определение ввели - надо было решать проблему со следованием сервисов, включая трафики на занятые пути, тем не менее, всё, что работало до сих пор, работает и поныне - светофор, который !enabled выдаёт BLOCK_JN_OBSTRUCTED независимо от состояния блока за ним.
Этих тонкостей мы не прочувствовали из-за формы определения зависимости свободности трека block_state() !=# BLOCK_CLEAR, при которой всё, что не BLOCK_CLEAR "подпадает" под определение FALSE. Но, на данный момент, есть большая разница между BLOCK_OCCUPIED и BLOCK_JN_OBSTRUCTED - работа этих параметров приведена, можно так выразиться, в соответствием с документацией самого MSTS:
BLOCK_OCCUPIED - сервис, стоящий неподвижно либо движущийся в том же направлении, что и сервис, для которого "проверяется" светофор.
BLOCK_JN_OBSTRUCTED - положение стрелок не по PATH, то есть сервис не может перевести себе стрелку из-за того, что она заблокирована другим сервисом, а также в случае если в противоположном направлении по тому же PATH движется другой сервис

[КЕ]

То есть теперь можно записать, например:
if (block_state() = # BLOCK_OCCUPIED)
state = STOP_AND_PROCEED;

[vicente]

Именно.
У меня было

if ((...) && (block_state() != # BLOCK_CLEAR))
state = SIGASP_RESTRICTING;

При таком скрипте сервис перед маневровым переводит себе стрелки по маршруту навстречу другому сервису, светофор открывается белым (2) и ничего не препятствует этому сервису проследовать светофор на занятый движущимся навстречу сервисом путь. Ведь состояние block_state() в этом случае BLOCK_JN_OBSTRUCTED, а это не BLOCK_CLEAR и условие выполняется. Если бы стояло if (block_state() = # BLOCK_OCCUPIED), светофор остался бы закрытым.

Добавлено через 46 минут
Как я уже описал, симулятор учитывает программы светофоров. Сервисы в моей ситуации имеют общий путь (Path по одним и тем же секциям пути) от маневрового, через входные стрелки, путь на станции, и расходятся в горловине с другой стороны на двухпутный перегон.
После посановки этого маневрового в запрещающий аспект (0) программно, он (OR) заблокировал сигнал для идущего навстречу сервиса там где пути обоих сервисов расходятся. Т.е. входной на станцию с противоположной стороны.

Добавлено через 12 минут
Таким образом функция block_state () выдаст BLOCK_CLEAR не только если "блок" (участок до следующей "сигнальной точки" - светофора или тупика) свободен от сервисов или статики, но ещё и никакой другой сервис не проложил маршрут через этот самый "блок".

[vicente]

Господа! Кто-нибудь имел счастье в этой или прошлой жизни получить хоть что-то от этих функций?

[КЕ]

Олег, я на днях тестил проходной с условным "Т" - на определенном расстоянии от него (типа тяжелый поезд - длинный поезд) обратностоящий "датчик" в виде DISTANCE-маркера менял state с 0 на 1 при BLOCK_STATE == BLOCK_OCCUPIED. Проходной-Т ловил этот аспект маркера по opp_sig_lr и переходил в state = 2.

[vicente]

Вот и я - о том же. На NORMAL-ах ночью бился с ними всю ночь - не ловит. Его только на DISTANCE можно поймать?

Добавлено через 1 час 51 минуту
Буржуи тоже об этом говорят. Странно. В магуале "от Кужу" написано SigFn_Type. Ладно. Как говаривал Дедушка Ленин в школьных легендах, "Мы пойдём другим путём!"

[КЕ]

Блин, забыл сказать - это в МСТС было. Вот ещё про МСТС, но может, пригодится для чего-то...
Маневровый режим сигнализации обычно "завязан" на аспекты STOP и RESTRICTING. Но при попытке использовать это для манёвров в горловине станций наталкиваемся на неудачу - при выезде за входную стрелку проходной светофор "где-то там на перегоне" переходит из !enabled в enabled, меняет свой аспект из STOP на CLEAR. Точнее, енейблятся все проходные (до входного другой станции - тот остаётся закрытым).
В моём случае это не давало бело-синему маневровому у входной стрелки (направленому на перегон) перейти в SIGASP_RESTRICTING и дать белый при считывании аспекта проходного по opp_sig_lr (у меня этот бело-синий маневовый - типа DISTANCE).
Если же на пути между горловиной и первым проходным будет нулевая стрелка - то проходной остаётся !enabled (потому что стоит за "узлом"), и маневровый сигнал срабатывает как надо.
Таким способом отмеряем нужное расстояние для манёвров, и МСТС теперь "знает" границу станции.
Сейчас погонял пробные сценарии в чётную и в нечётную сторону - да, первый проходной за нулевой стрелкой не энейблится.

Надо теперь в OR попробовать...

[vicente]

MSTS при постановке точки разворота "энейблит" сигнал вне маршрута сервиса? Ты уверен, что он это делает через enabled () ? У меня проходные от этой функции не завися вообще - автоблокировка же. Только на первый проходной ставлю флаг и он, в случае !enabled выдаёт RESTRICTING , чтобы по нему выходной давал тоже RESTRICTING. Вроде, работало это. Много времени прошло уже. Кроме указанного тобой случая "по удалению", когда RESTRICTING невозможно было дать из-за того, что MSTS "энейблит" два светофора после проследования сервиса. В Open Rails сфетофор становится !enabled сразу после проследования, и если нет маршрута по удалению - остаётся таковым.
В Open Rails проблем с белыми RES на выходных у меня проблем не было вообще. Единственная, можно сказать, "смазка" была - в окне диспетчера этот первый проходной был красным (в симуляции я это "подправил" постановкой draw_state в зависимости от занятости пергона и состояния следующих сигналов).

"Нулевая" стрелка, которая нормально "смотрит" в сторону? Да, это решает.

Вот скрипт проходного

SCRIPT KRN23_YGR_3

extern float block_state ();
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;
float has_gradient_plate;
float has_number_plate;

has_number_plate = sig_feature (SIGFEAT_NUMBER_PLATE);
has_gradient_plate = sig_feature (SIGFEAT_GRADIENT_PLATE);

next_state = next_sig_lr (SIGFN_NORMAL);

if (!enabled && has_number_plate)
{
state = SIGASP_RESTRICTING;
if (block_state() !=# BLOCK_CLEAR)
{
draw_state = 0;
}
else if ((next_state ==# SIGASP_STOP) || (next_state ==# SIGASP_STOP_AND_PROCEED) || (next_state ==# SIGASP_RESTRICTING))
{
draw_state = 1;
}
else
{
draw_state = 2;
}
}
else if (block_state() !=# BLOCK_CLEAR)
{
state = SIGASP_STOP; draw_state = 0;
}
else
{
if ((next_state ==# SIGASP_STOP) || (next_state ==# SIGASP_STOP_AND_PROCEED) || (next_state ==# SIGASP_RESTRICTING))
{
state = SIGASP_APPROACH_1; draw_state = 1;
}
else
{
state = SIGASP_CLEAR_2; draw_state = 2;
if (next_state ==# SIGASP_APPROACH_2) draw_state = 4;
else if ((next_state ==# SIGASP_APPROACH_3) || (next_state ==# SIGASP_CLEAR_1)) draw_state = 5;
}
}

[КЕ]

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

MSTS при постановке точки разворота "энейблит" сигнал вне маршрута сервиса? Ты уверен, что он это делает через enabled () ?

Вот именно, что вне маршрута - точка разворота рядом с входной стрелкой. Как только лок проходит стрелку - проходной зеленеет (при !enabled не горит).
Про остальное еще подумаю, сразу не соображу...
_____
В OR пока не могу проверить, на работе древний ноут - OR не установится, там WINXP. Если только старые версии, но в них сигналка работает через ж...

В скрипте "SCRIPT KRN23_YGR_3" каждый draw_state что означает?
draw_state = 0; /// Кр
draw_state = 1; /// Ж
draw_state = 2; /// Зел
draw_state = 4; /// Жмиг
draw_state = 5; /// Змиг
- так?

[vicente]

Так точно


В Open Rails, как я уже упомянул сигнал становится «отключенным» (!enabled) после того, как поезд передает сигнал! Таким образом, после прохождения поезда для функции всегда установлено значение FALSE.

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

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

В

В скрипте "SCRIPT KRN23_YGR_3"

Под number_plate - "флаг", который устанавливается на первом проходном. Только он даёт RESTRICTING-аспект. Остальные показывают обычные аспекты по скрипту.

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

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

В OR пока не могу проверить, на работе древний ноут - OR не установится, там WINXP. Если только старые версии, но в них сигналка работает через ж...

Не парься
Лови рабочий скрипт выходного "нового поколения" с белым независимо от состояния первого проходного:

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

SCRIPT KRN25_YR_YW

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 ();
extern float next_sig_id ();
float next_state;
float sigid;


state = SIGASP_STOP;
if (enabled && (block_state() ==# BLOCK_CLEAR) && route_set() )
{
next_state = next_sig_lr (SIGFN_NORMAL);
sigid = next_sig_id (SIGFN_NORMAL);
if (!train_requires_next_signal(sigid,1))
{
state = SIGASP_RESTRICTING;
}
else
{
state = SIGASP_APPROACH_2;
}
}
draw_state = def_draw_state (state);
if ((state >=# SIGASP_APPROACH_1) && (next_state ># SIGASP_RESTRICTING))
{
draw_state = 2;
}
if ((state == SIGASP_STOP) && (this_sig_lr (SIGFN_NORMAL) ># SIGASP_STOP))
{
draw_state = 4;
}

Маневровый белый этого светофора вообще не зависит от аспекта следующего.