Прежде всего, хочу поблагодарить всех, кто описывается здесь. Это очень важно для меня.
По пропаданию кодов и возобновлению их на некодируемых путях станций, я спрашивал несколько месяцев назад, получил такой ответ, поэтому сделал так, как сделал.
Теперь - технические моменты.
Open Rails был задуман в своё время как новая платформа для старичка MSTS , в которой вместо MSTS Bin- ов расширение возможностей будет реализовываться на совсем другой основе. В то же время, совместимость с MSTS (светофоры, сценарии и подвижной состав, который ездит в MSTS , должен ездить и работать в Open Rails) была продекларирована с самого начала проекта и до сих пор разработчики стараются это дело соблюдать. И если, после какого-то обновления, какой-то маршрут "родом из MSTS" работает по той или иной причине неадекватно, в теме по багам разрабам пишется предъява и она на полном серьёзе разбирается и фиксится.
Но это - "их нравы", как говорится. Мы, как водится, "пошли другим путём" и (совершенно резонно на тот момент) создали шаблон светофоров, основываясь на некоем упущении, недосмотре разработчиков MSTS и взяли за основу запрещающий аспект, который в оригинале был разрешающим. Я не буду повторять всей предыстории, почему вообще такое стало возможным, я десятки раз это разъяснял. В том числе (и в основном) на этом форуме. Но, этот самый аспект в MSTS и в первых версиях Open Rails не только останавливал поезда AI , но и взаимодействовал с механизмом блокировки (Deadlock) обоих симуляторов. После глобального обновления одной из версий 0.9, это дело "прикрыли". С точки зрения команды Open Rails , это было "закрытие старого бага MSTS , а мы... остались с тем, что имели. Так получилось. И когда пользователи у нас говорят: "сигнализации не работают в Open Rails", они имеют в виду прежде всего это.
Это было очень краткое объяснение для тех, кто не в теме. Если кому интересно, ищите мои сообщенияв этой теме, в теме по сигнализациям MSTS на этом форуме и в других темах.
Реагировать на то обновление принципа организации движения поездов в симуляторе можно было по-разному. Так это и произошло в действительности. Неудовлетворительная работа сигнализаций не прибавила поклонников Open Rails у нас. Наоборот. Многие "плюнули" на это дело и пошли в другие игрушки, где всё "в шоколаде". Я же, прочитав тогда переписку разработчика этого сайта APK_LVDZ с командой Open Rails , понял, что ради нас они ничего менять в концепции не будут и решил "перекроить" свою собственную сигнализацию под новые реалии и на сегодняшний момент получаю удовольствие от Open Rails без никаких оговорок.
На самом деле, чтобы все маршруты, существующие у нас для MSTS "заиграли" в Open Rails , нужно патчить во-первых, саму сигнализацию на маршруте, а во вторых, тяговый подвижной состав на предмет соответствия сигналов кабины. Так как подвижной состав, по-любому, нужно патчить (новые возможности, правка отображения, звуки и т.д.), я пробую заодно для этого патча изменить принцип получения сигнала АЛСН в кабине, попутно прикрутив к нему фишки, которые в MSTS вообще не вставали на повестку дня. Раздельная смена показаний, задержка реакции АЛСН на смену сигнала, объединение аспектов, новые показания (выкл, красн), проезд запрещающего (иди - пропиши это в MSTS или в Open Rails с MSTS-овским дисплеем кабины. Эта самая потеря кода, которую я показал - это попытка сделать что-то похожее, не абсолютное, как уже было сказано, что будет работать на уже существующих сигнализациях (пропатченых или нет - не важно) в случае, если пропатченый локомотив, с прописанным в нем TCS script-ом (можно патчить и без TCS - будет работать с обычным дсплеем кабины, как в MSTS) попадёт на маршрут с такой сигнализацией.
Добавлено через 46 минут
Последние несколько страниц я говорю об изменении принципа "снятия" кодов локомотивом, относительно старой MSTS-овской системы. Пример её, этой системы, я приводил раннее уже в
этом сообщении. Разница в подходах - в старом способе локомотивный светофор "тупо" показывает то, что в раскладке текстуры АЛСН соответствует аспекту NORMAL головы следующего сигнала. Смена показаний локомотивного происходит моментально при изменении аспекта следующего по ходу сигнала. Никакой технической возможности, при этом, для таких вещей, которые я показываю сейчас при той системе быть не может. В см
ысле, см.последние видео: в жизни никогда на следующий APPROACH_2 АЛСН не покажет в одном случае- жёлтый (перед входным), а в другом - белый (перед выходным), а на APPROACH_1 (первый проходной) - в одном случае- белый, а в другом - жёлтый
Добавлено через 10 минут
Само собой разумеется, возможности "сделать так, как хочется" ограничены. Поэтому, например, то что вы видите с белым - не более, чем работа таймеров. Потому "настроить до входных стрелок" - всего лишь увеличить время в таймере, а сделать "после выходных" - наоборот- сократить. Другое дело, что эта фигня работает одинаково на всех станциях. На последнем видео - станция маленькая, до первой стрелки - меньше 50 метров. Допустим, я настрою этот таймер точно. Что будет на больших станциях? А при меньших или больших скоростях? С другой стороны, старые маршруты своими сигнализациями потерю кодов вообще не предусматривают. Я могу сделать как в старых вариантах: на RESTRICTING давать белый и т.д.
Возможно, так и нужно делать. Есть, ведь сигналки, в которых так и задумано. Но, тогда, например, открыти маневрового выходного изменит показание локомотивного с кж на б
Добавлено через 5 минут
Короче, я понял. Действую. Возможно, уберу вообще эту потерю кода, она доставляет мне немало хлопот в коде.
Хочу поскорее закончить с NORMAL-ами и писать другую логику