[QUOTE=vicente;592525]...Один из разработчиков на буржуйском форуме писал, что у него все сигналы АБ с -1. То есть, он с выходого "энэйблит" сразу входной следующей станции независимо от количества блок-участков.[/QUOTE]
Вот если бы это было в МСТС - победили бы "вечный красный" в сценариях.

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

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

[QUOTE=vicente;592529]... За пределами SNCA...[/QUOTE]
И что тогда выяснили - на какое расстояние сим прокладывает маршрут сервису? Это зависит от количества блок-участков, или там километры?

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

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

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

Именно.
У меня было
[QUOTE] if ((...) && (block_state() != # BLOCK_CLEAR))
state = SIGASP_RESTRICTING; [/QUOTE]
При таком скрипте сервис перед маневровым переводит себе стрелки по маршруту навстречу другому сервису, светофор открывается белым (2) и ничего не препятствует этому сервису проследовать светофор на занятый движущимся навстречу сервисом путь. Ведь состояние block_state() в этом случае BLOCK_JN_OBSTRUCTED, а это не BLOCK_CLEAR и условие выполняется. Если бы стояло if (block_state() = # BLOCK_OCCUPIED), светофор остался бы закрытым.

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

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

opp_sig_lr()/opp_sig_mr()
 

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

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

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

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

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

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

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

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

Вот скрипт проходного
[QUOTE]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;
}
}
[/QUOTE]

[QUOTE=vicente;592724]MSTS при постановке точки разворота "энейблит" сигнал вне маршрута сервиса? Ты уверен, что он это делает через [I]enabled ()[/I] ?[/QUOTE]
Вот именно, что вне маршрута - точка разворота рядом с входной стрелкой. Как только лок проходит стрелку - проходной зеленеет (при !enabled не горит).
Про остальное еще подумаю, сразу не соображу...
_____
В OR пока не могу проверить, на работе древний ноут - OR не установится, там WINXP. Если только старые версии, но в них сигналка работает через ж...

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

Так точно


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

[size="1"][color="Silver"]Добавлено через 3 минуты[/color][/size]
[QUOTE=КЕ;592730]В

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

[size="1"][color="Silver"]Добавлено через 27 минут[/color][/size]
[QUOTE=КЕ;592730]
В OR пока не могу проверить, на работе древний ноут - OR не установится, там WINXP. Если только старые версии, но в них сигналка работает через ж...[/QUOTE]
Не парься :cool:
Лови рабочий скрипт выходного "нового поколения" с белым независимо от состояния первого проходного:
[SPOILER]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;
}[/SPOILER]

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