По БМО, у меня нет 1.8 (и не хочу :D ), так что, помощник в маршруте я - никакой.

Интересно, всё-таки, с "запоминалкой" для MSTS. Если попробовать заявить две переменные, скажем, m и n . Вначале поставить безусловное равенство m = n ;, а дальше - if (условие) { n = 1;} else (другое условие) { n = 0; }, m будет "помнить" значение n когда ни одно из условий не выполняется?

[QUOTE=vicente;602419]m будет "помнить" значение n когда ни одно из условий не [/QUOTE]
Да, ведь присваивание до [B]if[/B].
[CODE]
float m;float n;
m=5;
n=5;

// далее какой код, меняющий n

// тут m по прежнему 5

[/CODE]
Я правильно понял вопрос ?

[size="1"][color="Silver"]Добавлено через 4 минуты[/color][/size]
[QUOTE=vicente;602419]По БМО, у меня нет 1.8 (и не хочу :D )[/QUOTE]
Эхх, а я хотел узнать, как бороться с нежеланием симулятора прокладывать маршрут по узлам иногда. С сигналкой я понимаю как, я начинаю смотреть скрипт, чтобы понять почему так работает. А вот как бороться с внутренним алгоритмом прокладки маршрута не знаю.

Да. Совершенно точно.
Проблема в том, что в обычном С/С++ - всё ясно. А здесь - нужно проверять.
Я, когда тестил оппозиты, на одном из тестов не получил вполне ожидаемый результат. Причина - до if у меня 2 строки "наоборот" стояли: сначала я снимал данные со светофора, а потом - определял этот светофор. Повторюсь: скрипт - статический. Я боюсь, что не сработает это постоянное присваивание m значения n "из-под" if. Именно из-за программы.

[size="1"][color="Silver"]Добавлено через 8 минут[/color][/size]
Хотя... нет. Немного не так. Вопрос был:
[QUOTE]
(...)
float m;
float n;
(...)

m = n;
if (block_state () !=# 0)
{
state = 1;
n = 1;
}
else if (next_sig_lr (SigFn_NORMAL) ==# 1)
{
state = 3;
n = 0;
}
else
{
state = 7;
}
[/QUOTE]
Когда не выполняется ни if, ни else if, будет ли m в последнем значении n?

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
Особое замечание по отступам: [B]с телефона их съедает сайт[/B], а мне недосуг рисовать. Так что... с Вами наши извинения :D

[QUOTE=vicente;602422]
Когда не выполняется ни if, ни else if, будет ли m в последнем значении n?
[/QUOTE]
В m будет то значение, которое в нее сохранили последний раз, оно не изменится, если позже поменяешь значение n. У нас тут нету ни ссылок, ни указателей, обычные переменные, в которые "по значению" сохраняются.

Кстати еще по стилю скриптов, вместо цифр 0,1,2 стоит писать зарезервированные константы, то есть тут:
[B]if( block_state() != #0)[/B] пишем вместо 0 константу [B]Block_clear[/B]. По поводу [B]state[/B] тоже самое.
А то такой скрипт читаешь и нужно лезть в документацию, вспоминать в каком порядке там идут эти константы.

Кстати а чему изначально тут [B](...)[/B] эти переменные заданы. Они ведь там инициализируются ? Спрашиваю, чтобы понимать смысл сохранения перед [B]if[/B].

Это я так коряво пытался обозначить, что там пропущееы заявления и это кусок скрипта (и так понятно, да, больше не буду... ;)

Кто-нибудь из вас может проверить эту байду в MSTS? Позязя...

[size="1"][color="Silver"]Добавлено через 42 минуты[/color][/size]
А я, для себя, "как только, так и сразу" проверю в Open Rails. Если будет запоминать - возможно, это решит мою проблему с таймерами при загрузке игры

[QUOTE=vicente;602419]... Если попробовать заявить две переменные, скажем, m и n . Вначале поставить безусловное равенство m = n ;, а дальше - if (условие) { n = 1;} else (другое условие) { n = 0; }, m будет "помнить" значение n когда ни одно из условий не выполняется?[/QUOTE]


А потом, обновляя аспекты, сим "пройдёт" по скрипту, и всё снова сбросится!:mad:
Но проверить сейчас не могу...
[QUOTE=roman5;602425]Кстати еще по стилю скриптов, вместо цифр 0,1,2 стоит писать зарезервированные константы, то есть тут:
[B]if( block_state() != #0)[/B] пишем вместо 0 константу [B]Block_clear[/B][/QUOTE]
Так - и писали всегда. Цифрами только аспекты.

[QUOTE=КЕ;602429]А потом, обновляя аспекты, сим "пройдёт" по скрипту, и всё снова сбросится!:mad:
Но проверить сейчас не могу...[/QUOTE]
Обнуляться-то почему? "Заява" идёт без присвоения значения. В этом - суть.
float n;
а не
float n = 0;

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

[QUOTE=vicente;602431]Обнуляться-то почему? "Заява" идёт без присвоения значения. В этом - суть.
float n;
а не
float n = 0;[/QUOTE]
Без присвоения ? Там ведь либо 0, либо что попало (в с++ компиляторы работают по разному: одни 0 по умолчанию ставят, другие ничего не делают). Что ты пытаешься в m закинуть из n, если в n даже не задал ничего.

[QUOTE=КЕ;602432]Было у меня что-то подобное, тоже такая переменная - не соххранялась.
Но проверим потом, конечно.[/QUOTE]
Повторение, мать его. В Open Rails [B]не запоминает[/B]. Как я его не "крутил". И в начало ставил, и в "хвост" и под ифами присваивал значение m = n. Задавал начальные значения (0, 5...). Фигос. Только заходит под if, где нет условия - все переменные - в 0.

[size="1"][color="Silver"]Добавлено через 3 минуты[/color][/size]
А, вот, таймер во время загрузки, похоже, отключить удастся. Один из тестов - получилось. Уже совсем перед сном. О полном успехе говорить рано, но похоже не только удастся отключить внешний триггер Open Rails, но и привязать к этому и мои новые таймеры, которые здесь публиковал.

Что за внешний триггер?
И похоже, что переменная принимает нулевое значение при ее объявлении, и что это происходит каждый раз при "проходе" скрипта.

[QUOTE=КЕ;602441]Что за внешний триггер? [/QUOTE]
[QUOTE]
Сигнальные функции:

[B]Activate_Timing_Trigger[/B] (): активирует триггер по времени.

[B]Check_Timing_Trigger[/B] (n): проверяет триггер по времени и возвращает истину, если он был установлен более n секунд назад.

Эти две функции позволяют выполнять действия с сигналами, запускаемые по времени, например фиксированная задержка по времени при открытии светофора и т. д.
[/QUOTE]
Я на проходных испоьзую их для "оттяжки" на несколько секунд момента [B]визуального[/B] переключения сигнала с разрешающего на запрещающее показание (см.мои ролики - там это есть), а на светофорах перед стрелками, как я писал раннее, оттягиваю открытие сигнала, имитируя проследлвание изостыков/сч.осей и время требуемое СЦБ на отработку маршрута перед открытием сигнала.

[size="1"][color="Silver"]Добавлено через 57 минут[/color][/size]
[YOUTUBE="https://youtu.be/fHOKLFgCmNU"]fHOKLFgCmNU [/YOUTUBE]

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
Вот она - визуальная "оттяжка" момента переключения проходного с использованием вышеупомянутых функций

И к это пишется - в конфиге, или еще где-то?

На втором видео - иммитация открытия светофора с задержкой из-за работы СЦБ/дежурного:
[YOUTUBE="https://youtu.be/Hg5M-ETih_0"]Hg5M-ETih_0[/YOUTUBE]

[size="1"][color="Silver"]Добавлено через 14 минут[/color][/size]
[QUOTE=КЕ;602454]И к это пишется - в конфиге, или еще где-то?[/QUOTE]
Ничего в конфиге не пишется. В рамке в посте 807 описано: как делать в скрипте. Выбираешь какое-то положение, например, в последнем случае, я включаю триггер этот когда светофор заблокирован, проверку триггера - в условия открытия сигнала. И получается такая "няма":D

[size="1"][color="Silver"]Добавлено через 20 минут[/color][/size]
Проблема с этими триггерами - при загрузке сценария, они вообще не учитываются. То есть, если я поставил [B]
Check_Timing_Trigger*(n) [/B] в условие, оно [B]не будет выполняться[/B] пока игра загружается! То есть, светофор на последнем видео при "просчете" трафиков , стартующих до времени старта игрока, будет закрыт! В простых сценариях, может, это не так существенно - сценаристу нужно просто это учитывать. Там же вся движуха стартует практически вместе с игроком. Но, я ишраю по другому. У меня и в Activity Mode всё расписание проигрывается, а в Timetable Mode - там по умолчанию просчитывается всё расписание с 00:00. Поездная ситуация при старте игрока, скажем, в 7:00 у меня в Timetable была очень печальная. Всё стоит на входных/выходных, куча AI поездов не стартовала и была [S]изгнана сцаными тряпками[/S] выброшена из симуляции. На проходных - спокойней. Там привязан не аспект, а показание. В смысле, то, что ты видешь на видео - зелёный остаётся, на самом деле светофор, как только нос ездючины поравнялся с ним, сразу же становится STOP , при этом зелёный свет горит ещё 5 секунд.

[size="1"][color="Silver"]Добавлено через 14 минут[/color][/size]
Вторая проблема, для меня, во всяком случае - таймер этот можно использовать только единожды в сигнальной голове. Он один. В коде самой игры есть clock , он себе бежит, первой функцией мы просто включаем секундомер и таймер считает "с того момента". Я не могу его дважды стартовать- второй старт собъёт мне условие первого. То есть, оба "таймера" включатся. Возможно, теоретически, можно поставить в двух условиях, но эти условия должны "не соприкасаться," друг с другом. Мне лично, это не подходит. Да, и не могу себе представить, что кому-то где-то удастся так разделить работу сигнальной головы.

[size="1"][color="Silver"]Добавлено через 44 минуты[/color][/size]
А, хочется "няшности"! :o Чтобы и то, что на первом видео и на втором, работало [B]на одном светофоре[/B]! Касаемо входных, у меня стоит 45 секунд, плюс - каждый маневровый имеет свой триггер не 15 секунд (в нынешней версии, грядёт коренная переделка всей логики - все Main-светофоры будут работать по-другому), получается на входном - минута, 1:15 и т.д. - зависит от количества маневровых на пути сервиса и положения стрелок.выходные - 20 секунд (я уже писал, что в идеале - сделать "птички" в настройках светофора с разным временем, но где взять время на всё это?). К этому всему нужно "присобачить" delay на смене показания, когда ездючина проезжает маркер... Вот здесь и пригодится тот "таймер" внутри скрипта, что ч на днях здесь написал "онлайн" :p Причём, "моих" таймеров можно пихать в скрипт сколько угодно. :russian:

Константин, а ты не пробовал "впаривать" USER5, USER6 и так далее? Вы не проверяли это дело с Игорем, случайно?