Магия корейского рандома?
- Автор темы Zion [🌿]
- Дата начала
![Zion [🌿]](/data/avatars/m/17/17672.jpg?1657575550){kind=avatar}
скинь пример стат которые прописаны
Проблема темы в том, что корейский рандом к сборкам, которые не ПТС, никак не будет относиться 
Значит проблема в так называемых "калькуляторах" или кривых скриптах / датапаке.
Значит проблема в так называемых "калькуляторах" или кривых скриптах / датапаке.
<add val="5000" stat="maxMp" order="0x30"/>
<add val="450" stat="pDef" order="0x10"/>
проблемы могут быть из за этих значений, там где параметр add, а не mul, поставь 0x40, где mul - 0x30 (проверь все статы)
<add val="450" stat="pDef" order="0x10"/>
проблемы могут быть из за этих значений, там где параметр add, а не mul, поставь 0x40, где mul - 0x30 (проверь все статы)
это придётся на всех предметах менять что бы проверить в этом дело или нет (это более 200 итемов) ахахаха
P.S. эти 2 параметра отвечают тока за мп и пдеф, а мдеф почему скачит?
Проблема именно в этом, исправляй всё где налепил не правильные ордеры, в этой шмотке может ты просто мп хп не правильно выставил, а вот в любой другой как раз п деф м Деф, и поэтому все скачет при малейшем изменении характеристик. Исправляй что налепил. Кстати это могут быть не только предметы, но и баффы.
От 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к. Потом правда пришлось это переделывать по другому, т.к. оказалось что в данном случае это был неправильный подход, ибо там при экпипировке драко пух вобще полностью убирает лимит на хп, даже если статы на хп идут из других источников, не от пассивки в самой драко пухе
В итоге, когда к примеру в калькуляторе попадается с одним ордером например сложение и умножение - получаем неопределенное поведение, т.к. .раз на раз одна и та же последовательность операций совершенно не гарантируется.
Т.е. один раз к примеру может быть (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к. Потом правда пришлось это переделывать по другому, т.к. оказалось что в данном случае это был неправильный подход, ибо там при экпипировке драко пух вобще полностью убирает лимит на хп, даже если статы на хп идут из других источников, не от пассивки в самой драко пухе
Последнее редактирование:
Спасибо огромное, за такие подробности.От order зависит очередь применения значений статы в калькуляторе - берутся значения с меньшим ордером и по возрастающей.
В итоге, когда к примеру в калькуляторе попадается с одним ордером например сложение и умножение - получаем неопределенное поведение, т.к. .раз на раз одна и та же последовательность операций совершенно не гарантируется.
Т.е. один раз к примеру может быть (x + y) * z, а в другой x * z + y, что само собой приведет к разному результату.
Потому и негласно принято делать для сложения/вычитания и умножения/деления разные значения ордеров, чтобы не было такой путаницы.
0x10/0x0C обычно используют под начальное выставление параметров в предметах и для бонусов от заточки;
0х20 обычно используется для неявных модификаций значения в самом ядре сразу после начальной установки (обычно в классе StatFunctions ядра)
0x30/0x50 для умножения и деления;
0x40/0x60 для сложения и вычитания;
0х80 часто для установки параметра в финальное значение, которое не должно зависеть от других операций над статой, с более низким ордером;
0х100 для лимитирования макс/мин. значения некоторых стат (обычно в классе StatFunctions ядра)
Еще могут иногда задействоваться ордеры выше 0х100, если надо в какой-то ситуации обойти лимит. Я так к примеру какое-то время делал в драко пухах бонус к макс. хп, который должен обходить максимальный лимит хп в 150к. Потом правда пришлось это переделывать по другому, т.к. оказалось что в данном случае это был неправильный подход, ибо там при экпипировке драко пух вобще полностью убирает лимит на хп, даже если статы на хп идут из других источников, не от пассивки в самой драко пухе
