Сигнализация
 

В этой теме будут обсуждаться вопросы по сигнализациям в [B]Open Rails[/B].

[size="1"][color="Silver"]Добавлено через 8 минут[/color][/size]
Отныне, обсуждения сигнализаций для MSTS и Open Rails не будут переплетаться в теме в разделе MSTS , в Open Rails на сегодняшний момент уже достаточно отличий в работе программ, в том числе - по сигнализациям. Завтрашний день готовит нам дальнейший "уход" Open Rails от MSTS , возможность написания логики светофоров в С# и пр. Так что, кто отличает block_state () от TRAINHASCALLON_RESTRICTED() - дальнейшее обсуждение специфики Open Rails будем вести здесь и не бередить моск MSTS -овцам и ругаться незнакомыми словами.

Тогда надо тему переименовать в "Сигнализация ORTS".
Если там пойдут скрипты на C# - придется его изучать!:confused:
С чего начать-то?

Костя, тема в разделе Open Rails, понятно, что речь идёт об этом симуляторе. Так же, как и соответствующая тема в разделе MSTS не имеет этого уточнения. ИМХО.

Я начал с самоучителя в интернете. Идёт тяжело - я уже не мальчик, который "схватывает на лету", да и время - фактор немаловажный в этом вопросе - у меня его не много. Но, из того, что я понял на форуме у них, плюс к этому - самые азы синтаксиса, лично мне С# в ближайшее время "не грозит" - довольно скудный функционал (пока) при большом геморрое - скрипты в С# не обращаются к сигнальному объекту "напрямую", а через идентификацию (как в sigscr.dat обращаются к id_sig_XX(sigid). Более того, я просматриваю некие уже написанные скрипты для испанской TCS - способ передачи информации там - что-то типа логики сигнализации АРК для MSTS - обходные пути. Тем не менее, файл CsSignalScript.sc, в котором находится весь функционал С# скриптованной головы, верю, будет расширяться и пополняться. Возможно, со временем, он (функционал) меня заинтересует настолько, что я буду вынужден пойти туда. Речь, конечно, прежде всего, о маневровом, который должен зависеть от предыдущего входного для отделения маневрового режима от поездного. Но, есть и ещё, как я писал в параллельной теме, задачи, удовлетворительного решения которым, существующей логикой sigscr.dat я найти не могу. Маневровые светофоры на сегодняшний день у меня имеют всего один недостаток (но очень серьёзный): из-за поездной ситуации и положения стрелок "перед" сигналом, они могут ловить с оппозита переменную с перегона, которая ставит сигнальную голову поездной режим. Но, это - не только и не столько. У меня для sigscr.dat нет удовлетворительного решения на случай проезда красного (поавда есть идея прописать этот проезд в *.cvf, нарисовать текстуру АЛСН-светофора с красным и "закрыть" ею существующую, не знаю: насколько это возможно в 2d кабине, так что это - из области фантастики). Ещё одна проблема - потеря кодов на некодируемых путях (сегодня реализовано довольно топорно, не до выхода на перегон и не совсем, как в реале, а только там, "где это возможно"), и особенно - ПАБ - там просто тёмный лес. Заставить светофор аспектом, дающим белый на АЛСН остановить поезд невозможно, ставить дополнительный маркер перед основным светофором - путь в прошлое - поезда будут с платформ "подтягиваться" к закрытым сигналам, как в MSTS . С# сигнальный скрипт (в комплекте с TCS C# скриптом), возможно, решит эти проблемы для поезда игрока. Но мне нужна полноценная сигнализация и для трафика, с тем же количеством вариантов показаний и режимов, таймеров и гаснущих проходных светофоров, которые я имею сейчас на логике sigscr.dat

[quote]
Заставить светофор аспектом, дающим белый на АЛСН остановить поезд невозможно,... [/quote]
То есть если на аспект RESTRICTING прописать 0 км/ч - не получится? Я вроде тестировал, но результата не помню. Надо будет еще раз проверить.
С остальными показаниями для ПАБ проще - сигнальная точка из одной головы DISTANCE и нескольких NORMAL, каждая из которых имеет 2 аспекта - 0 и 2, и свою скорость - "открывается" при соответствующем DISTANCE-коде в РЦ. И регулирует скорость сервисов.
[quote] Ещё одна проблема - потеря кодов на некодируемых путях (сегодня реализовано довольно топорно, не до выхода на перегон и не совсем, как в реале, а только там, "где это возможно")[/quote]
Есть такое дело, уже просили это сделать в моей сигналке, думаю...

Теперь по существу.
"Петлю" которую я сделал [S]через танцы с бубнами[/S] [URL="http://www.trainsim.ru/forum/showpost.php?p=602397&postcount=782"]здесь[/URL] нужно [S]придрочиться[/S] использовать очень осторожно. "Считалка" работает, но работает очень не стабильно, с разной скоростью при разных условиях. Я не могу понять от чего именно она зависит с точки зрения маршрута. То есть, понятно, что её скорость зависит от скорости "прогона" программы, но вот, отчего зависит сам "прогон" - я не пойму. На маленьком двухтайловом тестовом маршруте оно у меня "летает": чтобы получить 20 секунд я устанавливал 400. О своём "тяжелом" маршруте я писал в приведенном мной сейчас посте. Разница может быть в ФПС, количестве светофоров "на тайл", в общем количестве светофоров - я не могу знать. Кроме того, оно раз на раз срабатывает, или не срабатывает, или частично срабатывает и во время загрузки. Я пихаю его сейчас в качестве "компенсатора" timing trigger, который 100% не учитывается при загрузке игры. Логика такая: проверяю check_timing_trigger (1 секунда). Если результата нет - триггер не работает, значит игра загружается - обход условия. Если есть результат - игра идёт. Логическим элементом "и" добавляю к этому check_timing_trigger (нужное количество секунд для задержки открытия светофора) в условие (if) и получаю желаемый обход триггера при загрузке игры. Далее проблема заключается в том, что если в зависимость поставить только это - в эту самую первую секунду отсчёта триггера, сигнал открывается и сразу же перекрывается обратно. Но, и игрок и трафик в этот момент ловят ok to proceed ... и трафик поехал к светофору. Потому, чтобы задержать светофор в запрещающем аспекте эту самую секунду, пока не будет "взведен" триггер, я пихаю в условие через "или" эту [S]порнографию[/S] свою петлю. Но, она тоже глючит при загрузке (на тестовом я сделал аналог for - 2 условия: начальное и конечное, поднимая значение с 0 до 7 - из-за табло, чтобы видеть, так, как в примере - "улетает" [S]нахрен[/S] вверх или вниз, я и так и так "крутил... так вот, на тестовом при начале игры стоит AI перед сигналом, а переменная эта добежала с нуля до 5 и держится, а уже в игре доходит до своих 7). Потому сделал ей "контр-петлю", которая вообще не обнуляется - игра пошла - она 7 и всё. В условие её через "и" к первой петле, как "противовес". Смысл - расчет на то, что одинаковые петли и глючить будут одинаково. Есть глюк - контр-петля не дошла до семи - условие обходится и светофор (невидимо при загрузке) переключается, нет глюка - не страшно - оба условия выполняются и светофор будет открыт с задержкой в 7 "тактов". Сейчас тестирую загрузки Timetable в разных точках с этим механизмом - вроде, все тестовые светофоры не "заклинивает".

[size="1"][color="Silver"]Добавлено через 50 минут[/color][/size]
[QUOTE=КЕ;602570]То есть если на аспект RESTRICTING прописать 0 км/ч - не получится? Я вроде тестировал, но результата не помню. Надо будет еще раз проверить.
С остальными показаниями для ПАБ проще - сигнальная точка из одной головы DISTANCE и нескольких NORMAL, каждая из которых имеет 2 аспекта - 0 и 2, и свою скорость - "открывается" при соответствующем DISTANCE-коде в РЦ. И регулирует скорость сервисов.[/QUOTE]
Попробуй. STOP_AND_PROCEED не "держит" с 0. Но с RESTRICTING может быть исключение, "унаследованное" каким-либо образом из MSTS - если разрабы не разобрались или упустили момент что в MSTS только этот аспект заставлял AI слушаться speedkph в конфигурации. Но, с моей точки зрения, проблема не только и не столько в наличии или отсутствии остановки, а в том, что в MSTS AI не только останавливался на STOP_AND_PROCEED со скоростью 0, такой сигнал там блокировался Deadlock -ом. Чего в Open Rails не происходит. Даже если случится чудо и RESTRICTING будет останавливать AI, будет ли поездная ситуация разруливаться Deadlock на такой сигнал?

Олег, а где есть описание, как вообще [B]Deadlock[/B] работает?

Здрямс
Я описывал его 18 раз. Последний раз, помнится, га прошлой неделе в теме в разделе MSTS . До этого - в той же теме и у Игоря. Ищи. Есть объяснение и в Мануале. Там просто всё. Но, при написании сигнализации, естественно, нужно знать, что это... А то можно прописать так, что с одной стороны поезд будет стоять из-за Deadlock , а с другой - из-за скрипта. И нихрена никому не откроется.

Положу сюда, под спойлер пример С# скрипта готового сигнала. Понимаю его, пока, только интуитивно, может, в общих чертах. " Учиться, учиться и учиться " (Гриб)
[SPOILER]
using System.Collections.Generic; namespace ORTS.Scripting.Script{ public class BAPR_AR60VL : SignalScript { public BAPR_AR60VL() { } public override void Update() { List<string> nextNormalParts = NextNormalSignalTextAspects; if (AnnounceByA(nextNormalParts, true, false)) { MstsSignalAspect = Aspect.Approach_1; TextSignalAspect = "FR_A"; } else if (AnnounceByRCLI(nextNormalParts)) { MstsSignalAspect = Aspect.Approach_3; TextSignalAspect = "FR_RCLI"; } else { MstsSignalAspect = Aspect.Clear_1; TextSignalAspect = "FR_VL_INF"; } DrawState = DefaultDrawState(MstsSignalAspect); } }}
[/SPOILER]

Протестил в сценарии - RESTRICTING не останавливает сервисы, если в конфиге указана скорость 0 км/ч. Трафик пролетает сигнал со скоростью, установленной ограничениями на участке. То есть получается, что скорость как бы и не задана.
Я проехал светофор и встал за ним метрах в 70. Трафик проехал сигнал RES и остановился метрах в 10 от моего хвоста. То есть происходит то же, что и на S.A.P.
Попробовал задать 10км/ч - траф послушно полз с этой скоростью до следующего светофора ([COLOR="DarkOrange"]Ж[/COLOR], 60 км/ч). Который прошёл всеми вагонами и стал разгоняться.

Сделай то же самое , только задай 20 км/ч. И посмотри на трафик

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
:D

[size="1"][color="Silver"]Добавлено через 7 минут[/color][/size]
Потом можешь 60 поставить. И следи: как AI проезжает сигнал ;)

[size="1"][color="Silver"]Добавлено через 13 минут[/color][/size]
И... да! В Open Rails STOP_AND_PROCEED и RESTRICTING вытаскивают ездючину из режима Auto Signal и запихивают её в режим Auto Node - движение "по "нодам" - секциям пути

Ну да, траф проезжает сигнал и останавливается у самой стрелки, ждя, пока я уеду за следующий светофор.

Дай ему волю! Стартуй его чуть позже и поставь на RESTRICTING скорость побольше ;)

Стартую с главного пути, трафик с бокового через 2 мин. После выходного светофора разгоняется, выходит на гл. путь, проезжает проходной сигнал RES и тормозит около меня. Я уезжаю - ждёт, когда уйду за след. сигнал, и всё повторяется. Все светофоры с аспектом RES ("заклинил реле в шкафах;)")

Не сбрасывает скорость при проезде сигнала? :eek:

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
По идее, он должен "сяпать" за тобой даже без сигнала. Как только ты отдалишься на какое-то расстояние. У меня в депо так вся "канава" двигается

На светофоре разгоняется. А потом тормозит.
В одном из тестов стартовали с разных путей, на выходных - RESTRICTING. Я останавливался в начале перегона, он "догонял" меня, а потом я уходил дальше. Через километр стоит проходной (APPROACH_2 или CLEAR_1) - пока я не проехал всеми вагонами этот проходной, трафик стоял и ждал.
Ну в общем, понятно.
[U]Выводы[/U]:
1. RES в качестве запрещающего (для ПАБ) не годится, остановка только STOP-ом.
2. Если в [B]sigcfg[/B] на аспект RESTRICTING указана скорость 0 км/ч - сервис презжает сигнал со скоростью, установленной для всего маршрута в [B]*.trk[/B], или местными путевыми ограничителями скорости.
3. При проходе сигнала с ограничением скорости, указанным в [I]sigcfg[/I] на аспект RESTRICTING, трафик будет ехать с этой скоростью до следующего светофора. Далее скорость регулируется значениями в аспектах и путевыми ограничениями. Трафик увеличивает скорость после прохода сигнала всеми вагонами.
4. Если на выходном светофоре самый запрещающий сигнал - RESTRICTING, трафик проезжает его и останавливается у первой (пошерстной) стрелки.

Я рассказывал когда-то о сигнальных головах типа SPEED (вообще, надо будет потихоньку дублировать сюда релевантные сообщения из MSTS овской темы - там очень много букафф, переписывать ой-как не хочется, а инфа может быть ценной). Я [S]естественно рано[/S], было обрадовался: мол вертел я теперь всю логику [S]на[/S]... Прикручу это дело дополнительными головами к NORMAL-ам и буду в шоколаде. Но, хрен там: если я устанавливаю скорость 0 на этот SPEED - AI пролетает светофор с установленной. Причём, не важно, какой там аспект - даже 0! Но, со SPEED -ами придётся ещё разбираться: что с ними можно делать, а чего нельзя. Когда я думаю о новой логике, этим головам готовится не последняя роль..

Теперь так. Я хочу поднять тему, к которой я правдами-неправдами подбиваю сообщество уже не первый год.
[S]Танцы с бубнами[/S] Выкрутасы со скриптами и подбивка функционала под наши реалии - дело хорошее и, можно сказать, "вечное". Что по аспектам? Костя, ты в команде, [S]сорока мне нашептала[/S] я так понял, что дальнейшее развитие симулятора решено делать ставку на Open Rails. Не пора ли определиться с аспектами? Мне ещё больше 5 лет назад стало ясно что [S]разработчикам насрать[/S] никто под нас запрещающий аспект подбивать не будет. Скажу больше. Сам движок вообще стараются не беспокоить, дабы не сломать то, что работает. Я решил расслабиться и получать удовольствие от того, что есть и быстро "перебил" аспекты. Но, одно дело - работает у Дяди Олега, другое - выпускать разработки под ОР без внятной сигналки.
Несмотря на то, что я думаю, что будущее за TCS scripts и C# scripts в сигналке, проблему это не снимает. Текстовых аспектов в C# scripts может быть сколько угодно, но, в обозримом будущем, пока европейским TCS-летунам будет хватать для построения движения свободности блока и аспекта следующего по ходу поезда сигнала (маневры и всё остальное на занятый путь они решают через функцию CALLON), система, гоняющая ездючина по трекам не изменится! NORMAL-аспектов как было, так и останется 8. Трафики останавливал и будет останавливать только STOP . Так, может, уже пришло время [S]двигать задницей[/S] пересмотреть это дело и выбрать для Open Rails свою собственную "систему координат"?

[quote] Костя, ты в команде, сорока мне нашептала я так понял, что дальнейшее развитие симулятора решено делать ставку на Open Rails[/quote]
Это да. МСТС уже вообще не запускается на игровых видеокартах, только на встроенной графике. А там ФПС ниже УГР.))
А по аспектам - собираюсь пробовать в тестах и понять, как лучше использовать эти STOP, S. A. P. и RESTRICTING.
Я так понял, что определимся с аспектами, и соответственно определим, кок делать локомотивный именно для ORTS.

Думайте. Время есть ;) :D

[QUOTE=КЕ;602636]
Это да. МСТС уже вообще не запускается на игровых видеокартах, только на встроенной графике. А там ФПС ниже УГР.)) [/QUOTE]
Ну, люди играют. Тема по сценариям MSTS жива. Значит, разработки должны продолжать работать и в MSTS;)
[QUOTE=КЕ;602636]
А по аспектам - собираюсь пробовать в тестах и понять, как лучше использовать эти STOP, S. A. P. и RESTRICTING.
Я так понял, что определимся с аспектами, и соответственно определим, как делать локомотивный именно для ORTS.[/QUOTE]
По MSTS-овскому интерфейсу большого выбора нет. ИМХО, 0 и 1 - к/ж, 2 - Б, 3,4 и 5 - Ж, и 6 и 7 - З. А какие ещё варианты?

Была задумка попробовать как рабочий аспект - STOP, а для [B]!enabled[/B] - S. A. P.

Смысл?

[size="1"][color="Silver"]Добавлено через 9 минут[/color][/size]
STOP_AND_PROCEED сейчас у меня остался только на маневровых и невидимых обратно-направленных головах на выходных. Он даёт к/ж или к/ж когда выходной красный. В принципе, есть способ проехать STOP , добавив в шейп сигнала голову типа SPEED , я думал сделать так, а STOP_AND_PROCEED ставить на маркер за светофорами и давать на него К если проезд красного, но передумал. Вреда от этого больше, чем пользы. Во-первых, сами маркеры надо ставить за каждым светофором, во-вторых, я теряю маневровый, так как скорость 0 не останавливает ничего даже на STOP . Придётся ставить дополнительный маркер на маневровый, а это - перебор. С другой стороны, STOP_AND_PROCEED как к/ж даёт нам к/ж на белый выходной и на пригласительный - я так понимаю, в реале именно так оно работает.

Привет. Предыстория: скрещение путей А и Б. По пути Б проходит поезд.

Вопросы:
1. Горят ли красные светофоры на пути А в обе стороны в пределах одного блок-участка (желтые в пределах двух)? Ведь занятости пути как таковой нет, поезд быстро проходит по скрещению и все. Но при этом, очевидно, надо как-то это регулировать.
2. Если таки горят, то КАК это реализовано? Ведь поезд, идущий по скрещению, находится не на пути А и не замыкает цепь. Возможно, вручную диспетчер устанавливает?

Прикладываю видео (с привязкой по времени). Там, кстати, слышно, как диспетчер предупреждает машиниста электрона о скрещении с пассажирским поездом.

[url]https://youtu.be/QkeP5Ve1ZEk?t=388[/url]

Если вопрос по работе сигналки в симуляторах, то:
В MSTS и RTS сигналы открыты по обоим направлениям.
В ORTS сигнал открыт тому, у кого приоритет (обычно игрок).

"Дабл-слип" - ещё тот геморрой! Хотя, я давно не проверял это дело в Open Rails . Возможно, разрабы пофиксили. Но, ещё в стабильной, если не ошибыюсь, не работало. Дело в том, что трек в симуляторе может иметь только три направления: эдакое Y... То есть, стрелки, которые мы видим на видео, с точки зрения Базы Данных Путей - это 4 "точки пути", по-простому - стрелки. Поэтому симулятор может спокойно построить маршруты крест-на-крест или по касательной на одной и той же стрелке. Потому что не может быть блокировки (deadlock) там, где нет точки пути. Естественно, светофоры могут быть открыты по этим направлениям. Кстати, эта проблема была и в MSTS и являлась причиной внезапных вылетов с сообщением "...car derailed" даже, когда поезд игрока стоял и не двигался никуда.
Почему я давно не проверял? Потому что эту проблему решали ещё в MSTS т.н. "ложными кроссоверами" - искуственными точками пути, которые прописывались [S]через такую жопу, что вам и не снилось[/S] посредством хитрости, колдовства и танцев с бубнами.

[QUOTE=vicente;602725]... искуственными точками пути, которые прописывались посредством хитрости, колдовства и танцев с бубнами.[/QUOTE]
Насколько надёжно работало?

100%. Сим видит это как стрелку. И блокирует, естесссно

[size="1"][color="Silver"]Добавлено через 2 минуты[/color][/size]
Что значит: "работало"? До сих пор работает без нареканий

Из темы о реальной сигнализации, а также из того, что помню сам, я понимаю, что
1. Локомотивный светофор имеет 7 показаний: з, ж, к/ж, к, б, к/ж+б и не горит при переключении на манёвры.
2. Также нужны два TwoState переключателя для сброса к/ж и к.
3. Станционные пути не кодируются, кроме главных, за исключением крупных станций (могет быть).
4. Маневры не влияют на кодировку. Если путь кодируется - коды идут.
5. В дополнение ко всему переключение локомотивного "ввех" происходит с задержкой в 6 сек, "вниз", насколько я помню, тоже секунду-другую нужно оттягивать.
6... А... ещё свисток УКБМ и "мигалка"...

Что-то не назвал?

Кстати, у нас подвижной состав "с основных сайтов" чем оборудован? Я просто себе только старые локи качаю, с АЛСН, да и то не все. Чехов, например, последних с дауна ещё не качал и не знаю когда. На КЛУБ, например, есть текстуры вменяемые?

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
Какие ещё системы есть? Или могут быть.

Костя, ты тестировал тупики на все типы сигнальных голов? Все STOP , как и положено, или есть сюрпризы?

Олег, не помню. Но все равно буду заново тестить. Ты говоришь про осигналивание у тупиковой призмы?

Если поставить табло аспектов перед тупиком, Dv и Dn тоже будут "0", так ведь?

Проверю - отпишусь.

Руки чешутся снова [S]наступить на те же грабли[/S] дать на STOP белый на АЛСН из-за тупиков.

Отбой по тупикам. [S]Ну их в задницу[/S]. Запихну белый в последний [B]else[/B] и будет тупик белый давать как миленький.

Все равно тестить надо - были случаи, когда сим "не видел" сигнал, если до него не доходил [B]path[/B] сервиса.

В смысле, "не видел"? Это ещё почему. Сигнал, на который "не доходит" path сервиса - !enabled - это да. А cabSignalScreen с какого лешего сигнал у себя "перед мордой" не видит?

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
В общем, в том, что я задумал - это не имеет значения. Я буду слать коды, как в реальном АЛСН, не будет кода - будет белый.

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
Потому, например, на некодируемых путях и на ПАБ не важно: какой будет аспект. На АЛСН будет белый

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
Потому что нет трансмиттера - нет кода, а нет кода - белый
:drinks:

Олег, а на RESTRICTING тогда что, тоже белый?
[url=https://ibb.co/rZKXFpq][img]https://i.ibb.co/rZKXFpq/1.jpg[/img][/url]
[U]Вот результатен:[/U]
Слева путь сервиса не доходит до тупикового маркера со [B]state = 2;[/B], на мониторе пути ничего нет.
Справа путь сервиса доходит до тупикового маркера со [B]state = 2;[/B], на мониторе пути красный STOP (???).
Табло показывает RESTRICTING в обоих тестах.
А предыдущий светофор (уже пройден) реагировал правильно - жёлтый в обоих случаях, у него в скрипте:
[B]if ( next_sig_lr (SIGFN_NORMAL) == 2 )
{ state = 4; }[/B]
И да, версия ORTS - последняя, сегодня обновился.

Костя, спасибо за тест.
Ты тестил не совсем то, что я просил, но то, что мне нужно было - тоже в тесте есть!

Монитор пути меня в данном случае не интересует. Он показывал и будет показывать эту самую "путевую обстановку". Но, если ты уже сделал тест, интересует АЛСН в обоих случаях. "Ловит" она этот белый, или не "ловит"?

Нет, из NORMAL ничего уже не выжать. Даже осигналив тупики, как сделал ты, как потерю кода на весь боковой путь сделать? А ПАБ?

[size="1"][color="Silver"]Добавлено через 14 минут[/color][/size]
[QUOTE=КЕ;602931]Олег, а на RESTRICTING тогда что, тоже белый?
[/QUOTE]
Костя, я вообще по-другому пытаюсь всё сделать. Пока рано что-то показывать и рассказывать. Но, если получится, 0 будет Б, 2 будет КЖ, и 0 будет КЖ, а также будет КЖ+Б со сбросом КЖ, а ещё К. Пока что, единственное продвижнние - "отвязал" лок от конвенциональной MSTS овской логики работы CabSignalScreen.

[QUOTE=vicente;602936]... Но, если ты уже сделал тест, интересует АЛСН в обоих случаях. "Ловит" она этот белый, или не "ловит"?[/QUOTE]
Белый - во втором случае, когда [B]path[/B] проходил через тупиковый маркер.
В первом случае локомотивный был зеленый! :confused:Может быть, это раскладка текстуры косячила?...

[size="1"][color="Silver"]Добавлено через 4 минуты[/color][/size]
[quote] Даже осигналив тупики, как сделал ты, как потерю кода на весь боковой путь сделать? А ПАБ?[/quote]
Ставить маркер, который по NORMAL дает RESTRICTING в рельсоую цепь, а аспекты передаются входному светофору через DISTANCE.

[QUOTE=КЕ;602938] Белый - во втором случае, когда [B]path[/B] проходил через тупиковый маркер.
В первом случае локомотивный был зеленый! :confused: [/QUOTE]
Вот это , номер! А я и внимания на это не обращал (ну, это потому что я игроком почти не гоняю, больше трафики разглядываю в расписании). Но, это же полный [S]трындец[/S] бардак! Всё ясно. Надо идти другим путём.
[QUOTE=КЕ;602938]
Может быть, это раскладка текстуры косячила? [/QUOTE]
Да, не думаю. Говорю же: не помню такого. Может быть "молодёжь" из команды разработчиков "поковырялась" в Основном Коде своими ручками. Для чистоты эксперимента, надо бы на Стабильной попробовать. Надо то же самое на stable сделать? У меня, правда, сигналка на Стабильной не работает - там не прописаны новые фишки, которые я применяю. Но, для тупика и версия для MSTS пойдет. Проверю.
[QUOTE=КЕ;602938]
Ставить маркер, который по NORMAL дает RESTRICTING в рельсоую цепь, а аспекты передаются входному светофору через DISTANCE.
[/QUOTE]
Не айс. Пассажирский AI, который стоит на скрещении на станции у платформы, когда пассажиры загрузятся, будет подтягиваться к закрытому светофору и встанет на нём. А мультиплеер? Я с некоторого времени ношу очки для чтения. Но и в очках - попробуй - мышкой попади в нужный маркер. И в Activity и Timetable иногда нужно открыть/перекрыть сигнал.