RailUnion.net

Всем привет.


Предложите технически реализуемый способ холодного/горячего старта локомотива, который можно было бы задать через редактирование сценария (не сценарным скриптом/событием - впрочем, в крайнем случае, это тоже неплохо).

Режимы:

- Холодный старт: остановлен дизель, выключено оборудование, тормозное оборудование в режиме торможения. Из холодного старта в режиме машиниста можно перейти в горячий режим подготовкой локомотива к работе
- Горячий старт: дизель запущен и находится на холостых оборотах, включено основное, необходимое для работы оборудование. Из горячего старта в режиме машиниста можно перейти в режим отстоя - остановить дизель, выключить оборудование и т.п.

Мне видится возможным только один вариант, озвучу его, если буду видеть интерес. Возможно, кто-то в данном вопросе разбирается лучше меня. Итак, нужно локомотивное (либо сценарное) решение, позволяющее выбрать один из двух режимов старта сессии на локомотиве - на локомотиве, готовом к движению, и на холодном локомотиве.

Варианты реализации:

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



Спасибо заранее.

Как по мне, самый правильный вариант реализации - это дефолтное состояние локомотива при запуске сценария и параллельно - задаваемое через сценарий, причем сценарное должно иметь приоритет.
При таком решении игрок может сделать выбор, как он хочет начать сценарий, но последнее слово останется за сценаристом и, если нужно, чтобы игра началась с холодного локомотива, сценарист сможет сделать так, что это случится, независимо от желания игрока.
В этом случае дефолтное состояние может задаваться, например, специальным контролом, который для холодного запуска должен иметь "0", для нормального - "1". Тогда нужно создать 2 конфига, по одному на каждый случай, один будет задавать холодный локомотив на старте, другой - запущенный (этот вариант не очень удобный, есть получше, но сейчас об этом рано говорить). В таком случае сценарный скрипт также будет иметь доступ к начальной установке через этот контрол.
Сценарист же может воздействовать на состояние локомотива, дописав в бортовой номер метку холодного старта - в импортных локомотивах это буква "S".
Скрипт, считывает метку в бортовом номере, если она есть - выбирает холодный старт; если нету - считывает контрол запуска и уже по его значению принимает решение о выборе ветки.
Принцип рабочий относительно любого локомотива - как принадлежащего игроку, так и под управлением AI.

сценарный скрипт

Мне тоже понравился метод, предлагаемый Светой - задание режима через метку в номере.


В каком формате нужно создать для этого локомотивные номера и как сделать символ неотображаемым по аналогии со светофорами?


Сценарный вариант тоже неплох, в конце концов, зная требуемый кусок кода, можно его вставлять в сценарные скрипты. Однако, этот способ, как я понимаю, не работает со Стандартными, Free Roam и Quick Drive сценариями? Что не есть гуд.

i2GR писал(а):сценарный скрипт

А это зачем?

Тоже можно: по умолчанию сделать тепловоз холодным, а сценарным куском кода приводить его в горячее состояние, так как готовый к движению тепловоз обычно и нужен только для стандартного и карьерного сценариев. А в остальных случаях можно и потратить пару минут на раскочегаривание.

Но метода с кодированием состояния в номер универсальнее.

Также возникает последующий вопрос: если локомотив имеет динамические номера (через PrimaryNumbers), можно ли сделать их подсвечиваемыми? Не просто самосветящимися (это как раз нетрудно), а связанными с локомотивной логикой? Я для ТУ7А реализовал подсветку номерных знаков, но с динамическими цифрами, мне кажется, работать не будет, так как метод основан на скрытии/отображении целиком номерной таблички, с "самосветящимся" шейдером для ночного режима - аналогично шкалам приборов с фосфором.

Можно ли аналогично скрывать объекты сцены, используемые для номеров, т.е. эти вот самые мелкие квадратики с цифрами?

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

Ну это немного не то. Это я могу реализовать хоть сейчас, дело нехитрое. Да и процедура запуска в моем случае не столь сложна, чтобы ее сводить на нажатие одной кнопки. Обсуждаемый локомотив и так заводится с двух тумблеров и стартерного ключа.

Я хочу научиться способу переключения этих веток посредством "меню локомотива" в редакторе сценария. И если в ТРС в этом меню есть возможность задать целую прорву опций (от номерных знаков до состояния систем), то интерфейс локомотива в TS имеет просто зачаточное состояние. Хорошо, хоть номер ввести можно. А я бы удавился за возможность задавать (и модифицировать) через него начальные состояния контролов локомотива, которым сделана т.н. "сериализация".

Т.е. мне нужна ситуация, когда в обоих случаях в сцену в редакторе сценариев ставится холодный локомотив (сделано), ему вводится сценарный номер, на конце номера прописывается не отображаемая в игре буква H или C (условно), в результате чего при старте сценария в режиме машиниста локомотив либо остается в холодном состоянии, либо переходит в готовое для движения. В случае трафика логику описывать не буду, о ней говорить рано и получив описаный здесь результат, я уже соображу, как увязать машину с работой в трафике под управлением AI.

Добавлено спустя 21 минуту 34 секунды:

Код: Выделить всё

GetRVNumber
Syntax:   GetRVNumber ()
Function:   Get the rail vehicle's number
Arguments:   N/A
Return:   The rail vehicle number

Если не ошибаюсь, это оно. Вопрос к знающим людям, так как обработкой текста не занимался на практике: как взять из полученного значения конкретный разряд в виде текстовой переменной?

Конкретный разряд(ы) извлекается с помощью функции string.sub ().
Конкретный символ(ы) обнаруживаются с помощью функции string.find ().

Благодарю, исчерпывающе.

Хорошо, хоть номер ввести можно

А больше ничего и не нужно.

я бы удавился за возможность задавать (и модифицировать) через него начальные состояния контролов локомотива

Вариант 1:
Локомотив имеет специальный контрол для сценария. Каждый разряд этого контрола отвечает за свою систему, всего может быть 9 (если немножко заморочиться - 10) состояний каждой системы, количество систем равно количеству разрядов контрола. Если сценарий устанавливает этот контрол, то настройка локомотива будет соответствовать установленному значению, если нет - будет дефолтное состояние;
Вариант 2:
Локомотив имеет заготовленные паттерны для состояния систем. Количество паттернов неограничено. Выбор паттерна задается а)цифрой в номере локомотива; б)значением сценарного контрола.
Вариант 3:
В папку сценария кладется текстовик-конфигуратор стандартизированной разметки, в котором прописываются все системы и их требуемое начальное состояние. Адрес на этот текстовик задается через буферный файл, размещаемый в корне игры. Ключ адреса задается в номере локомотива или сценарным контролом. Сценарист делает копию конфигуратора, настраивает локомотив как хочет и кладет свой файл в папку своего сценария. Потом создает путь к этому файлу и прикладывает его к описанию сценария. Пользователи копипастят этот путь в свои буферные текстовики. Локомотив при запуске первым делом проверяет контрол/номер, по ключу находит путь, открывает файл-конфигуратор и загружает с него все заданные настройки. Если путь с ошибкой или его не удается найти, загружается дефолтная конфигурация.

Света писал(а):

Хорошо, хоть номер ввести можно

А больше ничего и не нужно.

я бы удавился за возможность задавать (и модифицировать) через него начальные состояния контролов локомотива

Вариант 1:
Локомотив имеет специальный контрол для сценария. Каждый разряд этого контрола отвечает за свою систему, всего может быть 9 (если немножко заморочиться - 10) состояний каждой системы, количество систем равно количеству разрядов контрола. Если сценарий устанавливает этот контрол, то настройка локомотива будет соответствовать установленному значению, если нет - будет дефолтное состояние;
Вариант 2:
Локомотив имеет заготовленные паттерны для состояния систем. Количество паттернов неограничено. Выбор паттерна задается а)цифрой в номере локомотива; б)значением сценарного контрола.
Вариант 3:
В папку сценария кладется текстовик-конфигуратор стандартизированной разметки, в котором прописываются все системы и их требуемое начальное состояние. Адрес на этот текстовик задается через буферный файл, размещаемый в корне игры. Ключ адреса задается в номере локомотива или сценарным контролом. Сценарист делает копию конфигуратора и настраивает локомотив как хочет. Потом создает путь к этому файлу и прикладывает его к описанию сценария. Пользователи дописывают этот путь в свои буферные текстовики. Локомотив при запуске первым делом проверяет контрол/номер, по ключу находит путь, открывает файл-конфигуратор и загружает с него все заданные настройки. Если путь с ошибкой или его не удается найти, загружается дефолтная конфигурация.

Света, это все КОСТЫЛИ. Вот чтобы подобного не делать, и создается интерфейс. Оправдывать ущербность API TS тем, что якобы "больше ничего не нужно" (нужно!) - плохая идея. Работающие компрессоры тоже не нужны. И сопротивление движению в кривой тоже не нужно - выдумают еще, глупость какая. Ну, и утечки магистралей, правильная модель тяговых характеристик локомотивов, и возможность реализовать ту же тормозную систему через передачу сообщений по составу - тоже не нужно. Не нужно все - и на выходе получим МСТС с прикрученными тенями (коим и являлась первая редакция тогда еще Railsimulator-а). А в нем, кстати, подвижной состав в кривых растягивался - т.е. DTG ухитрились поломать даже то, что изначально присутствовало в доставшемся им коде.

Твой способ с паттернами используется моими ребятами для пультов - при помощи такого контрола пульт определяет, с каким локомотивом он сейчас работает, и какую конфигурацию подгружать для железа и виртуальной приборной доски. Да, при помощи паттернов (этот вариант гораздо удобнее, так как позволяет описать больше конфигураций) можно реализовать предложенный тобой функционал. Но, в отличие от действительно довольно полезной опции запуска тепловоза, это уже достаточно навороченная конструкция. Может быть полезно, скажем, для вагона метро, где можно таким образом автоматически настроить информатор и маршрут. Но все это высокотехнологичные (и что не очень хорошо - скриптовые) костыли, поддерживающие шаткую и несколько изувеченную при родах тварюшку. Весьма склочного нрава. Да и вбить в локомотив команду подгрузить такой паттерн способов немного - а отредактировать его и того меньше, так как числовой код завязан на логику. В общем, это уже перебор, из серии "maybe in future". Спасибо за идею насчет локомотивного номера, лично мне этого пока будет достаточно.

это все КОСТЫЛИ

С чего бы вдруг? Как-то слишком часто здесь употребляется это слово.
Я приведу цитату о том, что такое "костыль": "Костыли -- это неудобные, но работающие решения той или иной проблемы в коде программы. Неудобные обычно в смысле трудности дальнейшего развития системы и относящиеся к плохому стилю". Так вот, объясняю. Если симулятор стабильно вылетает на определенной платформе или при использовании какой-то конкретной версии библиотеки и мне пришлось написать свою заплатку, которая решила проблему вылета, но закрыла мне путь к последующим патчам или обновлениям - это самый настоящий костыль. Если я выкладываю скриптованное дополнение, например, локомотив, но в нем регулярно наблюдается баг, я даю файл, после которого баг исчезает, но одновременно полностью исчезает какая-нибудь второстепенная функция (например, падает рация или АЛСН) - это костыль, временное решение, чтобы игроки хоть с ограниченным функционалом, но могли использовать мою работу.
Но когда я с помощью скрипта (который для этого и предназначен, напоминаю) создаю в дополнении функционал, который изначально не был предусмотрен - то это не костыль, это использование гибкости среды разработки. И, уточню - до тех пор, пока получается реализовать свои идеи исключительно предоставленными методами, а именно, используя скрипт и собственные мозги, то это разработка и расширение функционала, а не закостыливание. А вот если для решения проблем в симуляторе (ещё раз - не реализации своих хотелок, а решения проблем!) придется лезть в движок - вот это будет костыль.
А у нас (я говорю "у нас", чтобы не сказать "у вас") надо прописать холодный запуск - это костыль, надо придумать систему обмена - это костыль, надо сделать систему безопасности - тоже костыль, надо реализовать какую-то фичу - опять костыль! С таким подходом надо писать свой собственный симулятор, запихивать в его код эти все приблуды, раз они так нервируют, находясь в скрипте, но выполняя те же функции. ИМХО.

С таким подходом надо писать свой собственный симулятор, запихивать в его код эти все приблуды, раз они так нервируют, находясь в скрипте, но выполняя те же функции. ИМХО.

Надо. Начнешь? Вот и ни к чему заводить эту шарманку снова и снова.

Не начну. В том числе и из-за того, что меня устраивает то, что есть и я свои решения (позволяющие реализовать мои хотелки) никогда не называю костылями, следовательно, ко мне этот принцип неприменим. На данный момент мне удалось решить субъективно 95% возникших задач. Остальные, нерешенные задачи я списываю на то, что мне ещё не все удалось изучить в симуляторе и на их малозначительность. В таких условиях я не вижу просто смысла начинать что-то лепить с нуля.
Хотя, разумеется, если группа компетентных разработчиков приступит к созданию аналогичного симулятора, но заточенного под ЖД пост-СССР, я буду всячески желать успеха этой команде, а если она добьется результата, я приложу свои скромные силы для продвижения этого симулятора.