Просмотр полной версии : Сигнализация: конфигурация и скрипты
Так - да. Или для особенных манёвров.
Как это писать в скрипте с dist_multi_sig_lr? Если у тебя все сигналы - NORMAL?
...маркер РЦ (есть и такой:D)...
- это кто такой???:)
На выходных светофорах я сделал обратно-смотрящую голову NORMAL, чтобы сделать дополнительный блок. Пока состав на стрелках, светофор перед узлом (у меня - маневровый) заблокирован. Иначе есть проблемы с переводом стрелок из-за особенностей скриптов маневровых.
Добавлено через 5 минут
Как это писать в скрипте с dist_multi_sig_lr? Если у тебя все сигналы - NORMAL?
А почему нет? Эта функция должна работать со всеми видами сигналов.
С забора перенесу сюда: Проверяет сигналы первого типа на пути до сигнала второго типа/враждебной стрелки/окончания пути
Ну, и ловит соответствующее значение подобно другим x_sig() функциям...
У него в заявлении два Fn_type. Первый ставим NORMAL, второй, скажем, DISTANCE и всё! Он читает NORMAL-ы
А ДИСТАНС придется отдельно ставить для этого?
Как до вржд. стрелки считать?
И что со стрелками не так?
Как писать?
Не знаю пока... Думаю пока как сделать условие, чтобы на пути функции были только аспекты 2
Вот если бы можно было передавать аспекты на впередистоящие светофоры...
С bak_sig_xx здесь никак не получится?..
А ДИСТАНС придется отдельно ставить для этого?
Вот и я не хочу их ставить. А только пользоваться второй частью определения "враждебной стрелки/окончания пути ". Ещё неизвестно как оно в ОР работать будет, но есть шанс. Дело в том, что светофор !enabled в ОР не "читает" положение стрелок перед собой. Я проверял функцию block_state() недавно. Светофор, через который не проходит путь выдает BLOCK_JN_OBSTRUCTED независимо от положения стрелки. Возможно и dist_multi_sig_xx() будет доходить до этого момента и прекращать проверку...
Надо завтра проверить. Только как писать? Первый тип укажем НОРМАЛ, а на месте второго что??
И что со стрелками не так?
Это особенность скрипта моих маневровых светофоров. Из за того, что перед узлом маневровый, именно он блокирует. А у меня на занятый путь он RES, тогда поезд следующий "по удалению" резервирует стрелку для себя не по своему маршруту, а по её последнему положению. Поэтому мне надо держать его "0" пока состав не освобождает стрелки.
Вот если бы можно было передавать аспекты на впередистоящие светофоры...
С bak_sig_xx здесь никак не получится?..
Эта функция работает только на светофоре, который перед тобой :(
Я вот сейчас хотел проверить, но, оказывается, это не то, что думал. Как этот bak_sig_xx на самом деле работает?
APK-LVDZ
28.10.2016, 02:25
Если имеется ввиду опция opp_sig_xx, то она работает так же как next_sig_xx, только в обратную сторону. Там есть ряд ограничений на тип головы, сейчас точно не помню. Вроде REPEATER не ловил, и можно было использовать не во всех головах. Это актуально для МСТС
Нет, именно это, extern float bak_sig_lr;, например.
Как этот bak_sig_xx на самом деле работает?
Лёша, В МСТС оно работает отлично от ОР
Ой... не то. Что это за bak?Я, как Лёша, перепутал с оппозитом
Добавлено через 3 минуты
Первый раз слышу о такой функции. Откуда это?
Брал здесь, но не до конца понятно:
next читает список аспектов следующей сигнальной точки,
this проверка своего светофора, например – передача кода с одной головки DISTANCE на другую NORMAL.
opp - маркер у считываемой точки - в сторону той, которая читает.
Т.е. если упростить до ПАБ, то так можно получить аспект входного светофора, когда точка (светофор), где
запущена функция, стоит к нему "лицом", т.е. они смотрят друг на друга.
bak - смотрит и передаёт в обратную сторону; пример - кодирование АЛСН по неправильному пути.
Bak-субобъекты
Bak-головой на спине выходного можно послать код маневров на все маршрутные и входной.
bak «вешает» любую головку на «спину», необязательно какую-то особенную, можно один и тот же маркер сделать на обе стороны. Обрабатываются как обычные головы, функции относительно "лица" точки; как от неё смотришь, так и прописываешь.
Передает, (как при этом принимает - не тестил) в обратную строну, соответственно, как у любой нормальной головы любого стандартного типа - у неё должно быть "неактивное" состояние, в котором она не светит и передает неуправляющий на фоне других аспект.
ИМХО тут нужно смотреть скриптом в ту сторону, куда смотрит головка, хотя надо затестить – может быть, только "передатчик" разворачивается.
Нет такого. Сейчас гляну там...
Добавлено через 13 минут
Костя, нет такой функции
Опечатка, наверное, была...
Значит, передать аспекты "вперёд" нельзя (оппозиты ведь не работают с ними)?
Думал так передавать маневровый режим.
Вперед передать надо, но тут "зацепиться" не за что. Оппозиты только занятость пути "понимают". Я так хочу со спины выходного попробовать для маневровых Б-С.
Или dist_multi_sig_xx применить... до какого сигнала проверять? Или до конца пути - тогда как скрипт должен выглядеть?
Олег, а ты в каком-нибудь сценарии маневровый "по удалению" за поездным сервисом с точкой ожидания делаешь?
Да.
На всех маневровых, если есть точка разворота за ними ( с пути на путь) ставлю точки ожидания "для реалистичности". Двухсекционникам от минуты до 2-х, маневровым локомотивам или составам 10-30 сек, чтобы сразу не возвращались.
Думаю, я понял: к чему ты клонишь. Именно поэтому сейчас снова пытаюсь "пробить" маневровый режим (не получается пока - переменные не хотят запоминать себя). У меня прописано маневровому на занятый путь не открываться, если следующий светофор открыт. То есть, за поездом маневровый сервис не поедет, не сцепится с ним и т.п. Но, эта связка ненадёжна. Я перегоняю локомотивы по главным путям станций, на них останавливаются только пассажирские и пригородные с открытыми выходными. Но, хочется универсальности, потому что, если выходной пассажирскому будет заблокирован, маневровый откроется.
переменные не хотят запоминать себя Да, всё "сбрасывается", по крайней мере у меня, хотя в МСТС работало...
маневровому на занятый путь не открываться, если следующий светофор открыт. То есть, за поездом маневровый сервис не поедет, не сцепится с ним и т.п. Но, эта связка ненадёжна. Я перегоняю локомотивы по главным путям станций, на них останавливаются только пассажирские и пригородные с открытыми выходными. Но, хочется универсальности, потому что, если выходной пассажирскому будет заблокирован, маневровый откроется.
Была мысль ставить специальные маркеры границы станции - если путь сервиса за них не заходит, то по !enabled выдают нужный управляющий аспект. Но то же самое можно считывать с уже имеющихся светофоров, только надо думать, как... Вот твой случай как раз и показал ненадёжность всего этого.
Да, это недостаток. Но, что сделано - то сделано. У меня маршрут почти 500 км, на всех станциях они стоят и работают. И сценарии только я делаю, так что эта ситуация принимается мной во внимание. Сигнализацию с того, что есть на сегодняшний день, я могу только улучшать. Не получается - будет работать так дальше.
Скрипт как-то странно работает в ОР. Придётся все функции с самого начала проверять на тестовом
Маневровый Б-С:
if ( enabled )
{ if ( ( opp_sig_lr (SIGFN_NORMAL) == 1 ) && ( next_N <= 2 ) && ( opp_D == 1 ) )
{ state = 2; draw_state = 1; } /// из горловины на станц. путь
}
else { state = 0; draw_state = 0; }
сам DISTANCE, opp_D == 1 - управляющий код в РЦ от оппозитно стоящего около входного светофора маневрового маркера, направленного на середину станции:
{ state = 0; }
if ( ( block_state() == BLOCK_CLEAR ) && ( next_sig_lr (SIGFN_NORMAL) <=1 ) && ( opp_sig_lr (SIGFN_NORMAL) <=1 ) )
{ state = 1; }
Буду проверять...
Ух, ты!!! Поменял на тестовом проходные на DISTANCE --- интересная штука получается. Ну-ка, какие твои выводы?
Добавлено через 7 минут
Костя, opp_sig_lr работает только на попутном светофоре. То есть, это
{ state = 0; }
if ( ( block_state() == BLOCK_CLEAR ) && ( next_sig_lr (SIGFN_NORMAL) <=1 ) && ( opp_sig_lr (SIGFN_NORMAL) <=1 ) )
{ state = 1; }
работать не будет
Как выводы??? Проходные DISTANCE? И что при этом происходит???
Зависимость DISTANCE от enabled()
Добавлено через 5 минут
DISTANCE работают как enabled() пока следующий NORMAL enabled(). Но, у меня тестовый полигон очень короткий. Я как-то тестил DISTANCE - там ещё расстояния имеют значение, если пользоваться этими функциями. Поэтому, я для передачи информации ими не пользуюсь
Добавлено через 8 минут
Мысль такая.
Первый проходной после станции в противоположном направлении от маневрового (нормальное положение RESTRICTING), в случае, если едет поезд в сторону станции будет !enabled, блок "за ним" по ходу - занят. Прописать в нём особый аспект на этот случай if (!enabled && (block_state() !=# BLOCK_CLEAR)){state = 1; }
Маневровый должен по if ( opp_sig_lr (SIGFN_NORMAL) == 1 ) "ловить" поездной режим и держать его до тех пор, пока сам не станет !enabled
Если условия в рамке не имело место - режим маневровый
А у меня так отдельный маневровый "датчик" работает.
А не повлияет этот проходной, если манёвры в сторону перегона? Хотя вроде не должен.
------------------------------------------------------------------
Дистансы работают. Я заехал за входной, и они все дружно загорелись жёлтым - для трафика.
"Своего" БУ не имеют.
DISTANCE работают как enabled() пока следующий NORMAL enabled()
Спасибо, про это не знал!
А не повлияет этот проходной, если манёвры в сторону перегона?
Нет. Выходной настраиваем давать на следующий 1 и 2 маневровый белый 2 и всё в ажуре. Проблема в другом. Как сохранить поездной режим?
Добавлено через 3 минуты
Лови скрипт моего маневрового :rolleyes:
(Хотя, я давал его уже на Заборе)
extern float block_state ();
extern float route_set ();
extern float next_sig_lr ();
extern float this_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;
next_state = next_sig_lr (SIGFN_NORMAL);
if (route_set ())
{
state = SIGASP_STOP;
if (enabled && (block_state() ==# BLOCK_CLEAR) && (next_state ==# SIGASP_STOP))
{
state = SIGASP_STOP_AND_PROCEED;
}
else if (enabled && (block_state() !=# BLOCK_CLEAR) && (next_state ==# SIGASP_STOP))
{
state = SIGASP_RESTRICTING;
}
else if (enabled && (block_state() !=# BLOCK_CLEAR) && (next_state ==# SIGASP_STOP_AND_PROCEED))
{
state = SIGASP_RESTRICTING;
}
else if (enabled && (block_state() !=# BLOCK_CLEAR) && (next_state ># SIGASP_RESTRICTING))
{
state = SIGASP_STOP;
}
else if (enabled && (next_state ==# SIGASP_RESTRICTING))
{
state = SIGASP_RESTRICTING;
}
else if (enabled && (block_state() ==# BLOCK_CLEAR) && (next_state ># SIGASP_RESTRICTING))
{
state = next_state;
}
draw_state = def_draw_state (state);
}
else
{
state = SIGASP_STOP; draw_state = 0;
if (this_sig_lr (SIGFN_NORMAL) ># SIGASP_STOP)
{
draw_state = 2;
}
}
Добавлено через 3 минуты
Это старый вариант без обратно-смотрящего маркера на выходных. Писал уже, что я их сейчас меняю на вариант с маркером из-за того, что стрелка не переводится, если за сервисом по удалению идёт ещё один
Спасибо! Посмотрю ещё раз, подумаю завтра - может, какие идеи появятся (а то спать надо...).
Как сохранить поездной режим?
Или наоборот, маневровый. Какие-то переменные нужны, чтобы не "сбрасывались". Например, у меня такая попытка была:
///////////////////// УПРАВЛЯЮЩИЙ МАНЕВРОВЫЙ МАРКЕР 1, светофор /////////////////////////////////////////////////////////////////////////////////////
SCRIPT TK_M1-V
extern float enabled;
extern float block_state ();
extern float next_sig_lr ();
extern float opp_sig_lr ();
extern float state;
///{ state = 0; }
if ( ( block_state() == BLOCK_CLEAR ) && ( next_sig_lr (SIGFN_NORMAL) <=1 ) && ( opp_sig_lr (SIGFN_NORMAL) <=1 ) )
{ state = 1; }
{ state = 0; } закомментировал.
То есть state равно 0, если только всё заново начинается.
Я пробовал инкримент. Если блок занят, прибавляется единица. Но, как только блок освобождается -- переменная обнуляется почему-то
Добавлено через 2 минуты
/////////////////////////////////////////////////////////////////////////////////////
SCRIPT TK_M1-V
extern float enabled;
extern float block_state ();
extern float next_sig_lr ();
extern float opp_sig_lr ();
extern float state;
///{ state = 0; }
if ( ( block_state() == BLOCK_CLEAR ) && ( next_sig_lr (SIGFN_NORMAL) <=1 ) && ( opp_sig_lr (SIGFN_NORMAL) <=1 ) )
{ state = 1; }
И что? Когда оппозит сбрасывается? Что со state?
Да, и dist_multi_sig_xx до конца пути как проверяет? То есть как это в скрипте выглядит?
Добавлено через 6 минут
И что? Когда оппозит сбрасывается? Что со state?
Вот это я проверять буду, с трафиком. Посмотрю, как оно работает, но только послезавтра.
http://storage7.static.itmages.ru/i/16/1029/s_1477773489_2688766_480c7d5d20.png (http://itmages.ru/image/view/5106146/480c7d5d)
Добавлено через 1 минуту
Да, и dist_multi_sig_xx до конца пути как проверяет? То есть как это в скрипте выглядит?
Как в дефолте
SCRIPT UKSemDist
// UK Semephore (Distance)
extern float block_state ();
extern float route_set ();
extern float def_draw_state ();
extern float dist_multi_sig_mr ();
extern float state;
extern float draw_state;
extern float enabled;
if ( //!enabled || // Not enabled/cleared to show natural state?
!route_set() || // Switch not set as per link?
dist_multi_sig_mr (SIGFN_NORMAL, SIGFN_DISTANCE) ==# SIGASP_STOP)
{
state = SIGASP_APPROACH_2;
}
else
{
state = SIGASP_CLEAR_2;
}
// Get draw state
draw_state = def_draw_state (state);
Проверяет головы NORMAL до следующего по пути DISTANCE. Если нет такового или путь заканчивается или есть на пути враждебная противошерстная стрелка - до места окончания пути
Для Open Rails заблокированный светофор тоже является "окончанием пути".
По скрипту, если есть хоть один STOP , считается, что условие выполняется!
Добавлено через 15 минут
http://storage7.static.itmages.ru/i/16/1029/s_1477774733_3413209_e1cafd4c37.png (http://itmages.ru/image/view/5106240/e1cafd4c)
Как удержать аспект? :mad:
Не удерживается даже в таком скрипте:
SCRIPT TK_WB
extern float block_state ();
extern float next_sig_lr ();
extern float state;
extern float draw_state;
float next_N;
float W;
next_N = next_sig_lr (SIGFN_NORMAL);
if ( ( state == 0 ) && ( block_state()!= BLOCK_CLEAR ) )
W = 1;
else if ( ( ( next_N == 1 ) || ( next_N == 2 ) ) && W == 0 )
{ state = 2; draw_state = 1; } /// из горловины на станц. путь
else { state = 0; draw_state = 0; }
Здесь переменная W задана для гашения белого в обратном направлении. Гаснет, но при обороте маневрового в горловине и движении обратно на станцию загорается белый, хотя сброс W в ноль не прописан в скрипте. То есть при перемене направления движения всё обнуляется заново независимо от скрипта.(?)
Похоже, что при переходе из !enabled в enabled или обратно происходит то же самое.
Переменная W - в принципе, тот же аспект.
1. М-м-дя-я... "Головы" SHUNTING тоже оппозиты не читают, условие opp_sig_lr (SIGFN_DISTANCE) всегда возвращает "0". И в стабильной, и в последней тестовой версиях.
2. Если на станц. пути стоят вагоны, а за вагонами горит белый ( state = 2;), то при этом на манёврах условие if ( next_N == 2 ) не работает, next_sig_xx возвращает ноль (вроде как РЦ зашунтирована колёсами, и коды не проходят:)).:mad:
Где можно посмотреть список внешних переменных для OR?
1. М-м-дя-я... "Головы" SHUNTING тоже оппозиты не читают, условие opp_sig_lr (SIGFN_DISTANCE) всегда возвращает "0". И в стабильной, и в последней тестовой версиях.
2. Если на станц. пути стоят вагоны, а за вагонами горит белый ( state = 2;), то при этом на манёврах условие if ( next_N == 2 ) не работает, next_sig_xx возвращает ноль (вроде как РЦ зашунтирована колёсами, и коды не проходят:)).:mad:
Где можно посмотреть список внешних переменных для OR?
Оппозит ловит только enabled светофор.
По 2.... Чет-ты, кажется, "мудришь" там. Работает.
Как это:if (enabled && (block_state() !=# BLOCK_CLEAR) && (next_state ># SIGASP_RESTRICTING))
{
state = SIGASP_STOP;
}
Так и это:
if (enabled && (block_state() !=# BLOCK_CLEAR) && (next_state ==# SIGASP_STOP))
{
state = SIGASP_RESTRICTING;
}
Моя версия 3651
Оппозит ловит только enabled светофор - вообще enabled, или у которого он указан в скрипте?
У меня маневровый Б-С типа SHUNTING, из-за этого и разница.
Всё, что я дал здесь (http://trainsim.ru/forum/showpost.php?p=539239&postcount=282) - работает. Просто добавь воды подставь и тести :cool:
Добавлено через 1 минуту
- вообще enabled, или у которого он указан в скрипте? Если у сигнала в скрипте прописана зависимость от оппозитной функции, эта зависимость будет проверяться только если сигнал перед поездом (enabled)
Подставил, работает! А SNCA у него какой, -1?
Что же, получается, все маневровые Б-С на NORMAL переводить...
Ну, это уже я не знаю )))
Я тебе тогда сразу сказал, что буду делать их NORMAL и сделал. По-другому с манёврами трафика проблемы. Маневровые не идеальны, есть несколько ситуаций, в которых приходится ехать "по приказу" на синий SAP, а также ситуация с занятым путём и красным на выходном. Хотя, с другой стороны, трафик не прицепляется к составу с локомотивом (для этого есть специальная WP), а идёт за ним по Нодам.
Добавлено через 1 минуту
Если решишь делать NORMAL-ами, советую ставить "заглушки" - маркеры РЦ (у меня они на точках выходных бэк-фэйсами, но можно и отдельно). Скрипты я дам.
Добавлено через 9 минут
А SNCA у него какой, -1?.
Да, -1
А что за маркеры РЦ, для чего они?
Скрипт РЦ (устанавливается на пути после всех стрелок, у меня, как я уже сказал, это обратно-смотрящая голова, но можно отдельно делать)
SCRIPT KRN23_RC_60
extern float block_state ();
extern float next_sig_lr ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float enabled;
extern float sig_feature ();
float next_state;
state = SIGASP_STOP;
next_state = next_sig_lr (SIGFN_NORMAL);
if (enabled && (block_state() ==# BLOCK_CLEAR) && (next_state ==# SIGASP_STOP))
{
state = SIGASP_STOP_AND_PROCEED;
}
else if (enabled && (block_state() !=# BLOCK_CLEAR) && (next_state ==# SIGASP_STOP))
{
state = SIGASP_RESTRICTING;
}
else if (enabled && (block_state() !=# BLOCK_CLEAR) && (next_state ==# SIGASP_STOP_AND_PROCEED))
{
state = SIGASP_RESTRICTING;
}
else if (enabled && (block_state() !=# BLOCK_CLEAR) && (next_state ># SIGASP_RESTRICTING))
{
state = SIGASP_STOP;
}
else if (enabled && (next_state ==# SIGASP_RESTRICTING))
{
state = SIGASP_RESTRICTING;
}
else if (enabled && (block_state() ==# BLOCK_CLEAR) && (next_state ># SIGASP_RESTRICTING))
{
state = next_state;
}
else
{
state = SIGASP_STOP;
}
draw_state = def_draw_state (state);
В принципе, практически то же самое, что я давал, они у меня раньше отдельными светофорами стояли, но, если несколько маневровых, надо было их по-разному делать, я сделал, но потом обнаружилась проблема с приготовлением маршрута, поэтому сегодня он только маркер :)
Маркеров несколько, отличаются только скоростью на SAP в конфиге в зависимости от пути (40 км/ч, 60... 80.... и т.д.)
Сам маневровый SCRIPT KRN23_WB_k2
extern float block_state ();
extern float route_set ();
extern float next_sig_lr ();
extern float this_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;
next_state = next_sig_lr (SIGFN_NORMAL);
if (route_set () )
{
state = SIGASP_STOP;
if (enabled && (block_state() ==# BLOCK_CLEAR))
{
state = next_state;
}
draw_state = def_draw_state (state);
}
else
{
state = SIGASP_STOP; draw_state = 0;
if (this_sig_lr (SIGFN_NORMAL) ># SIGASP_STOP)
{
draw_state = 2;
}
}
Этих можешь ставить сколько угодно. Они будут работать в связке и каждый отдельно (то есть, можно завести сервис за один/два/три и только они будут работать, остальные будут держать входной 0)
Всех дел :o
Добавлено через 4 минуты
Этоif (this_sig_lr (SIGFN_NORMAL) ># SIGASP_STOP)
{
draw_state = 2;
}Потому что он линкованый у меня из-за скорости. Я пока их не трогаю, они у меня расставлены на маршруте, но сегодня скорость на SAP можно не устанавливать, делать один, а скорость задавать специальным маркером типа SPEED - новый тип только для ОР
О, интересно! Что-то вроде было похожее у АРК с скоростями на SAP... Надо попробовать, потестировать вечером.
А, про ноды - если трафик идет "по ним", следующий сигнал с поездным значением отменяет это дело?
Да, отменяет. На Ноды переводят RES и SAP, остальные возвращают.
Про спид-маркеры читал, даже по-английски немного понял.:) То есть можно после SAP-маневрового поставить это, чтоб заходить на станцию со ск. например, 40 км/ч при закрытом выходном? А МСТС что скажет, не пошлет меня лесом с такими маркерами?:)
Добавлено через 7 минут
Тут еще дело в том, что делается скрипт ОР для версии сигналки, уже установленной на маршруте "Павловск". То есть в расстановке светофоров и маркеров все должно оставаться как есть, без изменений. Вот и пытаюсь что-то выжать из этого.:)
Естественно, в МСТС всё нужно ставить. То есть, прописывать в конфиге на МСТС-овском языке. Никаких новых функций там нет. головы надо прописывать как INFO, SuHNT и тому подобное, с "левыми" конфигами и скриптами. А как же иначе?
Добавлено через 2 минуты
Если на выходных у тебя есть "лишняя" голова, которую можно развернуть - отлично. Я на моделях Тимаса разворачивал не переставляя светофоры. У него там по 2 линка на главный путь и по 2 по неправильному с АЛСО, вот я по одной и "оттяпал" )))
У моих есть, но не у всех расставленных. И да, менял тоже, где были вторые головы.
_______________
Пробовал переводить сигналку в ручной режим по Ctrl+F9, но не понял, что же делать с этим... или это если сценарий "застрял"?:)
Что это за Ctrl+F9? 0_0
Добавлено через 2 минуты
Может, Alt+F9?
Перепутал:o, вот так - Ctrl+M.
Manual Mode (http://forum.zaborin.ru/topic.php?forum=7&topic=4&postid=1428607209#1428607209),что ли? Так оно "клинит" весь сценарий! Помни, что ни одна стрелка в этом режиме не переводится автодиспетчером.
Добавлено через 1 час 3 минуты
http://storage3.static.itmages.ru/i/16/1101/h_1477961543_3299901_752d0fc3dd.png (http://itmages.ru/image/view/5117512/752d0fc3)
;)
Добавлено через 49 минут
На скрине -- маневровый сигнал и "маркер РЦ". Стрелка остаётся "стерильной зоной". Когда состав на стрелке -- маневровый строго STOP, только так автодиспетчер может производить свои операции.
Маркеры РЦ - обратнонаправленные головы у выходных, так? Стоп перед стрелкой - как только голова ПС дойдет до маневрового сигнала.
Вчера гонял свои маневровые светофоры SHUNTING, они оппозиты то видят, то не видят - не пойму, от чего зависимость...
Про спид-маркеры читал, даже по-английски немного понял.:) То есть можно после SAP-маневрового поставить это, чтоб заходить на станцию со ск. например, 40 км/ч при закрытом выходном
Не забывать заявлять специальный флажок в конфигурации
SignalAspect ( STOP_AND_PROCEED "No" SpeedKPH ( 60) signalflags (OR_NOSPEEDREDUCTION) )
SignalAspect ( RESTRICTING "No" SpeedKPH ( 20 ) signalflags (OR_NOSPEEDREDUCTION) )
...чтобы трафики не притормаживали (до 5 миль/час)
Тут еще дело в том, что делается скрипт ОР для версии сигналки, уже установленной на маршруте "Павловск". То есть в расстановке светофоров и маркеров все должно оставаться как есть, без изменений. Вот и пытаюсь что-то выжать из этого.:)
ИМХО... Маршрут вышел? Ариведерчи! Будут патчить - переставишь сигналы. Если кроме них *.tdb не будет изменён, сценарии пойдут, максимум - пересохранить сцену в редакторе без изменений.
Добавлено через 4 минуты
Маркеры РЦ - обратнонаправленные головы у выходных, так?
Эгэж :crazy:
Но, можно и отдельным маркером делать - не принципиально.
Стоп перед стрелкой - как только голова ПС дойдет до маневрового сигнала Конечно! По block_state(), как обычный NORMAL.
Вчера гонял свои маневровые светофоры SHUNTING, они оппозиты то видят, то не видят - не пойму, от чего зависимость... Не игрался с ними. Они не влияют на сервис, а посему неинтересны мне. С DISTANCE работаю на ПАБ и INFO на указателях, повторительных головках и т.д.
Добавлено через 1 час 22 минуты
http://storage8.static.itmages.ru/i/16/1101/h_1478000417_3558211_a18df00398.png (http://itmages.ru/image/view/5119838/a18df003)
Тоже выходные с обратными головами? Малахитовка вроде...:)
Отказался от -1 на маневровых. Не очень хорошо получается. Он не учитывается, если поезд едет к нему. А, вот, после точки разворота на маневровом, светофор не "энэйблит" уже второй по ходу сигнал. -1, пока остаётся на светофорах прикрытия. Пока всё.
Ага, похоже вот и причина неработающих сигналов и у меня. Спасибо! Похожее было - не открывался Б-С маневрик с SNCA=-1 у точки разворота перед входной стрелкой.
Ну, отерываться-то он -- открывается. Только SAP по скрипту. Естественно, остаётся синим, но траф едет. Не айс, тем более, что ситуация вполне на RES и белый. Так что... входной надо расчитать, чтобы хватало на всё (у меня вообще предвходные этим делом заняты. Я их размножил и теперь имеются клоны на SNCA 2, 3, 4 и 5.)
А если поставить 2 подряд перед узлом, и один закопать?:D
Посмотреть, как будут работать...
А что, "ApproachControlSettings" только с NORMAL-ами работает?
Да так и есть - нормалы срабатывают, а "шунты" - нет.
Как и ШУНТИНГ - тоже не работают с этим. Надо к разрабам идтить челом бить...:)
Сходи-сходи! :D
Я никак не соберусь сходить и побить по челу челом за функции block_state () и next_sig_xx () , которые на выходных работают по какому -то аЦкому алгоритму и совершенно не предсказуемы... Что-то мне подсказывает, что буду послан. Разработка заигрались "неосигналенными" маршрутами и Timetable Mode, все в данный момент скандалят, а автор всего, что касается организации движения просто непробиваем...
Я б сходил бы, да в аглицкой мове не умён...:crazy:
А сколько там всего народу участвует в ORTS?
---
block_state () и next_sig_xx () непонятно как срабатывают, когда выходишь со станции по удалению. Получается, что первый проходной какое-то время !enabled, но непонятно - как именно это время рассчитано в движке.
Выходные, как я понял пока - даже если путь сервису не доходит до след. сигнала, и тот не виден на мониторе пути - скриптом его всё равно можно проверить, иначе бы маневровый на выходном по зависимости от next_sig_lr(SIGFN_NORMAL) == 1; (state=1; у проходного по !enabled) не открывался бы.
Уверен, что проблема с enabled()? У меня другие выводы. Я "грешу" именно на функции block_state () и next_sig_xx (). Если ещё точнее, на то, как они взаимодействуют. Писать разрабу сигнализации никак не соберусь (с лета ещё). Сначала хочу проверить свои скрипты. Вдруг проблема там? Пока занят сценариями.
Насчет выходных, у меня, тогда, противоположная проблема: он должен давать RES на след RES, проходные по !enabled() - RES. Если вывести путь сервиса за последнюю стрелку на главный ход, всё работает "на ура". Проблемы начинаются, когда манёвры идут внутри станции. Предварительно - блок высчитывается до первой стрелки за путём, она же даёт 0 по цепи. И всё! Арр... (ррр) - поездной аспект!
Был вообще дикий случай: с одного пути в депо заходили один за другим 3 тепловоза "Из-под составов". Первый и третий уходили по маневровому аспекту, а средний - по поездному.
Олег, ты на мониторе пути ничего странного не замечал? "Лишние" светофоры там показывались...:eek: На месте одного - два рядом.
Я сделал себе вот такую текстуру (https://yadi.sk/i/bb4876-Ty9n7A) для него - с тонкими линиями вместо кружков, и сразу видно, что что-то здесь не так...
Ну, о тестовой версии мог бы спросить! :confused:
Я пытался (http://trainsim.ru/forum/showpost.php?p=537688&postcount=19) :). А, вот, новости о версии 1.1 разочаровали. Я, если честно, хотел на неё "откатиться".
Что наделали?
Что наделали?
Ну, вот, об этом самом и хотел сказать. Глюки внешних функций влияют на сигналы. Я когда-то писал, что на 0.9 до какого-то момента работало по-другому. На 1.1 пришлось переписывать логику, но, где-то я упустил момент начала этих глюков. Всё невозможно сразу проверить. Блокировки работают, трафики гоняют, на дисплее диспетчера не всегда отчетливо видно что именно там открывается и кому. Потом заметил в одном месте, потом в другом... и пошло-поехало...
Олег, ты на мониторе пути ничего странного не замечал? "Лишние" светофоры там показывались...:eek: На месте одного - два рядом... что-то здесь не так...
Вижу давно это на Ctrl+Alt+F11. "Списывал" на "многоголовость" сигнальных точек, потому как проверил, что все они работают по SNCA четко. В поездном режиме вообще никаких проблем нет. Геморр начинается когда есть точки разворота... возможно и точки ожидания влияют перед окончанием трэка
Да, с точкой разворота. По Ctrl+Alt+F11 виден только выходной с 2Ж, а на мониторе - ещё и S.A.P. какой-то перед ним...:mad: Если бы вторая "голова"... но у неё вообще нет S.A.P. ни в конфиге, ни в скрипте...
Вот сейчас как раз пытаюсь "добить" одно место...
Лок отцепляется от состава, приехавшего на станцию и должен уйти в депо по маневровому белому (сигнал настроен давать RES на след. RES) в горловине между стрелками поставил точку (WB - даёт RES если block_state () !=# BLOCK_JN_OBSTRUCTED), SNCA выходного - 3... И - фигос! Маневровая точка в нуле и выходной открывается поездным Арр
Добавлено через 6 минут
Ха!!! Поставил на пути трафика внутри в депо ещё один маневровый... Заработало
"Внутри депо" - тупики все, что ли, осигналить рестриктом?
Стрелки, что ли, влияют на маневровое движение...
Давно эту хрень подозревал. Писал сегодня о случае с тремя тепловозами в депо, так вот, там они по разным путям шли. Два по одному, а третий по другому. Так там один путь с сигналом был, а другой без
Добавлено через 1 минуту
Стрелки, что ли, влияют так?
Думаю, что это связано с окончанием пути игрока/трафика
..Так там один путь с сигналом был, а другой без...
А поставь на другом тоже - как получится с показаниями?
Позже. Пока вот они - твои "двойные": :crazy:
Выходной
http://storage2.static.itmages.ru/i/16/1106/s_1478429318_9224732_28a544ae11.jpg (http://itmages.ru/image/view/5147766/28a544ae)
Первый маневровый
http://storage4.static.itmages.ru/i/16/1106/s_1478429319_2516989_8c58e9ca10.jpg (http://itmages.ru/image/view/5147768/8c58e9ca)
...и второй
http://storage3.static.itmages.ru/i/16/1106/s_1478429319_6236877_624d0cc0e7.jpg (http://itmages.ru/image/view/5147767/624d0cc0)
Добавлено через 28 минут
А, вот и стрелка, через которую не проходит путь сервиса:
http://storage8.static.itmages.ru/i/16/1106/s_1478431066_2309091_b34a6131ba.jpg (http://itmages.ru/image/view/5147846/b34a6131). Мне кажется, что, вот, именно эта хрень даёт чистый блок и "0" на след. аспект
http://storage6.static.itmages.ru/i/16/1106/s_1478431064_3791939_b270cd386a.jpg (http://itmages.ru/image/view/5147844/b270cd38)
Добавлено через 16 минут
Это получается некое "состояние неопределённости". И связано это не столько с тем, что так хочет Роб Ротердинк, который считает, что если стрелка не находится на маршруте сервиса, или/и светофор заблокирован или/и перед узлом есть точка разворота/ожидания, то не важно ни состояние блока ни положение стрелки, сколько с тем, что сим программируется на работу с "неосигналенными" маршрутами.
Тогда проверю своё в мультиплеерном режиме..
Погонял бы с тобой, но надо на работу ехать...
А поставь на другом тоже - как получится с показаниями?
Решил поставить, но сначала снова " проиграл" сцену без изменений сигналов...
Вот первый лок ждёт скрещенияhttp://storage9.static.itmages.ru/i/16/1106/s_1478468865_7798309_1b476b17b1.jpg (http://itmages.ru/image/view/5150718/1b476b17). Вот он уходит по RES http://storage1.static.itmages.ru/i/16/1106/s_1478468866_5459072_bab905d712.jpg (http://itmages.ru/image/view/5150719/bab905d7) Это сигналы на его пути http://storage3.static.itmages.ru/i/16/1106/s_1478468867_1049482_d4345fe806.jpg (http://itmages.ru/image/view/5150721/d4345fe8)
А, вот второй пошёл http://storage5.static.itmages.ru/i/16/1106/s_1478468901_5883707_3752326a7b.jpg (http://itmages.ru/image/view/5150723/3752326a) А это сигналы на пути второго http://storage7.static.itmages.ru/i/16/1106/s_1478468905_2717482_3a62b42b53.jpg (http://itmages.ru/image/view/5150724/3a62b42b)
Чёрт его знает. Теперь и здесь заработало нормально. Может, проблема заключалась в этом SNCA = -1?
Но, всё равно "определяющий" маневровое показание светофор не должен быть последним перед окончанием трека.
Добавлено через 4 минуты
Костя, вопрос:
Ты писал о "двойных" аспектах. А, вот с таким ты сталкивался? http://storage9.static.itmages.ru/i/16/1106/s_1478468906_7474415_20365c2afa.jpg (http://itmages.ru/image/view/5150726/20365c2a)
Э-э... это как??? Никогда не попадал на такое. Хм-м...!
___
Олег, с двойными показаниями на мониторе пути понял - косяк в текстуре SignalAspects, исправлено. Так что ложная тревога была.
И вот еще подумал, только сейчас не могу проверить - в настройках есть "Extented AI shunting", иди вроде того - это что, может выключить?
И вот еще подумал, только сейчас не могу проверить - в настройках есть "Extented AI shunting", иди вроде того - это что, может выключить?
Ни в коем случае! Трафики отцепляются только когда оно выбрано...
Олег, чем закончилось дело на последнем скрине?
____________________________________________
Проверил, "Extented AI train shunting" на светофоры не влияет. Попробовал отключить, показания маневровых светофоров не изменились, всё так же срабатывают "через раз".:rolleyes:
...Но, всё равно "определяющий" маневровое показание светофор не должен быть последним перед окончанием трека....
Точно так, тоже заметил. Давно ещё писал про тест с 2 тупиковыми маркерами рядом (в тупике), когда последний не "энейблился".
Олег, чем закончилось дело на последнем скрине?
.
Последний скрин показывал, что не проявляется аспект светофора по Ctrl+Alt+F11. А ты о чём? :crazy: О том, что линии накладываются? Дык... Так и должно там быть! Это поворотный круг, там нет перекрёстков...
Вот может из-за пересечения и "потерялся"?
А вообще подумал, что сервисы пошли одновременно. Вспомнил тему, где 2 сервиса на перекрёстной стрелке шли с отклонениями и "притирались боками"...
Нет, не из-за пересечения. Это - не единственное место, где "теряются". С перекрёстными стрелками - тоже беда. По симулятору - это не пересекающиеся пути. Пока что, с этим ничего поделать нельзя.
Еще где-то теряются - а где? Это как-то зависит от дальше стоящих по ходу сервиса сигналов (или стрелок)?
Не разобрался с этим. Теряется только изображение по Ctrl+Alt+F11. Сам сигнал работает
Добавлено через 28 минут
Вот, например, ещё место. Может, это проблема у меня с отображением. Потому что всё работает.
http://storage8.static.itmages.ru/i/16/1108/s_1478610234_4127113_4059d850ac.jpg (http://itmages.ru/image/view/5159200/4059d850)
Вот, сигнал блокирует. Всё нормально
http://storage9.static.itmages.ru/i/16/1108/s_1478610235_6711671_abf97afb92.jpg (http://itmages.ru/image/view/5159201/abf97afb)
Но, всё равно "определяющий" маневровое показание светофор не должен быть последним перед окончанием трека.
Он должен стоять "где-то на пути"; если поставить 2 рядом в тупике - то не сработает, если там перед ними точка разворота.
Конечно. Он должен быть включен. Я ставлю SAP в начале тупика, рядом с маневровым светофором в противоположном направлении. Можно давать и "1"
Понятно. Пока имеем такой ORTS - тупики осигналиваем в начале пути, а не в конце у призмы. Ведь заход в тупик почти всегда с разворотом.
У меня в конце пути хоть и есть маркер с постоянным аспектом RESTRICTING, выходной/маршрутный светофор этого "не видит", и "думает", что там STOP.
Хотя это все совместимо, и МСТС-у не помешает.
Когда-то давно я так начал на своем переделанном "Демитрове". Еще не умея как следует писать скрипты, просто ставил в начале тупикового пути маркер с постоянным рестриктом, чтобы можно было заехать на этот путь, даже если он занят.
Хорошо. А, вот, к тебе вопрос. У тебя присутствует "мигание" сигнала? В смысле, например в этой ситуации -- по выходному в тупик/депо. Сначала загорается Арр на долю секунды, а потом уже белый. В другом месте - наоборот у меня: сначала белый, потом - поездной. Причина ясна мне - сигналы "включаются" дальше по пути один за другим, а, вот, как с ним бороться - не представляю пока
Да, так иногда бывает. Наверно, скрипты срабатывают не сразу, пока сим на пути сервиса их все отрабатывает. Ничего не делал с этим (да и что тут сделаешь?..), считаю, что реле в шкафу так переключаются.:)
Олег, не замечал - у тебя "Extended AI train shunting" на работу светофоров влияет или нет?
"Extended AI train shunting" у меня всё время включено. Даже не пробовал другой режим. Поэтому, не могу ничего сказать. Для всех функций прицепок, абсолютных точек ожидания и т.п. оно должно быть выбрано. Поэтому, в другом виде не вижу целесообразным играть.
Костя, ну как? Сделал? Покажи скрипт маневрового!
Да так полностью и не добился чёткой работы маневровых. Сейчас скрипт карлика Б-С такой:
SCRIPT TK_WB_k
...
float next_N;
next_N = next_sig_lr (SIGFN_NORMAL);
if ( ( enabled ) && ( next_N <= 2 ) && ( block_state() != BLOCK_JN_OBSTRUCTED ) )
{ state = 2; }
else { state = 0; }
Пихал в него разные зависимости, но всё без толку...
Он сам типа SHUNTING.
В некоторых местах не загорается белый, если светофор стоит первым на пути сервиса перед входной стрелкой. Сам путь - с точкой разворота перед этой же стрелкой.
И как я понял, "шунты" тоже не читают opp_sig_xx, как и "дистансы".
Жаль. А то можно было бы гасить белый через обратно стоящий маневровый маркер по занятости БУ, если поезд с перегона.
Удаётся зажечь пригласительный через
if ( (Approach_Control_Speed(Approach_Control_Req_Posit ion, Approach_Control_Req_Speed)) )
В конфиге установил скорость 10 км/ч, и расстояние 17м - чтобы трафик не лез.
Странно как-то. Вынес зависимость от обратностоящих маркеров в отдельную строку, и заработало:
if ( ( enabled ) && ( next_N <= 2 ) && ( block_state() != BLOCK_JN_OBSTRUCTED ) )
{ state = 2; }
if ( opp_sig_lr (SIGFN_DISTANCE) == 1 )
{ state = 0; }
Получается, что сигнальные головы SHUNTING всё-таки "видят" оппозитные коды.
ORTS 1.1.1.3487
Мутота какая-то... В разных местах разные результаты тестов... похоже, не надо оппозиты применять вообще.
У тебя, скорее всего, расстояния разные в разных местах. Или ты тестировал с составами разной длины. Обрати внимание, что функция block_state() y DISTANCE работает иначе, чем у NORMAL! Если голова сервиса не находится перед сигналом, не важно есть на блоке вагоны или нет, функция возвращает BLOCK_CLEAR. Так что, возможно, не столько с opp_sig_xx() проблема, сколько с самим сигналом , с которого ты снимаешь показания.
То есть, только, если голова на блоке (или головная секция статики) DISTANCE считает блок занятым
Да, понятно.
Но дело не в этом. В любом случае при подходе поезда с перегона обратностоящий DISTANCE-маркер бывает в "!BLOCK_CLEAR" хоть какое-то время:
state = 0;
if ( block_state() != BLOCK_CLEAR )
{ state = 1; }.
А маневровые типа SHUNTING не всегда срабатывают на это по условию:
if ( opp_sig_lr (SIGFN_DISTANCE) == 1 )
{ state = 0; }
Бывали белые вместо синих. Я ж еду на этом паровозе, всё вижу, как они горят.
--------------
Просто в скрипте невозможно сделать, говоря электронным языком, какой-нибудь "запоминающий регистр" (ага, К155ТМ2 в релейный шкаф засунуть:D) для сохранения некоторого состояния сигналов. При изменении состояния одного маркера заново отрабатываются скрипты всех светофоров "с нуля", и при этом все переменные сбрасываются.
"Я так думаю" :)
Есть одно положение, в котором "запоминается" аспект перед стрелкой. Я его описывал, но, к сожалению, оно наоборот, мешает (((
Когда сигнал "включен" следом идущим сервисом и запрограммирован на 1 или 2.
Я тут вот думаю, как мне на АРС-ных линиях в метро автоблокировку включать для мотовозов например в сценариях. Сейчас у меня в конце маршрута в тупике валяется SHUNTING голова, в зависимости от состояния которой все предыдущие светофоры решают, включиться им, или нет. Самой этой головой в сценариях можно управлять хоть невидимым локомотивом на точке ожидания на невидимом отрезке пути за тоннелем с тупиком (куда заведомо никто не заедет). Проблема в том, что в ОР сигнал от этой головы на 40 километров явно не добьёт. К примеру, шунтинг валяется в самом конце 1 пути Алтуфьево, а первый включившийся светофор автоблокировки был только на Владыкино (в мультиплеере). Зато в сингле, если ехать задом, то зеленые были аж до самой Чертановской, но если загрузиться на этой же Чертановской и поехать вперёд, то так уже не будет. Т.е аспект очень далёкого шунтинга оно помнит, но не обновляет, пока не подъедешь. В связи с этим вопрос, как можно например сервису мотовоза в сценарии включить АБ, а за ним погасить...
Добавлено через 30 минут
Есть идиотская мысль включать, если !enabled, и ставить на пути следования точки ожидания хоть по секунде, но тогда АБ будет гореть всегда и не будет только когда едет сервис с точками ожидания, что тоже не есть хорошо
А почему SHUNTING?
Добавлено через 1 минуту
Не совсем понял ситуацию. Можно поподробней?
А, не, просто так можно и погасить, если STOP
Добавлено через 4 минуты
Линия метро с АЛС-АРС. Автоматические светофоры погашены, полуавтоматы горят синим. Едем по указателю в кабине (коды АЛС, нормалом передаю). Светофоры - дистанс головы, либо погашены, либо синие. Но могут быть ситуации, когда потребуется включение автоблокировки, например для поезда, необорудованного устройствами АЛС-АРС. Вот я и думаю, как в сценарии такому поезду все дистансы зажечь. А шунтинг как раз это условие, включать, или нет.
За 40 километров ты представляешь какой SignalNumClearAhead должен быть?
(А где маршрут? :D )
Добавлено через 1 час 15 минут
А NORMAL-ы где? На той же точке? Или они отдельно выставлены?
Мне такая же тема предстоит для МЦК.:)
Думаю: все светофоры делать "двухголовыми" для передачи доп. кода гашения. Этот код (напр., DISTANCE) меняет свое значение вот именно так - в зависимости от пути сервиса, там спец. маркер или светофор.
Наш выходной светофор считывает этот код по this_sig_lr(SIGFN_DISTANCE), и выдает нужный draw_state.
Все это мысли, надо проверять...
Добавлено через 2 минуты
SNCA вот тоже может не дать сработать этому...
Самой этой головой в сценариях можно управлять хоть невидимым локомотивом на точке ожидания на невидимом отрезке пути за тоннелем с тупиком (куда заведомо никто не заедет)
Упс... не заметил про невидимку. Дык, NORMAL сделай сигнал в тупике и одним аспектом передай без зависимости от enabled(). Вопрос здесь не столько в расстоянии, сколько в стрелках "по пути". Может и не пройти.
Допустим "за" мотовозом можно погасить, а перед ним - никак - не пройдёт аспект из тупика.
Единственное, что приходит в голову -- невидимые "развилки" на светофоре. Не знаю: есть ли такие секции пути вообще. В общем, идея бредовая. Мы, вон, с Костей так и не смогли "удержать" маневровый режим на 50-100м на станции, а тут - разная логика в зависимости от типа состава... Можно сделать для одного из сервисов, скажем двойные точки разворота, но тогда трафик будет останавливаться перед каждым светофором на секунду...
Ну можно не перед каждым, пока добивать не будет) В хвост поезду можно подавать, как бы его обгоняя, связкой с оппозитными головами?
Надо попробовать проверить, насколько вообще далеко возможно передать управляющий код... Попробовать сделать зависимость от конечной точки (типа пути) у сервиса. Путевыми маркерами типа INFO сделать осигналивание тупиков разных типов, например. И посмотреть - на каком расстоянии сим "увидит" этот маркер?
И погасить огни можно "на занятый путь".
Всё равно не дело это. Обыграть, что мотовоз короче, чем поезд, поставив сигнал с обратного направления, тоже, пока не представляю как. Светофор будет зажигаться метров за 80
(А где маршрут? :D )
Маршрут являет собой СТЛ с Бутовкой и ГЗЛ на тоннелях от E69 с дырками на стрелках, с тупо конвертнутыми станциями из ТРС). Мне кажется меня тут за него пристрелят)) Ибо у меня есть разрешение авторов только на куски эстакадных секций, и на ковыряние модели светофора от Кости:). Если интересно, могу создать тему, описать подробнее.
А... понятно. Что-то вроде моего маршрута... Не,не надо, а то загрызут )))
А стрелки дефолтные в туннели есть же...
...Обыграть, что мотовоз короче, чем поезд, поставив сигнал с обратного направления, тоже, пока не представляю как. Светофор будет зажигаться метров за 80
Зажигаться, если путь свободен от хвоста состава? Поставить какие-то 2 спецсветофора на заданном расстоянии друг от друга, задний - обратно развёрнутый; определим, что едет грузовой в 3 вагона или мотовоз...
И какой-то отдельный аспект надо передать вперёд по ходу поезда - оппозитными NORMAL-головами, стоящими в каждом светофоре? Тогда код "побежит" вперёд по ходу сервиса; но будут ли оппозиты чётко работать?
Не, короче-длиннее хрен с ним, просто в определенное время включить и выключить. Обратные коды может и сработают, но на некотором расстоянии их постигнет та же участь, что и передних...
Ручного переключения нет (только в РТС есть переключение режима для манёвров), надо в скриптах как-то делать.
просто в определенное время включить и выключить.
Нет такого. Ни в MSTS ни в ORTS.
Можно попробовать поймать последний сигнал в тупике через dist_multi_sig_хх(). Проблематично, конечно, но попробуй. Я не знаю: поймает ли сигнал эту функцию на большом расстоянии. Смысл такой: ставишь в тупике вместо SHUNTING особый NORMAL (сначала так попробуй, не факт что сработает, но шансов больше). Запрограммируй его давать аспект, который не используешь во всех режимах на маршруте (RESTRICTING, STOP_AND_PROCEED, CLEAR_1, APPROACH_3, по ситуации твоей), когда блок за ним занят (стоит твоя невидимка). Между ним и концом трэка поставь "для верности" DISTANCE (надеюсь, ты не используешь их, если используешь - другой тип надо ставить, которого нет на пути сервисов до самого конца). Стрелки должны по умолчанию вести в тупик (прямо, то есть).
В скрипте задай
if (dist_multi_sig_lr (SIGFN_NORMAL, SIGFN_DISTANCE) ==# [наш аспект особый] )
{есть показания}
Дальше всё зависит от того насколько далеко сим будет "видеть" путь. По хрестоматии, он должен видеть его по стрелкам до конца и ловить последний DISTANCE. Но, на практике из-за SNCA и множества узлов по пути, может быть сбой. Но, попытайся.
Лол, все использую. Все восемь. И ещё двух не хватает, дистанс тоже использую, как раз они и должны включаться)))
Лол, все использую. Все восемь. И ещё двух не хватает...
С защитными участками, что ли?
Если DISTANCE-ов нет, то можно и так
if (dist_multi_sig_lr (SIGFN_NORMAL, SIGFN_INFO) ==# [наш аспект особый] )
{есть показания}
Лол, все использую. Все восемь. И ещё двух не хватает, дистанс тоже использую, как раз они и должны включаться)))
Все восемь на метро? Ммм... Зажигать можно посредством draw_state, на той же голове NORMAL, не прибегая к DISTANCE
Хотя у меня APPROACH_1 используется для зажигания ПС в ручном режиме, или для выдачи кода ОЧ. Концы тупиков как раз осигналены нормалами, постоянно подающими этот аспект. Сейчас попробую воткнуть дистанс и посмотрю, зажжёт ли)
Добавлено через 3 минуты
С защитными участками, что ли?
Все восемь на метро? Ммм... Зажигать можно посредством draw_state, на той же голове NORMAL, не прибегая к DISTANCE
Нормалы - коды АРС. Указатель в кабине имеет ячейки: ОЧ 0 40 60 70 80. Если текущая разрешённая скорость больше, чем на следующей РЦ, то светятся две ячейки, с текущей и предупредительной частотой. Вот и получаем:
SIGASP_STOP - "0";
SIGASP_STOP_AND_PROCEED - "0" и "40";
SIGASP_RESTRICTING - "40";
SIGASP_APPROACH_1 - "ОЧ";
SIGASP_APPROACH_2 - "40" и "60";
SIGASP_APPROACH_3 - "60";
SIGASP_CLEAR_1 - "70";
SIGASP_CLEAR_2 - "80";
Добавлено через 9 минут
В тех доках МСТС говорится, что она может быть только dist_multi_sig_mr()
Добавлено через 12 минут
Пока не работает, немного скринов:
https://pp.vk.me/c837122/v837122167/e3c1/rSCdiHtrMDw.jpg
https://pp.vk.me/c837122/v837122167/e3ca/wP1Q_meblr8.jpg
https://pp.vk.me/c837122/v837122167/e3d3/j-SjE3_uXwI.jpg
Еду до Алтуфьево в ускоренном режиме, посмотрю, ближе к нему зажгутся, или нет.
Добавлено через 2 минуты
(Надо бы дырки у порталов позатыкать)
Добавлено через 2 минуты
На Биберево тоже не горят, значит дело в скриптах.
https://pp.vk.me/c837122/v837122167/e3dc/5rFT4XFuW8c.jpg
https://pp.vk.me/c837122/v837122167/e3e5/JjO24paPzH0.jpg
Добавлено через 4 минуты
А, ну ясен хрен, MOST RESTRICTIVE, а значит навернется на первом стопе.
CLEAR_2 будет
Добавлено через 1 минуту
Однако, пытаюсь
На последнем NORMAL в тупике показание дай "-1" на занятый блок, на остальных
if (dist_multi_sig_mr (SIGFN_NORMAL, SIGFN_DISTANCE) ==# -1 )
{есть показания}
Ты не будешь этот аспект ничем ловить, он только передаёт режим
Добавлено через 1 минуту
И иди "от тупика" дальше. Начни с ближайшей станции, а не за 40 км и отдаляйся с каждым тестом
Все равно не работает. Ничего, что у меня не дистанс, а шунтинг?
Покажи скрипты обоих полностью. Думаю, что шантингами они вообще не занимались. Так что результат непредсказуем
Блин, уже комп вырубил, завтра напишу. И на тестовом роуте поиграюсь, если что, то поменяю типы с дистансом местами. P.S. Светофоры дистансом, потому что они отдельно работают от АРС. Например, если впереди идущий отправился, то как только он освободит две рц-будет уже разрешающее показание. А светофор автоблокировки откроется только когда поезд уедет со следующей станции. Я вроде на заборине упоминал об этом
Ещё вводная. По-моему, ты много от сима хочешь)))
Ну тем и интереснее)) Накрайняк есть контроль енабледом)
"Энэйблить" будут в равной степени как мотовозы, так и поезда с АРС - фэйл, ИМХО.
Надо выделить чем эти два сервиса отличаются. Я тут писал о длине - раз. Ты говорил о пути - два. Чем ещё?
Тестил с ближайшей к тупику станции? И скрипты кинь проходных и тупикового. Может там что подправить надо будет
Сервисы ничем не отличаются, по условиям сценария включаем АБ, захотелось нам. Можем на нормальном поезде ехать, а потом типа у нас АРС накрылась и нам включили АБ
Добавлено через 3 минуты
Сам светофор
SCRIPT ARS_2AB
extern float block_state();
extern float route_set();
extern float def_draw_state();
extern float state;
extern float draw_state;
extern float enabled;
extern float dist_multi_sig_mr();
float next_state;
float ars_flag;
state = SIGASP_STOP;
next_state = next_sig_lr (SIGFN_DISTANCE);
//ars_flag = next_sig_lr (SIGFN_SHUNTING);
if (dist_multi_sig_mr (SIGFN_NORMAL, SIGFN_SHUNTING) ==# -1)
ars_flag = 1;
if ((block_state() ==# BLOCK_CLEAR && next_state ==# SIGASP_CLEAR_2) || (block_state() ==# BLOCK_CLEAR && next_state ==# SIGASP_RESTRICTING))
{
state = SIGASP_CLEAR_2;
}
if (ars_flag == 0)
draw_state = 2;
else
draw_state = def_draw_state (state);
Нормал в тупике
SCRIPT TUPIK
extern float state;
state = -1;
Шантинг
SCRIPT ARS_FLAG
extern float def_draw_state();
extern float state;
extern float draw_state;
extern float enabled;
float next_state;
state = SIGASP_APPROACH_1;
//state = next_sig_lr (SIGFN_SHUNTING);
draw_state = def_draw_state (state);
Ну, во-первых
SCRIPT ARS_2AB
extern float block_state();
extern float route_set();
extern float def_draw_state();
extern float state;
extern float draw_state;
extern float enabled;
extern float dist_multi_sig_mr();
float next_state;
float ars_flag;
state = SIGASP_STOP;
next_state = next_sig_lr (SIGFN_DISTANCE);
//ars_flag = next_sig_lr (SIGFN_SHUNTING);
if (((block_state() ==# BLOCK_CLEAR) && (next_state ==# SIGASP_CLEAR_2)) || ((block_state() ==# BLOCK_CLEAR) && (next_state ==# SIGASP_RESTRICTING)))
{
state = SIGASP_CLEAR_2;
}
draw_state = def_draw_state (state);
if (dist_multi_sig_mr (SIGFN_NORMAL, SIGFN_SHUNTING) ==# -1)
{
draw_state = 2;
}
Так будет правильней
Добавлено через 5 минут
Тупиковый
extern float block_state();
extern float state;
state = SIGASP_STOP;
if (block_state() !=# BLOCK_CLEAR)
{
state = -1;
}
draw_state = def_draw_state (state);
Ты же даёшь ему "-1" когда "за тупиком" стоит невидимка,так?
Добавлено через 3 минуты
Шантинг пофиг какой у него скрипт. Он нужен для того, чтобы дать границу функции dist_multi_sig_mr(), снимать с него показания вряд ли получится
Пока что пофиг, что там в тупике стоит, я пытался просто светофоры зажечь. В принципе, я все таки enabled'ом думаю. Интересно, что у меня с этой АБ получилось так, что на блок участки оно делится не светофором, а границей предыдущей РЦ (предыдущей красной пирамидкой). Вот и можно контролить в светофоре enabled, если нет, то зажигать его и пару-тройку за ним.
Добавлено через 18 минут
Где-то вдали у нас в конце обязательно будет тот, до которого путь не дойдёт, и он будет заведомо !enabled. Помимо этого, за ним ничего определяться, и если не использовать SIGASP_STOP, то по нему можно будет отловить конец трека. И уже тогда, если светофор !enabled и контрольная голова не равна нулю (!enabled && next_sig_lr(SIGFN_SHUNTING)), то тогда это точно светофор, начиная с которого надо врубать.
Добавлено через 1 минуту
Т.е тогда необходимость в двух-трёх отпадает
enabled() вообще не в тему здесь. Не важно: какой SNCA ты поставишь, ORTS на стрелках тебя "обломает". Я тут подумал : надо DISTANCEами передавать. Один аспект на АРС, остальные -- на показания. Всё равно гореть будет вся линия
Ну почему обломает, если у меня будет готовый маршрут для сервиса?
Добавлено через 34 минуты
Вообще, в изолированных условиях enabled работает как раз как надо. Живой пример: вот вам схема прекрасной станции Чертановская. https://pp.vk.me/c837122/v837122167/cc80/40dh2gWJ__Y.jpg
В её границах есть светофор ЧР-551, у которого есть маршрутный указатель с показаниями "1" и "Д". Если мы едем на Чертановскую - горит один. А если мы собираемся проехать за стрелку и встать у знака 8 (за светофор "Д"), то как раз горит Д.
https://pp.vk.me/c837122/v837122167/cc92/j6V6yOcGivA.jpg
https://pp.vk.me/c837122/v837122167/cc9b/95Qe5lbox0I.jpg
В мультиплеере (как на скринах выше) это реализовано банальным перекрыванием руками ближайшей к знаку 8 следующей сигнальной точки АРС с INFO-скриптом.
https://pp.vk.me/c837122/v837122167/cca4/aZ1Z3GP9EZA.jpg
В сценариях, как раз благодаря enabled, "Д" включается, если путь не доходит до точки с ИНФО-скриптом, в данном случае из-за реверсивной точки, что и соответствует действительности.
Сделай таблицу аспекты "против" сигалов АРС и АБ
Добавлено через 2 минуты
Идея заключается в том, чтобы DISTANCE сделать одним аспектом, а зажигать его через draw_state , привязывая к this_sig_xx(SigFn_NORMAL)
Добавлено через 4 минуты
Скажем, он у тебя при АРС погашен STOP, а если следующий NORMAL "-1" или следующий DISTANCE не STOP, давать другой аспект (например, CLEAR_2) и показание в зависимости от основного NORMAL
Добавлено через 1 минуту
Обязательно при этом определяющий светофор в тупике не привязывать к enabled()
Добавлено через 4 минуты
В сценариях, как раз благодаря enabled, "Д" включается, если путь не доходит до точки с ИНФО-скриптом, в данном случае из-за реверсивной точки, что и соответствует действительности.
ИМХО, в ОР чем дальше ты от него будешь, тем меньше шансов, что он будет работать, даже если SNCA будет 120. ОР всегда оставит стрелки в непонятном положении для возможности поставить блокировку, там идёт через BLOCK_JN_OBSTRUCTED и enabled() при этом не читается
Идея заключается в том, чтобы DISTANCE сделать одним аспектом, а зажигать его через draw_state , привязывая к this_sig_xx(SigFn_NORMAL)
Именно так я и сделал, если АРС-ный аспект, то синий или красный смотрим по коду АРС.
Тем временем есть результаты первых тестов:
Подъезжаем под точку ожидания, светофор автоблокировки включён (красный он тут потому что первый)
https://pp.vk.me/c837123/v837123167/c13e/enyw3F6Koik.jpg
Когда точка ожидания истекает, маршрут готовится через него и светофор гаснет:
https://pp.vk.me/c837123/v837123167/c147/C8T8lhFtUW8.jpg
Таким образом "элементарная" еденица управления автоблокировкой уже работает, сейчас буду тестить маршруты из нескольких перегонов. :)
Добавлено через 1 час 31 минуту
Ихихихи, работает!)
Kaminadan
02.12.2016, 00:46
Какая на данный момент сигнализация лучшая? И еще, много ли ресурсов она будет забирать, а то комп хилый, ему подавай что полегче
Сигнализация комп не грузит, на ФПС (есди говорим про это) никак не повлияет.
А какая лучше - это смотря что именно лучше? Простота установки, или количество моделей, или работа в разных трех симуляторах... Что именно нужно в первую очередь?
Kaminadan
02.12.2016, 16:45
Что именно нужно в первую очередь?
Нужно что бы было как можно больше разных типов светофоров, конечно важно что бы сосем уж сложно устанавливать не было
Много разных в сигнализации АРК.
Kaminadan
02.12.2016, 18:26
Надо посмотреть
Опомнился и вспомнил об ApproachControlSettings , для того, чтобы реализовать обгоны скриптом светофора (точки ожидания перестали удовлетворять), и вот очередной сюрприз: в версии х3725 оно уже не фурычит. Светофор действительно закрыт, но когда трафик проследует предыдущий светофор, он открывается вне зависимости от значения "position".
Разобрался. Если стартовать за SignalNumClearAhead, работает задержка в открытии сигнала. Сигнал при этом ничего не блокирует, маршрут сервису готовится, как будто сигнал открыт, просто открытие происходит на расстоянии position и на скорости speed
Forsayth
02.03.2020, 05:21
Прошу Вашей помощи в скрипте. При прописании строчки:
if (enabled)
{
if (route_set())
{
Что бы потушить светофоры встречного направления на однопутном участке, светофор перестал сигнализировать сигналом "один жёлтый мигающий" при открытом входном светофоре, сигнализирующим "два жёлтых огня" или "два жёлтых огня, из них один верхний мигающий" в этом случае предвходная точка сигнализирует "один зелёный огонь". При всех остальных сигналах входного светофора сигнализирует правильно.
Вот сам скрипт:
SCRIPT T_Head_YGR
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 (enabled)
{
if (route_set())
{
state = SIGASP_STOP_AND_PROCEED;
if ((enabled || !sig_feature (SIGFEAT_USER1)) && (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 if ((next_state ==# SIGASP_STOP_AND_PROCEED) || (next_state ==# SIGASP_RESTRICTING))
{
state = SIGASP_APPROACH_1;
}
else
{
state = SIGASP_CLEAR_2;
}
}
draw_state = def_draw_state (state);
if (state ==# SIGASP_CLEAR_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;
}
}
}
else
{
state = SIGASP_STOP;
if (block_state() ==# BLOCK_JN_OBSTRUCTED)
{
state = SIGASP_STOP_AND_PROCEED;
}
}
} else state = SIGASP_STOP;
draw_state = def_draw_state (state);
То есть (route_set()) - чтоб гасить встречные огни?? Это же для линковки по стрелкам для "головы" входного/выходного сигнала из нескольких субобъектов.
Проходные светофоры встречного направления гасятся через (!enabled).
Огни Жм, Ж-Ж, Ж-Жм на каких аспектах?
И лучше глядя в sigcfg разбираться.
Это точно скрипт проходного?
Forsayth
08.03.2020, 06:47
И лучше глядя в sigcfg разбираться.
Это точно скрипт проходного?
Вот скрипт sigcfg проходного светофора:
SignalType ( "T_Head_YGR"
SignalFnType ( NORMAL )
SignalLightTex ( "T_SignalLight.ace" )
SigFlashDuration ( 1.0 0.5 )
SignalLights ( 4
SignalLight ( 0 "Yellow Light"
Position ( 0 7.475 0.01 )
Radius ( 0.35 )
)
SignalLight ( 1 "Green Light"
Position ( 0 7.175 0.01 )
Radius ( 0.35 )
)
SignalLight ( 2 "Red Light"
Position ( 0 6.875 0.01 )
Radius ( 0.35 )
)
SignalLight ( 3 "No Light"
Position ( 0 -1 0 )
Radius ( 0.01 )
)
)
SignalDrawStates ( 7
SignalDrawState ( 0
"Red"
DrawLights ( 1
DrawLight ( 2 )
)
)
SignalDrawState ( 1
"Yellow"
DrawLights ( 1
DrawLight ( 0 )
)
)
SignalDrawState ( 2
"Green"
DrawLights ( 1
DrawLight ( 1 )
)
)
SignalDrawState ( 3
"White"
DrawLights ( 1
DrawLight ( 2 )
)
)
SignalDrawState ( 4
"Yellow F"
DrawLights ( 1
DrawLight ( 0 SignalFlags ( FLASHING ))
)
)
SignalDrawState ( 5
"Green F"
DrawLights ( 1
DrawLight ( 1 SignalFlags ( FLASHING ))
)
)
SignalDrawState ( 6
"No"
DrawLights ( 1
DrawLight ( 3 )
)
)
)
SignalAspects ( 5
SignalAspect ( STOP "No" SpeedKPH ( 0 ) )
SignalAspect ( STOP_AND_PROCEED "Red" SpeedKPH ( 0 ) )
SignalAspect ( RESTRICTING "White" SpeedKPH ( 20 ) )
SignalAspect ( APPROACH_1 "Yellow" SpeedKPH ( 60 ) )
SignalAspect ( CLEAR_2 "Green" )
)
SignalNumClearAhead ( 3 )
)
(route_set()) лучше вообще убрать.
И вообще странно, в секции конфига SignalDrawStates ( проходному прописан белый огонь, хотя в секции SignalLights ( белого огня нет...:confused:
Попробуем вообще убрать "всё насчёт белого" из скрипта.
Строку
next_state = next_sig_lr (SIGFN_NORMAL);
перенести в начало скрипта сразу после
if (enabled)
{...
Вот если так попробовать:
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 ( ( enabled || !sig_feature ( SIGFEAT_USER1 ) ) && ( block_state () == BLOCK_CLEAR ) )
{
if ( ( next_state == 1 ) || ( next_state == 2 ) )
{ state = 3; } /// "Yellow"
else { state = 7; }
}
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);
Forsayth
08.03.2020, 22:32
К сожалению, все также горит предвходной зелёный, при открытом входном на бок "Два желтых из них верхний мигающий" :(
А можно скрипт входного? Той части, которая набок сигналит?
Forsayth
08.03.2020, 22:46
Вот часть скрипта:
SCRIPT T_Head_Yx_RY_I
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);
}
А если вот такой вариант для проходного:
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);
Forsayth
08.03.2020, 23:41
Результат без изменений... Но, вот только что, попробовал изменить в sigcfg местами линзы огней, то желтый мигает но во всех случаях когда должен гореть зеленый. Получается что скрипт не считывает блок, где нужен желтый мигающий. Или же его пропускает. На все остальные сигналы реагирует нормально.
Думаю, что это может быть... ещё попытка:
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);
}
Forsayth
09.03.2020, 00:07
Думаю, что это может быть... ещё попытка:
Костя!) Огромная Вам Благодарность) Снова Вы мне очень помогли) И снова третья попытка увенчалась успехом)
ОГРОМНОЕ СПАСИБО) Большего ЗДОРОВЬЯ Вам и много счастья)
Спасибо!
дело было в последних 2 строках:
} else state = SIGASP_STOP;
draw_state = def_draw_state (state);
Получалось, что после правильной отработки включения огней скрипт проходил по
draw_state = def_draw_state (state);
и сбрасывал огни обратно на зелёный.
После заключения в скобки:
else {
state = 0;
draw_state = def_draw_state (state);
}
огни второй раз уже не менялись, скрипт не заходил на строку
draw_state = def_draw_state (state);.
Forsayth
09.03.2020, 00:55
Скрипт работает нормально... Но я решил посмотреть, что происходит из сигналом, после проследования состава... И выяснилось... что светофор не переключается на красный)
Вот в начало скрипта:
if (enabled)
{ next_state = next_sig_lr (SIGFN_NORMAL);
{ state = 1; draw_state = 0; }
...
...
Forsayth
09.03.2020, 01:13
Всё идеально сработало)
Еще раз ОГРОМНОЕ СПАСИБО) :drinks:
Олег, я в соседней теме просил скрипты, чтоб понять синтаксис, а то у меня OR ругается постоянно:
Unexpected number of = in string : ELSE IF ( NEXT_N = 3 ){STATE = 7...
Unmatching brackets in : ELSE IF ( NEXT_N...
Что-то там было, что терпит МСТС, а ОР вот так пишет в лог, но не помню, в чём именно дело...
Скобки проверь.
Он на скобки ругается.
Проблема, которую я описал (http://www.trainsim.ru/forum/showpost.php?p=592479&postcount=48) в теме о Timetable Mode касается исключительно сигнализаций, где количество активированных сигналов функционально задействовано в каких-то ситуациях. То есть, если сигнализация построена на том, что нет никаких дополнительных сигнальных точек, или аргумент SignalNumClearAhead постоянен - никаких изменений в работе не будет. Мне это сломало некоторые моменты из-за особенностей в самой сигналке. У меня всегда первая сигнальная точка после станции (а также на маршрутных светофорах, но там оно не мешает, проблема обнаружилась именно с выходными) в случае !enabled даёт аспект 2 (и зеленый, желтый или красный - в зависимости от занятости б/у если это проходной АБ или 2 и красный, если это входной АБ или ПАБ. Это нужно для того, чтобы в маневровом режиме давать 2 и белый на выходном. Логика проста. Естественно, если сервис отправляется на перегон и его Path не доходит до первого сигнала после входного, то этот самый первый сигнал !enabled (в МСТС, кстати, тоже так, поэтому я и написал там,,что сигналка в обоих симуляторах работает) и выдаёт 2. А выходной настроен на следующий 2 давать 2 и белый. В поездном режиме первый светофор после станции активируется , естественно и выходной выдаёт поездные аспекты. Присутствие в сигнализации дополнительного маркера рельсовой цепи в начале каждого станционного пути по ходу движения сервиса, а также маневровых сигналов на входных стрелках требует точного расчета SignalNumClearAhead у входного светофора. Он должен "доставать" через все станционные объекты сигнализации аж до этого самого первого проходного или входного на следующую станцию. Иначе мой входной просто не откроется - маневровые дают 2, если путь знаят, чтобы позволить прицепку на занятый путь, а также если путь свободен и на выходном -2 для маневрового проследования по свободному пути, а при маневровом режиме входные у меня "заперты", естественно.
Обидно, что когда я эту механику разрабатывал, и у меня был выбор: положиться ли на разработчиков ОР с их утверждением, что светофор с SignalNumClearAhead = -1 не учитывается симулятором в "общем зачёте" или прописывать "топором" все значения этого параметра для каждого светофора, включая маркеры, я выбрал первое. Зря... Бывает
Добавлено через 14 минут
Вносить поправки сейчас, ИМХО, смысла не имеет, всё вышеизложенное делалось "не от хорошей жизни" , а из-за нехватки аспектов и отсутствия соответствующих функций. В Open Rails теперь есть специальные дополнительные функции для сигнализации, расчитанные именно для возможности сделать маневровые показания.
Так что, если переделывать, так уже переделывать всё
[...рыдая бьётся головой о стену... :crazy:]
Ты по удалению, впередиидущий сервис что-то изменяет?
В Open Rails - нет. В MSTS enabled() распространяется и на светофор, который сервис проехал. Вернее - на тот, что проследовал и на один перед ним, если я правильно помню. На "Заборе" я выкладывал проверку по этой функции с картинками. Пост нашел, но картинки пропали.
Добавлено через 2 минуты
Поэтому, да, там поездной откроется. Я забыл
Вообще от скрипта зависит, но помню были случаи, когда после прохода трафика мне выходной белым горел вместо желтого, то есть реагировал на !enabled проходного.
Обидно, что когда я эту механику разрабатывал, и у меня был выбор: положиться ли на разработчиков ОР с их утверждением, что светофор с SignalNumClearAhead = -1 не учитывается симулятором в "общем зачёте" или прописывать "топором" все значения этого параметра для каждого светофора, включая маркеры, я выбрал первое. Зря... Бывает
Прошу прощения заочно у буржуинов-разработчиков Open Rails и очно у уважаемых участников форума. Описанное в указанном сообщении - исключительно мой косяк и рукожопость. Я почти год до карантина вообще его не трогал. Оказалось, что тогда я не переставил местами тестовые файлы скриптов со стабильными. Так что, "грязь" была в скрипте выходного и т.д.
Логика работает как работала!
Ещё раз "посыпаю голову песком", как говорил товарищ Дж. Лондон
То есть сим при подсчете светофоров твои маневровые пропускает, но работают они по обычному скрипту?
Добавлено через 20 минут
Нигде не встречал - когда в конфиге указывается число SNCA - учитываем значность сигнализации (3-значная, 4-значная), или это неважно?
То есть сим при подсчете светофоров твои маневровые пропускает, но работают они по обычному скрипту?
Именно. Можно, в принципе, сделать отдельный предвходной с большим SNCA, но его точно нужно расчитывать. Потому что "базовая" или "маленькая" станция - это входной, один маневровый перед стрелками и дальше - выходной. Но, у меня есть станции, где между входным и выходным или маршрутным - 4 маневровых. Здесь так просто не отделаться. Для унификации -1 -- самое то.
Есть разные способы. Один из разработчиков на буржуйском форуме писал, что у него все сигналы АБ с -1. То есть, он с выходого "энэйблит" сразу входной следующей станции независимо от количества блок-участков. Мне такой способ неприемлем, ИМХО, для трёхзначки достаточно 3, для 4-х - 4. И то - "с запасом" - из-за этого самого моего первого проходного с 2, когда он !enabled для маневрового на выходном.
Нигде не встречал - когда в конфиге указывается число SNCA - учитываем значность сигнализации (3-значная, 4-значная), или это неважно?
В принципе, достаточно и на один меньше, но и так можно. Получается с небольшим запасом - то что надо.
Действительно: скажем - 3-х-значная. Сервис движется, его светофор зелёный, за ним нам нужно 2 сигнала. Первый по ходу будет зелёный, за ним - жёлтый, за ним уже !enabled.
...Один из разработчиков на буржуйском форуме писал, что у него все сигналы АБ с -1. То есть, он с выходого "энэйблит" сразу входной следующей станции независимо от количества блок-участков.
Вот если бы это было в МСТС - победили бы "вечный красный" в сценариях.
"Вечный красный" в сценариях нужно "побеждать" стартом сервиса за SNCA. Если ты "врезаешь" сервис в уже подготовленный маршрут - конечно - кто-то становится "призраком" и сценарий начинает глючить. Стартовать перед сигналом - тоже "чревато". Я на "Заборе" когда-то для Сергей1969 выводил. Кажется, между сигналом и поездом должно быть место удвоенной длины этого состава (или что-то в этом роде, не помню точно). С Игорем много лет назад мы разбирали МСТС, пытаясь "подогнать" сигналку под наше видение создания сценариев. А вывод мой был совершенно противоположным - если правильно стартовать сервисы игрока и трафиков - всё будет работать.
Жаль, у Игоря Заборина на форуме все картинки потерялись. Там в первых двух темах мы на тестовом участке строили автоблокировку однопутную. Так вот, на "чистом" тестовом маршруте, при правильном старте обоих сервисов в противоположных направлениях МСТС прекрасно блокировал стрелку "скрещения" через светофоры, которые были ещё !enabled ! Да-да. За пределами SNCA. В дефолтных маршрутах обрати внимание как "издалека" стартует трафик. На старте игрока НИКОГДА трафики не пересекают Path игрока. Если и есть трафик на старте сценария, он всегда идёт по параллельному, не имеющему общих точек с игроком пути.
... За пределами SNCA...
И что тогда выяснили - на какое расстояние сим прокладывает маршрут сервису? Это зависит от количества блок-участков, или там километры?
Маршрут сим прокладывает на SNCA, но "агрит" сигнал перед ближайшей "совместной" точкой (стрелкой) за SNCA+1. То есть, кто первый "агрит" один из въездов на "совместное" звено пути, тот "получает" его. Будь то стрелка или перегон. В случае с перегоном количество блок-участков значения не имело. Да, Игорь говорил о расстояниях, но я не проверял как длина полигона меняет суть работы автодиспетчера. Моё мнение - работает всё-таки от светофора к светофору.
Вот если бы это было в МСТС - победили бы "вечный красный" в сценариях.
Пока что, уже долгое время, "конфликтные" ситуации, которые у меня время от времени возникают, не связаны с самим симулятором. Разработчики 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;
Именно.
У меня было
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 не только если "блок" (участок до следующей "сигнальной точки" - светофора или тупика) свободен от сервисов или статики, но ещё и никакой другой сервис не проложил маршрут через этот самый "блок".
Господа! Кто-нибудь имел счастье в этой или прошлой жизни получить хоть что-то от этих функций?
Олег, я на днях тестил проходной с условным "Т" - на определенном расстоянии от него (типа тяжелый поезд - длинный поезд;)) обратностоящий "датчик" в виде DISTANCE-маркера менял state с 0 на 1 при BLOCK_STATE == BLOCK_OCCUPIED. Проходной-Т ловил этот аспект маркера по opp_sig_lr и переходил в state = 2.
Вот и я - о том же. На NORMAL-ах ночью бился с ними всю ночь - не ловит. Его только на DISTANCE можно поймать?
Добавлено через 1 час 51 минуту
Буржуи тоже об этом говорят. Странно. В магуале "от Кужу" написано SigFn_Type. Ладно. Как говаривал Дедушка Ленин в школьных легендах, "Мы пойдём другим путём!"
Блин, забыл сказать - это в МСТС было. Вот ещё про МСТС, но может, пригодится для чего-то...
Маневровый режим сигнализации обычно "завязан" на аспекты STOP и RESTRICTING. Но при попытке использовать это для манёвров в горловине станций наталкиваемся на неудачу - при выезде за входную стрелку проходной светофор "где-то там на перегоне" переходит из !enabled в enabled, меняет свой аспект из STOP на CLEAR. Точнее, енейблятся все проходные (до входного другой станции - тот остаётся закрытым).
В моём случае это не давало бело-синему маневровому у входной стрелки (направленому на перегон) перейти в SIGASP_RESTRICTING и дать белый при считывании аспекта проходного по opp_sig_lr (у меня этот бело-синий маневовый - типа DISTANCE).
Если же на пути между горловиной и первым проходным будет нулевая стрелка - то проходной остаётся !enabled (потому что стоит за "узлом"), и маневровый сигнал срабатывает как надо.
Таким способом отмеряем нужное расстояние для манёвров, и МСТС теперь "знает" границу станции.:drinks:
Сейчас погонял пробные сценарии в чётную и в нечётную сторону - да, первый проходной за нулевой стрелкой не энейблится.
Надо теперь в OR попробовать...
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;
}
}
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; /// Змиг
- так?
Так точно
В Open Rails, как я уже упомянул сигнал становится «отключенным» (!enabled) после того, как поезд передает сигнал! Таким образом, после прохождения поезда для функции всегда установлено значение FALSE.
Добавлено через 3 минуты
В
В скрипте "SCRIPT KRN23_YGR_3"
Под number_plate - "флаг", который устанавливается на первом проходном. Только он даёт RESTRICTING-аспект. Остальные показывают обычные аспекты по скрипту.
Добавлено через 27 минут
В OR пока не могу проверить, на работе древний ноут - OR не установится, там WINXP. Если только старые версии, но в них сигналка работает через ж...
Не парься :cool:
Лови рабочий скрипт выходного "нового поколения" с белым независимо от состояния первого проходного:
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;
}
Маневровый белый этого светофора вообще не зависит от аспекта следующего.
next_sig_id - это что-то новое! Что за функция?
if (!train_requires_next_signal(sigid,1)) - что за условие?
Это новые функции, которые были внесены в Open Rails. Нехватка аспектов ощущается не только у нас ;)
sigid определяет объект, с которого нужно считать дополнительную информацию. Строкой sigid = next_sig_id (SIGFN_NORMAL); я "пометил" следующий светофор типа NORMAL. Это не единственный вариант. Можно выбирать не только этот тип, но и другие. Можно "метить" подобъекты и снимать с них информацию. Есть также функция next_nsig_id(SigFn_TYPE,n) на подобии функции next_nsig_lr (SigFn_TYPE,n), о которой я уже рассказывал. Работает точно также - на светофор, находящийся на удалении n.
train_requires_next_signal(sigid,position) - функция, проверяющая проходит ли Path через сигнал, идентифицированный параметром sigid
То есть эту "метку" ставить на первый проходной в нашем случае?
if (!train_requires_next_signal(sigid,1)) - число "1" означает проверку первого от нас светофора?
На сам светофор не надо ничего ставить. Я его функцией "пометил" с выходного
А, понял - выбираем нужный светофор, а потом по ходу дела проверяем, проходит путь сервиса через него или нет. Здорово!
Просто, как все гениальное!!! )))
В принципе, я сегодня нулевыми стрелками делал то же самое! )))
Вот этого, как раз, я пока не соображу: можно или не можно...
"Долблюсь" как раз с этим. Поэтому и про оппозиты спрашивал. Мне надо передать от выходного (того самого, что на скрипте KRN25_YR_YW ) противостоящему маневровому информацию о том, что выходной открылся белым. Маневровый должен обработать эту информацию, передав её всем своим "головам" и запомнить. И после того, как манёвры выедут с пути станции, ограждённого этим выходным, "знать", что нужно открываться маневровым показанием. Более того, мне нужно, чтобы, в Timetable Mode, в случае команд $forms, $triggers и так далее, этот маневровый "помнил" в каком режиме он находится. Потому что $forms, $triggers "и так далее" - это пропадание сервиса и возникновение на его месте другого. В смысле, если я проложу путь на станцию, и на ней сделаю $forms / $triggers - выходной с пути , на котором будет выполяться команда останется закрытым до возникновения нового сервиса. А, закрытым он будет, потому что !enabled.
Не знаю, как в OR, но в МСТС - как я ни бился, запомнить состояние не получалось... При каких-то изменениях в одной сигнальной точке остальные тоже отрабатывают свой скрипт, обновляются, и маневровый режим терялся в момент прохода сервиса через какую-либо сигнальную точку, даже если ее аспект не менялся...
Нет никакой внешней переменной, об'единяющей все светофоры, которую можно было бы устанавливать и сбрасывать командой из скрипта (что-то отдаленно похожее есть в RTS, но там signal_mode устанавливается и сбрасывается игроком вручную (сочетанием клавиш по ходу игры), а скрипты ее только считывают). А мы можем только менять аспекты сигнальных голов, и больше ничего...
Ну вот только если только попробовать у противостоящего маневрика это:
if (opp_sig_lr (SIGFN_NORMAL) ==2)
{
state =2;
}
и больше ничего! ))
При загрузке сценария исходно все аспекты по нулям, а потом он перейдет в RESTRICTING, да так и останется (?)...
То есть эту "метку" ставить на первый проходной в нашем случае?
if (!train_requires_next_signal(sigid,1)) - число "1" означает проверку первого от нас светофора?
"position" ("число 1") здесь означает другое. Что Path пересекает этот светофор. То есть заходит за него.
Если позиция = 0, проверяется, достигает ли маршрут требуемого сигнала;
если позиция = 1; проверяется, выходит ли маршрут за пределы требуемого сигнала.
[зачем им нужен "0" - я хз :confused:]
Добавлено через 7 минут
Не знаю, как в OR, но в МСТС как я ни бился, запомнить состояние не получалось. При каких-то изменениях в одной сигнальной точке остальные тоже отрабатывают свой скрипт, обновляются, и маневровый режим терялся в момент прохода сервиса через какую-либо сигнальную точку, даже если аспект не менялся...
Если только попробовать
if (opp_sig_lr (SIGFN_NORMAL) ==2)
{
state =2;
}
и больше ничего! )))
У меня была другая идея. Заявить переменную, скажем, float shunt;
Вписать ей действие shunt = shunt +0;, в случае, если на выходном появляется 2, давать shunt = 1, найти условие, при котором возвращать shunt = 0, скажем, поезд прехал маневровый в сторону станции по block_stste () через BLOCK_OCCUPIED - как я уже писал, в ORTS состояние блока учитывает направление движения. Но, я не могу поймать "оппозит"!!!
Сейчас буду пробовать через sigid фуекцией sigid = opp_sig_id(SIGFN_Type, <n>) (этот <n> мне тоже непонятен. ИМХО - очепятка просто)
Переменная float shunt - не сбросится в ноль при перезагрузке сервисов?
Я так делал, но такая же внутренняя переменная при движении сервиса "терялась" при реверсе движения или еще как-то, как я писал чуть выше.
надо передать от выходного (того самого, что на скрипте KRN25_YR_YW ) противостоящему маневровому информацию о том, что выходной открылся белым
- сервис должен идти по сигналу на выходном, а маневровый "смотрит" вслед сервису? Он не сработает по opp_sig_lr, он в оппозитном положении вообще ничего не считывает с других сигналов. Может только менять свой аспект по BLOCK_STATE ().
Не знаю. Может, я что-то делаю не так...
И
Не должен сбрасываться. Светофор связан с сервисами постольку-поскольку. Через функции. Всё это я собираюсь делать когда светофор !enabled - сервис движется в другом направлении, он будет !enabled. И, когда сервис проехал светофор - тот становится снова !enabled. Вопрос в том, корректно ли так писать скрипт.
Я использовал оппозиты (маркеры-"датчики" на пути) только для определения занятости БУ, считывая их аспект, меняющийся через функцию BLOCK_STATE (). Они больше ничего не могут.
И нормалы тоже так.
Хотя в последних версиях ОР надо проверять.
sigid = opp_sig_id(SIGFN_Type, <n>) - сработает? Получится оппозитно проверить путь до какого-то сигнала - после реверса, когда сервис уже прошел наиболее отдаленную точку пути - точку разворота, и пошел по горловине в сторону станции?
Сработало :D
В смысле что-то изменилось. Со скриптом не то. Не открывается.
<n> я не ставил. Мне кажется, это очепятка у Буржуев
Добавлено через 1 минуту
Нет. Мне тупо нужно знать, что выходной открылся маневровым, а не путевым. Я считываю аспект с этого светофора и всё
Добавлено через 1 минуту
Вот скрипт
sigid = opp_sig_id (SIGFN_NORMAL)
next_state = next_sig_lr (SIGFN_NORMAL);
opp_state = ID_SIG_LR (sigid);
shunt_state = shunt_state + 0;
if (!enabled && (opp_state ==# SIGASP_RESTRICTING))
{
shunt_state = 1;
}
if (!enabled && (block_state() ==# BLOCK_OCCUPIED))
{
shunt_state = 0;
}
if (route_set () )
{
state = SIGASP_STOP;
if (enabled && (shunt_state ==# 1))
{
state = SIGASP_RESTRICTING;
}
else if (enabled && (block_state() ==# BLOCK_CLEAR))
{
state = next_state;
}
draw_state = def_draw_state (state);
}
else
{
state = SIGASP_STOP; draw_state = 0;
if (this_sig_lr (SIGFN_NORMAL) ># SIGASP_STOP)
{
draw_state = 2;
}
}
Добавлено через 9 минут
Вот маневровый на выходном.
http://i.piccy.info/i9/5b8d4218b78f48e17253872d1060de79/1587945631/25229/1373151/RunActivityLAA_2020_04_27_02_55_46_38_500.jpg (http://piccy.info/view3/13776164/db1d3866c221148533c0f5924b726434/)http://i.piccy.info/a3/2020-04-27-00-00/i9-13776164/477x350-r/i.gif (http://i.piccy.info/a3c/2020-04-27-00-00/i9-13776164/477x350-r)
Я снял а number_plate и проходные за станцией - в обычном режиме
Добавлено через 3 минуты
Дополнительные строки в скрипте - до if (route_set())
http://i.piccy.info/i9/c843cc2bceafbab840dff503ed3343a8/1587945774/26555/1373151/RunActivityLAA_2020_04_27_02_56_49_76_500.jpg (http://piccy.info/view3/13776165/3e1315e11a34f34718bf4e8ca07b156f/)http://i.piccy.info/a3/2020-04-27-00-02/i9-13776165/477x350-r/i.gif (http://i.piccy.info/a3c/2020-04-27-00-02/i9-13776165/477x350-r)
Без этого должно было открыть паровозику STOP_AND_PROCEED на свободный путь со следующим красным. Что-то пошло не так.
Странно!! Смотрю скрины с телефона - все нормально, а с ноута через телефон - вместо картинок - "Your IP is blacklisted"...:confused:
Что-то тот сайт хернёй занимается...
Костя, картинки надо удалить. Они не иллюстрируют ситуацию. У меня там пунктуационная ошибка в скрипте в строке sigid = opp_sig_id (SIGFN_NORMAL)
Добавлено через 2 минуты
Сейчас настраиваю маневровый, будет время - потестим переменную.
Добавлено через 13 минут
Значит, иллюстрирую проблему:
http://i.piccy.info/i9/d4c86327a7fff4e1d2189207f0f81609/1587980415/67461/1373151/RunActivityLAA_2020_04_27_12_32_44_17_800.jpg (http://piccy.info/view3/13776576/f30914870e185f3a51ad65940fc2ab74/orig/)http://i.piccy.info/a3/2020-04-27-09-40/i9-13776576/763x559-r/i.gif (http://i.piccy.info/a3c/2020-04-27-09-40/i9-13776576/763x559-r)
Сервис выезжает по маневровому сигналу в горловину станции. Заходит за маневровый и возвращается на свободный путь. Из-за того, что сервис с перегона на станцию при закрытом выходном должен проделать тот же путь, я не могу "выделить" отдельно ни маневровый аспект, ни маневровое показание. Поэтому до сих пор на незанятый путь у меня вот так:
http://i.piccy.info/i9/fa2cfb3dc93836d05b3d77bd13c62a9b/1587980732/72234/1373151/RunActivityLAA_2020_04_27_12_34_10_98_800.jpg (http://piccy.info/view3/13776585/3adfe7b2d813030dd922223313df8487/orig/)http://i.piccy.info/a3/2020-04-27-09-45/i9-13776585/763x559-r/i.gif (http://i.piccy.info/a3c/2020-04-27-09-45/i9-13776585/763x559-r)
Ехаем на синий (((
Чтобы было по-другому, мне нужно "поймать" момент на картинке 1, передать его на маневровый, раздать его всем "головам" и запомнить.
Если только маневровый аспект дать обратно развернутой "головой" на том выходном, когда он открывается белым? Но наш маневровый "поймает" этот аспект, пока сервис не дошел до точки разворота? И после реверса он не потеряет значение нужной переменной?
И вот еще проверить - функция this_sig_lr работает только с "головами" одного направления, а если это в скрипте головы, которая BACK_FACING, то может не работать.
Но не могу сейчас, в старом ноуте OR годовой давности только, более новый не работает из-за несовместимости WINХР и Framework-4.7.
Не ловится нифига. Ни NORMAL и ни DISTANCE. Возможно, сама функция "бракованная".
Добавлено через 9 минут
this_sig_lr[(), по идее, должен работать со всеми головами. Ещё один геморрой! У меня на выходных - обратно глядящая голова, которая сама по себе даёт RES на занятый путь и на следующий RES если путь свободен. Ох, какое "веселье" меня ждёт! А, всего-то нужно дать RES на свободный путь с выходным STOP...Я этого момента даже видеть в игре не всегда могу... (((
В общем, поймал я opp_sig_lr (SigFn_NORMAL).
Я неправильно его понимал. И, с английским, очевидно, совсем у меня тяжко. С пониманием прочитанного, в смысле. Буржуи пишут "первый светофор ПЕРЕД сигналом повернутый в противоположную сторону" . Как это было понимать?
На самом деле речь идёт о сигнале "сзади". То есть, если это входной, то "оппозит" к нему - первый проходной. Если это маневровый, как в моём случае - всё равно - первый проходной. Оно видит "через" входной.
НО!!!
Всё это , если между ними нет сервиса. Как только этот "блок" между сигналами занимает "нос" сервиса - функция не видит ничерта. Где это может быть полезно - я хз пока. В принципе, я могу "поймать" ситуацию, когда манёвры выезжают с пути станции по белому - как раз первый проходной RES, блок между ними свободен, но тогда - какой смысл в том, что я сделал со входным? Оно и так прекрасно работало
То есть оппозит - точка, "смотрящая" на попутный сигнал. ну я так и считал всегда.
И что на деле: если этот оппозит "под колесами", то - он не работает, или светофор впереди не видит его аспект по opp_sig_lr?
Значит, только занятость блок-участка можно проверить.
То есть оппозит - точка, "смотрящая" на попутный сигнал. ну я так и считал всегда.
Ааа... хочешь сказать, что я и по-русски плохо понимаю?
Если я поезд, и приближаюсь к сигналу, у этого сигала (к которому я приближаюсь) "оппозит" у меня за спиной. :D
что на деле: если этот оппозит "под колесами", то - он не работает, или светофор впереди не видит его аспект по opp_sig_lr?
Или...
Светофоры все работают, а вот аспект "поймать" если на блоке поезд по opp_sig_lr () не получится.
Значит, только занятость блок-участка можно проверить.
А зачем нам занятость блок-участка перед светофором?
Ну, хорошо. Запомним
А зачем нам занятость блок-участка перед светофором?
Ну, хорошо. Запомним
Я это пытался использовать для отличия маневрового режима от поездного.
Но тоже всё упирается в запоминание состояния...
Состояние я уже запомнил. Надо ещё поиграться с ним, потестировать разные варианты.
[У нас сегодня День Памяти павших в войнах и террактах, поэтому комп не открываю, с вечера - День Независимости - буду занят. Может, ночью будет время, если буду в состоянии, а нет - так на днях "добью" логику и поделюсь]
Олег, ты в какой версии OR тестишь?
У меня две версии стоят: последняя тестовая и Open Rails New Year MG 56.1
Они по сигналке как-то отличаются?
Нет, конечно.
Версия MG - это временное "ответвление" одного из разработчиков на платформе Monogame. Последняя официальная тестовая версии совместима с New Year MG 59. Так указанно в превью. Я оставил 56.1 потому что кто-то утверждал, что при установленном с ней ReShade нет байды с серыми текстурами ПС. Пока что, мне действительно нравится. Тестовый свой отрезочек "гоняю" на последней тестовой
Олег, это отсюда (http://james-ross.co.uk/projects/or/builds?utm_campaign=unstable-version&utm_source=openrails.org&utm_medium=referral) качать? Какую именно, если нужна 56.1? А то они там с непонятными названиями....
Нет. 56.1 была на файлообменнике другого разработчика. Не могу найти её. Возможно, он убрал уже. Есть версия 59, пока что, она последняя и совместима с тестовой официальной на openrails.org. Пока искал, прочел, что и 59 работает с ReShade. Так что, что касается меня, 56.1 можно сносить. Единственное - ReShade нужно ставить или старее 4.3.0 или новее 4.5.2. Я пробовал ставить 4.4.2 ,сейчас прочел, что она несовместима с Open Rails (а я подумал: это дело в версии NY MG и оставил 56.1).
Короче, OR NY MG качать здесь:
http://www.interazioni-educative.it/Downloads/index.php
Там лежит сейчас 59, как я уже сказал, разработчики утверждают, что она уже совместима с тестовой, так что, как закончу с сигналкой , попробую поставить на официальную тестовую ReShade , и NY MG станет лишней. Как установить ReShade на Open Rails - опишу по свободе в профильной теме.
Ну вот... этим версиям нужен Net.Framework 4.7 и выше, а он на мой десктоп с WIN7x32 не ставится...
Тогда на 1.3.1 буду.
С точки зрения сигнализации - никаких отличий быть не должно.
Вот я старый склеротик! :eek:
Вот что значит, отойти надолго от дел. Всё позабывал. Вот та обратно-глядящая голова на входном, которую ты видишь на моих скринах - она не просто так стоит. Я совсем забыл, что она - ключевой момент сигнализации, без которого всё катилось в тарары. Я её тогда поставил со скрипом на сердце - если ты помнишь, я очень не люблю все эти дополнительные головы, будь они NORMAL, DISTANCE или что-то другое. Но, у меня выбора не было: светофоры перед узлами "тупили" по-черному. Вот тогда-то я и ругался на разработчиков! Они просто взяли и лишили светофоры которые охраняют узлы "зрения". В том смысле, что !enabled-сигнальная точка не проверяет ни состояние route_set() , ни block_state(). Такой сигнальной точкой можно было "ловить" исключительно аспекты других сигналов. Я тогда поматерился сильно, ты, наверное помнишь, но, в конце концов поставил за стрелками на входных и маршрутных эту обратно-смотрящую NORMAL-голову и окрестил её "РЦ" - рельсовая цепь. И уже с этой головы снимал аспекты и передавал их первому со стороны пути станции маневровому путём state = next_state
Слушай, я - работать. Будет время - сделай на тестовом маршруте простую проверку. Расставь тупые трёхзначные светофоры YGR. Запрограммируй их только на три простых аспекта : 1, 3 и 7. На станциях - никаких линков. Тупо блок не свободен (именно block_state !=# BLOCK_CLEAR , а не уточняя как именно - 1, свободен один блок - 3, свободно два и более блоков - 7. Погоняй трафик, посмотри как работает deadlock - блокировка. Цель проверки - тормозит ли сим сервисы на аспект 1 с заданной скоростью 0 км/ч.
Отодвинь светофоры , что перед стрелками на какое-то расстояние от самих стрелок - метров на 30-50 хотя бы. Цель проверки - узнать ревкцию сервиса на аспект 1 с 0 км/ч. Да-да, начинаем всё сначала. Если останавливается - можно будет говорить о разработке сигнализации, совместимой с локомотивными нашими. Если будет притормаживать и проезжать и останавливаться перед самой стрелкой - придётся ставит "0".
Добавлено через 1 минуту
Версия ОР не важна. 1.3.1 достаточно хорошо. Можно и более ранние, начиная с 1.2
Хорошо, Олег; попробую позже. Как раз собирался на ОР сигналку потестировать.
Вот:
Версия 1.3.1.
Тестовая станция - 3-путный раз'езд. Захожу с перегона, в это время попутный сервис трафика стартует с бокового пути, и перед выходным встает на точке ожидания, после чего проезжает дальше на сигнал с S.A.P., и встает за выходным светофором перед стрелкой, пропуская меня.
Я ухожу на перегон и специально останавливаюсь за проходным.
Трафик выезжает со станции, притормаживает перед закрытым проходным (тоже S.A.P. - светофор одного типа везде), потом проезжает его и встает сзади меня в 8 метрах.
Следующий за ним сервис трафика делает то же самое, так же проезжая S.A.P. и встает на том же расстоянии (около 8 метров) за первым сервисом.
"Как хорошо, что все мы здесь сегодня собрались!":crazy:
Добавлено через 13 минут
Так собрав всех:p, отправляюсь дальше - стоящий сзади сервис ждет, когда я уйду за следующий проходной сигнал, и тоже отправляется .
Ахаха!
Я как чувствовал, что на работе будет время - взял ноут. Тоже сделал этот тест. Вольно. Ничего хорошего. Но, я хотя бы попытался.
Я запустил 4 маршрута трафика с ЧМЭухами . Броуновское движение с завистью глядело на этот "тест". На блокировках ЧМЭ спокойно проехал светофор с SAP и остановился на пине шейпа стрелки. Ещё раньше две ЧМЭушки пригрелись рядышком на одном пути - первая заехала по желтому (3), а вторая без остановки проехала SAP (1) - на входе.
В общем, отлегло у меня. Я уже подумал было,,что упустил что-то.
Отбой
Кстати, заодно проверил и в МСТС - если в конфиге на S.A.P прописать скорость не 0, а например, 20км/ч - трафик его проезжает.
В моих тестах OR , конечно, было 0км/ч.
Кстати, заодно проверил и в МСТС - если в конфиге на S.A.P прописать скорость не 0, а например, 20км/ч - трафик его проезжает.
Конечно. На Зилупе 3.6 на сигнализации от APK_LVDZ подно таких S.A.P ов
Добавлено через 1 час 48 минут
Итак, первое правило для создания сигнализации для Open Rails мы проверили. Никаких SAP-ов в качестве запрещающих аспектов! Они не останавливают трафики.
Вторая очень важная деталь: Светофор, ограждающий узел (стрелку) работает не так, как его собрат на перегоне. Даже если это один и тот же светофор с точки зрения скрипта.
Да, и в моем OR-тесте с сервисами трафика - каждый презжал SAP, подходил метров на 8 к стоящему впереди, а потом ехал только тогда, когда передний трогался с места и уходил за следующий светофор (проходной).
Добавлено через 1 минуту
...очень важная деталь: Светофор, ограждающий узел (стрелку) работает не так, как его собрат на перегоне. Даже если это один и тот же светофор с точки зрения скрипта.
Олег, опиши подробно, чтоб я ничего не забыл.
Добавлено через 18 минут
Ради интереса попробовал заменить SAP на RESTRICTING с 0км/ч - то же самое, сервисы проезжают, как на SAP.
Добавлено через 7 минут
А в МСТС меня уволили за проезд! )))
А в РТС это решается банально просто. Сервису устанавливается точка блокировки( перед светофором) которая "зажигает" на светофоре красный и дальше её маршрут не строится. Снять её можна любым способом. По времени, по событию локации встречного сервиса, когда тот освободит перегон и ещё много чем. Это одна из фишек РТСа, благодаря которой я оставил ОР и ушёл в РТС
Прохорчук
30.04.2020, 19:57
А в РТС это решается банально просто. Сервису устанавливается точка блокировки( перед светофором) которая "зажигает" на светофоре красный и дальше её маршрут не строится.
Только это то же самое, что вместо красного сигнала светофора ставить на дорогу бетонный блок)))
Не бетонный, а железо-бетонный.)) Ибо работает безотказно. Любие скрещения, обгоны благодаря этой банальной штуки работают на ура.
В том смысле, что*!enabled-сигнальная точка не проверяет ни состояние*route_set()*, ни*block_state(). Такой сигнальной точкой можно было "ловить" исключительно аспекты других сигналов
Написал уже. Насчет аспектов - я, пожалуй, погорячился. У меня не работало:
if (!enabled && (opp_sig_lr (SigFn_NORMAL) ==# SIGASP_RESTRICTING)) a
if (opp_sig_lr (SigFn_NORMAL) ==# SIGASP_RESTRICTING)
сработало.
Когда я обратился с нотой протеста и требованиями объяснений к буржуинам, был послан "читать про enabled () и , пока я не покаялся, на меня тупо забили. Так что, на аспекты я бы тоже не надеялся
А не могут они сделать остановку на SAP опционально, "галкой" в настройках сима?
Народ, а насчет РТС - тут вопросов нет, Ted все нам сделал!
Кстати, он не появлялся? Что-то давно его не видно здесь...
Не сделают. Когда-то APK_LVDZ уже пытался.
Я хотел у них попросить сделать видимым для !enabled-светофора хотя бы функцию block_state(), но передумал. Быть посланным в пешее путешествие от них мне, конечно, "по барабану". Но, не хочу подставляться. Потому как нет-нет - и получаю от них хоть какую, но помощь
OR: если сигнал имеет аспект STOP - Монитор пути не показывает следующие по ходу светофоры, даже если путь проложен. Светофоры были принудительно закрыты невозможным условием в скрипте.
Изначально при загрузке сценария state и draw_state имеют наименьшее значение. state - 0 "STOP", draw_state - тоже 0.
В MSTS разве не так было?
Добавлено через 1 минуту
Проаерил обратно смотрящую голову на enabled() в случае , если "основная" работает - не включается.
Добавлено через 4 минуты
Что у нас ИСИ говорит? Есть выезд на перегон по белому не в маневровом режиме?
По Бмиг пригласительному на выходном, или на отдельной головке Бмиг, висящей на "спине" входного противоположного направления. У меня такая есть, но работает только в РТС.
В РТС можно "метить" поезда? Или все поезда при условиях скрипта поедут по Бмиг?
Едем дальше по Open Rails.
В отличие от MSTS, в Open Rails обратно-глядящая голова логически является отдельной сигнальной головой, несмотря на то, что в конфигурации она привязана к шейпу, точно также, как в MSTS. То есть , функцией this_sig_lr(SigFn_Type) невозможно "считывать" аспекты с голов, направленных в противоположную сторону. С другой стороны, она и не "энейблится". То есть enabled будут всегда головы одного направления.
А в МСТС вроде так же.
Насчет маневрового режима в РТС - надо протестировать во встроенном редакторе, там есть команда"Start shunting" в Track control-е, сегодня проверю, что она меняет (как ни странно, ни разу не пробовал...).
MSTS и OR как ни тестил - не стоит особо надеяться на DISTANCE при манёврах. По сравнению с NORMAL-головами обновляются реже (даже в прямом направлении), и мои маневровые светофоры Б-С "тупят". Впрочем, об этом APK-LVDZ писал уже давно - а я убедился ещё раз...http://arcanumclub.ru/smiles/smile14.gif
Хорошо, что на моей сигнализации ничего на DISTANCE не завязано! :russian:
Костя, в ОР есть теперь как передавать данные. Сколько угодно данных. Надеюсь к вечеру закончить с этим чертовым показанием маневрового на свободный путь станции с выходным красным - покажу всё. Единственное что - после перезагрузки из сэйва сигналы не помнят введенные данные. Поэтому надо всегда думать о подстраховке.
Передавать данные - это next_sig_id?
Записывать данные это store_lvar (key, value)
Извлекать их - this_sig_lvar (key)
Передавать - next_sig_lvar (key), и id_sig_lvar (sigid, key)
Добавлено через 2 минуты
next_sig_id (SigFn_Type) функция которая идентифицирует сигнал для дальнейшей работы с ним по идентификатору, который она возвращает
То есть запоминается что-то? А при реверсе движения сервиса не теряется?
Нет конечно. Работаешь с этим так же как с конвенциональной логикой в MSTS. Задаешь условия, при выполнении которых запоминаешь значения.
Насчет маневрового режима в РТС - надо протестировать во встроенном редакторе, там есть команда"Start shunting" в Track control-е, сегодня проверю, что она меняет (как ни странно, ни разу не пробовал...).
Проверил, что это такое.
В окне TRACK CONTROL (открывается через Ctrl+Alt+F7) можно задавать маневровый режим себе или любому сервису трафика, выбирая правым мышом на значке движущегося ПС в выпадающем меню "Start shunting/Cancel shunting". Себе, кроме этого, можно выбирать "Force shunting" сразу по Ctrl+Alt+F7, не заходя в TRACK CONTROL.
Все светофоры переключаются в аспект RESTRICTING. Даже проходные, они при этом загораются жёлтым.
Но делать это можно только "на ходу", а задать точки переключения на пути сервиса (по типу постановки точек ожидания) нельзя.
А хорошо было бы...
Это не то.
Сигнализация сама распознаёт: когда сервис движется маневровым порядком, а когда - поездным. Один и тот же сервис может двигаться часть пути одним порядком, а часть - другим. Трафик прибывает на станцию по 2Ж, должна произойти смена локомотива, он отцепляется и уходит по Б на перегон по правильному пути за маневровый, затем возвращается по свободному пути, по выходному Б едет в тупик или на гл. путь, оттуда - в депо. На его место маневровым порядком заходит под поезд сменный лок , опробывание и поезд уходит на тот же путь на перегоне, но уже не по Б, а по поездному. Таких трафиков на маршруте одновременно - несколько десятков. Можно сказать, в любое время где-то на маршруте происходят маневровые передвижения. Как я буду вручную менять режимы?
По Open Rails (и, скорее всего, в MSTS - то же самое) : opp_sig_Xr (SigFn_Type) а в Open Rails и opp_sig_lvar (sigid, key) работают только на enabled светофорах!!! Запоминать информацию могут все светофоры. А, вот, извлечь её, по крайней мере, с оппозитов могут только те, enabled () которых выдаёт TRUE.
[Ругается матом и ложится спать]
...Таких трафиков на маршруте одновременно - несколько десятков. Можно сказать, в любое время где-то на маршруте происходят маневровые передвижения. Как я буду вручную менять режимы?
В окне TrackControl. Диспетчером будешь! :D
Нет, уж, спасибо. Предпочитаю роль "зрителя" :cool:
Что-то, я тупил последние пару дней, пытаясь получить это несчастное маневровое показание через какую-то страшную ...опу - через два оппозита. Типа, маневровый "смотрит" назад, на первый проходной, тот, в свою очередь - на входной. И этот, второй оппозит не срабатывал, естественно, потому что проходной-то - !enabled!
Правильная мысль всегда приходит последней.
Думаю, достаточно будет "ловить" маневровым только первый проходной обратного направления. Логика такая: проходным через функцию block_state () о работе которой я писал раннее, можно "поймать" направление движения сервиса "к входному" . Потому что, на втором от станции блок-участке в сторону станции сервис может быть только в поездном режиме. В этот момент маневровый уже должен быть enabled . Совокупность этих двух условий будет запоминать на маневровом поездной режим. При поездном режиме маневровый дублирует аспекты маркера РЦ, а тот - выходного, а если тот 0, даёт 1 со скоростью, соответственно пути приема (60, 40, 25 и т.д). Аспекты я решил не менять - оно и так работает прекрасно. Есть, как я писал, пара "штрихов", которые я исправляю. Дело в том, что если путь приёма занят, сегодня у меня на маневровом горит белый на аспекте 2, а входной при таком раскладе запрограммирован давать 0 на следующий 2. В поездном режиме я оставлю маневровый 2, но показание дам - синий. Второй момент - в обоих режимах на свободный путь станции при выходном 0, маневровый даёт 1, и синий, при манёврах я смогу при том же 1, дать ему белое показание.
Reset "механизма":
Проходной "обнуляется" когда он !enabled и блок за ним не занят вообще, а маневровый - когда он !enabled (голова проследовала его).
Через пару часов будет возможность протестировать это. Будет работать - можно будет поиграться с условиями сброса маневрового, чтобы не менялся с белого на синий сразу после проследования головы.
Кроме возвращения с сейва, издержкой такого подхода может быть то, что чертов Open Rails учитывает длину поезда при прокладке маршрутов (мануал симулятора). У меня на тестовой ветке ЧМушки, и он спокойно может пустить лок до входного, когда маневровый лок выезжает со станции и становится на отрезке между входным и маневровым сигналами. Но, тут уже буду думать потом: стоит ли блокировать весь перегон. Ситуация редкая, хотя, если честно, в реале (по крайней мере - у нас, в Израиле, чтобы манёвры отправились на перегон, направление на пульте должно быть "от станции" и никаких встречных не может быть по определению.
...Типа, маневровый "смотрит" назад, на первый проходной, тот, в свою очередь - на входной. И этот, второй оппозит не срабатывал, естественно, потому что проходной-то - !enabled!
Я так тоже пытался делать - бесполезно!http://arcanumclub.ru/smiles/smile14.gif
...маркера РЦ...
Как он работает?
В поездном режиме я оставлю маневровый 2, но показание дам - синий.
Это если на выходном STOP?
Как он работает?
Если блок свободен:
На следующий 0 даёт 1;
Остальные аспекты дублирует.
Если блок занят (JN_OBSTRUCTED) - 0;
Если блок занят (OCCURRED):
Выходной открыт любым показанием - 0;
Выходной закрыт - 2;
Вроде, всё назвал. С телефона сейчас.
Это если на выходном STOP?
Да. Нужно различать между сервисом, следующим с перегона на станцию по 1 и тем, что выезжает маневровым порядком и возвращается на свободный путь со следующим 0 по тому же 1.
А этот маркер не мешает локомотивной сигнализации?
Нет. Он же дублирует выходной. На 2D кабинах я "подправил" себе АЛСН под Open Rails - на 0 у меня КЖ, на 1 - тоже. Остальные аспекты дублируются, так что, всё оk. Даже какую-то трёхмерную кабину так переделал "методом тыка"... или две. Не помню уже. ЭРка, вроде, какая-то и ЧС4т от Spiritа. Давно не гоняю уже. Тупо любуюсь сценарием, лично не участвуя в нём.
:D
О, не видел такие кабины... Рулил только в трехмерной для 2ТЭ10М.
Где их скачать?
Я не помню уже. Давно это было. Но, руками точно ковырялся. Возможно, прикручивал РТС-овские кабины. Не помню, честно. Сейчас не до кабин.
vBulletin® v3.8.12 by vBS, Copyright ©2000-2025, Jelsoft Enterprises Ltd. Перевод: zCarot