Стандарт цен

[AS_ 327]

А скачивал мод на увеличение длинны суток. Он там что-то в паке ui поменял. В остальном же изменения значения в файле engine.script даёт результаты. Однако самая большая проблема - та цифра совершенно ни о чём не говорит. Надо подбирать значение методом научного тыка.

[tomcat 4 271]

В остальном же изменения значения в файле engine.script даёт результаты.

Даёт результаты, но, к сожалению, кратковременные. Уменьшил соответствующее значение в engine.script с 10000 до 1500, день стал длиться вместо стандартных 8 секунд целую минуту, но с началом нового месяца всё сбилось опять на дефолт. Так что нужно ещё какой-то параметр менять параллельно, а где - не пойму.

[Alex 10 131]

Так-с. Просмотрев несколько своих сохранённых игр, выношу новое предложение по ресурсу для транспорта:

Автобус - 220км;

Троллейбус - 280км;

Трамвай - 400км;

Метропоезд - 700км.

Разброс ресурса по годам здесь может быть очень разным: например, у меня в Роттенбурге на кольцевом маршруте трамваи проезжают в среднем 16 километров в год, на одном из радиальных - 20, на другом - вообще 11. Самый старый автобус в среднем проезжал 13 километров за год. Метропоезда - 25-30 километров.

Таким образом усредённный ресурс по возрасту будет таковым:

Автобус - 10 лет;

Троллейбус - 14 лет;

Трамвай - 20 лет;

Метропоезд - 35 лет.

1. Очень важно: нужны ещё данные по пробегу от других игроков, у кого длина суток дефолтная (8 секунд).

2. Максимальный ресурс у нас будет считаться при обслуживании 95%?

[Sobolev_IP 618]

Честно скажу износ должен зависеть еще от изначальной надежности. Т.е. немецкие автобусы могут проходить и 1000 км, а вот газелька и 100 не сможет, к примеру. То же самое и с трамваями. 10 лет для качественно автобуса мало, вон немецкие автобуса Стандарта 1, выпущенные в 70-х до сих пор успешно несут службу на маршрутах в России, а им уже по 30-40 лет и об их уходе никто не думает, т.е. уровень обслуживания 0%. Когда что-то сломается, что-нибудь приколохозят, и снова на линию.

[ArtMetro 1 274]

Ну, метро тоже может больше 35 лет ездить. Во многих городах составам и по 80 лет было, когда их снимали с эксплуатации. Но это не есть правильно. К тому же есть мод ремонта, где мы ТС капиталим. Здесь же речь идёт о пробеге только на техническом содержании. Но автобусам и троллейбусам я бы лет 15 дал всё-таки. Думаю, даже можно немного увеличить пробег для всех видов ТС.

[Alex 10 131]

Вот как раз для того, чтобы прикинуть, какой пробег брать за основу, мне нужно как можно больше данных от игроков с информацией о пробеге и возрасте т\с. Лучше всего это смотреть на какой-нибудь "многолетней" игре. Потому что, например, у меня в Роттенбурге есть несколько автобусов, которые в среднем за год проезжали лишь10-11 километров, следовательно 220км ресурса для них равно 20-22 годам.

[tomcat 4 271]

10 лет для качественно автобуса мало, вон немецкие автобуса Стандарта 1, выпущенные в 70-х до сих пор успешно несут службу на маршрутах в России, а им уже по 30-40 лет и об их уходе никто не думает

Подтверждаю. У нас во Пскове целые маршруты из 30-летних Мерсов составлены - ездят как миленькие.

[AS_ 327]

Подтверждаю. У нас во Пскове целые маршруты из 30-летних Мерсов составлены - ездят как миленькие.

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

[AS_ 327]

Хочу попробовать объединить вот этот мод http://www.cimexchange.com/index.php?/files/file/42-repair-mod-for-cities-in-motion/ с ECЦ.

Такой вопрос:

$data.$vMaintenanceExpenses -= int($data.$maintenanceLevel[$vehicle.$type] * $vehicle.$price * 0.0005);

В ЕСЦ этой строчки нет. Её сознательно убирали?

[Alex 10 131]

Наш мод капремонта - переработанный 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));}

[AS_ 327]

Наш мод капремонта - переработанный repairmod. Там была какая-то непонятная формула расчёта стоимости ремонта.

Т.е. он отличается от того, что есть на каком-то импортном сайте? Я подумал что одно и то же, поэтому качал оттуда. Мне главное чтобы при состоянии в 88% транспорт не ломался очень часто.

[Alex 10 131]

Нене, я там выше описал, наш капремонт - немного другое. Но, снова же, repairmod с ЕСЦ несовместим, разве что если вручную скрипты править.

[AS_ 327]

Просто есть два repair мода. Один добавляет панель капремонта, другой изменяет вероятность поломок в зависимости от состояния. Первый ставится в addons, второй в metro. Собственно, второй я и вписал в скрипт ЕСЦ.

[Alex 10 131]

Получается, этот мод исключает прямое влияние графы "Вероятность поломки" т\с на, собственно, вероятность поломки?

[AS_ 327]

Не уверен.

[tomcat 4 271]

Alex, ASk

Было бы здорово, если бы вы объединились и работали совместно над улучшением существующего ЕСЦ, если, конечно, его есть куда улучшать. Ну это так - личное пожелание, но думаю многие поддержат

[Alex 10 131]

Ну, так мы понемногу этим и занимаемся вроде...

[Alex 10 131]

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

$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% и так далее).

В общем, может, у кого-нибудь есть идея, как брать не весь пробег т\с, а только то, что оно проехало за месяц?

[AS_ 327]

А чем плох весь накопившийся пробег?

(0.145 + $maintenanceLevel * 0.009)

Я себе в конец 1 поставил. Теперь транспорт не восстанавливается до 90% и более процентов как при значении 5,8 или 9, а потихонечку стареет. Причём скорость старения ощутимо зависит от обслуживания. При 20% обслуживания ТС с пробегом 300+ теряет в месяц почти по 1-2%. Хотя может маловато? На капремонт это всё тоже влияет. Если при 20% обслуживания сделать капремонт, то машина довольно быстро ушатается обратно до своего состояния. Если же поставить обслуживание 50%, то машинка вполне ещё поездит.

Пока без учёта надёжности т\с, беру только пробег и уровень обслуживания.

Вообще в итоге смысл должен быть в том, что, например, при попадании в Каир Х+М и Цитадиса, последний ушатается в хлам значительно быстрее. Т.е. надо либо надёжность переставлять у всех ТС, либо подставлять в формулу цену ТС.

Таким образом, получается:

Если за ТС не следить, то оно рассыпется быстрее.

Если ТС изначально дешёвое, значит оно простое. Если оно простое, то его сложно будет ушатать.

А надёжность? А надёжность нужна будет для подсчёта стоимости обслуживания. ИМХО её больше нигде и не надо учитывать. Если я не ошибаюсь, у Цитадиса и Х+М она стоит одинаковая. Следовательно для старения она ничего не даст. Иначе получится что оба после 5 лет работы в Каире должны выглядеть одинаково.

---------------------

Теперь о поломках. Выше я описывал эксперимент. Эксперимент удался. ЕСЦ работает. Теперь при состоянии выше 60% ТС практически не ломается, при состоянии 40%-60% ТС ломается так же часто, как раньше ломалось при состоянии 40%-90%. При состоянии ТС ниже 40% оно должно ломаться практически регулярно, но не проверял. При этом параметр надёжность не стал бесполезным. Даже если он теперь не влияет на частоту поломок, он всё равно учитывается в стоимости обслуживания. Что-то вроде: механики ещё в депо стараются предотвратить возможные поломки - отсюда и повышенный расход на обслуживание.

Если надо могу скинуть файлик.

----------------

Эксперименты со временем суток завершены. Итог: лучше оставить как есть.

Проблемы:

1. При слишком длинных сутках прибыль становится просто огромной (по 1 станции метро в месяц). Ибо расходы у нас в основном все за календарный месяц высчитываются, а прибыль считается по событиям (покупка билетов).

2. При небольшом увеличении длины суток, первая проблема не так актуальна. Но! Подумайте сами: день 12 секунд, следовательно 12*365/60 = 73 минуты. Такое время идёт игровой год. Т.е. 5 лет это 6 часов реального времени. Много ли произойдёт в городе за это время? Много ли ТС появится? Мне лично неинтересно терять столько времени жизни пялясь в экран ожидая чего-то нового. Стандартный же год проходит где-то за 48-52 минуты. Т.е. 5 лет где-то 4 с небольшим часа.

[ArtMetro 1 274]

2. При небольшом увеличении длины суток, первая проблема не так актуальна. Но! Подумайте сами: день 12 секунд, следовательно 12*365/60 = 73 минуты. Такое время идёт игровой год. Т.е. 5 лет это 6 часов реального времени. Много ли произойдёт в городе за это время? Много ли ТС появится? Мне лично неинтересно терять столько времени жизни пялясь в экран ожидая чего-то нового. Стандартный же год проходит где-то за 48-52 минуты. Т.е. 5 лет где-то 4 с небольшим часа.

Тебе неинтересно, а мне интересно. Я люблю долгие затяжные игры на хороших картах с развитием. Так что это уже дело вкуса. Согласен, что "вшивать" такое изменение в мод не нужно. Но можно сделать дополнительный мод или сказать где и что поменять.

[Alex 10 131]

Выше я описывал эксперимент. Эксперимент удался. ЕСЦ работает. Теперь при состоянии выше 60% ТС практически не ломается, при состоянии 40%-60% ТС ломается так же часто, как раньше ломалось при состоянии 40%-90%. При состоянии ТС ниже 40% оно должно ломаться практически регулярно, но не проверял.

Здесь меня очень смущает одна вещь: далеко не весь новый п\с реально может работать без сбоев, придя даже только-только с завода. Стоящие под забором и горящие первые 333 или тот же Е-186, или ещё много-много техники в пример. Покупая транспортное средство с вероятностью поломки 35%, мы должны понимать, что несмотря на то, что оно новое, оно может внезапно поломаться в любой момент. Здесь же получится, что мы сможем скупить пачку 333-х сразу после их появления не особо заботясь о том, будут они стоять под забором или работать на линии.

Честно говоря, меня за время игры ни разу не напрягала частота поломок. И в Роттенбурге, и в Мюнхене при обслуживании 95% транспорт ломался вполне себе сносно и чинился достаточно быстро. Конечно, там транспорт был немецкий с соответствующей надёжностью, однако это лишний раз доказывает необходимость прямого влияния вероятность поломки на вероятность поломки (пардон за каламбур).

По этим двум причинам я очень сомневаюсь в необходимости добавления этого мода в ЕСЦ.

Вообще в итоге смысл должен быть в том, что, например, при попадании в Каир Х+М и Цитадиса, последний ушатается в хлам значительно быстрее. Т.е. надо либо надёжность переставлять у всех ТС, либо подставлять в формулу цену ТС..

В принципе-то сейчас оно примерно так и есть. Вероятность поломки вагона Х - 2%, вероятность поломки Цитадиса - 20%. В Роттенбурге поезд Х+М+М у меня отъездил больше тысячи километров, и состояние его сейчас что-то в районе 20% вроде, точно уже не помню, надо будет глянуть. Вряд ли Цитадис так смог бы. Но да, в итоге в нашей формуле надёжность должна сильнее оказывать влияние на продолжительность жизни т\с, потому я и предлагал конечный результат умножать на надёжность: допустим, для Х это было бы 500км * 0,98 = 490км ресурса, для Цитадиса - 500 * 0,8 = 400км ресурса. Ну, это грубо говоря, но как-то так.

Если ТС изначально дешёвое, значит оно простое. Если оно простое, то его сложно будет ушатать.

Не всё так просто, увы. Например, MB O305 стоит в 2 раза дороже, чем ЛиАЗ-5256, а ушатать ЛиАЗ, судя по всему, несколько проще. Хотя тут было бы желание. В любом случае, добавлять цену в формулу просчёта состояния т\с - не самая лучшая идея, на мой взгляд.

Я себе в конец 1 поставил. Теперь транспорт не восстанавливается до 90% и более процентов как при значении 5,8 или 9, а потихонечку стареет. Причём скорость старения ощутимо зависит от обслуживания. При 20% обслуживания ТС с пробегом 300+ теряет в месяц почти по 1-2%. Хотя может маловато? На капремонт это всё тоже влияет. Если при 20% обслуживания сделать капремонт, то машина довольно быстро ушатается обратно до своего состояния. Если же поставить обслуживание 50%, то машинка вполне ещё поездит.

Об этом - в посте ниже.

[Alex 10 131]

Так, ночью мы накатали кривую программу, которую теперь допилили и она правильно считает нам динамику ухудшения состояния т\с. Если допилим ещё лучше - можно будет её сюда закинуть наверное, чтобы каждый мог посчитать что хочется.

Собственно, для эксперимента я взял Цитадис, который в месяц проезжает 2 километра (24км в год, немало для игровых п\с). Обслуживание - 95%, начальное состояние - 100%, надёжность - 80%. Что получилось (строка = месяц):

Как видно, через 10 лет и 240км пробега его состояние составляет 40%. То же самое для вагона Х (надёжность 0,98):

Его состояние через 10 лет и 240км равно 44%, то есть не намного-то и больше.

Интересно, что дальше транспорт стареет не очень сильно: состояние 40-летнего MB O305 (значение надёжности у него такое же, как у Х) будет равно 25%.

А вот значения для Цитадиса, если в формуле 0.009 заменить на 1:

За 240км его состояние ухудшится лишь на 1,5%.

[Alex 10 131]

А вот и программка, если кому интересно. Спасибо Фаусту за это :3

В архиве с ней лежат две библиотеки Visual, их нужно закинуть в C:/Windows/System32.

Для расчёта состояния нужно ввести пробег за месяц, уровень обслуживания, надёжность т\с и интересующий период.

Да, после капремонта состояние транспортного средства быстро ухудшается именно потому, что при расчёте используется не месячный пробег, а весь пробег т\с.

Допустим: у нас есть транспортное средство с надёжностью 0.9 (90%). Через 10 лет и 144 километра пробега его состояние будет равно 55%. Теперь мы берём и ремонтируем его, состояние становится 100%, но пробег-то не исчезает! И вот что мы получаем (для этого программка была немного изменена):

Уже через год состояние т\с равно тем же 55%.

VehConditionCounter.rar

[ArtMetro 1 274]

Да, после капремонта состояние транспортного средства быстро ухудшается именно потому, что при расчёте используется не месячный пробег, а весь пробег т\с.

Допустим: у нас есть транспортное средство с надёжностью 0.9 (90%). Через 10 лет и 144 километра пробега его состояние будет равно 55%. Теперь мы берём и ремонтируем его, состояние становится 100%, но пробег-то не исчезает! И вот что мы получаем (для этого программка была немного изменена):

Уже через год состояние т\с равно тем же 55%.

Теперь ясно в чём соль. Меня это всегда раздражало. Только отремонтировал, а состояние ТС быстро скатывается до прежних значений. Из-за этого встаёт вопрос о рациональности ремонта в принципе.

[Alex 10 131]

Да, вот поэтому тоже хорошо бы как-то получать именно ежемесячный пробег, а не весь сразу.