-
Публикации
11 968 -
Зарегистрирован
-
Посещение
Тип публикации
Профили
Статьи
Форум
Файлы
Все публикации пользователя Alex
-
Неплохо для начала, нно есть несколько "но". По этому фото видно, что серия 510 всё-таки значительно отличается от 464, и одной перекраской здесь не обойтись. У неё как минимум выше проём окон, есть чердак и сверху на торцевых стенах достаточно большие декоративные (?) элементы. С серией 515 то же самое, хотя она на 464 несклько больше похожа, конечно. Кроме того, на моделях с плоской крышей торцевые элементы видны только с внешней стороны, что смотрится не очень. А у МГ-601 увы ну оочень мыльные текстуры
-
А вот и программка, если кому интересно. Спасибо Фаусту за это :3 В архиве с ней лежат две библиотеки Visual, их нужно закинуть в C:/Windows/System32. Для расчёта состояния нужно ввести пробег за месяц, уровень обслуживания, надёжность т\с и интересующий период. Да, после капремонта состояние транспортного средства быстро ухудшается именно потому, что при расчёте используется не месячный пробег, а весь пробег т\с. Допустим: у нас есть транспортное средство с надёжностью 0.9 (90%). Через 10 лет и 144 километра пробега его состояние будет равно 55%. Теперь мы берём и ремонтируем его, состояние становится 100%, но пробег-то не исчезает! И вот что мы получаем (для этого программка была немного изменена): Уже через год состояние т\с равно тем же 55%. VehConditionCounter.rar
-
Так, ночью мы накатали кривую программу, которую теперь допилили и она правильно считает нам динамику ухудшения состояния т\с. Если допилим ещё лучше - можно будет её сюда закинуть наверное, чтобы каждый мог посчитать что хочется. Собственно, для эксперимента я взял Цитадис, который в месяц проезжает 2 километра (24км в год, немало для игровых п\с). Обслуживание - 95%, начальное состояние - 100%, надёжность - 80%. Что получилось (строка = месяц): Как видно, через 10 лет и 240км пробега его состояние составляет 40%. То же самое для вагона Х (надёжность 0,98): Его состояние через 10 лет и 240км равно 44%, то есть не намного-то и больше. Интересно, что дальше транспорт стареет не очень сильно: состояние 40-летнего MB O305 (значение надёжности у него такое же, как у Х) будет равно 25%. А вот значения для Цитадиса, если в формуле 0.009 заменить на 1: За 240км его состояние ухудшится лишь на 1,5%.
-
Обновление на сайте. Палатки в нём пока что были отключены.
-
Здесь меня очень смущает одна вещь: далеко не весь новый п\с реально может работать без сбоев, придя даже только-только с завода. Стоящие под забором и горящие первые 333 или тот же Е-186, или ещё много-много техники в пример. Покупая транспортное средство с вероятностью поломки 35%, мы должны понимать, что несмотря на то, что оно новое, оно может внезапно поломаться в любой момент. Здесь же получится, что мы сможем скупить пачку 333-х сразу после их появления не особо заботясь о том, будут они стоять под забором или работать на линии. Честно говоря, меня за время игры ни разу не напрягала частота поломок. И в Роттенбурге, и в Мюнхене при обслуживании 95% транспорт ломался вполне себе сносно и чинился достаточно быстро. Конечно, там транспорт был немецкий с соответствующей надёжностью, однако это лишний раз доказывает необходимость прямого влияния вероятность поломки на вероятность поломки (пардон за каламбур). По этим двум причинам я очень сомневаюсь в необходимости добавления этого мода в ЕСЦ. В принципе-то сейчас оно примерно так и есть. Вероятность поломки вагона Х - 2%, вероятность поломки Цитадиса - 20%. В Роттенбурге поезд Х+М+М у меня отъездил больше тысячи километров, и состояние его сейчас что-то в районе 20% вроде, точно уже не помню, надо будет глянуть. Вряд ли Цитадис так смог бы. Но да, в итоге в нашей формуле надёжность должна сильнее оказывать влияние на продолжительность жизни т\с, потому я и предлагал конечный результат умножать на надёжность: допустим, для Х это было бы 500км * 0,98 = 490км ресурса, для Цитадиса - 500 * 0,8 = 400км ресурса. Ну, это грубо говоря, но как-то так. Не всё так просто, увы. Например, MB O305 стоит в 2 раза дороже, чем ЛиАЗ-5256, а ушатать ЛиАЗ, судя по всему, несколько проще. Хотя тут было бы желание. В любом случае, добавлять цену в формулу просчёта состояния т\с - не самая лучшая идея, на мой взгляд. Об этом - в посте ниже.
-
Он не находит файлы, где прописано название. Вероятно, это немецкий мод, и в нём нет файлов en_US.scripten_US.script.
-
Так-с, продолжаю разбираться с формулой. На данный момент код выглядит так: $targetCondition = (1.0 - $transportVehicle.travelDistance / 320000) * (0.145 + $maintenanceLevel * 0.009); $vehicleData["condition"] = $transportVehicle.condition = $vehicleData["condition"] * $targetCondition; Пока без учёта надёжности т\с, беру только пробег и уровень обслуживания. Здесь пробег - в метрах, уровень обслуживания - целое значение от 0 до 95 (кратное 5). И вот всё бы, в принципе, хорошо, если бы не одно "но": пробег в функции берётся не за месяц, а за всю транспортную жизнь т\с, что меня сейчас не очень устраивает. Если бы пробег был месячный - формула каждый месяц считала бы дельту, зависящую (при максимальном обслуживании и до ввода в формулу остальных значений) только от того, какую часть дистанции относительно ресурса проехало т\с в этом месяце. Получалось бы какое-то число (например, при месячном пробеге 2км и ресурсе 320км это было бы 0,99375), на которое бы умножался показатель состояния т\с на начало месяца, выдавая конечный результат (первый месяц - 100%*0,99375 = 99,37%, второй - 99,375*0,99375 = 98,75% и так далее). В общем, может, у кого-нибудь есть идея, как брать не весь пробег т\с, а только то, что оно проехало за месяц?
-
Очевидно, эти строки: this.addWorkPlaces(GRID_CITIZEN_BLUE_COLLAR, 80, GRID_VISIT_HEAVY_INDUSTRIAL); this.addWorkPlaces(GRID_CITIZEN_WHITE_COLLAR, 6); this.addWorkPlaces(GRID_CITIZEN_STUDENT, 10); this.addWorkPlaces(GRID_CITIZEN_BUSINESS, 3);
-
Ну, так мы понемногу этим и занимаемся вроде...
-
Получается, этот мод исключает прямое влияние графы "Вероятность поломки" т\с на, собственно, вероятность поломки?
-
Нене, я там выше описал, наш капремонт - немного другое. Но, снова же, repairmod с ЕСЦ несовместим, разве что если вручную скрипты править.
-
Наш мод капремонта - переработанный repairmod. Там была какая-то непонятная формула расчёта стоимости ремонта. upd: а, нет, наш капремонт - переработанный repairpanel, или как-то так. Но RepairMod несовместим с ЕСЦ, поскольку заменяет player.script. $data.$vMaintenanceExpenses -= int($data.$maintenanceLevel[$vehicle.$type] * $vehicle.$price * 0.0005); В этой строке расчитывается стоимость облсужвания п\с. По дефолту она одна для всех видов транспорта, у нас же это занимает огромный кусок кода, поскольку помимо стоимости наша формула учитывает ещё множество факторов. В общем-то, по сути, у нас это выглядит так: if ($vehicle.$type == 0) {$data.$vMaintenanceExpenses -= int($data.$maintenanceLevel[$vehicle.$type] * $vehicle.$price * $vehicle.$reliabilityClass * 0.00027 * (2 - $vehicleData["condition"]) * (2 - $vehicle.$reliability));} if ($vehicle.$type == 1 && $vehicle.$subtype == 0) {$data.$vMaintenanceExpenses -= int($data.$maintenanceLevel[$vehicle.$type] * $vehicle.$price * $vehicle.$reliabilityClass * 0.00015 * (2 - $vehicleData["condition"]) * (2 - $vehicle.$reliability) * $tramControlSystem * $tramPriceFactor);} else if ($vehicle.$subtype == 7) {$data.$vMaintenanceExpenses -= int($data.$maintenanceLevel[$vehicle.$type] * $vehicle.$price * $vehicle.$reliabilityClass * 0.00020 * (2 - $vehicleData["condition"]) * (2 - $vehicle.$reliability) * $trolleyControlSystem);} if ($vehicle.$type == 2) {$data.$vMaintenanceExpenses -= int($data.$maintenanceLevel[$vehicle.$type] * $vehicle.$price * $vehicle.$reliabilityClass * 0.00015 * (2 - $vehicleData["condition"]) * (2 - $vehicle.$reliability)) * $metroControlSystem;} if ($vehicle.$type == 3) {$data.$vMaintenanceExpenses -= int($data.$maintenanceLevel[$vehicle.$type] * $vehicle.$price * $vehicle.$reliabilityClass * 0.00027 * (2 - $vehicleData["condition"]) * (2 - $vehicle.$reliability));} if ($vehicle.$type == 4) {$data.$vMaintenanceExpenses -= int($data.$maintenanceLevel[$vehicle.$type] * $vehicle.$price * $vehicle.$reliabilityClass * 0.00027 * (2 - $vehicleData["condition"]) * (2 - $vehicle.$reliability));}
-
tomcat9, грубо говоря, ЕСХ отвечает за характеристики транспорта, ЕСЦ - за всякую экономику (стоимость обслуживания, топлива и т.д.). Вообще же ЕСХ в первую очередь создавался для того, чтобы моддерский транспорт мог конкурировать между собой, и чтобы не было "кто во что горазд" в характеристиках, что мы можем увидеть на западных сайтах. А чтобы это всё нормально игралось - за основу был взят VehRealism, потом он же не раз был исправлен, чтобы соответствовать ЕСХ, и в общем заверте... По мере допиливания, кстати, они всё-таки будут объединены. Что касается метро - да, они просто почему-то иногда слишком долго стоят на станциях, абсолютно игноря поджимающий сзади состав, а то и несколько.
- 21 ответ
-
1
-
Да вот чёрт его знает. Для НОТ разработчики ситуацию поправили в каком-то из патчей, а вот с метропоездами то ли у них что-то не сложилось, то ли у нас что-то работает не так, как задумано. Но в любом случае я сейчас не знаю, какой именно скрипт (и скрипт ли) за это отвечает.
-
Поезда сбиваются в кучу увы везде, это не очень зависит от их типа и надёжности.
-
По Мегам - у нас есть их несколько вариантов, но все ссылаются на одну (Trolza5256b). Нужно бы подправить скрипты, но пока что это лечится скачиванием всех трёх версий Тролзы. С ЛиАЗами то же самое, судя по всему...
-
Нужно скрипты зданий править.
-
Троллейбус и город - не для CiM.)
-
Вот как раз для того, чтобы прикинуть, какой пробег брать за основу, мне нужно как можно больше данных от игроков с информацией о пробеге и возрасте т\с. Лучше всего это смотреть на какой-нибудь "многолетней" игре. Потому что, например, у меня в Роттенбурге есть несколько автобусов, которые в среднем за год проезжали лишь10-11 километров, следовательно 220км ресурса для них равно 20-22 годам.
-
Переустанови, включи чистую игру, и если всё будет нормально - устанавливай моды по одному-два, включай и проверяй.
-
Дело не в электричестве (оно и остётся), а в стоимости обслуживания, которая завязана на тип т\с. Проще... не знаю, проще всего удалить реальную к\с, тогда останется дефолтная, правда столбы там не то чтобы намного лучше.
-
Так-с. Просмотрев несколько своих сохранённых игр, выношу новое предложение по ресурсу для транспорта: Автобус - 220км; Троллейбус - 280км; Трамвай - 400км; Метропоезд - 700км. Разброс ресурса по годам здесь может быть очень разным: например, у меня в Роттенбурге на кольцевом маршруте трамваи проезжают в среднем 16 километров в год, на одном из радиальных - 20, на другом - вообще 11. Самый старый автобус в среднем проезжал 13 километров за год. Метропоезда - 25-30 километров. Таким образом усредённный ресурс по возрасту будет таковым: Автобус - 10 лет; Троллейбус - 14 лет; Трамвай - 20 лет; Метропоезд - 35 лет. 1. Очень важно: нужны ещё данные по пробегу от других игроков, у кого длина суток дефолтная (8 секунд). 2. Максимальный ресурс у нас будет считаться при обслуживании 95%?
-
Документы/Cities in Motion/log_metro.txt
-
Достаточно удалить строчки с упоминанием объекта в environment.script - он просто не будет загружаться и занимать память в этом случае.