Планка рифтов 150

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

Хм, eu_diablo3_com получил циклическое перенаправление. Красавцы! :wink:

Ок, чтобы не меряться познаниями в программировании, вообще наибанальнейший фикс, который не потребует никаких споров и прочего.
Вопрос снова: откуда у нас взялись гигантские числа, переполняющие int64? Они взялись из-за геометрической прогрессии роста HP мобов. Ну ок. А что с параметрами нашего урона? Они тоже растут в геометрической прогрессии? Не-а. Они корректируются в ручном режиме бонусами сетов. Сейчас у нас на них нарисовано около 10к% = 100 раз. Плюс есть бонусы самоцветов и прочего, что даёт мультипликативный урон. Что мешает - начиная с некоторого уровня - делить базовое HP мобов на этом уровне раз этак в 1000 (запас в 44 уровня ВП) или в 10k (запас в 58 уровней ВП), ну и наш урон, естественно, тоже (перед дальнейшим перемножением коэффициентов для более высоких уровней для HP; с уроном как бы проще - просто не нужно его домножать на 100 + нужно делить еще на 10 / 100). В плане отображения циферек ничего не поменяется (для сокращённого формата - это не проблема заменить млн на млрд в sprintf, учитывая откидывание 3-х нулей). Но в итоге имеем дополнительные 50 уровней ВП сверх капа. Аналогично поступаем для +50 уровней на их границе. Ну и всё, проблема (высосанная из пальца) решена. :smile:

В сухом остатке получается что проблема вполне себе решаемая если пораскинуть мозгами в исходном коде (правда индусский код тут точно не подойдет). Тогда если проблема не в циферках, то какая истинная причина верхней планки в 150? Есть идеи? Хотя по хорошему это надо просто спросить у самих близов, но они могут как обычно отметелиться…

Из того, что проблема решаема не следует, что ее нету. Естественно приложив некоторое число усилий можно решить практически любую проблему с софтом (в пределе можно весь код переписать), вопрос в том, готовы ли их прикладывать те, кто занимается игрой. (Но они годами не решают критичные для софтверной компании проблемы вроде утечки памяти или лагов от аое, с чего бы тут было иначе?)

С этого (2 поста выше) и нужно было начать еще 60 постов назад, а то взяли как аксиому предположение о том, что проблема с переполнением int64 не решаема совсем и пошли городить ересь.
Касаемо “усилий” и “переписывания всего кода” - я привёл пачку способов как можно реализовать проблему минимальными усилиями, поэтому тут вся проблема не столько в том, что она не может быть решена или может быть решена лишь приложением больших усилий, а - как обычно - в “особом складе мышления разрабов”: т.е. делают только то, что хотят, и когда хотят. Ну, короче, всё как всегда. :sunny:

P.S.: по поводу “индусского кода” - в принципе, справедливо, если стал писать код на С, не нужно было извращаться с добавлением левых конструкций. Ок, исправляюсь:
if (HP >> 62){ HP >>= 1; m++; }; HP *= k; // k = 1.17
DMG >>= m; // модификация влетаемого в моба урона

P.P.S.: странные люди - ни спасибо тебе, ни захудалого лайка. И это за “решение неразрешимой проблемы ‘тысячелетия’”. :smile:

2 лайка

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

Факт - закрытие рифта. Как тебе такое, илон маск? За 15 минут ты закрываешь разный уровень рифта. За месяц работы ты получаешь зп.

Вся суть подобных рассуждений сводится к тому что «секс = фрикции». Как бы процесс всегда одинаков. И формально это правда. Но эт информация не несет в себе никакой ценности или вывода. И использоваться кроме как для демагогии не может больше ни для чего. Потому что формально очень многое не отличается от очень многого в своей сути, если посмотреть с удобного угла и вырвать из контекста. Но это никак с реальностью соотноситься не будет

Ты понимаешь разницу между работать и получать зарплату?
Факт закрытия рифта это вообще не геймплей, геймплей это совокупность игровых процессов.
Такой ты правда бред несешь, уж извини

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

Просто уже три дегенерата в теме, не способные дальше узкого контекста анализировать

В попытке оправдаться ты фейлишь еще больше)))
Ты че 10к получаешь как то отлично от получения 50к?
Все бредовее и бредовее.
Разница в процессе получения зарплаты… фейспалм.
Попытки оскорбления оппонентов скорее тебя характеризует как дегенерата, чем их

Лайков: 1

Типичная подмена понятий. Ты потерял суть игрового процесса, и подменил его результатом оного.

По технике - да,не отличается.Но в данном случае корректней было бы рассматривать процесс поднятия 100кг и 1500кг (хотя и тут разница будет только в затраченном времени и уровне контроля - чем больше вес,тем больший контроль).А по технике - они аналогичны.

проблема явно не в цифрах, я играл в кликер там была планка е200, поменяли переменную стало е300, начали хранить цифру в двух переменных подняли планку до е1000. не уверен что из за нескольких переменных будет логать игра , возможно проблемы в движке, а его лень допиливать , нужно же другие игры делать. Глюк с уроном по области несколько лет не могут исправить а я уверен что для современных компьютеров это не должно быть проблемой, если бы игру оптимизировали.

Гриша Перельман от миллиона “зелени” отказался за “тысячелетку”, так что не мелочись.)

Лайков: 1

Это все интересно, но интереснее другое: что с этим “чудом” делать? Вот влетел в гварда урон; если его хп лежит в int64, то мы просто за пару тактов и вычли из переменной его здоровья влетевший урон и сразу же заодно проверили, не помер ли гвард (хп еще выше нуля). А тут, глядя на чудо-структуру… *чешет репу

Для начала ремарка: в коде логическая ошибка, сам найдешь? :slight_smile:
Ладно: ты проверил по старшему биту, что хп гварда уже в “опасной близости” к капу и когда это так, то ты ополовинил урон по гварду, ополовинил его здоровье, а затем апнул ему новое хп на 17% обратно вверх. Образно говоря (числа условные, просто для прояснения): был у нас урон 10, а у гаварда хп 100; в результате у нас урон стал 5, а хп гварда не 50, а 58,5. Короче, умножение на 1,17 надо в начале ставить, а уже потом проверять хп и предпринимать меры. Хотя, что-то еще раз перечитал, походу у меня сейчас туго варит башка с дороги: если вызывать просто для расчета +1 к вп, то будет работать что так, что так. Уф, устал, извини.

А вообще, как я понимаю, этот кусок кода для того, чтобы при старте рифта произвольного уровня подрихтовать хп гварда так, чтобы оно не превышало кап int64, а также вычислить необходимый при этом делитель урона. Ок, т.е. его надо вызвать в цикле, да? Ну там для вп2 один раз цикл пройти, для вп150 уже 149 раз повторить исполнение, да? Циклы, фи… :slight_smile: Если алгебру подключить, то оно эстетичнее получится

А с другой стороны зачем это вообще? Можно ведь зафиксировать макс. хп гварда в вп150+ и просто планомерно снижать входящий по нему урон на те же 1,17 за каждый последующий рифт. Вычислений меньше, результат тот же.

Так ты ее не решил, ты ее только отодвинул. Уже к 300+ рифту придется резать вливаемый урон в 4 миллиарда раз, а к 430+ рифту любой урон будет так зарезан сдвигом, что станет равным нулю. Это не тянет на премию :slight_smile:
И, кстати, сходу вижу сторонний эффект срезав урон по мобам, мы срежем и отражаемый в нас урон у мобов, которые умеют его возвращать (есть такой аффикс у элиток). А значит надо будет латать этот момент. Но, честно говоря, весь этот теорикрафт утомляет: только из командировки приехал, а тут сезон стартует. Даже некогда подготовиться.
*слышен звон стеклянной тары при подготовке к сезону :slight_smile:

UPD: а плюс, да, ставлю. Ибо главное же не сдаваться и искать. Вот бы еще разрабы так бы…

2 лайка

Так я же не лям зелени прошу. :wink:
К тому же, ты уже жмакнул кнопочку (большое спасибо), поэтому я доволен как эм, забыл как кто, - хоть кто-то оценил и то ладно. :blush:
P.S.: касаемо Гриши - дык это, он отказался от ляма из-за появившейся фрустрации по причине того, что неразрешимых задач больше нема. А у нас тут таких задачек еще “вагон и маленькая тележка”. :sunny:

bigblack, ну вот видишь, в итоге ты и готовый код с функциями на С набросал. :wink: Правда ведь, совсем не трудно? :sunny:

был у нас урон 10, а у гаварда хп 100; в результате у нас урон стал 5, а хп гварда не 50, а 58,5. Короче, умножение на 1,17 надо в начале ставить, а уже потом проверять хп и предпринимать меры.

На нужном нам уровне HP изначально было 100*1.17 = 117 (а не 100), стало 58.5 = 117/2. Всё правильно. :wink:
Если сначала домножать на 1.17, а потом проверять, то можно и улететь за переполнение ненароком.

Правильно понял, код именно для того чтобы при старте рифта произвольного уровня подкорректировать HP мобов (ну да, в частности, гварда - у него ведь больше всего HP) и соответственно уменьшить влетаемый по ним урон (эм, без достаточного урона мы ведь всё равно завалим рифт; при очень малом уроне - еще на первом же мобе).

Касаемо

А с другой стороны зачем это вообще? Можно ведь зафиксировать макс. хп гварда в вп150+ и просто планомерно снижать входящий по нему урон на те же 1,17 за каждый последующий рифт. Вычислений меньше, результат тот же.

Так я с этого как бы и начал (фиксированный HP мобов для какой-то сложности и всё последующее его увеличение - тупо в дебаф урона; аналогично и для урона), только тогда эту идею никто не подхватил. А тут - в итоге - к этому и пришли.

Касаемо

Так ты ее не решил, ты ее только отодвинул. Уже к 300+ рифту придется резать вливаемый урон в 4 миллиарда раз, а к 430+ рифту любой урон будет так зарезан сдвигом, что станет равным нулю. Это не тянет на премию

Тут никто и о ВП-151 мечтать не мог, а ты уже на ВП-300 замахнулся. :wink:
Решение такое же наипростейшее (и уже было предложено, может быть лишь частично). Нам главное что? Найти этот самый параметр m, на который мы будет резать урон, а это ведь степень - до переполнения int64 для неё мы никогда не дойдём (ну, в разумных пределах). Для урона находим также параметр n (ну, тут ведь проще, не правда ли? урон у нас увеличивается в “ручном режиме” - циферками сетов и легендарок, поэтому мы сразу знаем этот параметр просто зная шмот надетый на перса, а в ВП шмот еще и лочится). Ну а потом просто вычитаем (n-m) и уже на это значение и сдвигаем вправо урон. Делов-то. :sunny:

Касаемо

И, кстати, сходу вижу сторонний эффект срезав урон по мобам, мы срежем и отражаемый в нас урон у мобов, которые умеют его возвращать (есть такой аффикс у элиток).

С чего это вдруг? Мы же своё HP не режем, с чего это нам резать влетаемый по нам урон? (P.S.: а, ну да, это он дважды не будет резаться, а единожды - вполне себе может.) И - если не ошибаюсь - от нашего урона возвращаемый в нас урон давно уже не зависит.

P.S.: заметил довесок - большое спасибо за спасибо. :wink:

P.P.S.: ну усё, моя миссия выполнена - ЦУФ-программист суть идеи понял (и набросал код! хз, для меня всегда было проще понять суть идеи, смотря код, нежели чем читая стены тексты), дополнительное улучшение для ВП-300+ тоже запросто поймет, так что могу смело “умывать руки” (эм, разместить на US-форуме - при желании - сможет / смогут; тем более, что мой перевод англоязычные обычно воспринимают как прямое оскорбление их нежных чувств, чуть ли не посыл на известное место). :blush:

Лайков: 1

Деление с точки зрения СPU жутко затратный процесс по сравнению с остальными 3-мя действиями. Может занять и все 80 тактов. Тогда как FMUL жалкие 5. Хотя можем просто наносимый урон умножать на 0,87. Вот только для условного 200 рифта это придётся делать 200 раз. Хотя можно заранее вычислить коэффициенты умножения для каждого рифта и занести в общую таблицу как массив констант.

Ну и в заключение, касаемо “алгебру подключить” и дабы оправдать мои упреки в адрес разрабов (и не только) по поводу её незнания.
У нас переполнение int64 из-за чего? Из-за геометрической прогрессии роста параметров мобов (в частности, их HP), а экспонента - это штука быстро растущая, как известно. Что является противопоставлением экспоненциальной зависимости (для знающих математику - её инверсной функцией)? Правильно, логарифм.

Немного циферек (a = 1.17):
HP = HP_70 * am
DMG = DMG_0 * bn
HP - DMG = понятно что
Проблема из-за наличия больших чисел в обоих.

Берём логарифмы (сразу упростил, a = 1.17):
ln HP = ln HP_70 + m * ln a
ln DMG = ln DMG_0 + n * ln b
ln (HP / DMG) = ln HP - ln DMG =
  ln (HP_70 / DMG_0) + (m * ln a - n * ln b) =
   const1 + (m * const2 - n * const3)
Естественно, нужно брать отношение величин (а не разницу, хотя это особой роли не играет), но никаких больших чисел нет и в помине, ровно как и проблемы с ними, причём решение выше (с переполнением int64) - как можно заметить - имеет точно ту же логику (я даже использовал те же имена переменных: m и n).

На этом точно всё. :wink:

Какая-то мелковатая ирония, что её даже и не видно за гигантским комплексом неполноценности. :smile: