Перебрал весь шейп. Разворачивал и возвращал в исходную позицию. Кроме изменения координат модели, больше ничего не меняется. Линза огня стоит мертво в одну сторону.

[size="1"][color="Silver"]Добавлено через 1 час 19 минут[/color][/size]
В файле шейп. Есть строчки:
sort_vectors ( 0 )
colours ( 0 )
matrices ( 1
matrix Signal ( 1 0 0 0 1 0 0 0 1 0 0 1 )
)
Где matrix Signal отвечает за положение линзы. Как не менял цифры, свет линзы будет растягиватся вдоль и в поперек, пропадать. Ни ни как не развернется.

Скорей всего нужно делать новую голову и подстраивать положение линзы под разворот маркера.

Единственное, что я нашёл у буржуев, это то, что [B]чтобы линза повернулась, надо развернуть оси относительно объекта SIGNAL[/B].
Честно говоря, я не очень себе это представляю. Сигнал с линзами "против шерсти" маркера я никогда не делал у себя.

В их сигнализации, открыв шейп. Увидел, что светофор сделан, как два объекта, которые с помощью опций делает его с сигнальной головой в разные стороны. Выбираешь одну опцию: Head1 - появляться одна голова, нажимаешь Head1 в другой вкладке - появляется голова противоположного направления. И эти все опции прописаный в файлах sigcfg и sigscr.
Так, что не получится ни как развернуть линзу. Нужно новый объект делать.

Да, похоже на то...
У меня множество двусторонних светофоров, но без огней. Поднял и увеличил линзу на одном из них, покрасил её красным - оказалось - то же самое: смотрит в ту же сторону.
[IMG]https://i.ibb.co/tmzndkF/train-2020-10-10-00-54-11-11.png[/IMG]

В одном из заграничных маршрутов есть трех-крылый семафор.
[img]https://a.radikal.ru/a13/2010/23/5fc6150f3069t.jpg[/img]
В сигнализации СССР подобные семафоры использовались для указания направления при многопутном участке: При наличии трёх и более направлений применяются трёхкрылые семафоры ... Третье крыло сигнализирует также, как и второе крыло, желтым огнем.
Есть ли возможность поднять одновременно три крыла семафора?

Используя, вот этот скрипт:
[B]sigcfg.dat[/B]
SignalType ( "[B]T_Semaphore_GR_X_X[/B]"
SignalFnType ( NORMAL )
SignalLightTex ( "ltex" )
SemaphoreInfo ( 1 )
SignalFlags ( SEMAPHORE )
SignalLights ( 2
SignalLight ( 0 "Red Light"
Position ( -0.367 0 -0.04 )
Radius ( 0.1 )
SignalFlags ( SEMAPHORE_CHANGE )
)
SignalLight ( 1 "Green Light"
Position ( -0.367 0 -0.04 )
Radius ( 0.1 )
SignalFlags ( SEMAPHORE_CHANGE )
)
)
SignalDrawStates ( 2
SignalDrawState ( 0
"Stop"
DrawLights ( 1
DrawLight ( 0 )
)
SemaphorePos ( 0 )
)
SignalDrawState ( 1
"Green"
DrawLights ( 1
DrawLight ( 1 )
)
SemaphorePos ( 2 )
)
)
SignalAspects ( 2
SignalAspect ( STOP_AND_PROCEED "Stop" SpeedKPH ( 0 ) )
SignalAspect ( CLEAR_1 "Green" )
)
SignalNumClearAhead ( 1 )
)
SignalType ( "[B]T_Semaphore_GX_Y_X[/B]"
SignalFnType ( NORMAL )
SignalLightTex ( "ltex" )
SemaphoreInfo ( 1 )
SignalFlags ( SEMAPHORE )
SignalLights ( 3
SignalLight ( 0 "No Light"
Position ( 0 0 0 )
Radius ( 0.001 )
SignalFlags ( SEMAPHORE_CHANGE )
)
SignalLight ( 1 "AmberF Light"
Position ( -0.367 0 -0.04 )
Radius ( 0.1 )
SignalFlags ( SEMAPHORE_CHANGE )
)
SignalLight ( 2 "Green Light"
Position ( -0.367 0 -0.04 )
Radius ( 0.1 )
SignalFlags ( SEMAPHORE_CHANGE )
)
)
SignalDrawStates ( 2
SignalDrawState ( 0
"No Light"
DrawLights ( 1
DrawLight ( 0 )
)
SemaphorePos ( 0 )
)
SignalDrawState ( 1
"YellowGreen"
DrawLights ( 2
DrawLight ( 1 )
DrawLight ( 2 )
)
SemaphorePos ( 2 )
)
)
SignalAspects ( 2
SignalAspect ( STOP "No Light" )
SignalAspect ( APPROACH_1 "YellowGreen" SpeedKPH ( 40 ) )
)
SignalNumClearAhead ( 3 )
)
SignalType ( "[B]T_Semaphore_GX_Y_Y[/B]"

SignalFnType ( INFO )
SignalLightTex ( "ltex" )
SemaphoreInfo ( 1 )
SignalFlags ( SEMAPHORE )
SignalLights ( 4
SignalLight ( 0 "No Light"
Position ( 0 0 0 )
Radius ( 0.001 )
SignalFlags ( SEMAPHORE_CHANGE )
)
SignalLight ( 1 "Amber Light"
Position ( -0.367 0 -0.04 )
Radius ( 0.1 )
SignalFlags ( SEMAPHORE_CHANGE )
)
SignalLight ( 2 "AmberF Light"
Position ( -0.367 0 -0.04 )
Radius ( 0.1 )
SignalFlags ( SEMAPHORE_CHANGE )
)
SignalLight ( 3 "Green Light"
Position ( -0.367 0 -0.04 )
Radius ( 0.1 )
SignalFlags ( SEMAPHORE_CHANGE )
)
)
SignalDrawStates ( 2
SignalDrawState ( 0
"No Light"
DrawLights ( 1
DrawLight ( 0 )
)
SemaphorePos ( 0 )
)
SignalDrawState ( 1
"YellowYellow"
DrawLights ( 3
DrawLight ( 3 )
DrawLight ( 2 )
DrawLight ( 1 )
)
SemaphorePos ( 2 )
)
)
SignalAspects ( 2
SignalAspect ( STOP "No Light" )
SignalAspect ( APPROACH_1 "YellowYellow" SpeedKPH ( 40 ) )
)
SignalNumClearAhead ( 5 )
)

SignalShape (
"LHUQ3abs.s"
"Выходной Семафор 3 Крыла"
SignalSubObjs ( 3
SignalSubObj ( 0 "HEAD1" "Одно Крыло-Главный Путь"
SigSubType ( SIGNAL_HEAD )
SignalFlags ( JN_LINK )
SigSubSType ( "[B]T_Semaphore_GR_X_X[/B]" )
)
SignalSubObj ( 1 "HEAD2" "Два Крыла-Ответление На Боковой Путь"
SigSubType ( SIGNAL_HEAD )
SignalFlags ( JN_LINK OPTIONAL DEFAULT )
SigSubSType ( "[B]T_Semaphore_GX_Y_Y[/B]" )
)
SignalSubObj ( 2 "HEAD3" "Три Крыла-Ответление На Боковой Путь"
SigSubType ( SIGNAL_HEAD )
SignalFlags ( JN_LINK OPTIONAL DEFAULT )
SigSubSType ( "[B]T_Semaphore_GX_Y_Y[/B]" )

)
)
)

[B]sigscr.dat[/B]
[B]SCRIPT T_Semaphore_GR_X_X[/B]

extern float block_state ();
extern float route_set ();
extern float next_sig_lr ();
extern float next_sig_mr ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float enabled;
extern float sig_feature ();
float next_state;

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_STOP_AND_PROCEED)))
{
state = SIGASP_CLEAR_1;
}
else
{
state = SIGASP_CLEAR_1;
}
}
draw_state = def_draw_state (state);

[B]SCRIPT T_Semaphore_GX_Y_X[/B]

extern float block_state ();
extern float route_set ();
extern float next_sig_lr ();
extern float next_sig_mr ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float enabled;
extern float sig_feature ();
float next_state;

if (route_set())
{
state = SIGASP_STOP_AND_PROCEED;
if (enabled && (block_state() ==# BLOCK_CLEAR))
{
next_state = next_sig_lr (SIGFN_NORMAL);
if ((next_state ==# SIGASP_STOP_AND_PROCEED) || ((next_sig_mr (SIGFN_NORMAL) ==# SIGASP_STOP_AND_PROCEED) && (next_state ==# SIGASP_STOP_AND_PROCEED)))
{
state = SIGASP_STOP_AND_PROCEED;
}
else
{
state = SIGASP_APPROACH_1;
}
}
draw_state = def_draw_state (state);
if ((state >=# SIGASP_APPROACH_1) && (next_state ># SIGASP_STOP_AND_PROCEED))
{
draw_state = 1;
}
else if (next_state ==# SIGASP_STOP_AND_PROCEED)
{
draw_state = 1;
}
}
else
{
state = SIGASP_STOP_AND_PROCEED;
if (block_state() ==# BLOCK_JN_OBSTRUCTED)
{
state = SIGASP_STOP_AND_PROCEED;
}
draw_state = def_draw_state (state);
}


[B]SCRIPT T_Semaphore_GX_Y_Y[/B]

extern float block_state ();
extern float route_set ();
extern float next_sig_lr ();
extern float next_sig_mr ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float enabled;
extern float sig_feature ();
float next_state;

if (route_set())
{
state = SIGASP_STOP_AND_PROCEED;
if (enabled && (block_state() ==# BLOCK_CLEAR))
{
next_state = next_sig_lr (SIGFN_NORMAL);
if ((next_state ==# SIGASP_STOP_AND_PROCEED) || ((next_sig_mr (SIGFN_NORMAL) ==# SIGASP_STOP_AND_PROCEED) && (next_state ==# SIGASP_STOP_AND_PROCEED)))
{
state = SIGASP_STOP_AND_PROCEED;
}
else
{
state = SIGASP_APPROACH_1;
}
}
draw_state = def_draw_state (state);
if ((state >=# SIGASP_APPROACH_1) && (next_state ># SIGASP_STOP_AND_PROCEED))
{
draw_state = 1;
}
else if (next_state ==# SIGASP_STOP_AND_PROCEED)
{
draw_state = 1;
}
}
else
{
state = SIGASP_STOP_AND_PROCEED;
if (block_state() ==# BLOCK_JN_OBSTRUCTED)
{
state = SIGASP_STOP_AND_PROCEED;
}
draw_state = def_draw_state (state);
}

У меня следующая ситуация:
При указании главного пути: Семафор сигнализирует правильно:
[img]https://c.radikal.ru/c17/2010/67/c4953470c24ct.jpg[/img]
При указании бокового направления и два крыла. Семафор сигнализирует правильно.
[img]https://d.radikal.ru/d14/2010/e2/ad0b96eb7ad8t.jpg[/img]
А при использовании третьего направления,почему-то не подымается, среднее крыло.
[img]https://c.radikal.ru/c31/2010/0b/7ad859710382t.jpg[/img]
Возможно нужно прописать какой-то дополнительный параметр?

Маршрут не по линку - вот и не поднимается.

Там просто не видно третьего пути)
Получается, что скрипт полностью правильный?

Ну, если не работает так, как хочешь - значит нужно переделывать.

[size="1"][color="Silver"]Добавлено через 39 минут[/color][/size]
Логика мне видится примерно твк:
Верхнее крыло работает на "закрыто-открыто". Поэтому линковка там - ни к чему. Остальные подобъекты - линкованые. Причем, если одно из них работает по своему линку, другому нужно прописать ещё зависимость от показаний "подсобрата"

[QUOTE=vicente;596352]Причем, если одно из них работает по своему линку, другому нужно прописать ещё зависимость от показаний "подсобрата"[/QUOTE]

Вот поэтому не могу понять, что именно нужно прописать в зависимость "подсобрата".
В сигналке я - аматор. И пытаюсь понять исходя из созданных сигнализаций или советов.

Открытое показание нижнего крыла сделай не APPROACH_1, a CLEAR_2 (с желтым показанием) и среднему крылу добавь, что если маршрут не по линку
if (!route_set && this_sig_lr ==# SIGASP_CLEAR_2) {state = APPROACH_1};

[size="1"][color="Silver"]Добавлено через 4 минуты[/color][/size]
Логика ясна? Если маршрут не по линку среднего, но по линку нижнего, средний через эту зависимость будет видеть, что нижний открыт и открываться

[QUOTE=vicente;596355]
if (!route_set && this_sig_lr ==# SIGASP_CLEAR_2) {state = APPROACH_1};
[/QUOTE]

В которую строчку именно это прописать?

Логику понял. Сейчас пробовать буду.

И ещё. Я не вдавался в твой скрипт, но я бы его "почистил". Почему на следующий закоытый сигнал семафор закрыт, например?

Разберусь с этим. Видимо допустил ошибку.

Вот это:
[QUOTE] next_state = next_sig_lr (SIGFN_NORMAL);
if ((next_state ==# SIGASP_STOP) || ((next_sig_mr (SIGFN_NORMAL) ==# SIGASP_STOP_AND_PROCEED) && (next_state ==# SIGASP_STOP_AND_PROCEED))) [/QUOTE]
довольно громоздко. Я знаю, что это списано у Тимаса, но по моему мнению, здесь достаточно только первой части выражения.

[size="1"][color="Silver"]Добавлено через 2 минуты[/color][/size]
Кроме того, у семафора два положения, поэтому для него достаточно в дополнение к [I]enabled[/I]() только очистки блока. Остальное - долой!

[QUOTE=vicente;596360]...Я знаю, что это списано у Тимаса, но по моему мнению, здесь достаточно только первой части выражения...[/QUOTE]

А это, по-моему, задел то ли на манёвры, то ли на потерю кодов на бок. Из не вышедшей третьей части. Суть такая: next_state даёт бОльшее из next_sig_mr и next_sig_lr. Если, конечно, я что-то за тринадцать лет ещё помнюю.

Знал бы я тогда, как сейчас, как всё интересно в реальности работает - ни за что бы не взялся писать скрипты, бо они и половины возможностей СЦБ не отражают!

[QUOTE=Timas;596365]
Знал бы я тогда, как сейчас, как всё интересно в реальности работает - ни за что бы не взялся писать скрипты, бо они и половины возможностей СЦБ не отражают![/QUOTE]
Значит, хорошо, что не знал :D

Понятно, что в игре мы пытаемся максимально приблизить работу сигнализации к реальности, насколько это позволяет то, что дал нам разработчик. А дал он - по минимуму. Проблема не только у нас, кстати, но и у большинства нерусскоязычных товарищей. В Open Rails они довольно серьёзно расширили возможности создания сигнализаций,.но изменили весь принцип их работы в коде. Как следствие - наше сообщество "застряло" на довольно ранней версии симулятора в мультиплеерах.

А я тебе [B][I][U]по секрету[/U][/I][/B] скажу, какие моменты надо в симуляторе такого рода предусматривать, чтобы потом не пришлось страдать некрофилией:

0. Ввести понятие стыка - точки с событийно контролируемым проследованием каждой колёсной парой. Это даёт возможность учитывать занятость любой достаточно протяжённой секции пути, как сумму колёсных пар на её субсекциях (сплайнах).

1. Организовать трансляцию кодов только до первой ездючины на пути. Это сложно и кодоёмко, но иначе непрерывные системы никак не сделать. Точечные системы передачи информации вешаются на события из п. 0.

3. Организовать обратную связь объектов с логикой СЦБ (взрез стрелки, например).

4. Секционирование КС - по принципу секционирования путей.

5. Нужен мощный и быстрый скриптовой движок с поддержкой ООП для программирования самой СЦБ. Примерно как в Метрострое, но только лучше и вкуснее!

6. Если СЦБ прогать чисто событийно (и массово пренебречь временнЫми параметрами схем), то оно не отожрёт много ресурсов, бо события в СЦБ не так уж и часты, это не физику ездючины считать. Ресурсы отожрёт передача кодирования, но и это можно продумать.

7. Ну и, соот-но, на всё это прогать отдельную морду для управления. Считаться оно должно исключительно на стороне сервера.

ЗЫ. Потом ещё диких детей учить, как в этой морде работать!

Ну... ты "загнул" здесь, по-моему.
Как раз "в симуляторе такого рода" такие задачи, насколько я понимаю, не ставились. Достаточно вспомнить, что [I]изначально[/I] сие детище KUJU было попыткой создать симулятор [B]машиниста[/B]. Действительно, всё было привязано к стставу мгрока! Включая 4-й вид "стоящего" человека, мимо которого проходит поезд. И тот сменялся быстро после проследования передней части состава. Всё остальное: окружающий мир, сигнализация... были даны по минимуму. Единственное, игрушка была открыта на предмет создания дополнений. Но, опять же - по тому же принципу - более в плане в физики ПС, скажем, и менее в остальных аспектах по мере удаления от этого самого поезда игрока. Так как сигнализация в игре - это то, с чем взаимодействует игрок на уровне "я вижу", возможностей в создании дополнений к ней было немного побольше, но всё равно - далеко от того уровня идеала, который ты описал. Ведь даже диспетчерских функий в MSTS не было. Они оганичивались возможностью сделать тот или иной сигнал "неисправным" в редакторе, опять же, для того, чтобы машинисту организовать принудительный проезд этого самого светофора. Тут не до взреза стрелок. Какой там? Симулятор "увольнял" игрока при проезде запрещающего немедленно!

А это по той причине, что он однопользовательский был. Как только появилась задача организовать многопользовательский (сетевой) режим - наружу вылезли все костыли. Начиная от отсутствия разделения вычислений на клиентскую и серверную стороны и заканчивая отсутствием всего и вся. Собст-но, ровно по этой причине я и считаю нынешнюю околоМСТСную возню некрофилией. Я не имею ничего против этой возни, но втайне надеюсь, что где-то у кого-то появится мысль начать всё с нуля и заточить под нужды совместной игры. Тем более, что игровые движки и вычислительные мощности вполне себе это позволяют.

Для меня, весь этот околоМСТС - некий ностальгический момент. Я вышедший ЭП20 даже не качал, например. Он мне лично неинтересен. И РТС запустил пару раз. Вся эта суета с запусками локомотива и неисправностями, как в Симуляторе Усова - мне на работе этого добра хватает с головой. Я ещё в МСТС в своё время расставил на станциях на мостах-переходах невидимые рельсы, ставил невидимку составом игрока и нсблюдал за движением на станции. Потом открыл для себя Open Rails. Там с этим проще уже было, так как оказалось, что есть там разработчики, которые также любят понаблюдать. Они создали для такого способа игры все условия. Возможно, их проблема в том, что они декларируют полную совместимость с МСТС. То есть, одним из незыблимых правил там является, что то, что работает в МСТС,.должно работать и в OR. Где-то этот"момент" и "тормозит" этот симулятор.

Насчет "с нуля". Это нужна команда. Чтобы была команда, такой подход должен был интересен. И не на уровне "я бы в такое поиграл" , но на уровне "я бы такое сделал". Иначе, это займёт годы. Я ничего нового не создаю, моделированием не занимаюсь. Уже лет 15 "ковыряю" свою переделку маршрута и конца-края этому занятию не видно. Из почти 800 км главного хода "катаю" 65 где-то. Вот сейчас весной на карантине начал "оживлять" ещё один участок - так запал с сигнализацией (в который раз), потом решил перейти на Timetable Mode (совсем иной принцип создания сценария). А, вчера, вот, подумал о "стыках", о кторых ты писал - и вожжа мне в голову заселилась... А если у меня в голове крутится какая-то идейка... блин. :D Вместе с основной мыслю всегда идёт "а ещё неплохо бы..." Я понимаю, что это месяцы возни, но ничего с собой поделать не могу. Хорошо бы, чтобы получилось. Давно меня бесит, что как только поезд стрелку проезжает (даже за track pin полностью не заходит), она переводится и строится другой маршрут.

Сейчас мы тут уйдём в тёмные дебри и огребём!

Команда - это хорошо, но это и плохо. Начинаешь зависеть от кого-то другого, ждать, согласовывать и т.д. Трата времени и сил. Если в ковырятельном режиме - лучше уж одному, ну или на вспомогательные операции команду привлекать (тестирование, создание объектов, текстур...).

А новый сим таки просится. Run8, хоть и дорогой, но свою нишу занял. Не скажу, что там много чего надобавляли, но составителю и диспетчеру там работа найдётся. И делают они его уже второй десяток лет.

Если что - это оффтоп был.

Что касаемо стыков - штука очень нужная. МСТСы, как и ряд других симуляторов (zzZ всех видов, ZDSim...) привязывают ездючину к пути одной точкой - математическим центром. Соот-но, ездючина с секции на секцию перескакивает мгновенно. А для реализма должна сначала головой занимать, потом хвостом освобождать. Это я про состав из одной ПЕ. Поэтому стык и раздельный контроль занятия и освобождения - это уже половина СЦБ, по сути.

[QUOTE=Timas;596466]... огребём!..[/QUOTE]
Ну, огребём - так огребём :D
Все безумные идеи рождаются а оффтопе (ха-ха)
[QUOTE=Timas;596466]
Команда - это хорошо, но это и плохо. Начинаешь зависеть от кого-то другого, ждать, согласовывать и т.д. Трата времени и сил. Если в ковырятельном режиме - лучше уж одному, ну или на вспомогательные операции команду привлекать (тестирование, создание объектов, текстур...).[/QUOTE]
Ну, если разраб сам осиливает - круто. Я поглядываю на команду Open Rails и, если честно, не представляю себе, как один или даже два-три программера поднимают такой проект в такие сроки.
[QUOTE=Timas;596466]
А новый сим таки просится.[/QUOTE]
Кто будет делать? Тут недавно в одной из тем кто-то из команды этого сайта писал, что звукарей не осталось... и всё. Нужны люди молодые и голодные. А ещё ПС конвертить и объекты. Я тут не решаюсь попросить народ "подбить" кабины, чтобы АЛСНы, КЛУБы всякие в Open Rails работали... Ведь пошлют же... и будут правы :)
[QUOTE=Timas;596466]
Что касаемо стыков - штука очень нужная. МСТСы, как и ряд других симуляторов (zzZ всех видов, ZDSim...) привязывают ездючину к пути одной точкой - математическим центром. Соот-но, ездючина с секции на секцию перескакивает мгновенно. А для реализма должна сначала головой занимать, потом хвостом освобождать. Это я про состав из одной ПЕ. Поэтому стык и раздельный контроль занятия и освобождения - это уже половина СЦБ, по сути.[/QUOTE]
Какое железо такое потянет? Или - ну их - нищебродов? :D
Состав из 60 вагонов это 120 тележек... Если не сказать 240 осей. Если каждую считать...

[size="1"][color="Silver"]Добавлено через 1 час 55 минут[/color][/size]
Теперь по существу того, на что меня натолкнул тыой разговор о стыках. Опишу здесь. Может, кто-то из пользователей или строителей маршрутов захочет воспользоваться.
Проблему я описал: стрелка переводится как только "коробка" хвостового ПС пересекает Track Pin этой стрелки (если другой поезд запрашивает маршрут) и открывается светофор в другом направлении. В MSTS или Activity Mode ORTS движение начнется соазу же. В Timetable Mode я установил задержку перед началом движения - ТС ждет вплоть до минуты пепед тем, как тронуться. Но, всё равно - выглядит - не очень. И, если честно, довольно серьёзно подбешивает мну.
Я пытался добавить задержку светофору, но, к сожалению, компилятор не учитывает счётчик когда игра загружается.
Идея заключается в том, чтобы поставить на уровне [прежде всего] выходных светофоров ложные кроссоверы - точки пути. Логика проста: если на пути сервиса есть общая точка с соседним путём, по которому движется другой сервис, сим будет видеть эту точку "занятой" и маршрут не будет построен пока хвост не зайдет за РЦ или счётчик осей у светофора .

Технология
Учимся устанавливать вручную ложные кроссоверы [URL="https://msts.steam4me.net/tutorials/make_xover.html#complex"]здесь[/URL]. Обязательно бэкапимся (в статье написано). Изменения такого рода [B]необратимы[/B]! Обратите внимание на то, что нужно указывать верную секцию пути, а не те, что указаны в статье.

[size="1"][color="Silver"]Добавлено через 22 минуты[/color][/size]
Несмотря на то, что в первом тесте система показала мне большой кукиш, думаю - работать будет

Кроссоверы ставятся попарно. То есть, если на станции 3 пути, нужно ставить 3 пары кроссоверов, чтобы всё перекрывалось. На 4 пути нужно уже 6 пар, на 5 путей - 10 и т.д. в той же прогрессии. Если перегон от станции двухпутный - связывать главные пути я не буду. Чтобы обеспечить одновременную работу в оба направления по главному ходу. Обратите внимание, что "совместной" является [B]вся секция пути[/B], на которой установлена точка кроссовера. Поэтому секции, заходящие на пути станции не годятся. Именно это и явилось причиной "фака", который я получил в первом тесте. Я установил кроссовер на боковом на секции 250 м. Поезд стал под обгон, физически с точки съехал, но остановился на секции хвостом и больше ничего никому не открылось вообще.

[size="1"][color="Silver"]Добавлено через 3 минуты[/color][/size]
Второй тест. Сделал на другой станции (пути менять не хочу). Полёт нормальный. Всё сработало. Плюс бонус - в версии 77 OR NY MG есть "оттяжка" открытия светофора "от симулятора". Встречный заехал за "стык", а светофор открылся только через несколько секунд.

Ну, с точки зрения вычислений обработка стыков - не такая уж и сложная задача. Координата ведь всё равно считается относительно секции пути. Для СЦБ, по сути, нужна первая и последняя колёсные пары. Причём это же не на каждом стыке возникает событие, а только на том, коий является изолирующим стыком (т.е. стыком двух рельсовых цепей). У меня-то этот алгоритм работает прекрасно.

Про кроссоверы задачка интересная, но это пока до сортировки не дошло. Построит кто-нибудь Инскую или Орехово-Зуево, и сам же запутает себя в маршрутизации.

Если честно, я не сильно понимаю, почему алгоритм непрерывного поиска ездючин на пути (он что в МСТС, что в zzZ всех версий) проще событийного их отслеживания. Просто чтобы упростить жизнь пользователю что ли? Чтобы он не заморачивался со сборкой рельсовых цепей из отдельных секций пути?

Собст-но, с кодированием насквозь ездючины вопрос примерно тот же...

А, сколько таких стыков на каждой станции? ;)
И, это мы не дошли ещё до Орехово-Зуево или Инской :D

Но... Ты (я так понимаю) этим занимаешься в своём проекте - тебе видней. Мне кажется, это слишком замысловато для "просто игрушки". А все вышеупомянутые "симуляторы", включая Run 8, именно игрушками и являютя. Я тебе больше скажу. У меня на работе есть симулятор машиниста. Кабина в натуральную величину и всё такое. Так вот, там "положили" не только на графику ПС, объекты окружения и пр. Всё, тобой описаное, там отсутствует напрочь. Оператор на своем пульте задаёт участок, по которому едет кадет, есть определенный набор событий (кроме неисправностей самого локомотива) на трассе, никоим образом с движением поездов не связаных. В смысле, вообще никакой организации движения там нет. Трафик представляет собой "кривые" картинки, призванные, скорее всего, убедить кадета в том, что его не запустили одного в этой "коробке" в открытый космос :D Несомненно, у описываемого симулятора - другое предназачение, но я, выйдя из кабины тогда, сказал сослуживцам и начальчтву, что если бы мне дали половину от7 миллионов американских рублей (а утверждается, что именно столько сие чудо стоило) минус кабина, я бы им на базе любого симулятора (того же МСТС или ОР смоделил бы весь Израиль... [S]с блэкджеком и шлюхами[/S] с сигнализацией и трафиком.... :D :D

А здесь, у меня лично, цель другая. Кайфануть. Причем сделать это, когда мне того хочется и столько, сколько мне хочется. Мультиплеер, например, меня вообще не возбуждает. У меня на работе каждый день Мультиплеер :D Если честно, я вообще не понимаю, как это дома может происходить. Ведь в любой момент в кабину могут ворваться жена, дети. Тёща может позвонить... Может потребоваться открыть банку или помочь с пультом от зомбоящика.... ну, в общем, мужская грубая сила :D :D :D. А есть ещё начальство у мультов... строгое ;) Я пару дней назад на их сайт зашёл и понял: как чувствовали себя простолюдины во времена Инквизиции! Вроде, ты не ведьма, а всё равно - ссыкотно :D

Что касается сигнализации и организации движения поездов, я ставлю себе задачи гораздо проще. Во-первых, [B]чтобы оно работало![/B]. С этими "нашими" МСТСами/Опэнрэйлсами - это желательно. Во-вторых, чтобы из кабины и со стороны наблюдателя оно было [B]похоже[/B] на то, что происходит в реальной жизни. . Вопрос в том, насколько необходимо пользователям игрушки вдаваться в СЦБ. Стыки - это хорошо, но кому, кроме операторов пультов ДСП и СЦБистов есть дело до них? Объясню. Я работаю машинистом. Для меня, как ездуна, простейшая по своему строению станция делится на 5 зон: от входного (границы станции) до первого маневрового - область манёвров. Ну, или точнее - приёма на станцию маневровым порядком. Далее, от первого маневрового до выходного противоположного направления - область стрелок. Затем - путь станции и до границы станции - в том же порядке.

Конечно, по стыкам - оно по другому. Стрелки разделены, на ответвлениях тоже счётчики осей установлены. Но, в симуляции оно мне зачем? Мне важно, что если на стрелках находится, как ты выражаешься, "ездючина", сигнализация это видела, и никого туда не пускала. А на какой оно именно стрелке - дело пятое. Так ещё (неровен час) можно и до неисправностей СЦБ докатиться :crazy: .... ложные занятости всякие, прибытие не в полном составе... там...

В общем, по этому принципу я и [S]переделывал твою[/S] делал свою сигнализацию.

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

Нет. Что-то не то с этими кроссоверами. :D
Не на всех путях работает. Видно, напутал с секциями пути.

[QUOTE=vicente;596485]А сколько таких стыков на каждой станции? ;)
И, это мы не дошли ещё до Орехово-Зуево или Инской :D ...[/QUOTE]

Стыков раза в полтора больше, чем рельсовых цепей. На сотню РЦ будет примерно полторы сотни стыков. Я не беру во внимание внутренние стыки между остряками и крестовиной стрелочного перевода, которые нужны для организации чередования полярности в РЦ. Только те, которые разграничивают РЦ.

Я тоже совершенно не прочь иметь какую-нибудь залипательную фигню, где всё ездит само, а ты только глядишь. Но описать её достаточно проблематично, причём это гораздо сложнее, нежели описать СЦБ. Слишком много описаний, хотя при поверхностном взгляде оно кажется простым. В основном это связано с выбором вариатного маршрута и первоочерёдностью задания маршрутов.

Даже если это не совместная игра, моё видение СЦБ всё же стремится к реализму. , если выбор правильного варианта маршрута - задача в данной реальности неразрешимая, то, как минимум, работу с охранными стрелками делать надо. Едет ли поезд ИИ или игрок - стрелки должны вставать в охрану. ИИ можно запрограммировать не ехать, игрок может поехать, куда и когда захочет. Ну это, конечно, если не увольнять его. Да и есть ещё аспекты, где проявляется некорректность и негибкость работы СЦБ.

Неисправности - штука хорошая, но они-то как раз не для детей, а для движенцев и СЦБистов. В условиях совместной игры их реализовать-то можно, но корректно отработать выход из них - нет. У ложной занятости может быть с десяток причин, у ложной свободности - поменьше.

То есть, ты считаешь, что описать такое возможно и построить так маршрут длинной в сотни километров с десятками станций и запустить туда трафик в сотни поездов (Я сейчас гоняю 461 поезд, в час пик пригородные с интервалом в 15 минут, скрещения, обгоны, смены локомотивов)?

Интересная вещь. Читал когда-то на форуме elvastower.com о перепитиях организации движения в OpenRails. Как известно, этот симулятор задуман был для того, чтобы поставить MSTS на "новые рельсы" - дать ему второе дыхание. Чтобы не пропали созданые маршруты, сценарии, подвижной состав... Вначале пути организация движения была перенесена "как есть" из MSTS, но немного позднее небезизвестной версии Х1370 всё было переработано чуть более, чем полностью. Именно с этим нововведением наши сигнализации "остались не у дел" в OpenRails. Так вот, автор разработки писал на форуме о причинах, по которым всё это было переделано "с нуля". И, вот, одной из причин было названо "отсутствие автодиспетчера" в MSTS. А, вот, в технической документации к сигнализации MSTS об автодиспетчере говорится прямо и понятно. То есть, явно кто-то напутал с терминологией. Много лет назад долгими ночами мы сидели с Игорем Забориным каждый за своим компьютером и трахались с MSTS, чтобы выяснить: как оно [B]на самом деле работает[/B]. Целью.было создание открытой сигнализации, чего в конце концов не случилось. Но, в процессе многое стало понятно (обидно, но те вещи, к которым я приходил, гоняя ездюяины по сотне раз туда-сюда, оказалось гораздо раньше были "разжеваны" буржуями на "Стиме" и trainsim.con). Но, с другой стороны, это и порадовало. В смысле, что я всё правильно понял тогда. Принцип MSTS очень прост и практичен. Каждый поезд имеет своё "задание" - path. Он появляется в начале path и исчезает в конце. Между этими событиями можно задать ему что-то из определённого набора команд, очень ограниченного... точки разворота, точки ожидания, остановки на станциях, альтернативные маршруты и т.д. Если на пути есть узлы - стрелки, поезд "запрашивает" их согласно строго определённому алгоритму, связанному с параметром. SignalNumClearAhead, заданному в файле конфигурации сигнализации маршрута. Если узел не зарезервирован другим поездом, он получает этот узел и через узел строится маршут дальше согласно заданию. Если узел ограждён светофором - светофор откроется в случае если соблюдены остальные условия его скрипта. Если узел зарезервирован другим поездом - светофор будет закрыт через функцию BLOCK_JN_OBSTRUCTED, которая должна быть, опять опять-же, в этом скрипте прописана. На этом - почти всё. Единственное, что, может, следует добавить - если участок однопутный и есть поезд навстречу, а маршрут через узел проложен - неважно: сколько проходных светофоров на участке - поезд зарезервирует себе и следующий узел, чтобы встречный не занял этот совместный участок!
Всё это, включая существование блокировки (deadlock), непонятно и лаконично описано в документе по сигнализации MSTS.
И тут на заре развития OpenRails встаёт себе Роб Ротердинк и заявляет : в MSTS нет автодиспетчера! А он нам нужен! Организация движения - не идеальна. Пользователи "плавают" в сценариях. Нам нужно делать более сложные сценарии. Второй главной причиной вмешательства в механизм MSTS было отсутствие (якобы) возможности делать то, что они называют Call On - проезд запрещающего сигнала на занятый путь. На самом деле красные светофоры в MSTS можно спокойно проезжать даже на дефолтной сигнализации Marias Pass , через условно-разрешающий и маневровый аспекты, заложеные изначально в симулятор разработчиками.
Что в этом всём интересного и как это связано с нашим разговором?
Конечный вариант (а Роб отходит от дел и никто (пока) не решается даже приблизится к этой части кода) сигнализации OpenRails концептуально выглядит с этой точки зрения... примерно так же. Поезд имеет задание и запрашивает себе путь! Да, нюансы там есть, deadlock "отделён от государства", но... стало ли легче делать сложные сценарии (в добавилось множество функций)? Вопрос. У меня были случаи, когда простыми точками разворота deadlock сбивался к чертям и у Роба не было решений, кроме как закончить сервис, и из него создать новый.
Но, по моим понятиям, автодиспетчера как такового как не было - так и нет.

То о чем пишешь ты требует описания диспетчера. В одиночной поездке этот диспетчер должен просчитывать десятки, если не сотни вариантов на каждой станции. А на маршруте? Но, как бы ты не пришел к тому же самому : различать поезда диспетчер-то должен всё равно - по заданию. Или как?

[size="1"][color="Silver"]Добавлено через 54 минуты[/color][/size]
Всё-таки выставлю ролик, который снимал для себя в рабочем порядке. Прошу прощения за съёмку на телефон. На ролике - открытие светофора с ложным кроссовером. На место установки кроссовера на пути электрички указываю мышкой.

[YOUTUBE=""]JXkTX0egfPY[/YOUTUBE]

А куда оно денется, если работать не будет. Оно жеж событийное, никаких постоянных расчётов ему там делать не надо, чтобы какие-то сложные циклы крутились и перебирали всю кучу объектов. Друг делал в zzZ'19 СЦБ по моим принципам, но не в виде ООП, а в виде скриптов. Так он при правильном секционировании путей мелкие станции за вечер скриптом описывал. Крупные - да, дольше, но на крупных и я в своём проекте плаваю, бо нет пока автоматизации по их созданию.

Вот хочу после переезда проекта попробовать сделать автоматическое формирование базы маршрутов. Стыки расставлены, стрелки и секции описаны, пусть сама ищет. В условиях любого другого симулятора это тоже вполне реально: стрелки уже есть, стыки расставил и запускай её на поиск. Потом выкинуть из поиска всё лишнее (поездные маршруты в непоездные тупики, например), прописал тип сигнализации по маршрутам и оно работает.

Для того, чтобы состоялся правильный автодиспетчер, надо отдельно по готовым таблицам маршрутов описать те пути, по которым разрешён безостановочный пропуск (и, соот-но, увязка попутных показаний светофоров (да, она не везде!)), И всё. Для организации именно пропуска этого вполне достаточно. АД должен считать на перспективу занятие путей на каждой станции всеми вошедшими в модель организованными поездами и следить, чтобы на однопутных участках не возникало перенасыщения участка поездами.

С манёврами тяжче. Выбрать тупик, через который оборачивать отцепляемый локомотив - и то может стать затыком на перспективу (будет ли куда с тупика выехать в ближайшее время, не понадобится ли этот тупик кому-то ещё, у которого других вариантов не будет). Тут уже, по сути, ручками техпроцесс прогать, чтоб красиво ездило. Каждый поезд, состав, группа вагонов со своими условиями следования - это цепочка действий. Вот тут - да, автодиспетчер на поиске оптимального варианта работы отожрёт процессор неплохо!

Теперь, что касаемо поездной сигнализации. Все эти извращения с описыванием 1234567890 почти одинаковых скриптов, различающихся только разлинзовкой, это реально извращения. Для выбранного типа сигнализации необходимо составить трёхмерную таблицу, в которой упорядочиваются зависимости сигналов на попутных светофоров. Ест-но, с учётом стрелок и скоростей по ним. Одна таблица на всю карту (если неск. типов СЦБ применяется - будет неск. таблиц). Каждый аспект в таблице должен уметь отображаться тем или иным светофором. Собрал таблицу маршрутов - пошёл назначать каждому маршруту алгоритм из таблицы. На этом этапе светофор может сматериться, что у него нет способа отобразить такое-то показание. В этом случае светофор заменить (именно заменой, чтобы не обвалить таблицы маршрутов, которые ведут до или за этот светофор). И всё. Логика описывается один раз, а не таскается из скрипта в скрипт.

Я вот у себя тоже хочу от чисто МПСовской сигнализации уйтить в сторону вариантной. Но не сейчас.

[QUOTE] и то может стать затыком на перспективу[/QUOTE]Обход затыков можно внедрять в логику, или (как у меня в маршрутизации) делать два варианта маневровых маршрутов - на занятый путь или только на свободный (во втором случае "кто-то ещё", кому нужен этот же тупик, не поедет, пока данный лок не освободит тупик). Ну и + система разграничений, чтобы с маршрутами работал только тот локомотив, который ближайшим к изостыку стоит.. Выглядит это так - [url]https://youtu.be/kK0-ocptUM4?t=9[/url]

[QUOTE]составить трёхмерную таблицу, в которой упорядочиваются зависимости сигналов на попутных светофоров[/QUOTE]Почему на всю карту? У меня например одна таблица(код) на любые светофоры, с зависимостью кроме вышеперечисленного от наличествующих в светофорах линз... [url]https://github.com/TRam1990/sU-core/blob/5ca06d3091a616117fe8c859dba0d2b7d67323ff/sU-core/zx_indication.gs#L853[/url]

[QUOTE=TRam_;596574]Обход затыков можно внедрять в логику...[/QUOTE]

Можно. Но осторожно. Потому как иногда при поодиночном движении в тупик не хватает пропускной способности тупика. Если в тупике оборачивается два локомотива, то экономится время одной операции на смену кабины. И это ещё не учтены станции стыкования (Я надеюсь, что в МСТСах и проч. научатся секционировать контактную сеть).

[QUOTE=TRam_;596574]...Почему на всю карту? У меня[B][I][U],[/U][/I][/B] например[B][I][U],[/U][/I][/B]... [/QUOTE]

Из расчётов, что на разных картах может применяется разная сигнализация (МПС СССР, ОСЖД и т.д.) или одна и та же, но в разных временнЫх исполнениях. Для каждого варианта своё исполнение таблицы.

[B]Timas[/B], да, для разных "эпох" нужны разные исполнения, взять хотя бы эволюцию сигнала желтый-зелёный. Но опять же - тогда и семафоры с дисками нужно там же описывать. Просто имею в виду, что универсальный алгоритм определения показания светофора для современных нормативов сигнализации уже реализовывался.

[size="1"][color="Silver"]Добавлено через 2 минуты[/color][/size]
[QUOTE]Если в тупике оборачивается два локомотива[/QUOTE]В смысле поочерёдно - тогда решение мной указано выше (проверка свободности тупика при попытках сбора маршрута). Если одновременно (т.е. в тупик загоняется по 2 локомотива) - тут уже сложнее.

[QUOTE=TRam_;596594]
В смысле поочерёдно - тогда решение мной указано выше (проверка свободности тупика при попытках сбора маршрута). Если одновременно (т.е. в тупик загоняется по 2 локомотива) - тут уже сложнее.[/QUOTE]
В принципе, в Timetable Mode Open Rails такое возможно. Вообще, многое из вышеизложенного возможно уже сегодня в OpenRails. Те же шаблоны скриптов, к примеру. Когда один скрипт можно применять хоть ко всем светофорам на маршруте.И симулятор развивается сразу в нескольких направлениях. Например сейчас анонсирован новый формат файлов составов. Кроме рэндомальной сборки будет ещё и инжикация состава по типу: пассажирский, грузовой и т.д. Надеюсь, что кагда-нибудь займутся и базой данных пути. Хотя, пока, создаётся впечатление, что она всех устраивает.

Вот такие функции:
[QUOTE]
Activate_Timing_Trigger() : Активирует таймер.
Check_Timing_Trigger(n) : Проверка триггера. Возвращает TRUE, если таймер "досчитал" до числа [B]n[/B][/QUOTE]
На видео я установил для выходного 45 секунд. Ещё раз прошу прощения за качество. Пока - только так


[YOUTUBE="Таймер на светофоре Open Rails"]Hg5M-ETih_0[/YOUTUBE]

[QUOTE=Сергей1969;601952]В этом Иванцево иногда даже на пустой путь не запускает виртуальный диспетчер...[/QUOTE]
А как по отлаживать сигналку ? Я нашел функцию в sigscr, а как ее отладить, интересно найти ошибку в сигналке.

[QUOTE=roman5;601954]А как по отлаживать сигналку ? Я нашел функцию в sigscr, а как ее отладить, интересно найти ошибку в сигналке.[/QUOTE]
Какая функция?

[QUOTE=КЕ;601956]Какая функция?[/QUOTE]
Например, входной Иванцево со стороны Драчеево. Вот этот сигнал задан этой функцией APK_4AB_YR_GY_I_Kv в sigcfg.dat - состоит из (APK_3AB_YGR_YW_DISTANCE, APK_INFO_CLEAR_2, APK_ALSN_KZ_0_B_0, APK_ALSN_KZ_20_B_20, APK_3AB_YGR_YW_ALSN_Z_40_B_40, APK_3AB_YGR_YW_ALSN_Z_60_B_60, APK_4AB_YRG_YW_ALSN_Zel_B_Z, APK_4AB_YR_GY_Kv ) - скрипты описаны в sigscr.dat в скобках перечисленные.
В одном из сценариев этот сигнал не пускает на главный путь пока на боковом стоит пригород. Какой надо смотреть из скриптов в скобках и есть ли возможность отладить скрипт в игре, то есть добавить в него логи или отладчиком как-нибудь туда залезть и найти ошибку.

Возможно, надо попробовать переустановить этот светофор в RE. Или даже их все на станции.
Иногда это помогало с зависаниями сигналки.
А так только сам Алексей Фёдоров [B]APK LVDZ[/B] сможет разобраться, в его сигнализации слишком много зависимостей.