К сожалению, все также горит предвходной зелёный, при открытом входном на бок "Два желтых из них верхний мигающий" :(

А можно скрипт входного? Той части, которая набок сигналит?

Вот часть скрипта:

SCRIPT [B]T_Head_Yx_RY_I[/B]

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;

if (route_set())
{
state = SIGASP_STOP_AND_PROCEED;
if (enabled && (block_state() ==# BLOCK_CLEAR))
{
next_state = next_sig_lr (SIGFN_NORMAL);
if ((next_state ==# SIGASP_STOP) || ((next_sig_mr (SIGFN_NORMAL) ==# SIGASP_STOP_AND_PROCEED) && (next_state ==# SIGASP_RESTRICTING)))
{
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 = 3;
}
}
else
{
state = SIGASP_STOP;
if (block_state() ==# BLOCK_JN_OBSTRUCTED)
{
state = SIGASP_STOP_AND_PROCEED;
}
draw_state = def_draw_state (state);
}

А если вот такой вариант для проходного:

[B]SCRIPT T_Head_YGR

extern float enabled;
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 sig_feature ();
float next_state;

if (enabled)
{ next_state = next_sig_lr (SIGFN_NORMAL);
state = 1;
if ( ( !sig_feature ( SIGFEAT_USER1 ) ) && ( block_state () == BLOCK_CLEAR ) )
{
if ( ( next_state == 1 ) || ( next_state == 2 ) )
{ state = 3; } /// "Yellow"
else { state = 7; } /// "Green"
draw_state = def_draw_state (state);
if ( state == 7)
{
if ( next_state == 4)
{ draw_state = 4; } /// "Yellow F"
else if ( ( next_state == 5 ) || ( next_state == 6 ) )
{ draw_state = 5; } /// "Green F"
}
}
}
else state = 0;
draw_state = def_draw_state (state);[/B]

Результат без изменений... Но, вот только что, попробовал изменить в sigcfg местами линзы огней, то желтый мигает но во всех случаях когда должен гореть зеленый. Получается что скрипт не считывает блок, где нужен желтый мигающий. Или же его пропускает. На все остальные сигналы реагирует нормально.

Думаю, что это может быть... ещё попытка:

[B]SCRIPT T_Head_YGR

extern float enabled;
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 sig_feature ();
float next_state;

if (enabled)
{ next_state = next_sig_lr (SIGFN_NORMAL);
state = 1;
if ( ( !sig_feature ( SIGFEAT_USER1 ) ) && ( block_state () == BLOCK_CLEAR ) )
{
if ( ( next_state == 1 ) || ( next_state == 2 ) )
{ state = 3; } /// "Yellow"
else { state = 7; } /// "Green"
draw_state = def_draw_state (state);
if ( state == 7)
{
if ( next_state == 4)
{ draw_state = 4; } /// "Yellow F"
else if ( ( next_state == 5 ) || ( next_state == 6 ) )
{ draw_state = 5; } /// "Green F"
}
}
}
else {
state = 0;
draw_state = def_draw_state (state);
}[/B]

[QUOTE=КЕ;591506]Думаю, что это может быть... ещё попытка:
[/QUOTE]

Костя!) Огромная Вам Благодарность) Снова Вы мне очень помогли) И снова третья попытка увенчалась успехом)
ОГРОМНОЕ СПАСИБО) Большего ЗДОРОВЬЯ Вам и много счастья)

Спасибо!
дело было в последних 2 строках:
[B]} else state = SIGASP_STOP;
draw_state = def_draw_state (state);[/B]
Получалось, что после правильной отработки включения огней скрипт проходил по
[B]draw_state = def_draw_state (state);[/B]
и сбрасывал огни обратно на зелёный.
После заключения в скобки:
[B]else {
state = 0;
draw_state = def_draw_state (state);
}[/B]
огни второй раз уже не менялись, скрипт не заходил на строку
[B]draw_state = def_draw_state (state);[/B].

Скрипт работает нормально... Но я решил посмотреть, что происходит из сигналом, после проследования состава... И выяснилось... что светофор не переключается на красный)

Вот в начало скрипта:
[B]if (enabled)
{ next_state = next_sig_lr (SIGFN_NORMAL);
{ state = 1; draw_state = 0; }
...
...[/B]

Всё идеально сработало)
Еще раз ОГРОМНОЕ СПАСИБО) :drinks:

Олег, я в соседней теме просил скрипты, чтоб понять синтаксис, а то у меня OR ругается постоянно:
[I]Unexpected number of = in string : ELSE IF ( NEXT_N = 3 ){STATE = 7...
Unmatching brackets in : ELSE IF ( NEXT_N...[/I]
Что-то там было, что терпит МСТС, а ОР вот так пишет в лог, но не помню, в чём именно дело...

Скобки проверь.
Он на скобки ругается.

Проблема, которую я [URL="http://www.trainsim.ru/forum/showpost.php?p=592479&postcount=48"]описал[/URL] в теме о Timetable Mode касается исключительно сигнализаций, где количество активированных сигналов функционально задействовано в каких-то ситуациях. То есть, если сигнализация построена на том, что нет никаких дополнительных сигнальных точек, или аргумент [B]SignalNumClearAhead[/B] постоянен - никаких изменений в работе не будет. Мне это сломало некоторые моменты из-за особенностей в самой сигналке. У меня [B]всегда[/B] первая сигнальная точка после станции (а также на маршрутных светофорах, но там оно не мешает, проблема обнаружилась именно с выходными) в случае [B]!enabled[/B] даёт аспект 2 (и зеленый, желтый или красный - в зависимости от занятости б/у если это проходной АБ или 2 и красный, если это входной АБ или ПАБ. Это нужно для того, чтобы в маневровом режиме давать 2 и белый на выходном. Логика проста. Естественно, если сервис отправляется на перегон и его Path не доходит до первого сигнала после входного, то этот самый первый сигнал [B]!enabled[/B] (в МСТС, кстати, тоже так, поэтому я и написал там,,что сигналка в обоих симуляторах работает) и выдаёт 2. А выходной настроен на следующий 2 давать 2 и белый. В поездном режиме первый светофор после станции активируется , естественно и выходной выдаёт поездные аспекты. Присутствие в сигнализации дополнительного маркера рельсовой цепи в начале каждого станционного пути по ходу движения сервиса, а также маневровых сигналов на входных стрелках требует точного расчета [B]SignalNumClearAhead[/B] у [B]входного[/B] светофора. Он должен "доставать" через все станционные объекты сигнализации аж до этого самого первого проходного или входного на следующую станцию. Иначе мой входной просто не откроется - маневровые дают 2, если путь знаят, чтобы позволить прицепку на занятый путь, а также если путь свободен и на выходном -2 для маневрового проследования по свободному пути, а при маневровом режиме входные у меня "заперты", естественно.
Обидно, что когда я эту механику разрабатывал, и у меня был выбор: положиться ли на разработчиков ОР с их утверждением, что светофор с [B]SignalNumClearAhead = -1[/B] не учитывается симулятором в "общем зачёте" или прописывать "топором" все значения этого параметра для каждого светофора, включая маркеры, я выбрал первое. Зря... Бывает

[size="1"][color="Silver"]Добавлено через 14 минут[/color][/size]
Вносить поправки сейчас, ИМХО, смысла не имеет, всё вышеизложенное делалось "не от хорошей жизни" , а из-за нехватки аспектов и отсутствия соответствующих функций. В Open Rails теперь есть специальные дополнительные функции для сигнализации, расчитанные именно для возможности сделать маневровые показания.
Так что, если переделывать, так уже переделывать всё

[...рыдая бьётся головой о стену... :crazy:]

Ты по удалению, впередиидущий сервис что-то изменяет?

В Open Rails - нет. В MSTS [B][I]enabled()[/I][/B] распространяется и на светофор, который сервис проехал. Вернее - на тот, что проследовал и на один перед ним, если я правильно помню. На "Заборе" я выкладывал проверку по этой функции с картинками. Пост нашел, но картинки пропали.

[size="1"][color="Silver"]Добавлено через 2 минуты[/color][/size]
Поэтому, да, там поездной откроется. Я забыл

Вообще от скрипта зависит, но помню были случаи, когда после прохода трафика мне выходной белым горел вместо желтого, то есть реагировал на !enabled проходного.

[QUOTE=vicente;592482]Обидно, что когда я эту механику разрабатывал, и у меня был выбор: положиться ли на разработчиков ОР с их утверждением, что светофор с SignalNumClearAhead = -1 не учитывается симулятором в "общем зачёте" или прописывать "топором" все значения этого параметра для каждого светофора, включая маркеры, я выбрал первое. Зря... Бывает[/QUOTE]
Прошу прощения заочно у буржуинов-разработчиков Open Rails и очно у уважаемых участников форума. Описанное в указанном сообщении - исключительно мой косяк и рукожопость. Я почти год до карантина вообще его не трогал. Оказалось, что тогда я не переставил местами тестовые файлы скриптов со стабильными. Так что, "грязь" была в скрипте выходного и т.д.
[B]Логика работает как работала[/B]!
Ещё раз "посыпаю голову песком", как говорил товарищ Дж. Лондон

То есть сим при подсчете светофоров твои маневровые пропускает, но работают они по обычному скрипту?

[size="1"][color="Silver"]Добавлено через 20 минут[/color][/size]
Нигде не встречал - когда в конфиге указывается число SNCA - учитываем значность сигнализации (3-значная, 4-значная), или это неважно?

[QUOTE=КЕ;592520]То есть сим при подсчете светофоров твои маневровые пропускает, но работают они по обычному скрипту?[/QUOTE]
Именно. Можно, в принципе, сделать отдельный предвходной с большим SNCA, но его точно нужно расчитывать. Потому что "базовая" или "маленькая" станция - это входной, один маневровый перед стрелками и дальше - выходной. Но, у меня есть станции, где между входным и выходным или маршрутным - 4 маневровых. Здесь так просто не отделаться. Для унификации -1 -- самое то.
Есть разные способы. Один из разработчиков на буржуйском форуме писал, что у него все сигналы АБ с -1. То есть, он с выходого "энэйблит" сразу входной следующей станции независимо от количества блок-участков. Мне такой способ неприемлем, ИМХО, для трёхзначки достаточно 3, для 4-х - 4. И то - "с запасом" - из-за этого самого моего первого проходного с 2, когда он !enabled для маневрового на выходном.

[QUOTE=КЕ;592520]Нигде не встречал - когда в конфиге указывается число SNCA - учитываем значность сигнализации (3-значная, 4-значная), или это неважно?[/QUOTE]
В принципе, достаточно и на один меньше, но и так можно. Получается с небольшим запасом - то что надо.
Действительно: скажем - 3-х-значная. Сервис движется, его светофор зелёный, за ним нам нужно 2 сигнала. Первый по ходу будет зелёный, за ним - жёлтый, за ним уже !enabled.

[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] не зависит от аспекта следующего.

[B]next_sig_id[/B] - это что-то новое! Что за функция?
[B]if (!train_requires_next_signal(sigid,1))[/B] - что за условие?

Это новые функции, которые были внесены в Open Rails. Нехватка аспектов ощущается не только у нас ;)
[B]sigid[/B] определяет объект, с которого нужно считать дополнительную информацию. Строкой [QUOTE]sigid = next_sig_id (SIGFN_NORMAL);[/QUOTE] я "пометил" следующий светофор типа [B]NORMAL[/B]. Это не единственный вариант. Можно выбирать не только этот тип, но и другие. Можно "метить" подобъекты и снимать с них информацию. Есть также функция [B][I]next_[B]n[/B]sig_id(SigFn_TYPE,[B]n[/B])[/I][/B] на подобии функции [B][I]next_[B]n[/B]sig_lr (SigFn_TYPE,[B]n[/B])[/I][/B], о которой я уже рассказывал. Работает точно также - на светофор, находящийся на удалении [B]n[/B].
[B]train_requires_next_signal(sigid,position)[/B] - функция, проверяющая проходит ли [I]Path[/I] через сигнал, идентифицированный параметром [B]sigid[/B]

То есть эту "метку" ставить на первый проходной в нашем случае?
if (!train_requires_next_signal(sigid,1)) - число "1" означает проверку первого от нас светофора?

На сам светофор не надо ничего ставить. Я его функцией "пометил" с выходного

А, понял - выбираем нужный светофор, а потом по ходу дела проверяем, проходит путь сервиса через него или нет. Здорово!
Просто, как все гениальное!!! )))
В принципе, я сегодня нулевыми стрелками делал то же самое! )))