Нужен совет.

  • Автор темы Автор темы Sunday
  • Дата начала Дата начала
Статус
В этой теме нельзя размещать новые ответы.
Я когда у себя делал рейтовку дропа, то просто сделал число прогонов группы равным рейтам, т.е условно при рейтах на дроп х50, дроп считается так, как будто игрок убил не одного моба, а 50. Это полностью избавляет от проблемы с рейтами при ритейл-лайк реализации дропа-спойла. Возможно ТСу это как-то поможет, но без сурсов там тяжело чет будет разобрать, как и что считается.
 

x1 - x10.webp
Разницы 0

NoRateEtquipmen = true\false - ограничит рейты на кол-во целой экипировки (оружие, броня и пр)
NoRateKeyMaterial = true\false - ограничит рейты на кол-во материалов (куски, ресурсы и пр)
NoRateRecipes = true\false - ограничит рейты на кол-во рецептов

сделал число прогонов группы
это как ?
Отзовитесь кто может помочь с этим, очень нужно как это решить. :cry:
 
Имхо сумма шансов в группе не обязательно должна быть равна 100. Вцелом это изначально кривая механика, которая снижает шанс дропа, так как если у тебя одновременно из одной группы дропает 2 предмета, например брига шлем и его кусок- ты получишь только кусок, так как шанс выше. То как я понял. Интересно услышать механику, как реализованно на птс. И в чем смысл этих групп? Почему не прописать просто шансовый список?
шта?
Из группы, за один проход всегда выбирается только один предмет.
И алгоритм выбора там достаточно примитивный. Если в очень упрощенном виде, то если выпало что из группы должно что-то дропнуться, то кидается рандом на диапазон от 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 - у него хоть и по сути выпадают часто сами группы, но вот уже при выборе награды из группы часто получаем попадание в никуда, т.к. рандомное значение шанса, выпавшее при расчете, превышает сумму имеющихся шансов и при переборе предметов до него даже не доходит.
Вот именно "попадение в никуда" при малом рейте дропа 0, при элементарно х 10, его очень много...
Что тут говорить если с другом дошли до того что решили поставить х3-х4 а в описании писать что у нас х10, НО количиство где в стандарте -5-7шт. достигает большого количества и дропает как на х100.

Если бы можно было дроп оставить как х1 НО имучий шанс повысить, это бы был топ.

Жду помощи человека который готов прыгнуть в норку за зайчиком...
 
Ну, могу посоветовать только проехаться по всему дропу и сделать его "правильно", т.е. чтобы суммы шансов предметов в группах были равны 100% и дальше уже шаманить именно с шансами самих групп, для повышения шансов дропа нужных групп.

З.Ы. видимо в люцере нет валидатора групп дропа. у меня бы сразу были матюки в логе сервера при запуске, если хоть где-то обнаружилось что какая-то из групп дропа у какого-то нпс не соответствует стандарту, т.е. сумма шансов в ней отличается от 100%.
 
шта?
Из группы, за один проход всегда выбирается только один предмет.
И алгоритм выбора там достаточно примитивный. Если в очень упрощенном виде, то если выпало что из группы должно что-то дропнуться, то кидается рандом на диапазон от 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 - у него хоть и по сути выпадают часто сами группы, но вот уже при выборе награды из группы часто получаем попадание в никуда, т.к. рандомное значение шанса, выпавшее при расчете, превышает сумму имеющихся шансов и при переборе предметов до него даже не доходит.
мы похоже про разное. и у автора в сборке другой метод рассчета дропа.
я про другое, я про то, что вообще из группы только один айтем выбирается, получается по одному проходу для каждой группы. В твоем примере шанс выпадения айтема равен произведению шанса группы, на шанс айтема в группе. Но на практике мы получаем по теории вероятностей еще меньший шанс, так как вводится дополнительнео условие, что айтем только один из группы может падать (верно для твоего случая? в некоторых сборках именно так). То есть при совпадении случая, когда повезло и выиграл по вероятности 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"/>

метод дропа уж очень не хочется сейчас искать по файлам... но если надо, то найду
 
я про другое, я про то, что вообще из группы только один айтем выбирается, получается по одному проходу для каждой группы. В твоем примере шанс выпадения айтема равен произведению шанса группы, на шанс айтема в группе. Но на практике мы получаем по теории вероятностей еще меньший шанс, так как вводится дополнительнео условие, что айтем только один из группы может падать (верно для твоего случая? в некоторых сборках именно так). То есть при совпадении случая, когда повезло и выиграл по вероятности 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"/>

метод дропа уж очень не хочется сейчас искать по файлам... но если надо, то найду
Вот как дроп этого НПЦ выглядит на ПТС ХФ
Каждая группа имеет внутри себя общий шанс 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}

}
Т.е тебе с этого моба на ПТС никогда не упадет например одновременно stem и suede. При этом, тебе с моба может вообще ничего не упасть, если не прокнет шанс ни у одной из групп.
 
Последнее редактирование:
Вот как дроп этого НПЦ выглядит на ПТС ХФ
Каждая группа имеет внутри себя общий шанс 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}

}
Т.е тебе с этого моба на ПТС никогда не упадет например одновременно stem и suede. При этом, тебе с моба может вообще ничего не упасть, если не прокнет шанс ни у одной из групп.
У меня на сборке тоже так, если это рейтовая група дропа, там должно быть 100% и сума внутри группы не привышать 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}

}
угу, это я понял, что разные методы рассчета дропа. То есть автору не поможет просто выровнять сумарные шансы в группах до 100%, так как у него скорее всего другой метод рассчета дропа. это первое.

2. я пока не докумекал, какой метод лучше, и какие минусы у того и другого. это надо сравнивать коды методов выбора, не обрезается ли какой дроп из-за того что айтемы в группе конфликтуют при совпадении и выбирается только.

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

ну формально это не совсем корректно, так как по терверу шансы будут разные, но погрешность часто небольшая.

На примере - при рейтах х1 вероятность дропа при 20 попытках айтема с шансом 5% кажется точно должен выпасть, но реально же:
1-(1-0,05)^20 = 0,64 = 64%.
при рейтах х10 классическим методом умножения шанса дропа получаем шанс дропа 50%, и логично, что попыток надо тоже в 10 раз меньше - то есть 2. получаем:
1-(1-0,5)^2 = 0,75 = 75% , то есть заметно выше.

ЗЫ мне этот тервер мозг ломает ((((
 
угу, это я понял, что разные методы рассчета дропа. То есть автору не поможет просто выровнять сумарные шансы в группах до 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% , то есть заметно выше.

ЗЫ мне этот тервер мозг ломает ((((
Зачем вы умножаете шанс на 10? Шанс как был 5% так и остался. То что было увеличено количество попыток, не повысило шанс.
Возможно недопонимание. В моей механике увеличения дропа, количество прогонов группы с каждого моба расчитывается с учетом ее шанса. Т.е если условно шанс группы 1% и рейты х100, то это не значит, что при прохождении шанса 1%, будет выдано 100 итемов. Это значит, что будет 100 попыток реализовать шанс 1%, по итогу которых дропа в целом может и не быть.
 
У меня на сборке тоже так, если это рейтовая група дропа, там должно быть 100% и сума внутри группы не привышать 100%.
НО % от дропа там не меняеться.
А вот если нерейтовая группа то там вообще ничего не рейтуеться, выставляй как хочешь, на первой страничке скидывал это с гайда на сайте зборки.
Шта? что ты подразумеваешь под рейтовой и не рейтовой группой? ты выше приводил пример, где у тебя на х1 в группах сумма шансов не равна 100, а аналогично с моим примером Акиса
Зачем вы умножаете шанс на 10? Шанс как был 5% так и остался. То что было увеличено количество попыток, не повысило шанс.

Это для понимания разницы с вашим вариантом реализации. Увеличение количества проходов в коэффициент рейта дропа сервера не дает ровно такого же умножения шанса дропа по теории вероятностей, как если увеличить не количество проходов, а сам шанс. Чем ниже шанс дропа - тем ниже погрешность, но для высоких значений шанса погрешность думаю может достигать 20-30%, что впрочем не критично

ЗЫ как сказывается на быстродействии такое умножение количества циклов в десятки раз? а если х1000?.... может всетаки отредачить метод, чтобы он шанс/количество пересчитывал от рейтов?
 
Последнее редактирование:
Шта? что ты подразумеваешь под рейтовой и не рейтовой группой? ты выше приводил пример, где у тебя на х1 в группах сумма шансов не равна 100, а аналогично с моим примером Акиса


Это для понимания разницы с вашим вариантом реализации. Увеличение количества проходов в коэффициент рейта дропа сервера не дает ровно такого же умножения шанса дропа по теории вероятностей, как если увеличить не количество проходов, а сам шанс. Чем ниже шанс дропа - тем ниже погрешность, но для высоких значений шанса погрешность думаю может достигать 20-30%, что впрочем не критично
вот
 
Зачем вы умножаете шанс на 10? Шанс как был 5% так и остался. То что было увеличено количество попыток, не повысило шанс.
Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?
 
Шта? что ты подразумеваешь под рейтовой и не рейтовой группой? ты выше приводил пример, где у тебя на х1 в группах сумма шансов не равна 100, а аналогично с моим примером Акиса


Это для понимания разницы с вашим вариантом реализации. Увеличение количества проходов в коэффициент рейта дропа сервера не дает ровно такого же умножения шанса дропа по теории вероятностей, как если увеличить не количество проходов, а сам шанс. Чем ниже шанс дропа - тем ниже погрешность, но для высоких значений шанса погрешность думаю может достигать 20-30%, что впрочем не критично
С корейскими шансами я бы вообще не игрался, т.к там есть неиллюзорный шанс напороться на какой-то корейский костыль, в одном из 20к мобов и заруинить экономику сервера. Поэтому я выбрал метод увеличения количества попыток группы, как наименее инвазивный метод, относительно датапака ПТС.

Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?
В ПТС используется ГПСЧ, под названием Mersenne Twister, который дает очень качественные случайные числа и практически не подвержен тому, о чем вы написали.
 
Такая крутая тема, а ее в раздел флейм закинули. ЪУЪ
 
Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?

В ПТС используется ГПСЧ, под названием Mersenne Twister, который дает очень качественные случайные числа и практически не подвержен тому, о чем вы написали.


Вы о разном. Низ, тут проходы не перемножаются по вероятности, а сумируются. то есть из 10 проходов шанс выкинуть хоть раз орла сильно выше, чем из 1.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху Снизу