Магия корейского рандома?

[Zion [?]]

Хроники

1. Interlude

Исходники

Присутствуют

Сборка

pw

Столкнулся с довольно странной проблемой

Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация

Статы прыгают как в лотерее при переодевании любой шмотки, даже одной и той же =\

Кто то знает как это лечить?

 

[akk12345]

PW не излечимо, попробуй приложить трусы баюма.

 

[JimmieStrimell]

Столкнулся с довольно странной проблемой

Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация

Статы прыгают как в лотерее при переодевании любой шмотки, даже одной и той же =\

Кто то знает как это лечить?

скинь пример стат которые прописаны

 

[MrKirill1232]

Проблема темы в том, что корейский рандом к сборкам, которые не ПТС, никак не будет относиться
Значит проблема в так называемых "калькуляторах" или кривых скриптах / датапаке.

 

[Zion [?]]

скинь пример стат которые прописаны

-<for>

<mul val="1.50" stat="pDef" order="0x30"/>

<mul val="1.30" stat="mDef" order="0x30"/>

<add val="5000" stat="maxMp" order="0x30"/>

<add val="450" stat="pDef" order="0x10"/>

<mul val="1.2" stat="maxHp" order="0x30"/>

<mul val="1.20" stat="pAtkSpd" order="0x30"/>

<mul val="1.60" stat="pAtk" order="0x30"/>

<add val="80" stat="rCrit" order="0x30"/>

<mul val="1.30" stat="mAtkSpd" order="0x30"/>

<mul val="1.80" stat="mAtk" order="0x30"/>

<enchant val="0" stat="pDef" order="0x10"/>

<enchant val="0" stat="mDef" order="0x10"/>

<add val="10000" stat="maxCp" order="0x30"/>

<enchant val="0" stat="pAtkSpd" order="0x0C"/>

<enchant val="0" stat="mAtkSpd" order="0x0C"/>

</for>

</item>

 

[JimmieStrimell]

<add val="5000" stat="maxMp" order="0x30"/>

<add val="450" stat="pDef" order="0x10"/>

проблемы могут быть из за этих значений, там где параметр add, а не mul, поставь 0x40, где mul - 0x30 (проверь все статы)

 

[Zion [?]]

<add val="5000" stat="maxMp" order="0x30"/>

<add val="450" stat="pDef" order="0x10"/>

проблемы могут быть из за этих значений, там где параметр add, а не mul, поставь 0x40, где mul - 0x30 (проверь все статы)

это придётся на всех предметах менять что бы проверить в этом дело или нет (это более 200 итемов) ахахаха

P.S. эти 2 параметра отвечают тока за мп и пдеф, а мдеф почему скачит?

 

[France]

это придётся на всех предметах менять что бы проверить в этом дело или нет (это более 200 итемов) ахахаха

P.S. эти 2 параметра отвечают тока за мп и пдеф, а мдеф почему скачит?

вообщето ордер = очереди применения статов.

 

[Sladost]

это придётся на всех предметах менять что бы проверить в этом дело или нет (это более 200 итемов) ахахаха

P.S. эти 2 параметра отвечают тока за мп и пдеф, а мдеф почему скачит?

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

 

[Zion [?]]

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

С предметами то исправил, а в бафах то чт оправить?

 

[Gaikotsu]

От order зависит очередь применения значений статы в калькуляторе - берутся значения с меньшим ордером и по возрастающей.
В итоге, когда к примеру в калькуляторе попадается с одним ордером например сложение и умножение - получаем неопределенное поведение, т.к. .раз на раз одна и та же последовательность операций совершенно не гарантируется.
Т.е. один раз к примеру может быть (x + y) * z, а в другой x * z + y, что само собой приведет к разному результату.
Потому и негласно принято делать для сложения/вычитания и умножения/деления разные значения ордеров, чтобы не было такой путаницы.

0x10/0x0C обычно используют под начальное выставление параметров в предметах и для бонусов от заточки;
0х20 обычно используется для неявных модификаций значения в самом ядре сразу после начальной установки (обычно в классе StatFunctions ядра)
0x30/0x50 для умножения и деления (mul/div);
0x40/0x60 для сложения и вычитания (add/sub);
0х80 часто для установки параметра в финальное значение, которое не должно зависеть от других операций над статой, с более низким ордером (set);
0х100 для лимитирования макс/мин. значения некоторых стат (обычно в классе StatFunctions ядра)

Еще могут иногда задействоваться ордеры выше 0х100, если надо в какой-то ситуации обойти лимит. Я так к примеру какое-то время делал в драко пухах бонус к макс. хп, который должен обходить максимальный лимит хп в 150к. Потом правда пришлось это переделывать по другому, т.к. оказалось что в данном случае это был неправильный подход, ибо там при экпипировке драко пух вобще полностью убирает лимит на хп, даже если статы на хп идут из других источников, не от пассивки в самой драко пухе

 

[Zion [?]]

От order зависит очередь применения значений статы в калькуляторе - берутся значения с меньшим ордером и по возрастающей.
В итоге, когда к примеру в калькуляторе попадается с одним ордером например сложение и умножение - получаем неопределенное поведение, т.к. .раз на раз одна и та же последовательность операций совершенно не гарантируется.
Т.е. один раз к примеру может быть (x + y) * z, а в другой x * z + y, что само собой приведет к разному результату.
Потому и негласно принято делать для сложения/вычитания и умножения/деления разные значения ордеров, чтобы не было такой путаницы.

0x10/0x0C обычно используют под начальное выставление параметров в предметах и для бонусов от заточки;
0х20 обычно используется для неявных модификаций значения в самом ядре сразу после начальной установки (обычно в классе StatFunctions ядра)
0x30/0x50 для умножения и деления;
0x40/0x60 для сложения и вычитания;
0х80 часто для установки параметра в финальное значение, которое не должно зависеть от других операций над статой, с более низким ордером;
0х100 для лимитирования макс/мин. значения некоторых стат (обычно в классе StatFunctions ядра)

Еще могут иногда задействоваться ордеры выше 0х100, если надо в какой-то ситуации обойти лимит. Я так к примеру какое-то время делал в драко пухах бонус к макс. хп, который должен обходить максимальный лимит хп в 150к. Потом правда пришлось это переделывать по другому, т.к. оказалось что в данном случае это был неправильный подход, ибо там при экпипировке драко пух вобще полностью убирает лимит на хп, даже если статы на хп идут из других источников, не от пассивки в самой драко пухе

Спасибо огромное, за такие подробности.