это как ?сделал число прогонов группы
шта?Имхо сумма шансов в группе не обязательно должна быть равна 100. Вцелом это изначально кривая механика, которая снижает шанс дропа, так как если у тебя одновременно из одной группы дропает 2 предмета, например брига шлем и его кусок- ты получишь только кусок, так как шанс выше. То как я понял. Интересно услышать механику, как реализованно на птс. И в чем смысл этих групп? Почему не прописать просто шансовый список?
public ItemData get()
{
int chance = Rnd.get(1, ItemData.MAX_CHANCE);
int current = 0;
for (ItemData item : _items)
{
current += item.getChance();
if (current >= chance)
return item;
}
return null;
}
Вот именно "попадение в никуда" при малом рейте дропа 0, при элементарно х 10, его очень много...шта?
Из группы, за один проход всегда выбирается только один предмет.
И алгоритм выбора там достаточно примитивный. Если в очень упрощенном виде, то если выпало что из группы должно что-то дропнуться, то кидается рандом на диапазон от 0 до суммы шансов всех предметов в группе и потом просто перебираются в цикле все предметы в группе и суммируются их шансы, пока сумма не будет равна или превысит выпавшее при рандоме значение и возвращается текущий предмет, как выбранный для дропа.
Для примера вот код рандомного выбора наград из группы наград, работающий по тому же принципу.
в расчете дропа код посложнее, но общая логика в целом такая же.Java:public ItemData get() { int chance = Rnd.get(1, ItemData.MAX_CHANCE); int current = 0; for (ItemData item : _items) { current += item.getChance(); if (current >= chance) return item; } return null; }
ну и я сомневаюсь что в люцере при расчетах дропа из групп для каждой группы вычисляется ее индивидуальная сумма шансов всех предметов в группе, скорее уж как в большей части всех сборок принимается что она равна значению, равному 100%.
в итоге я не особо удивляюсь тому, что в примере описания дропа, приведенного ТСом, у него такой хреновый дроп при х1 - у него хоть и по сути выпадают часто сами группы, но вот уже при выборе награды из группы часто получаем попадание в никуда, т.к. рандомное значение шанса, выпавшее при расчете, превышает сумму имеющихся шансов и при переборе предметов до него даже не доходит.
мы похоже про разное. и у автора в сборке другой метод рассчета дропа.шта?
Из группы, за один проход всегда выбирается только один предмет.
И алгоритм выбора там достаточно примитивный. Если в очень упрощенном виде, то если выпало что из группы должно что-то дропнуться, то кидается рандом на диапазон от 0 до суммы шансов всех предметов в группе и потом просто перебираются в цикле все предметы в группе и суммируются их шансы, пока сумма не будет равна или превысит выпавшее при рандоме значение и возвращается текущий предмет, как выбранный для дропа.
Для примера вот код рандомного выбора наград из группы наград, работающий по тому же принципу.
в расчете дропа код посложнее, но общая логика в целом такая же.Java:public ItemData get() { int chance = Rnd.get(1, ItemData.MAX_CHANCE); int current = 0; for (ItemData item : _items) { current += item.getChance(); if (current >= chance) return item; } return null; }
ну и я сомневаюсь что в люцере при расчетах дропа из групп для каждой группы вычисляется ее индивидуальная сумма шансов всех предметов в группе, скорее уж как в большей части всех сборок принимается что она равна значению, равному 100%.
в итоге я не особо удивляюсь тому, что в примере описания дропа, приведенного ТСом, у него такой хреновый дроп при х1 - у него хоть и по сути выпадают часто сами группы, но вот уже при выборе награды из группы часто получаем попадание в никуда, т.к. рандомное значение шанса, выпавшее при расчете, превышает сумму имеющихся шансов и при переборе предметов до него даже не доходит.
<npc id="18001" name="Blood Queen" title="">
<drops>
<category id="1">
<drop itemid="2397" min="1" max="1" chance="12"/>
<drop itemid="2402" min="1" max="1" chance="19"/>
<drop itemid="2406" min="1" max="1" chance="8"/>
</category>
<category id="2">
<drop itemid="1419" min="1" max="1" chance="200000"/>
<drop itemid="1864" min="1" max="1" chance="166667"/>
<drop itemid="1866" min="1" max="1" chance="62500"/>
<drop itemid="1878" min="1" max="1" chance="37037"/>
<drop itemid="1885" min="1" max="1" chance="7092"/>
<drop itemid="1889" min="1" max="1" chance="5435"/>
<drop itemid="4069" min="1" max="1" chance="2102"/>
<drop itemid="4070" min="1" max="1" chance="3192"/>
<drop itemid="4071" min="1" max="1" chance="1615"/>
<drop itemid="4197" min="1" max="1" chance="8"/>
</category>
<category id="0">
<drop itemid="57" min="765" max="1528" chance="700000"/>
</category>
<category id="-1">
<drop itemid="1806" min="1" max="1" chance="10868"/>
Вот как дроп этого НПЦ выглядит на ПТС ХФя про другое, я про то, что вообще из группы только один айтем выбирается, получается по одному проходу для каждой группы. В твоем примере шанс выпадения айтема равен произведению шанса группы, на шанс айтема в группе. Но на практике мы получаем по теории вероятностей еще меньший шанс, так как вводится дополнительнео условие, что айтем только один из группы может падать (верно для твоего случая? в некоторых сборках именно так). То есть при совпадении случая, когда повезло и выиграл по вероятности 2 айтема из группы- то получаешь только один. Получается фактическая вероятность еще ниже рассчетной. А с учетом правила, что вероятность выбить из 10 сундуков приз с шансом 10% в сундуке - нифига не равна 100%, а всего 65%, то получаем, что итоговая вероятность выбить айтем еще снижается. Это хорошо видно на высоких рейтах на некоторых сборках. когда должна была дропаться и пуха, а сыпет кусками
Далее, на месте автора, я бы сменил сборку, так как если она даже дроп криво считает при смене рейтов - каких еще гадостей от нее ожидать? Грамотные сборки в рассчете дропа при рейтовом коэффициента сначала повышают шанс дропа, а если он превышает 100%, тогда начинают увеличивать количество.
ну и вот пример хмлки дропа из акиса. Сумма шансов в группе даже близко не равна 100%.
Код:<npc id="18001" name="Blood Queen" title=""> <drops> <category id="1"> <drop itemid="2397" min="1" max="1" chance="12"/> <drop itemid="2402" min="1" max="1" chance="19"/> <drop itemid="2406" min="1" max="1" chance="8"/> </category> <category id="2"> <drop itemid="1419" min="1" max="1" chance="200000"/> <drop itemid="1864" min="1" max="1" chance="166667"/> <drop itemid="1866" min="1" max="1" chance="62500"/> <drop itemid="1878" min="1" max="1" chance="37037"/> <drop itemid="1885" min="1" max="1" chance="7092"/> <drop itemid="1889" min="1" max="1" chance="5435"/> <drop itemid="4069" min="1" max="1" chance="2102"/> <drop itemid="4070" min="1" max="1" chance="3192"/> <drop itemid="4071" min="1" max="1" chance="1615"/> <drop itemid="4197" min="1" max="1" chance="8"/> </category> <category id="0"> <drop itemid="57" min="765" max="1528" chance="700000"/> </category> <category id="-1"> <drop itemid="1806" min="1" max="1" chance="10868"/>
метод дропа уж очень не хочется сейчас искать по файлам... но если надо, то найду
additional_make_multi_list={
{
{
{[adena];765;1528;100}
};70};
{
{
{[tunic_of_shrnoen];1;1;0.1646};
{[tunic_of_shrnoen_fabric];1;1;30.262};
{[hose_of_shrnoen];1;1;0.2638};
{[hose_of_shrnoen_fabric];1;1;45.9482};
{[avadon_robe];1;1;0.1126};
{[avadon_robe_fabric];1;1;23.2488}
};0.6946};
{
{
{[stem];1;1;62.1614};
{[suede];1;1;20.7205};
{[braided_hemp];1;1;12.4323};
{[high_grade_suede];1;1;2.5901};
{[compound_braid];1;1;2.072};
{[rp_demon's_sword];1;1;0.0237}
;28.6912};
{
{
{[proof_of_blood];1;1;100}
};20}
}
У меня на сборке тоже так, если это рейтовая група дропа, там должно быть 100% и сума внутри группы не привышать 100%.Вот как дроп этого НПЦ выглядит на ПТС ХФ
Каждая группа имеет внутри себя общий шанс 100%.
Т.е тебе с этого моба на ПТС никогда не упадет например одновременно stem и suede. При этом, тебе с моба может вообще ничего не упасть, если не прокнет шанс ни у одной из групп.Код:additional_make_multi_list={ { { {[adena];765;1528;100} };70}; { { {[tunic_of_shrnoen];1;1;0.1646}; {[tunic_of_shrnoen_fabric];1;1;30.262}; {[hose_of_shrnoen];1;1;0.2638}; {[hose_of_shrnoen_fabric];1;1;45.9482}; {[avadon_robe];1;1;0.1126}; {[avadon_robe_fabric];1;1;23.2488} };0.6946}; { { {[stem];1;1;62.1614}; {[suede];1;1;20.7205}; {[braided_hemp];1;1;12.4323}; {[high_grade_suede];1;1;2.5901}; {[compound_braid];1;1;2.072}; {[rp_demon's_sword];1;1;0.0237} ;28.6912}; { { {[proof_of_blood];1;1;100} };20} }
угу, это я понял, что разные методы рассчета дропа. То есть автору не поможет просто выровнять сумарные шансы в группах до 100%, так как у него скорее всего другой метод рассчета дропа. это первое.Вот как дроп этого НПЦ выглядит на ПТС ХФ
Каждая группа имеет внутри себя общий шанс 100%.
Код:additional_make_multi_list={ { { {[adena];765;1528;100} };70}; { { {[tunic_of_shrnoen];1;1;0.1646}; {[tunic_of_shrnoen_fabric];1;1;30.262}; {[hose_of_shrnoen];1;1;0.2638}; {[hose_of_shrnoen_fabric];1;1;45.9482}; {[avadon_robe];1;1;0.1126}; {[avadon_robe_fabric];1;1;23.2488} };0.6946}; { { {[stem];1;1;62.1614}; {[suede];1;1;20.7205}; {[braided_hemp];1;1;12.4323}; {[high_grade_suede];1;1;2.5901}; {[compound_braid];1;1;2.072}; {[rp_demon's_sword];1;1;0.0237} ;28.6912}; { { {[proof_of_blood];1;1;100} };20} }
Я когда у себя делал рейтовку дропа, то просто сделал число прогонов группы равным рейтам, т.е условно при рейтах на дроп х50, дроп считается так, как будто игрок убил не одного моба, а 50. Это полностью избавляет от проблемы с рейтами при ритейл-лайк реализации дропа-спойла. Возможно ТСу это как-то поможет, но без сурсов там тяжело чет будет разобрать, как и что считается.
Зачем вы умножаете шанс на 10? Шанс как был 5% так и остался. То что было увеличено количество попыток, не повысило шанс.угу, это я понял, что разные методы рассчета дропа. То есть автору не поможет просто выровнять сумарные шансы в группах до 100%, так как у него скорее всего другой метод рассчета дропа. это первое.
2. я пока не докумекал, какой метод лучше, и какие минусы у того и другого. это надо сравнивать коды методов выбора, не обрезается ли какой дроп из-за того что айтемы в группе конфликтуют при совпадении и выбирается только.
ну формально это не совсем корректно, так как по терверу шансы будут разные, но погрешность часто небольшая.
На примере - при рейтах х1 вероятность дропа при 20 попытках айтема с шансом 5% кажется точно должен выпасть, но реально же:
1-(1-0,05)^20 = 0,64 = 64%.
при рейтах х10 классическим методом умножения шанса дропа получаем шанс дропа 50%, и логично, что попыток надо тоже в 10 раз меньше - то есть 2. получаем:
1-(1-0,5)^2 = 0,75 = 75% , то есть заметно выше.
ЗЫ мне этот тервер мозг ломает ((((
Шта? что ты подразумеваешь под рейтовой и не рейтовой группой? ты выше приводил пример, где у тебя на х1 в группах сумма шансов не равна 100, а аналогично с моим примером АкисаУ меня на сборке тоже так, если это рейтовая група дропа, там должно быть 100% и сума внутри группы не привышать 100%.
НО % от дропа там не меняеться.
А вот если нерейтовая группа то там вообще ничего не рейтуеться, выставляй как хочешь, на первой страничке скидывал это с гайда на сайте зборки.
Зачем вы умножаете шанс на 10? Шанс как был 5% так и остался. То что было увеличено количество попыток, не повысило шанс.
вотШта? что ты подразумеваешь под рейтовой и не рейтовой группой? ты выше приводил пример, где у тебя на х1 в группах сумма шансов не равна 100, а аналогично с моим примером Акиса
Это для понимания разницы с вашим вариантом реализации. Увеличение количества проходов в коэффициент рейта дропа сервера не дает ровно такого же умножения шанса дропа по теории вероятностей, как если увеличить не количество проходов, а сам шанс. Чем ниже шанс дропа - тем ниже погрешность, но для высоких значений шанса погрешность думаю может достигать 20-30%, что впрочем не критично
Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?Зачем вы умножаете шанс на 10? Шанс как был 5% так и остался. То что было увеличено количество попыток, не повысило шанс.
С корейскими шансами я бы вообще не игрался, т.к там есть неиллюзорный шанс напороться на какой-то корейский костыль, в одном из 20к мобов и заруинить экономику сервера. Поэтому я выбрал метод увеличения количества попыток группы, как наименее инвазивный метод, относительно датапака ПТС.Шта? что ты подразумеваешь под рейтовой и не рейтовой группой? ты выше приводил пример, где у тебя на х1 в группах сумма шансов не равна 100, а аналогично с моим примером Акиса
Это для понимания разницы с вашим вариантом реализации. Увеличение количества проходов в коэффициент рейта дропа сервера не дает ровно такого же умножения шанса дропа по теории вероятностей, как если увеличить не количество проходов, а сам шанс. Чем ниже шанс дропа - тем ниже погрешность, но для высоких значений шанса погрешность думаю может достигать 20-30%, что впрочем не критично
В ПТС используется ГПСЧ, под названием Mersenne Twister, который дает очень качественные случайные числа и практически не подвержен тому, о чем вы написали.Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?
Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?
В ПТС используется ГПСЧ, под названием Mersenne Twister, который дает очень качественные случайные числа и практически не подвержен тому, о чем вы написали.
Сам в шоке, что я тут развёлТакая крутая тема, а ее в раздел флейм закинули. ЪУЪ
нужен код метода подсчета шанса дропа от рейтов. вот патаму я не рассматривал для себя сборки без исходов....
Он может и х*** за воротник насовать, опасно (без негатива)Сам в шоке, что я тут развёл
П.С надо Дизира сюда как-то позвать )))
Deazer
обратите внимание пожалуйста !!!!
СогласенОн может и х*** за воротник насовать, опасно (без негатива)
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?