NickLon, "прикрути" скрипты от локомотивов, которые расположены в этой теме Дело 10 минут максимум.
---------- Сообщение добавлено в 18:57 ---------- Предыдущее сообщение размещено в 18:26 ----------
У меня тоже вопрос. Есть веерное депо. Как локомотиву дать знать какой путь свободен, чтобы туда повернуть круг, и в памяти оставить его положение (путь), чтобы потом опять себе повернуть круг и выехать на контрольный?
Ну вот, наткнулся я на естественное ограничение в Trainz. Сессия "БАМ: Олекма - Северобайкальск" в том виде, в котором я её изначально задумывал оказалась не жизнеспособна - слишком много подвижного состава не то, чтобы даже в зоне видимости, а вообще, на карте. Тормоза просто неприемлемые, даже на моём, довольно таки не слабом компьютере. Ну оно и не мудрено. Карта без малого 1000 км. и на всём этом расстоянии надо сделать так, чтобы хотя бы парочка поездов встречалась в течение получаса хотя бы. Когда расставил три пары пассажирских поездов, курсирующих по расписанию, всё было нормально, а вот когда начал пичкать карту грузовыми, тут и началось.
На данный момент на карте присутствуют:
31 магистральный машинист с поездами
2 диспетчера;
8 толкачей
6 маневровых
Это, оказывается, многовато для Trainz. А это ещё только процентов 65 от задуманного. И вот как быть в этой ситуации? Забрасывать не хочется, т.к. списки команд в библиотеке команд и в библиотеке очередей ожидания команд практически все уже составлены. Логика движения уже тоже практически настроена, включая движение с толкачами.
Я вижу такой выход из создавшейся ситуации. Не строить одну гигантскую сессию для всей карты, тем более, что за один присест вряд ли кто-то доедет от Северобайкальска до Олекмы - там пассажирский только идет 16 часов, грузовые вообще, могут более суток идти от края до края. А создать несколько сессий, каждая последующая из которых будет продолжением предыдущей. Муторно, конечно. Это в любом случае одну гигантскую сессию всё равно придется делать и наблюдать за конвульсиями подвижного состава, чтобы выяснить и записать какой поезд в какой момент времени где находится. Точнее, в так называемое, "пограничное" между сессиями время. А потом, в каждой сессии использовать только тот состав, который будет виден игроком во время прохождения сессии. Остальные в списке машинистов будут подсвечены красным, кстати, при этом ничего плохого не произойдет?
А кто-нибудь сталкивался с такой проблемой? И если да, то как решали?
P.S. В варианте дробления сессии уже увидел недостаток один. На дальних станциях относительно игрока не будет формирования отцепов на индустриях, которые впоследствии забирает игрок, если успеет, конечно, перед ботом. Получается, либо "лысые" покатушки, либо кошмарные тормоза. Думаю, второй вариант сам собой отпадает.
Иногда мы принимаем такие решения, которым тараканы в голове аплодируют стоя.
NickLon,
Я полагаю, что сессия может быть очень длинной по времени и протяжённой по расстоянию, но разумеется при условии ограничения нагрузки на комп. Скорее всего это выразится в поддержании активности ботов и различных правил/скриптов в пределах некоторой зоны впереди и позади игрока. По мере продвижения игрока, зона активности перемещается вместе с ним. Всё, что произойдёт нескоро или давно произошло, не должно влиять на производительность, в том числе расставленные на карте составы. В том числе нужно:
- отключать физику у всех не двигающихся составов
- ограничивать количество движущихся составов
- делить сессию на несколько микросценариев с "точками сохранения" между ними. Точка сохранения - момент когда все ранее запущенные логические конструкции уже отработали, и если после загрузки сохранения какое-то правило или набор команд не восстановится, это ни на что не повлияет. После сохранения игрок проезжает триггер, который запускает новые наборы правил на следующем участке. Помимо решения проблемы с сохранениями, такой подход позволяет отдельно тестировать каждый новый участок.
Ant.taranish,
Давай разберём по полочкам. Сначала насчет длины сессии. Лет шесть уже лелею мысль сделать "бесконечную сессию", здесь я только "За!" А вот о каком ограничении нагрузки на комп ты говоришь? Когда запускается сессия, в ней есть определенное количество составов: вагонов, локомотивов, машинистов. И это количество никак в течение всей сессии, сколь долгой она ни была, не уменьшится и не увеличится. Как в течение сессии можно что-то ограничить?
Скорее всего это выразится в поддержании активности ботов и различных правил/скриптов в пределах некоторой зоны впереди и позади игрока.
Как боты могут быть не активны "где-то там"? Они же тоже должны что-то делать, чтобы когда они окажутся "где-то здесь" результатами их труда можно было бы воспользоваться. Например, задача для двух маневровых на угольной шахте наполнять поступившие полувагоны углём, чтобы прибывший игрок, в том числе, смог их забрать к перевозке из пункта А в пункт Б, как дополнительные к составу вагоны.
Далее. "- отключать физику у всех не двигающихся составов". А это как? Когда я поставил правило, отключающее физику у составов без машинистов, у меня ВЛ80с-2223 даже пантографы не поднял. А машинист там был. Может быть я чего-то не умею, чего ты умеешь?
"- ограничивать количество движущихся составов". Ну, так к этому выводу я и прихожу. Хотя из слона сделать кучу мух и заставить их жужжать у меня вряд ли получится. Нужно пересматривать саму концепцию построения сессий, переходящих одна в другую.
Точки сохранения. Мысль то конечно очень здравая! Но как ты эту точку определишь? (между прочим, к этому вопросу - как определить правильно точку сохранения сессии ещё предстоит вернуться отдельно, т.к. это весьма важный момент) В этой точке не должно быть совмещенных команд, которые помимо движения бота перед этим ещё осуществляют сборку маршрута, например, "Маневрировать за М4, собрать маршрут на свободный путь". Хотя, здесь я могу ошибаться, Эрендир, вроде, этот ньюанс как-то пофиксил. То есть, если я восстанавливаю сохраненную сессию и там работает команда эта, она "понимает", что маршрут то уже собран маневровый и теперь надо только ехать, а не пытаться его опять собрать. Но это можно потестить. Вот этим вечером это и посмотрю. А помимо таких команд, есть ещё куча других. Не приведи Господи сохранить сессию, когда кто-то выполняет команду Load/UnLoad на индустрии! После сохранения сессии на этом месте, она восстановлению вообще не подлежит, т.к. достаточно одного "бешеного" маневрового, чтобы испортить всю сессию дальше.
И всё-таки, твой ответ на мой пост меня подталкивает к тому, что действительно, нужно делить весь сценарий на 3-4 микросценария.
P.S. А может, я чего-то не понимаю или не знаю?
Иногда мы принимаем такие решения, которым тараканы в голове аплодируют стоя.
Когда запускается сессия, в ней есть определенное количество составов: вагонов, локомотивов, машинистов
Пока они находятся вне видимости, пока для них не считается физика и не выполняются скриптовые расчёты, можно считать, что они не нагружают комп. То есть ограничивать надо не количество ПС на карте, а количество одновременно активного ПС.
Сообщение от NickLon
Когда я поставил правило, отключающее физику у составов без машинистов, у меня ВЛ80с-2223 даже пантографы не поднял. А машинист там был.
Вряд ли это связано. Если машинист был, значит физика не отключалась. Надо тестировать. У некоторых локов машинист ничего не может сделать, пока этот лок выбран игроком. Кстати, правило при выполнении пишет в окно сообщений, сколько составов найдено, и у скольких отключена физика.
Сообщение от NickLon
Как боты могут быть не активны "где-то там"? Они же тоже должны что-то делать, чтобы когда они окажутся "где-то здесь" результатами их труда можно было бы воспользоваться
Далее будет много букв.
Всякую ситуацию в сессии можно создать простым и сложным путём.
Сложный путь- создать условия для возникновения нужной ситуации. В твоём случае - смоделировать бесконечный процесс погрузки и перевозки угля. Результат ты представляешь только в общих чертах и поэтому моделируешь процесс "универсально", учитывая максимум факторов. Потом в ходе тестирования на конкретном участке карты ты начинаешь улучшать и упрощать логику процесса (выясняется, что какие-то ситуации в реалиях нашей станции/участка не могут произойти, какие-то наоборот ты не предусмотрел, что-то можно реализовать проще и надёжнее т.д.)
Простой путь - создать саму ситуацию, оставив за скобками всё, что предшествовало её возникновению. Вот мы расставили вагоны на станции и индустрии, дали маневровым наборы команд, чтобы они какое-то время изображали активность, пока игрок находится на станции и цепляет вагоны с углём. После того как игрок уехал, быстренько обновили декорации - выкатили из портала новый состав, загрузили его углём, вывели на станцию и ждём пока игрок за ним вернётся. При этом такие вопросы как оборот вагонов, время, затрачиваемое на операции, оптимальные маневровые маршруты - все это остаётся условностями.
Особенности результатов, которые мы можем получить тем или иным способом.
1. Статичность результата. Железная дорога на самом деле, как мне кажется, очень линейная штука. График движения и организация работы на определённом участке ж/д глобально не меняется из года в год, потому что большинство влияющих факторов перманентны (прежде всего сама дорога, профиль, путевое развитие и т.д.). Однажды рассчитали все показатели для конкретного участка и организовали всё единственным оптимальным (с точки зрения затрат времени и ресурсов) образом. В игре это выражается в следующем: пытаясь смоделировать сложную систему с учётом множества условий, мы в итоге всё равно получаем очень статичный (единственно оптимальный) результат. Множество факторов рождают очень малое число вариаций с точки зрения стороннего наблюдателя. Создать высокий шанс вариации при втором (а не десятом) прохождении - наверно самое сложное. И сразу возникает вопрос - а стоило ли столько возиться?
2. Ценность результата. Ценность результата, полученного сложным способом, в основном, существует только для разработчика, поскольку ему очень интересно моделирование ж/д процессов, их оптимизация с учётом игровых реалий, реалий конкретного маршрута и т.п. После сложной работы ты создал простой отлаженный механизм и очень доволен. Сторонний же игрок не сможет оценить всю его прелесть, даже если будет перемещаться по карте и смотреть, где что происходит (разве что он полезет в редактор и будет очень долго разбираться как всё устроено внутри). А уж из кабины локомотива он вообще не увидит разницы по сравнению с ситуацией, созданной посредством декораций.
3. Оптимальность результата. С другой стороны, сложная модель даёт точный, обоснованный всеми факторами результат. Если мы "театральными" средствами создаём конкретную ситуацию, то она может быть неоптимальной для данного участка (то есть нереалистичной) и вообще может противоречить логике сессии. Например, выпустили мы из портала на ближайшей станции несколько грузовых с небольшим интервалом навстречу игроку. А на самом деле они не могли идти в это время с таким интервалом, потому что дальше за станцией - однопутный мост, который они по логике должны были проследовать одновременно с впередиидущим пассом. Другое дело - обратит ли на это внимание сторонний игрок?
С учётом всего этого, а также ограничений по производительности я пришёл к тому, что детально моделировать отдельные процессы нужно, без этого вариативности не будет совсем, будет хромать логика происходящего вокруг и вообще разрабатывать сессию будет неинтересно. Но делать это нужно избирательно (другие, менее интересные процессы можно показать чисто декоративно), и по возможности последовательно. Иначе всё это будет слишком трудоёмко, накладно по производительности и не будет отвечать "сюжету" нашей сессии (поездка от А до Б, местная работа на участке, маневровая работа на крупной станции и т.д.).
Возможно, как-нибудь выложу тут описание реализованной в моих сессиях системы скрещения со встречными грузовыми, идущими со случайными интервалами. Она, как мне кажется, наглядно иллюстрирует всё вышеописанное, и особенно - проблемы с вариативностью.
Последний раз редактировалось Ant.taranish; 19.12.2015 в 16:11.
Всем привет и с Новым годом! Ant.taranish, внимательно прочитал, что ты написал. Спасибо. Сейчас с учетом вышеизложенного пытаюсь что-то реализовать. Но возникла другая непредвиденная ситуация. О чем и вопрос.
Настройка порталов по триггеру генерирует поезда с интервалом, которым там указал. Но мне это не нужно. Указано 2 поезда, вот их сгенерировать и больше не надо. Это возможно?
Иногда мы принимаем такие решения, которым тараканы в голове аплодируют стоя.
Всех приветствую. Задался вот каким вопросом: когда маршрут реальный, например, Печорка, то сценарий можно построить исходя из реального расписания РЖД на этом участке. А вот как быть с картами, которые полностью вымышлены, например Степная Даль? Конкретно интересует момент со стоянкой вашего поезда строго определённое время. Например, чтобы по моему приходу на станцию Хани выходной закрывался ровно на три минуты, а потом по команде диспетчера в HTML окне либо без оной открывался. Можно конечно построить весь трафик на карте чисто на связках Timecheck + Addpath, но это муторно и долго.
Последний раз редактировалось RZD29RUS; 24.01.2016 в 22:03.
Причина: опечатка