[QUOTE]
SignalSubObj ( 2
"SIGNAL" "Dlja drugix ukazanij ispolzujte marker!"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "APK_INFO_CLEAR_2" )
)[/QUOTE]

[QUOTE]
SCRIPT APK_INFO_CLEAR_2 extern float sig_feature (); extern float def_draw_state (); extern float state; extern float draw_state; state = SIGASP_STOP; if ( sig_feature( SIGFEAT_USER1 ) ) { state = SIGASP_CLEAR_2; } draw_state = def_draw_state (state);
[/QUOTE]
Не даёт выбрать опцию "Dlja drugix ukazanij ispolzujte marker!", потому как не стоит опциональный флаг, ни флаг Default . Поэтому и птичка в настройках не кликабельна. Я так понимаю, шина INFO по умолчанию - CLEAR_2 , если не тыкаем между двумя светофорами маркер.

[size="1"][color="Silver"]Добавлено через 7 минут[/color][/size]
Поэтому, в нашем случае, например, предыдущему такому же светофору, будь он так установлен, информация по INFO - вообще фиолетова. Он его игнорит программой, причём сделано это явно с умыслом. А что там за выходной с главного пути стоит? Сколько там голов с INFO в названии?

[QUOTE=vicente;602213]А что там за выходной с главного пути стоит? Сколько там голов с INFO в названии?[/QUOTE]
Вот светофор:

[SPOILER]SignalShape (
"APK_4AB_YR_GW_Kr.s"
"APK_4AB_YR_GW_Kr"
SignalSubObjs ( 12
SignalSubObj ( 0
"SIGNAL" "Nastrojki predidusego signala:"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "APK_3AB_YGR_DISTANCE" )
)
SignalSubObj ( 1
"SIGNAL" " - Datj zelenij (inace 2 zeltih)"
SigSubType ( USER1 )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 2
"SIGNAL" "Dlja drugix ukazanij ispolzujte marker!"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "APK_INFO_CLEAR_2" ) ///[COLOR="Red"] [B]INFO[/B][/COLOR]
)
SignalSubObj ( 3
"SIGNAL" "Nastrojki etogo signala:"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "APK_ALSN_KZ_0_B_0" )
)
SignalSubObj ( 4
"SIGNAL" " - Videlitj, esli ALSN kodiruetsa"
SigSubType ( USER2 )
SignalFlags ( OPTIONAL DEFAULT )
)
SignalSubObj ( 5
"SIGNAL" " - Zeltij ALSN na odin zeltij migajusij"
SigSubType ( USER4 )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 6
"SIGNAL" "Odnostoronnij propusk poezda:"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "APK_ALSN_KZ_20_B_20" )
)
SignalSubObj ( 7
"SIGNAL" " - Vhodnoj svetofor"
SigSubType ( GRADIENT_PLATE )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 8
"SIGNAL" " - Prohodnoj svetofor"
SigSubType ( NUMBER_PLATE )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 9
"SIGNAL" " "
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "APK_4AB_YR_GW_Kr" )
)
SignalSubObj ( 10
"SIGNAL" " "
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "APK_3AB_YGR_ALSN_Z_60_B_60" )
)
SignalSubObj ( 11
"SIGNAL" " "
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "APK_4AB_YRG_ALSN_Zel_B_Z" )
)
)
)[/SPOILER]

Спасибо. Я так и думал. По INFO - постоянный CLEAR_2. То есть в скрипте next_INFO = 8. Зря табло делали. Мог бы и догадаться я. Прошу прощения

[QUOTE=vicente;602211]
Вообще не рекомендую ловить состояние блока головами типа DISTANCE и делать на этом основании сигнальные выводы.(ц)[/QUOTE]
А можно подробнее, для меня эти distance,info,normal как набор равнозначных объектов для хранения состояний. Я как раз и спрашивал выше про особенности.

[QUOTE=vicente;602211]

Почему нижний?
[/QUOTE]
Ну да, наиболее разрешающий аспект там.

Покопал сигналку, info используют для настройки входных, выходных - то есть на боковой и подобное. Самое интересное это distance там. Проходные это состояние спрашивают друг у друга по цепи. Состоянием stop_and_proceed идет переключение перегона. Самое интересное - это функциональная голова входных distance.

Проходные зажигаются по stop, а по stop_and_proceed гаснут distance.
Входные Иванцево и Драчеево имеют один скрипт для обработки: [B]APK_3AB_YGR_YW_DISTANCE[/B]

Если входной выдаст distance stop_and_proceed, то проходные попутные его подхватят, на другом конце в Драчеево это как-то перекинется на встречное направление - пока не понял где и как, но видимо в логике distance входного Драчеево.

[size="1"][color="Silver"]Добавлено через 2 минуты[/color][/size]
[QUOTE=vicente;602213] шина INFO по умолчанию - CLEAR_2[/QUOTE]
Именно так, на все пути, по умолчанию, выдавать 2 желтых. А ниже этой головы в этих служебных [B]APK_Sluz_INFO_Link_Marker[/B], для настройки путей, на которые зеленый давать.

[QUOTE=vicente;602213]
next_INFO = 8[/quote]
А разве сим может правильно работать при значениях аспектов больше 7?

[size="1"][color="Silver"]Добавлено через 5 минут[/color][/size]
[QUOTE=roman5;602218]А можно подробнее, для меня эти distance,info,normal как набор равнозначных объектов для хранения состояний.[/QUOTE]
Они не равнозначны! (хотя хотелось бы!)
Грубо говоря, NORMAL опрашивается постоянно, DISTANCE немного реже, остальные ещё реже.
[quote]
Закодировать все необходимые данные для обмена между сигнальными точками только 8 "поездными" кодами невозможно, особенно учитывая, что они созданы для управления движением, а не для передачи служебной информации СЦБ.

DISTANCE выбран как наиболее стабильный и достаточно часто обновляемый, после NORMAL. Далее по тексту канал "D".[/quote]
Взято [URL="http://forum.zaborin.ru/topic.php?forum=33&topic=3"]отсюда[/URL].

[QUOTE=КЕ;602220]А разве сим может правильно работать при значениях аспектов больше 7?
[/QUOTE]
Там хитро сделано. 8 задаётся изначально. Передаются обычные аспекты 0-7, в случае если ни одно из условий не соблюдается, остаётся 8, а также - часть из того, что передаётся, позже приравнивается тоже к 8-ми.

Помнится, мы с Игорем пробовали со [B]state = 8;[/B], но разные симы по-разному воспринимали такой аспект.

Костя, нет там аспекта 8. next_INFO - просто переменная внутри скрипта

[QUOTE=КЕ;602223]Помнится, мы с Игорем пробовали со [B]state = 8;[/B], но разные симы по-разному воспринимали такой аспект.[/QUOTE]
Там не аспект 8, а локальная переменная.

А, да, действительно!

[B] roman5 [/B] по DISTANCE , функция block_state () в тестах показала, что ей нельзя доверять. При фактической занятости безмоторными единицами возвращала BLOCK_CLEAR.

Вообще есть некоторые отличия между сигнальными головами NORMAL и остальными. Я не разбирал все из них, мне достаточно было что-то прочесть на форумах, у других, что-то протестировать самому или с коллегами, так сказать, по цеху, чтобы отмести не NORMAL сигналы от определённых функций в сигнализации. Конечно, самое главное отличие сигналов NORMAL от всех остальных - только сигнальные головы этого типа останавливают составы AI - трафики. Об этом пишет и Мануал KUJU по сигнализациям MSTS. Тот же Мануал даёт определение "блока", или, как мы привыкли выражаться, блок-участка: [B]от сигнальной точки до следующей сигнальной точки, ИМЕЮЩЕЙ СИГНАЛЬНУЮ ГОЛОВУ ТИПА NORMAL[/B]. Это важно понять. Понять и простить. Сигнальными головами типа DISTANCE мы обязаны европейским дефолтным маршрутам (также, как 8 аспектам мы обязаны двум американским). Само название DISTANCE взято из европейских сигнализаций, где есть MAIN - светофоры (по MSTS-овски - NORMAL), DISTANCE - предупредительные, а с этим разработчики впихнули и остальные, "перспективные" типы голов: SHUNTING - маневровые, INFO - всё понятно здесь, REPEATER - повторительные etc. DISTANCE, однако, единственный тип, который используется в дефолте. Я не вижу никакой причины использовать DISTANCE не по своему назначению, как [B]предупредительный сигнал[/B]. В любом случае, повторюсь, снимать состояние блока этим типом сигнальной головы - не достоверно. С другой стороны, передача информации, как выражается Костя,, "по шине", думаю, вполне возможна.

[size="1"][color="Silver"]Добавлено через 42 минуты[/color][/size]
[QUOTE=roman5;602218]
Самое интересное это distance там. Проходные это состояние спрашивают друг у друга по цепи. Состоянием stop_and_proceed идет переключение перегона. Самое интересное - это функциональная голова входных distance.

Проходные зажигаются по stop, а по stop_and_proceed гаснут distance.
[/QUOTE]
Вот, за это - спасибо. Я тогда, когда сигналка эта вышла, так и не понял: как он гасит противоположгое направление. :drinks:

То есть в SAP переходят головы "ненужных" светофоров?

[QUOTE=vicente;602229]так и не понял: как он гасит противоположгое направление. :drinks:[/QUOTE]
Я вот его скрипт distance входного смотрю:
[SPOILER][CODE]SCRIPT APK_3AB_YGR_YW_DISTANCE

extern float block_state ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float next_sig_lr ();
extern float next_sig_mr ();
extern float opp_sig_lr ();
extern float opp_sig_mr ();
extern float sig_feature ();
float WORK1; float ONE_WAY; float SVET; float POEZD; float next_INFO; float opp_ONE_WAY; float opp_POEZD;

ONE_WAY = 0; SVET = 0; POEZD = 0; next_INFO = 8; opp_POEZD = 0; opp_ONE_WAY = 0;
if ( block_state() !=# BLOCK_JN_OBSTRUCTED ) {
WORK1 = next_sig_mr ( SIGFN_NORMAL ); if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { ONE_WAY = 1; }
WORK1 = next_sig_lr ( SIGFN_DISTANCE );
if ( WORK1 ==# SIGASP_CLEAR_2 ) { SVET = 5; } if ( WORK1 ==# SIGASP_CLEAR_1 ) { SVET = 4; }
if ( WORK1 ==# SIGASP_APPROACH_3 ) { SVET = 3; } if ( WORK1 ==# SIGASP_APPROACH_2 ) { SVET = 2; }
if ( WORK1 ==# SIGASP_APPROACH_1 ) { SVET = 1; }
if ( WORK1 ==# SIGASP_RESTRICTING ) { POEZD = 2; } if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { POEZD = 1; }
WORK1 = next_sig_mr ( SIGFN_INFO );
if ( WORK1 ==# SIGASP_CLEAR_1 ) { next_INFO = 7; } if ( WORK1 ==# SIGASP_APPROACH_3 ) { next_INFO = 6; }
if ( WORK1 ==# SIGASP_APPROACH_2 ) { next_INFO = 5; } if ( WORK1 ==# SIGASP_APPROACH_1 ) { next_INFO = 4; }
if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { next_INFO = 2; } if ( WORK1 ==# SIGASP_RESTRICTING )
{ next_INFO = 3; } if ( WORK1 ==# SIGASP_STOP ) { next_INFO = 0; }



}
if ( sig_feature( SIGFEAT_GRADIENT_PLATE ) && !sig_feature( SIGFEAT_NUMBER_PLATE ) ) { //для входного
WORK1 = opp_sig_mr ( SIGFN_NORMAL ); // опрашиваем проходной встречный рядом со входным вроде ? APK_4AB_YRG_Kv - проходной
if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { opp_ONE_WAY = 1; } // у отключенных проходных APK_ALSN_KZ_20_B_20 выдает stop - не выполняеся это условие
WORK1 = opp_sig_lr ( SIGFN_DISTANCE );
if ( WORK1 ==# SIGASP_RESTRICTING ) { opp_POEZD = 2; } if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { opp_POEZD = 1; }
//проходной не выдает distance res - тут только opp_POEZD = 1
}

if ( next_INFO ==# 4 ) { next_INFO = 8; }
if ( next_INFO ==# 5 ) { next_INFO = 8; }
if ( next_INFO ==# 6 ) { next_INFO = 8; }
if ( next_INFO ==# 3 && sig_feature( SIGFEAT_NUMBER_PLATE ) )
{ next_INFO = 8; }

state = SIGASP_STOP;
if ( next_INFO ==# 8 && POEZD ==# 0 && block_state() ==# BLOCK_CLEAR ) {
if ( SVET ==# 0 ) { state = SIGASP_CLEAR_1; }
if ( SVET ==# 1 ) { state = SIGASP_APPROACH_3; }
if ( SVET ==# 2 ) { state = SIGASP_CLEAR_2; }
if ( SVET ==# 3 ) { state = SIGASP_CLEAR_2; }
if ( SVET ==# 4 ) { state = SIGASP_CLEAR_2; }
if ( SVET ==# 5 ) { state = SIGASP_CLEAR_2; }
}
if ( next_INFO ==# 0 && POEZD ==# 0 && block_state() ==# BLOCK_CLEAR ) { state = SIGASP_APPROACH_1; }

if ( sig_feature( SIGFEAT_GRADIENT_PLATE ) && !sig_feature( SIGFEAT_NUMBER_PLATE ) ) {


if ( ( block_state() ==# BLOCK_OCCUPIED || POEZD !=# 0 ) && opp_POEZD !=# 1 ) { state = SIGASP_STOP_AND_PROCEED; } //вроде должно сработать, когда за входной заедет прибывающий
// и начать переключать перегон, но opp_POEZD = 1 - мимо пройдет
if ( opp_ONE_WAY ==# 1 || opp_POEZD ==# 2 ) { state = SIGASP_STOP_AND_PROCEED; } // тоже не сработает
}
if ( sig_feature( SIGFEAT_NUMBER_PLATE ) && POEZD ==# 1 ) { // не проходной - мимо
state = SIGASP_STOP_AND_PROCEED;
}
draw_state = def_draw_state (state);[/CODE][/SPOILER]

Если [B]opp_POEZD !=# 1[/B] поменять на [B]opp_POEZD ==# 1[/B], то гаснут попутные в момент пересечения входного трафиком, но обратное направление не зажигается. Не понятно, в скрипте ошибка или упускаю что-то ?

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
[QUOTE=КЕ;602231]То есть в SAP переходят головы "ненужных" светофоров?[/QUOTE]
Именно и если sap на входном поставить, то все проходные его подхватят и погаснут. Надо теперь понять, чего с другой стороны перегона входной не прокинул "не sap".

SAP дают головы, если поезд движется "на них" в противоположном направлении. Заманчиво конечно. Проблема в том, что у меня не получалось так "снимать" "оппозиты" - если поезд не движется на светофор, тот в упор не видел светофор за ним...

[QUOTE=vicente;602234]"оппозиты"[/QUOTE]
Кстати в доке не очень понятно opp_sig_mr - функция берет сигнал, который в обратную сторону светит и стоит до текущего сигнала или за ним ?

Хорошо. Допустим, у меня в "чердаке" перепутались уже MSTS и Open Rails. В последнем светофоры "не видят" "через стрелки" во всех случаях, кроме того, что поезд идёт на этот светофор. В MSTS, понятное дело, всё по-другому и функция block_state () не "убивает" скрипт. Я не вижу в скриптах входных и выходных (один скрипт иногда) того места, где передача STOP_AND_PROCEED прерывается, а она должна прерываться на станциях - скрещения, старты-стопы сервисов и т.п.

[size="1"][color="Silver"]Добавлено через 5 минут[/color][/size]
Opp_sig_lr/opp_sig_mr - снимают показания сигнала перед светофором по ходу движения поезда на этот светофор в противоположном направлении. То есть, в нашем случае со выходным в Иванцево - речь идёт о первом проходном. Ну, тем, что рядом с входным стоит. Они вершинами маркеров друг на друга смотрят. Да, мануал здесь зажал информацию. На всех форумах её уточняют

[size="1"][color="Silver"]Добавлено через 5 минут[/color][/size]
И ещё по поводу opp_sig_lr/opp_sig_mr. Когда я завопил на elvastower.com , что меня ограбили и в Open Rails эти функции косячат, один буржуй-сигнализатор "отрезал мне а ответ, что "функции протестированы и работают [B]как в MSTS[/B].

Эти функции и в МСТС ненадёжны.

Я могу допустить, что разница в симуляторах - функция enabled () работает совершенно по-другому и оппозиты снимаются только enabled-головами. В этом случае скрипт АРК работает так как [B]светофоры обратного направления перед сервисом - enabled[/B] (в количестве 2-х штук) и если они снимают эти данные - по совокупности того, что я писал раньше, ТЕОРЕТИЧЕСКИ, поезд движущийся по станционному пути в сторону входного обратного направления "включает" этот входной и тот снимает нужный RES с первого проходного, чтобы дать opp_poezd 2

[QUOTE=vicente;602236]Я не вижу в скриптах входных и выходных (один скрипт иногда) того места, где передача STOP_AND_PROCEED прерывается, а она должна прерываться на станциях - скрещения, старты-стопы сервисов и т.п.[/QUOTE]

Вот скрипт distance выходного. Выходной не хватает sap.

[SPOILER][CODE]SCRIPT APK_3AB_YGR_DISTANCE // прогон для выходных

extern float block_state ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float next_sig_lr ();
extern float next_sig_mr ();
extern float opp_sig_lr ();
extern float opp_sig_mr ();
extern float sig_feature ();
float WORK1; float ONE_WAY; float SVET; float POEZD; float next_INFO; float opp_ONE_WAY; float opp_POEZD;

ONE_WAY = 0; SVET = 0; POEZD = 0; next_INFO = 8; opp_POEZD = 0; opp_ONE_WAY = 0;
if ( block_state() !=# BLOCK_JN_OBSTRUCTED ) {
WORK1 = next_sig_mr ( SIGFN_NORMAL ); if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { ONE_WAY = 1; }
WORK1 = next_sig_lr ( SIGFN_DISTANCE );
if ( WORK1 ==# SIGASP_CLEAR_2 ) { SVET = 5; } if ( WORK1 ==# SIGASP_CLEAR_1 ) { SVET = 4; }
if ( WORK1 ==# SIGASP_APPROACH_3 ) { SVET = 3; } if ( WORK1 ==# SIGASP_APPROACH_2 ) { SVET = 2; }
if ( WORK1 ==# SIGASP_APPROACH_1 ) { SVET = 1; }
if ( WORK1 ==# SIGASP_RESTRICTING ) { POEZD = 2; } if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { POEZD = 1; }
WORK1 = next_sig_mr ( SIGFN_INFO );
if ( WORK1 ==# SIGASP_CLEAR_1 ) { next_INFO = 7; } if ( WORK1 ==# SIGASP_APPROACH_3 ) { next_INFO = 6; }
if ( WORK1 ==# SIGASP_APPROACH_2 ) { next_INFO = 5; } if ( WORK1 ==# SIGASP_APPROACH_1 ) { next_INFO = 4; }
if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { next_INFO = 2; } if ( WORK1 ==# SIGASP_RESTRICTING )
{ next_INFO = 3; } if ( WORK1 ==# SIGASP_STOP ) { next_INFO = 0; }
}
if ( sig_feature( SIGFEAT_GRADIENT_PLATE ) && !sig_feature( SIGFEAT_NUMBER_PLATE ) ) { // для входного - мимо
WORK1 = opp_sig_mr ( SIGFN_NORMAL );
if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { opp_ONE_WAY = 1; }
WORK1 = opp_sig_lr ( SIGFN_DISTANCE );
if ( WORK1 ==# SIGASP_RESTRICTING ) { opp_POEZD = 2; } if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { opp_POEZD = 1; }
}

if ( next_INFO ==# 0 ) { next_INFO = 8; }
if ( next_INFO ==# 4 ) { next_INFO = 8; }
if ( next_INFO ==# 5 ) { next_INFO = 8; }
if ( next_INFO ==# 6 ) { next_INFO = 8; }
if ( next_INFO ==# 3 && sig_feature( SIGFEAT_NUMBER_PLATE ) )
{ next_INFO = 8; }

state = SIGASP_STOP;
if ( next_INFO ==# 8 && POEZD ==# 0 && block_state() ==# BLOCK_CLEAR ) {
if ( SVET ==# 0 ) { state = SIGASP_CLEAR_1; }
if ( SVET ==# 1 ) { state = SIGASP_APPROACH_3; }
if ( SVET ==# 2 ) { state = SIGASP_CLEAR_2; }
if ( SVET ==# 3 ) { state = SIGASP_CLEAR_2; }
if ( SVET ==# 4 ) { state = SIGASP_CLEAR_2; }
if ( SVET ==# 5 ) { state = SIGASP_CLEAR_2; }
}

if ( sig_feature( SIGFEAT_GRADIENT_PLATE ) && !sig_feature( SIGFEAT_NUMBER_PLATE ) ) { // для входного - мимо
if ( ( block_state() ==# BLOCK_OCCUPIED || POEZD !=# 0 ) && opp_POEZD !=# 1 ) { state = SIGASP_STOP_AND_PROCEED; }
if ( opp_ONE_WAY ==# 1 || opp_POEZD ==# 2 ) { state = SIGASP_STOP_AND_PROCEED; }
}
if ( sig_feature( SIGFEAT_NUMBER_PLATE ) && POEZD ==# 1 ) { // для проходных SIGFEAT_NUMBER_PLATE - мимо
state = SIGASP_STOP_AND_PROCEED;
}
draw_state = def_draw_state (state);[/CODE][/SPOILER]

Между входным и выходными обычно стоят служебные сигналы скрытые, у них так обычно: копируют состояние distance у последнего проходного.
[SPOILER][CODE]SCRIPT APK_Copy_DISTANCE

extern float block_state ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float next_sig_lr ();
float WORK1; float POEZD;

POEZD = 0;
if ( block_state() !=# BLOCK_JN_OBSTRUCTED ) {
WORK1 = next_sig_lr ( SIGFN_DISTANCE );
if ( WORK1 ==# SIGASP_RESTRICTING ) { POEZD = 2; } if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { POEZD = 1; }
}

state = SIGASP_STOP;
if ( block_state() !=# BLOCK_JN_OBSTRUCTED ) { state = next_sig_lr ( SIGFN_DISTANCE ); }
if ( block_state() ==# BLOCK_OCCUPIED && POEZD !=# 1 ) { state = SIGASP_RESTRICTING; }
draw_state = def_draw_state (state);[/CODE][/SPOILER]

[QUOTE=КЕ;602240]Эти функции и в МСТС ненадёжны.[/QUOTE]
В MSTS я точно это деол пробовал. Задумка была немного другая: светофор противоположного направления должен был ловить оппозит светофора перед поездом (скажем, поезд приближается к первому проходному перегона, а входной должен был "ловить" [B]opp_sig_lr (SigFn_NORMAL)[/B], что тот - открыт, давть STOP без огней, а уже этот STOP остальные проходные того же (обратного) направления ловят через обычную next_sig_lr (SigFn_NORMAL). Так вот, не фига не работало.

Примерно так же пытался делать для манёвров - тоже "фиг вам"! ::wall::

А как правильно редактировать shape в файле [B]sigcfg.dat[/B], захотел во входном светофоре заменить имя скрипта distance головы на свой, так как родной скрипт используется еще в куче сигналов других и в лог идет еще и с них, хотел отсеять.
Заметил, что в [B]tdb [/B]и [B]tit [/B]файлах по координатам имена этих скриптов стоят. То есть редактирование [B]sigcfg.dat[/B] не дает эффекта.

Правильно ли я понял, что можно в tdb и tit поправить имя скрипта, зная координаты нужного сигнала ?

Прежде чем что-то менять в [I]sigcfg[/I] - надо удалить изменяемые светофоры, и только потом их установить заново.

Если сигнальная голова используется ещё где-то, надо не заменять, а добавлять. Я описывал несколько страниц назад процедуру. Добавить Signal_Head, написать её скрипт, добавить его в sigscr.dat , затем заменить в нужном SignalShape нужный саб-объект. Обязательно иметь в виду, что в редакторе сценариев светофор нужно как минимум "подвигать", а лучше - удалить и установить заново. Даже если просто поменят тип Signal_Head , скажем с NORMAL на DISTANCE.

Лучше переустановить, ведь все субобъекты в БД записываюся. И зная глючность МСТС-редактора в этом деле - лучше перестраховаться.

[QUOTE=КЕ;602247]Примерно так же пытался делать для манёвров - тоже "фиг вам"! [/QUOTE]
Да, тоже для манёвров тестил. "Настроил" даух-ходовочку - маркер смртит на входной через opp_sig_lr(SigFn_NORMAL), а маневровый светофор - на маркер через opp_sig_lr (SigFn_DISTANCE), потом - через opp_sig_lr (SigFn_NORMAL). Маневровый ловил аспект функцией без проблем, а вот, маркер...

То есть получается - маркер за входным на перегоне?

[QUOTE=APK-LVDZ;538889]Если имеется ввиду опция opp_sig_xx, то она работает так же как next_sig_xx, только в обратную сторону. Там есть ряд ограничений на тип головы, сейчас точно не помню. Вроде REPEATER не ловил, и можно было использовать не во всех головах. Это актуально для МСТС[/QUOTE]
В том-то и дело. Там не только тип головы, а ещё ограничения! Я только не могу уже припомнить: что там касается Open Rails , а что - MSTS.

Костя, обсуждения наших мытарств по маневрам тоже а тот период было. Кликни на цитату - попадёшь на нужные страницы темы.

[size="1"][color="Silver"]Добавлено через 2 минуты[/color][/size]
[QUOTE=КЕ;602259]То есть получается - маркер за входным на перегоне?[/QUOTE]

Да. Идея была в этом. В принципе, "связка" : входной- первый проходной в Иванцево - тоже подходит под определение. Так как их маркеры расположены

С проходным на тестах в МСТС бывало такое - пока маневровая ездючина проходит горловину, он !enabled (аспект STOP в моем случае, и на выходном, естественно, белый). Но при выходе за последнюю стрелку и проходе за точку разворота этот проходной "включался" и открывался.

[QUOTE=КЕ;602252]Прежде чем что-то менять в [I]sigcfg[/I] - надо удалить изменяемые светофоры, и только потом их установить заново.[/QUOTE]
Все удалить проблемно, я ведь не знаю, где автор еще такой же поставил. А мне для теста только 1 из них заменить интересно.

Можно по имени шейпа в *.w найти место установки.

[QUOTE=roman5;602267]А мне для теста только 1 из них заменить интересно.[/QUOTE]
Я же написал как делать.
Копмруешь шейп саетофора, переименовав его (файлы *.s
и *.sd, не забывая в редакторе подправить внутри *.sd название шейпа).
Добавляешь в sigcfg.dat тестовый шейп, копируя нужный блок шейпов. Не забыть увеличить на 1 общее количество шейпов в шапке Signal_Shapes.
Также добавляешь 1 в шапке Signal_Heads , копируешь блок головы, которую хочешь изменить в светофоре.
Меняешь в тестовом шейпе головы
Скрипт новой головы добавляешь в sigscr.dat
Меняешь тот светофор, который хочешь тестировать на маршруте на тестовый

[size="1"][color="Silver"]Добавлено через 10 минут[/color][/size]
[QUOTE=КЕ;602265]С проходным на тестах в МСТС бывало такое - пока маневровая ездючина проходит горловину, он !enabled (аспект STOP в моем случае, и на выходном, естественно, белый). Но при выходе за последнюю стрелку и проходе за точку разворота этот проходной "включался" и открывался.[/QUOTE]
Я не сталкивался с этим, и знаешь почему? А какая мне разница: что происходит с первым проходным после того, как я получил белый на выходгом и выехал к точке разворота? Тем более, если я проехал за неё? У меня и в MSTS и в стабильной версии Open Rails , если помнишь, первый проходной, если был !enabled, давал 2, выходной быд запрограмирован на следующий 2 давать тоже 2. Вот и все манёвры на выходном. Как только я его проехал, в RESTRICTING на первом проходном необходимость - дело пятое. Единственное, когда он RESTRICTING , будет белый на локомотивном, а если проходной станет enabled и изменится на CLEAR_2 , локомотивный сменится на зелёный. Кстати, в реале как АЛСН работает в такой ситуации? Белый до проследования входного, потом что в сторону перегона? Ловит зелёный или нет?

[QUOTE=vicente;602269]...А какая мне разница: что происходит с первым проходным после того, как я получил белый на выходном и выехал к точке разворота? Тем более, если я проехал за неё?[/QUOTE]
Я пытался его STOP ловить по [I]opp_sig_lr()[/I], искал условия для манёвров, чтобы зажечь белый на маневровом Б-С, стоящем у первой стрелки. А сейчас просто вспомнил.
[QUOTE=vicente;602269]У меня и в MSTS и в стабильной версии Open Rails, если помнишь, первый проходной, если был !enabled, давал 2, выходной был запрограммирован на следующий 2 давать тоже 2. Вот и все манёвры на выходном.[/QUOTE]
Олег, а чем лучше на [I]!enabled[/I] давать "2", а не "0"?
А, понял, это для ORTS.
Вообще да, при движении по горловине в сторону перегона белый легко зажечь. А вот обратно...
[QUOTE=vicente;602269]Кстати, в реале как АЛСН работает в такой ситуации? Белый до проследования входного, потом что в сторону перегона? Ловит зелёный или нет?[/QUOTE]
А кто его знает... наверно, зелёный покажет, если проходной открыт.

[QUOTE=КЕ;602272]
Я пытался его STOP ловить по [I]opp_sig_lr()[/I], искал условия для манёвров, чтобы зажечь белый на маневровом Б-С, стоящем у первой стрелки. А сейчас просто вспомнил. [/QUOTE]
Хм... Хорошо, но если этот проходной
[QUOTE]if (!enabled) {state = SIGASP_STOP;} [/QUOTE]
и становится в какой-то момент enabled и меняет аспект, как только ты переводишь реверс, он снова должен становиться !enabled ... Даже трафик пройдя точку разворота (правильно для MSTS ), сделает движение в сторону даже закрытого сигнала и "перевернёт" этот проходной снова в !enabled.
С оппозитами есть ещё одна байда - функция делает проблемы, если между соответствующими светоформи находится поезд, насколько я помню.

[QUOTE=КЕ;602272]
Олег, а чем лучше на [I]!enabled[/I] давать "2", а не "0"?
А, понял, это для ORTS.
Вообще да, при движении по горловине в сторону перегона белый легко зажечь. А вот обратно... [/QUOTE]
Дело не в симуляторе. С выходным в MSTS другая проблема: выход на манёвры "по удалению" невозможен. Откроется поездной сигнал. По этой логике решается только служебным маркером на границе станции, дающим STOP и RESTRICTING . Я ставил его back_facing головой на входном, а выходной на следующий STOP оставался закрытым. Так что, STOP я использовал для этого. Конечно, заманчиво не ставить маркеры в тупиках, но в MSTS катастрофически не хватает аспектов, а информацию от светофора к светофору можно передать только аспектами... ну... кому я рассказываю? ;)
Потому и RESTRICTING.




Насчёт обратной стороны, в MSTS было настроено так:
RESTRICTING давался
1. На занятый путь
2. На свободный путь, если следующий- тоже RESTRICTING
В остальных случаях:
1. На следующий STOP_AND_PROCEED- STOP_AND_PROCEED со скоростью желтого
2. На остальные аспекты следующего светофора - state = next_state;
Показания прописывались отдельно, через draw_state - белый на RESTRICTING , остальные аспекты горели синими.
Конечно, было не идеально, но терпимо.
Если поезд останавливался у красного входного, который был прописан на следующий RESTRICTING давать STOP_AND_PROCEED красный, был виден горящий белым маневровый - это раз. При маневрах на свободный путь с закрытым выходным, маневровый оставался синим при том, что он открывался STOP_AND_PROCEED. Но... Для MSTS , повторяю, было удовлетворительно. В MSTS , напомню, трафики не сцепляются, а игрок на свободный путь, в основном, "обгоняется". Если ехать строго по показаниям, а выходной закрыт из-за блокировки, игрок может и подождать пока выходной откроется RESTRICTING и ему откроется маневровое показание.
Идея с оппозитами заключалась в том, что поезд с перегона - ему обязательно должен открыться входной, прежде чем он проедет его. В MSTS функция block_state () не определяет направление движения поезда, по-любому она вернёт BLOCK_OCCUPIED если блок занят. Поэтому и пытался ловить через оппозит открытый входной. Но, этого не достаточно. Маневровый должен не просто поймать момент, когда входной открыт. Он должен ещё запомнить, что входной был открыт, когда голова поезда проследует этот входной и сигнал перекроется. А это - ой как не просто в статическом скрипте. Мне казалось, что , сегодня, после того как я научился запоминать информацию в Open Rails , мне удастся соорудить что-то подобное для MSTS . Как я уже писал, я собирался написать новую сигналку, которая будет работать в обоих симуляторах, плюс мультиплейер... но... пока жизнь не даёт на это времени.

[QUOTE=КЕ;602272] А кто его знает... наверно, зелёный покажет, если проходной открыт. [/QUOTE]

Мне нужна информация по АЛСН. Маневры на перегон, маневры по станции, потеря кодов в поездном режиме. Когда какие коды. В интернете, что-то, не густо в этом плане...:o

[quote] Хорошо, но если этот проходной
[B]if (!enabled) {state = SIGASP_STOP;}[/B]
и становится в какой-то момент enabled и меняет аспект, как только ты переводишь реверс, он снова должен становиться !enabled ... Даже трафик пройдя точку разворота (правильно для MSTS ), сделает движение в сторону даже закрытого сигнала и "перевернёт" этот проходной снова в !enabled. [/quote]
Нет, проходной оставался открытым при реверсе.
[quote] в MSTS катастрофически не хватает аспектов[/quote]
Но если б можно было передавать аспекты "вперед" по ходу сервиса.... Мечты!:(
[quote]Насчёт обратной стороны, в MSTS было настроено так:
RESTRICTING давался...[/quote]
Насколько надежно это работало?
[quote]Он должен ещё запомнить, что входной был открыт, когда голова поезда проследует этот входной и сигнал перекроется. А это - ой как не просто в статическом скрипте.[/quote]
Да, трудновато!)) Я так и не добился надёжного сохранения внутренней переменной. Поэтому и мечтал о передаче "вперёд".:o
[quote]Мне нужна информация по АЛСН. Маневры на перегон, маневры по станции, потеря кодов в поездном режиме. Когда какие коды. В интернете, что-то, не густо в этом плане...[/quote]
Спросил на форуме [url]http://scbist.com/obschie-voprosy-ekspluatacii-ustroistv-scb/28682-glupye-voprosy-632.html[/url]?
ЗЫ:
Залез[URL="http://www.elvastower.com/forums/index.php?app=members&module=messaging&section=view&do=showConversation&topicID=43761&st=0#msg121253"] сюда[/URL].))

[QUOTE=КЕ;602278]Нет, проходной оставался открытым при реверсе.
[/QUOTE] Да, это так. Подзабыл, прошу прощения. Ровно 10 лет назад я [S]нацарапал на заборе[/S] тестил эту функцию "чистым тестом" [S]с блэкджеком и шлюхами[/S] с фотографиями (к сожалению, сайты давно почили в бозе, и много материала утеряно). Описание теста прилагаю полным текстом сообщения, за исключением скринов..
[SPOILER]
Немного о функции*enabled

Данная функция является внешней функцией относительно скрипта. Мы знаем, что в скриптах есть функции внешние, то есть прописаны они в другом месте - ехе-файле симулятора и изменять в работе самой функции мы ничего не можем (см.мануал) и есть функции, которые, теоретически, может прописать разработчик сигнализации внутри самого скрипта (чем и занимаюсь сейчас для создания своего варианта одностороннего пропуска).
Итак, enabled.
Кужувский разработчик пишет:

Код:

Contains TRUE (non-zero) if the current signal instance is enabled to show
its natural state, or FALSE otherwise.


Это значит, что функция возвращает единицу, если светофор включен, чтобы показать его состояние, в противном случае - выдает 0.
То есть не все светофоры на маршруте работают по скрипту, а только те, которые находятся впереди и позади сервиса на определенном расстоянии. Расстоянием здесь является не километраж и не количество узлов, как в подготовке маршрута МСТС, а количество светофоров. Какое кол-во светофоров будут enabled перед сервисом (кстати, не важно сервис ли это игрока или трафик) мы задаем в файле конфигурации сигнала в параметре SignalNumClearAhead. Небольшой тест покажет наглядно как это работает.
Я поставил на перегоне проходные светофоры (модели Тимаса), прописав в них SignalNumClearAhead (2), обычные сигналы проходного 3АБ, а при функции enabled = 0, или правильней - !enabled - синий.

Результат - перед сервисом 2 светофора зеленые, остальные - синие - !enabled. Это понятно. Цель теста - выяснить, что с остальными светофорами на перегоне. У нас еще три направления. На скрине мы видим, что за занятым сервисом блок-участком светофор красный, то есть enabled. За этим светофором, против хода сервиса,как и положено желтый, а уже перед ним - !enabled - синий.
Что происходит с противоположной стороны?


Перед сервисом 2 светофора становятся enabled красный и желтый. Светофоры же позади него сразу же становятся !enabled - синие.
[B]Интересно, что если я возвращаюсь назад, то светофоры по мере удаления от них остаются enabled[/B] - зелеными. То есть если я вернусь на 2 блок-участка, то впереди меня будет не 2, а 4 зеленых светофора. В обратном же направлении, направлении движения, ни один светофор enabled не становится.
[/SPOILER]
Нужное место я выделил под спойлером в последнем абзаце

[size="1"][color="Silver"]Добавлено через 30 минут[/color][/size]
[QUOTE=КЕ;602278]
Но если б можно было передавать аспекты "вперед" по ходу сервиса.... Мечты!:( [/QUOTE]
Ну, с MSTS уже вряд ли что можно сделать. Но, мечты сбываются в наше время в Open Rails , и это дело обещают/сделано уже там. Но, как поётся в песне, "того, что нужно нам, всегда на свете нет..." Прграммировать светофоры для этого нужно с [B]С#[/B], а я вообще не знаю его, и в жизни программированием не занимаюсь.

[QUOTE=КЕ;602278]
Насколько надежно это работало? [/QUOTE]
Всегда. Там никакого выпендрёжа нет, на самом деле. Вся цепочка светофоров NORMAL-ы, каждый работает по известным и накатанным функциям и зависит толькоот следующего сигнала. Единственное- пришлось поднять SignalNumClearAhead , а я это очень не люблю. Но, маршрут - мой личный, [S]ворочу чего хочу[/S], в сценариях, естественно, я это учитывал.

[QUOTE=vicente;602286]Прграммировать светофоры для этого нужно с С#...[/QUOTE]
В смысле - менять исходный код ORTS?
[QUOTE=vicente;602286]... Единственное- пришлось поднять SignalNumClearAhead , а я это очень не люблю. Но, маршрут - мой личный, [S]ворочу чего хочу[/S], в сценариях, естественно, я это учитывал.[/QUOTE]
Какое число было необходимым?

[QUOTE=КЕ;602278]
Да, трудновато!)) Я так и не добился надёжного сохранения внутренней переменной. Поэтому и мечтал о передаче "вперёд".:o[/QUOTE]
То, что я хотел сделать и описал выше - наоборот - "ловить" поездной режим, а если не ловится - скрипт маневрового. У меня сейчас так в Open Rails с внешними переменными (в Open Rails можно кидать переменные во внешние регистры и не только запоминать их, но и "снимать" эти переменные с других светофоров. К сожалению, только по аналогии MSTS : next_.. (next_n...) и opp_... . Но, я не удовлетворён его работой - иногда оппозит преподносит сюрпризы (дело в скриптах, нужно переделывать) из-за того, что стрелки в Open Rails остаются в последнем положении и, если кто-то "сбивает" маршрут к светофору, с которого я снимаю данные (перекрёстный маршрут), тупая программа "ловит" переменные, к примеру, не с нужного маркера, а с другого... или из тупика. :crazy:

Оег, ты говоришь про это? -
[quote]Записывать данные: store_lvar (key, value)
Извлекать их: this_sig_lvar (key)
Передавать: [B]next_sig_lvar (key)[/B], и[B] id_sig_lvar (sigid, key)[/B]
[B]next_sig_id (SigFn_Type)[/B] - функция, которая идентифицирует сигнал для дальнейшей работы с ним по идентификатору, который она возвращает

[B]direction = this_sig_lvar (1);[/B]
[B]if (block_state ==# BLOCK_JN_OBSTRUCTED) {state = SIGASP_RESTRICTING;store_lvar (1,1);}
else { store_lvar (1,0);}[/B]
Первая цифра в скобках - "разряд", вторая - само значение. Можно запоминать их сколько угодно! Под каждым "разрядом" - своя переменная. В смысле, под (1,Х) - одни переменные, (2,Х) - другие и т.д.[/quote]


Нашёл интересное замечание в наших давних сообщениях:
[quote]
[B]opp_sig_x[/B]
функция задумывалась как чтение аспекта противостоящего сигнала, контролирующего вход в этот же блок с противоположной стороны. Она читает сигнал за поездом с противоположной стороны, но - выдает только аспекты 0, 7, и -1 (!).[/quote]
Надо будет проверить.