Нужен совет.

Статус
В этой теме нельзя размещать новые ответы.
Никак не сказывается. Это обычные арифметические операции, которые даже в сотнях тысяч повторений выполняются за пару десятков миллисекунд даже на простом процессоре. Дроп выдается один раз, по итоговому результату.
 
В оверовском классе Rnd, который юзается по сути везде в сборке для рандомайза, такой же юзается.
Ну и не думаю что явовская реализация оного ГПСЧ сильно отличается от сишной.

З.Ы. я когда у себя озаботился вопросами вероятностей выпадения и того, правильно ли дроп считает в зависимости от разных рейтов и т.д., просто запилил у себя возможность симуляции дропа - т.е. идут все те же расчеты и т.д. что и при обычном дропе, но сами предметы не дропаются - просто отдается инфа о том что выпало. Ну и тестировал, к примеру симулируя 1кк попыток дропа с моба, подсчитывая сколько раз в итоге выпало за столько попыток разных предметов из дропа. ну и из полученных данных легко вывести, с каким шансом они нападали. и чем больше попыток - тем более шанс стремится тому что и задан.
 
Последнее редактирование:
Чет я не помню у оверов реализации вихря Мерсенна. Глянул JTS - там ThreadLocalRandom на XORShift

явовская реализация оного ГПСЧ сильно отличается от сишной.
Нажмите, чтобы раскрыть...
64-битную версию тяжело корректно реализовать прямым портом с Си, т.к в яве нет аналога беззнакового int64, а long покрывает только половину диапазона. Я использую 32-битную версию из библиотеки math3. Разницы нет, кроме потери пары процентов производительности.
 
Последнее редактирование:
ну так в шаре разные версии овера ходят.
в той, что я брал когда-то за основу, юзается MersenneTwister из Apache Commons Math
 
и что в итоге, пересериализовали?
 
Да, я тоже использую реализацию из этой библиотеки, но у меня не овер.
 
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
 

На практике ThreadLocalRandom по сравнению с MersenneTwister дает какое-либо различие в дропе, или это просто из любви к искусству? У меня есть чуйка, что для линеечного рандома любой не самый примитивный рандомайзер подойдет.

вот это красивый подход! ток по хорошему надо наверно хоть х1000 к минимальному шансу дропа, то есть примерно миллиард попыток.
 
Спасибо) Чет я даже не знал про такую либу.

Вот может кому пригодиться реализация для получения double значений между 0 и 1 и гистограму


Код: 
private static final MersenneTwister64 rnd = new MersenneTwister64(new long[0]);

    public static double nextDouble() {
        return Double.longBitsToDouble((rnd.nextLong() >>> 12) | 0x3FFL << 52) - 1.0;
    }

    public static void main(String[] args) {
        double[] h = new double[10];

        int numValues = 10_000_000;
        for (int i = 0; i < numValues; i++) {
            double value = nextDouble();
            int index = (int) (value * 10);
            h[index]++;
        }

        for (int i = 0; i < h.length; i++) {
            h[i] /= numValues;
        }

        for (int i = 0; i < h.length; i++) {
            System.out.println("[" + (i * 0.1) + ", " + ((i + 1) * 0.1) + "): " + h[i]);
        }
    }

Распределение на 10 лямов попыток довольно интересное


Код: 
[0.0, 0.1): 0.1000733
[0.1, 0.2): 0.0998243
[0.2, 0.3): 0.1001036
[0.3, 0.4): 0.099975
[0.4, 0.5): 0.1000705
[0.5, 0.6): 0.0998879
[0.6, 0.7): 0.1000587
[0.7, 0.8): 0.0999524
[0.8, 0.9): 0.1002074
[0.9, 1.0): 0.0998469
 
Последнее редактирование:
По теме, есть кто поможет реализовать проблему )?
 
У меня есть прога для подобных целей.
 
В обсуждении мы потеряли несколько важных вопросов:
1. какого Х в птс выбирается только один предмет из группы? то есть вы фактически теряете дроп, когда у вас выпадает совпадение удачное, например в примере Аристо из Кровавой Королевы не дропнется одновременно несколько ресурсов, хотя шансы даже на х1 достаточно высокие, и периодически идет совпадения 2, а то и более ресов, которые должны выпасть. Получаем и неравномерность дропа, и ниже шанс. то есть по терверу у нас добавляется некорректное условие, что должно настать не только само событие шанса, но и то, что предмет не должен совпасть по группе с одногрупниками. А это урезание шанса выпадения

2. Какой в итоге алгоритм подсчета дропа именно у этой сборки автора? так как автор говорит, что похожий на ПТС, но в его примерах ХМЛЬки явно не так, и нет суммы шансов 100% в рамках группы.

3. зачем вообще в ПТС введены эти группы дропа? ну рассчитывали бы шанс по отдельности на каждый айтем, зачем сложности и урезание дропа такой группировкой?

4. Автор, какая именно у тебя сборка Люцеры, актуальная Дизеровская? или это древняя пародия на нее? Ты вообще уверен, что у тебя дроп на х1 слишком мало, а на х10 - слишком много? может ты х10 и на шанс, и х10 и на дроп ставишь? скинь кусок файла с настройками рейтов сервера, когда ты ставишь х10.


Какая лютая кривота это ваш мобиус... это свежие релизы или калл мамонта? убогий костыль в попытке избежать перехода при некоторых рейтах дропа из шанса в количество, вместо грамотного обработчика.... который при этом работает некорректно. так как допустим захочешь распределить рейты х25 как х5 к шансу и Х5 к количеству, но будет некорректный просчет там, где х5 шанс уже дает шанс выше 100%.


Это всего лишь галки, которые можно проставить, чтобы при установке рейтов некоторые типы дропа не множились. чепуха. перекореживает и так кривую корейскую экономику произвольным образом.


Sunday написал(а):
Посмотреть вложение 74170
Разницы 0
Нажмите, чтобы раскрыть...

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


а) Как определяется разделение по группам? Была бы логика, например целиковый шмот отнести в одну, а ресы, куски и рецепты в другую. но тут намешанно.
б) Как тогда посчитать объективный шанс выпадения айтема? ибо в случае с группами мы имеем не только условие что повезло с результирующим шансом выпадения, равным произведения шанса группы на шанс айтема в группе, но и условие, что этот шанс не должен совпасть с другими шансами из группы? Зачем вообще сделанны группы, если они режут реальные шансы дропа? ЗЫ, душевные терзания вслух: какая же убогая ЛА2, если у тебя с моба 60 лвл шанс выпадения сраной ветки стема - 17%... а авадон робы 1 из 20тыс... симулятор бомжа-терпилы...


А ты и не увидишь в датапаке изменение процента. Он меняется при рассчетах в ядре, в исходах, которых походу у тебя нет.

А рейтовая и не рейтовая группа это про другое. это запрет на применение увеличенных рейтов дропа к некоторым айтемам. то есть ты хоть Хмиллион поставь в настройках сервера, а этот айтем с этого моба всеравно будет х1.


Невозможно заруинить то, чего нет. она изначально космически кривая, но все привыкли считать баг - фичей. у Акиса мне вроде понравился метод пересчета дропа. он там грамотно переводил шансы в количество в случае превышения шанса дропа айтема больше 100%, но там и этой дурацкой системы с 100%й суммой шансов в группе нет. а вот есть ли там выбор только одного айтема в группе- это вопрос, позже найду этот метод, надо глянуть. вообще мне эта система групп кажется предельно уепищьной и попыткой какой-то оптимизации сервера, чтобы он не считал на 20 айтемов шанс, а только на 3-4 группы, а если вдруг выпала группа - только тогда уже шансы в ней, что гораздо реже. абсолютно неактуальной при современных мощностях.

LightFusion написал(а):
Может решить проблему ?
Реализуют задачи/замысли обычно.
Нажмите, чтобы раскрыть...

Нет, в случае автора - это именно реализовать.... костыль к кривой сборке.

z0n4r1e написал(а):
У меня есть прога для подобных целей.
Нажмите, чтобы раскрыть...

1. с какими исходными данными датапака она работает? с группами с сумарным шансом 100%, или с произвольным сумарным шансом в группе?
2. какой метод пересчета дропа от рейтов, при превышения шанса 100% дропа айтема из шанса в количество?
 
Последнее редактирование:
BladeRunner все на самом деле предельно логично, если смотреть на шансы не с точки зрения отдельного игрока, а с точки зрения геймдизайнера, который не хочет, чтобы пять тысяч человек онлайна, 24/7 убивая сотни тысяч мобов ежедневно, на каждом из трех десятков серверов, получили все ценное за первую неделю игры. Также, достаточно логично выглядит то, что большая часть сборок л2 пилилась во времена, когда доступ к ПТС серверу был у единиц, и все механики пилились на глазок. Более того, условному игроку, который не видит циферки дропа(а на офе их не видно) и в голову не придет возмущаться тому, что с моба X падает шмотка Y с шансом 0.0001%, так как он не узнает об этом никогда. Тем более, эта система дропа - наследие тех времен, когда доступ в л2 был по подписке и в игре не было микротранзакций, а компаниям было выгодно, чтобы игрок максимально долго находился в игре, оплачивая подписку. Большая часть проблем л2 связаны с ее возрастом.
 
Позволь не согласиться по всем пунктам))

1. Шансы я предлагал рассмотреть с точки зрения геймдизайнера, а точнее его базового пониманния вероятностей и их взаимодействия.
2. С точки зрения геймдиза НЦсоф обосрались по полной. Они перепутали восхищение игрой, и как следствие, что в ней много проводили время, с тем, что по их мнению людям нравится тупой гринд за последующую эмоцию награды. В итоге они добавили не контента интересного в игру, а количество гринда, необходимого для хай-контента. и тут надо понимать, что хай-контент по хроникам- динамический. То есть в с1 количество гринда чтоб набить 50й лвл, то на ИЛе - набить 78й это в разы дольше. ТЕма не очевидная, и требует углубления, но что точно можно сказать:
3. тупой гринд уничтожил популярность ЛА с точки зрения геймдизайнера. Всегда должен быть баланс между хардкорностью и казуальностью, так как даже затуманеный эмоциями мозг прикидывает нос к х*ю, что слишком уж дофига сложенно сил в сомнительные и не топовые пиксели. так вот с ТЗ геймдизайна баланс хардкорности в ЛА2 прое*бан в десятки раз. Потому и пошел отток игроков. Они позднее пытались костылями в виде ускорения прокачки и автофармом это поправить, но это помогло примерно как крюк пирата пианисту вместо его пальцев.
4. падаешь в крайности, между тем чтобы весь контент выфармить за неделю, и год на х1 со старта без доната набивать по 10 часов день сраный 70й лвл в бомжовском кармиане, если не обузить парики. так низя
5. механики ПТС как я понимаю слили достаточно давно, и примерно во времена ПТС ХФ, если не раньше. и уже можно было много раз отрефакторить код ява-сборок, переписать то пару методов и перепарсить дроп-датапак
6. игрок не настолько даун. Если он убил 1000 мобов на 20 лвл, и с них не дропнулось ничего, серьезнее какого-то нубского шлема, то где-то ,бл*ть подвох явно.
7. все дата-базы были почти с самого появления ЛА2. Я играл с 2004 года, и тогда уже были относительно точные базы благодаря Волкеру, статистику которого по мобам и дропу выгружали, если память не изменяет, на l2wh. То есть игрок, который умнее овоща, мог найти инфу по дропу и шансам.
8. с точки зрения гейм-дизайнера, повторюсь, НЦсофт обосрались по полной, о чем говорит и вся статистика офф серверов. Я играл на еврооффе по подписке в С5-С6, если что. так вот, задача геймдиза при подписке удержать игрока как можно больше дней в игре, и часов в день, чтобы он не бросил игру. а не задолбать его многочасовой игрой в день. Часто решения для удержания по количеству дней противоположенны решениям по удержанию максимум часов в день.
9. большая часть проблем ЛА с возрастом вообще никак не связанна. у шахмат тогда вообще ппц климакс должен быть пару тысячелетий назад. Все проблемы ЛА связанны с придурками- геймдизами. Так как эстетически и по механикам боя+ части геймлея она хороша. Но вот 90% остального геймплея геймдизы обосрали в хлам. И как раз сегодня вышел подкаст у Фокусдеса, где они обсуждают многие косяки современной ЛА и ее геймплейных реалий. По сути ЛА - это яркий пример, как при отличной идее можно все адски обосрать и превратить в голимое казино с колоссальным социальным игровым расслоением и бото-тамагочи. Хочешь успешный сервер? смотриш на офф, и делаешь все наоборот. в некоторой степени мумии первых хроник, в стиле Эльморлаба - и являются некоторым возвращением в более адекватные по геймплею хроники, которые сами по себе предельно не адекватны, но гораздо лучше того, к чему сейчас приплыли. и потому они пользуется немаленьким спросом. как и рейтованные фришки. Но это разные и разрозненные костыли, которые не дают координального улучшения вцелом


по теме:
вот как обрабатывается рейтовое умножение в Акисе:

Now decide the quantity to drop based on the rates and penalties. To get this value
simply divide the modified categoryDropChance by the base category chance. This
results in a chance that will dictate the drops amounts: for each amount over 100
that it is, it will give another chance to add to the min/max quantities.

For example, If the final chance is 120%, then the item should drop between
its min and max one time, and then have 20% chance to drop again. If the final
chance is 330%, it will similarly give 3 times the min and max, and have a 30%
chance to give a 4th time.
At least 1 item will be dropped for sure. So the chance will be adjusted to 100%
if smaller.

Код: 
/**
     * Calculate the quantity for a specific drop.
     * @param drop : The {@link DropData} informations to use.
     * @param levelModifier : The level modifier (will be subtracted from drop chance).
     * @param isSweep : If True, use the spoil drop chance.
     * @return An {@link IntIntHolder} corresponding to the item id and count.
     */
    private IntIntHolder calculateRewardItem(DropData drop, int levelModifier, boolean isSweep)
    {
        // Get default drop chance
        double dropChance = drop.getChance();
       
        if (Config.DEEPBLUE_DROP_RULES)
        {
            int deepBlueDrop = 1;
            if (levelModifier > 0)
            {
                // We should multiply by the server's drop rate, so we always get a low chance of drop for deep blue mobs.
                // NOTE: This is valid only for adena drops! Others drops will still obey server's rate
                deepBlueDrop = 3;
                if (drop.getItemId() == 57)
                {
                    deepBlueDrop *= (isRaidBoss()) ? (int) Config.RATE_DROP_ITEMS_BY_RAID : (int) Config.RATE_DROP_ITEMS;
                    if (deepBlueDrop == 0) // avoid div by 0
                        deepBlueDrop = 1;
                }
            }
           
            // Check if we should apply our maths so deep blue mobs will not drop that easy
            dropChance = ((drop.getChance() - ((drop.getChance() * levelModifier) / 100)) / deepBlueDrop);
        }
       
        // Applies Drop rates
        if (drop.getItemId() == 57)
            dropChance *= Config.RATE_DROP_ADENA;
        else if (isSweep)
            dropChance *= Config.RATE_DROP_SPOIL;
        else
            dropChance *= (isRaidBoss()) ? Config.RATE_DROP_ITEMS_BY_RAID : Config.RATE_DROP_ITEMS;
       
        // Set our limits for chance of drop
        if (dropChance < 1)
            dropChance = 1;
       
        // Get min and max Item quantity that can be dropped in one time
        final int minCount = drop.getMinDrop();
        final int maxCount = drop.getMaxDrop();
       
        // Get the item quantity dropped
        int itemCount = 0;
       
        // Check if the Item must be dropped
        int random = Rnd.get(DropData.MAX_CHANCE);
        while (random < dropChance)
        {
            // Get the item quantity dropped
            if (minCount < maxCount)
                itemCount += Rnd.get(minCount, maxCount);
            else if (minCount == maxCount)
                itemCount += minCount;
            else
                itemCount++;
           
            // Prepare for next iteration if dropChance > DropData.MAX_CHANCE
            dropChance -= DropData.MAX_CHANCE;
        }
       
        if (itemCount > 0)
            return new IntIntHolder(drop.getItemId(), itemCount);
       
        return null;
    }
   
    /**
     * Calculate the quantity for a specific drop, according its {@link DropCategory}.<br>
     * <br>
     * Only a maximum of ONE item from a {@link DropCategory} is allowed to be dropped.
     * @param cat : The {@link DropCategory} informations to use.
     * @param levelModifier : The level modifier (will be subtracted from drop chance).
     * @return An {@link IntIntHolder} corresponding to the item id and count.
     */
    private IntIntHolder calculateCategorizedRewardItem(DropCategory cat, int levelModifier)
    {
        if (cat == null)
            return null;
           
        // Get default drop chance for the category (that's the sum of chances for all items in the category)
        // keep track of the base category chance as it'll be used later, if an item is drop from the category.
        // for everything else, use the total "categoryDropChance"
        int baseCategoryDropChance = cat.getCategoryChance();
        int categoryDropChance = baseCategoryDropChance;
       
        if (Config.DEEPBLUE_DROP_RULES)
        {
            int deepBlueDrop = (levelModifier > 0) ? 3 : 1;
           
            // Check if we should apply our maths so deep blue mobs will not drop that easy
            categoryDropChance = ((categoryDropChance - ((categoryDropChance * levelModifier) / 100)) / deepBlueDrop);
        }
       
        // Applies Drop rates
        categoryDropChance *= (isRaidBoss()) ? Config.RATE_DROP_ITEMS_BY_RAID : Config.RATE_DROP_ITEMS;
       
        // Set our limits for chance of drop
        if (categoryDropChance < 1)
            categoryDropChance = 1;
       
        // Check if an Item from this category must be dropped
        if (Rnd.get(DropData.MAX_CHANCE) < categoryDropChance)
        {
            final DropData drop = cat.dropOne(isRaidBoss());
            if (drop == null)
                return null;
// Now decide the quantity to drop based on the rates and penalties. To get this value
            // simply divide the modified categoryDropChance by the base category chance. This
            // results in a chance that will dictate the drops amounts: for each amount over 100
            // that it is, it will give another chance to add to the min/max quantities.
            //
            // For example, If the final chance is 120%, then the item should drop between
            // its min and max one time, and then have 20% chance to drop again. If the final
            // chance is 330%, it will similarly give 3 times the min and max, and have a 30%
            // chance to give a 4th time.
            // At least 1 item will be dropped for sure. So the chance will be adjusted to 100%
            // if smaller.
         
            double dropChance = drop.getChance();
            if (drop.getItemId() == 57)
                dropChance *= Config.RATE_DROP_ADENA;
            else
                dropChance *= (isRaidBoss()) ? Config.RATE_DROP_ITEMS_BY_RAID : Config.RATE_DROP_ITEMS;
         
            if (dropChance < DropData.MAX_CHANCE)
                dropChance = DropData.MAX_CHANCE;
         
            // Get min and max Item quantity that can be dropped in one time
            final int min = drop.getMinDrop();
            final int max = drop.getMaxDrop();
         
            // Get the item quantity dropped
            int itemCount = 0;
         
            // Check if the Item must be dropped
            int random = Rnd.get(DropData.MAX_CHANCE);
            while (random < dropChance)
            {
                // Get the item quantity dropped
                if (min < max)
                    itemCount += Rnd.get(min, max);
                else if (min == max)
                    itemCount += min;
                else
                    itemCount++;
             
                // Prepare for next iteration if dropChance > DropData.MAX_CHANCE
                dropChance -= DropData.MAX_CHANCE;
            }
         
            if (itemCount > 0)
                return new IntIntHolder(drop.getItemId(), itemCount);
        }
        return null;
    }
 
    /**
     * Calculate the quantity for a specific herb, according its {@link DropCategory}.
     * @param cat : The {@link DropCategory} informations to use.
     * @param levelModifier : The level modifier (will be subtracted from drop chance).
     * @return An {@link IntIntHolder} corresponding to the item id and count.
     */
    private static IntIntHolder calculateCategorizedHerbItem(DropCategory cat, int levelModifier)
    {
        if (cat == null)
            return null;
     
        int categoryDropChance = cat.getCategoryChance();
     
        // Applies Drop rates
        switch (cat.getCategoryType())
        {
            case 1:
                categoryDropChance *= Config.RATE_DROP_HP_HERBS;
                break;
         
            case 2:
                categoryDropChance *= Config.RATE_DROP_MP_HERBS;
                break;
         
            case 3:
                categoryDropChance *= Config.RATE_DROP_SPECIAL_HERBS;
                break;
         
            default:
                categoryDropChance *= Config.RATE_DROP_COMMON_HERBS;
        }
     
        // Drop chance is affected by deep blue drop rule.
        if (Config.DEEPBLUE_DROP_RULES)
        {
            int deepBlueDrop = (levelModifier > 0) ? 3 : 1;
         
            // Check if we should apply our maths so deep blue mobs will not drop that easy
            categoryDropChance = ((categoryDropChance - ((categoryDropChance * levelModifier) / 100)) / deepBlueDrop);
        }
     
        // Check if an Item from this category must be dropped
        if (Rnd.get(DropData.MAX_CHANCE) < Math.max(1, categoryDropChance))
        {
            final DropData drop = cat.dropOne(false);
            if (drop == null)
                return null;
         
            /*
             * Now decide the quantity to drop based on the rates and penalties. To get this value, simply divide the modified categoryDropChance by the base category chance. This results in a chance that will dictate the drops amounts : for each amount over 100 that it is, it will give another
             * chance to add to the min/max quantities. For example, if the final chance is 120%, then the item should drop between its min and max one time, and then have 20% chance to drop again. If the final chance is 330%, it will similarly give 3 times the min and max, and have a 30% chance to
             * give a 4th time. At least 1 item will be dropped for sure. So the chance will be adjusted to 100% if smaller.
             */
            double dropChance = drop.getChance();
         
            switch (cat.getCategoryType())
            {
                case 1:
                    dropChance *= Config.RATE_DROP_HP_HERBS;
                    break;
             
                case 2:
                    dropChance *= Config.RATE_DROP_MP_HERBS;
                    break;
             
                case 3:
                    dropChance *= Config.RATE_DROP_SPECIAL_HERBS;
                    break;
             
                default:
                    dropChance *= Config.RATE_DROP_COMMON_HERBS;
            }
         
            if (dropChance < DropData.MAX_CHANCE)
                dropChance = DropData.MAX_CHANCE;
         
            // Get min and max Item quantity that can be dropped in one time
            final int min = drop.getMinDrop();
            final int max = drop.getMaxDrop();
         
            // Get the item quantity dropped
            int itemCount = 0;
         
            // Check if the Item must be dropped
            int random = Rnd.get(DropData.MAX_CHANCE);
            while (random < dropChance)
            {
                // Get the item quantity dropped
                if (min < max)
                    itemCount += Rnd.get(min, max);
                else if (min == max)
                    itemCount += min;
                else
                    itemCount++;
             
                // Prepare for next iteration if dropChance > L2DropData.MAX_CHANCE
                dropChance -= DropData.MAX_CHANCE;
            }
         
            if (itemCount > 0)
                return new IntIntHolder(drop.getItemId(), itemCount);
        }
        return null;
 
Последнее редактирование:
4. Да, Дизеровская актуальная. Interlude.

Патча нету... на картинке дроп соотвецтвует тому количесту что показивает. т.е если там 1-20 то больше 20 не дропаеться....и процент тоже.
Повторюсь, вот что пишут на форуме зборки, цытирую :
"дизер вроде бы отвечал, что рейт дропа работает только на множку (множитель, условно говоря, изначально шанс выпадения 1 итема 2%, при рейте дропа х10 - будет падает 10 итемов с тем же шансом 2%), что делать с шансом дропа - хз, скорее всего пилить отдельную таску, что бы разграничил шанс/кол-во как и спойлом, аля RateDropSpoil (кол-во) и AltSpoilItemChanceRate (шанс) только по анологии с дропом"

8-9 : Подтверждаю

8-9 : Согласен.
Мысли в слух: Вот по этому и хочеться создать что-то свое, тех времен когда мне было 13 и шпили сутками....фармили крафтили, собирали ресы, трейдили, радовались каждому КК... а знаете почему ?
Да потому что на том же х50 было максимально комфортно играть (да это были явы) НО основная составляющая игры, "дроп" с помощью которого всё и реализуется...ОН БЫЛ АДЕКВАТНЫЙ... а не вот это всё...Я не хочу сервер одно-дневку, мы не делаем его для заработка, мы хотим дать людям то что было у нас. Имея желание и мечту, которую не реализовали тогда в молодости
Зачем мне дроп который херачит 20-50 итемов с 3 мобов, если я хочу их получать с 10-20 мобов, по 2-5 "образно". Хочеться наслаждаться фармом и качем... а не за неделю ити на хиро фуловым....
 
Sunday написал(а):
По теме, есть кто поможет реализовать проблему )?
Нажмите, чтобы раскрыть...
Flylink
Напиши ему лс, много лет назад мы обсуждали парсер дропа под яву с птс с рейтовкой.. (правельную)
как что точно я не помню) но думаю скрипты у него остались!
пс. отписал ему лс в мессенджерах, что бы обратил на тебя внимание.
 
Спасибо.!

Увы, человек занят. На месяц
Тема остается актуальной
 

Вот тебе и Люцера... Я все больше начинаю любить шарный Акис...
Смотри, если тебе надо исправить что-то через задницу, то тебе надо думать как человек, это сделавший)
Как минимум для того чтобы нанять человека - тебе надо четкое ТЗ, а для этого самому разобраться в шизе автора исходов. Чтобы конкретно сказать человеку, что скрипт должен делать вот так-то и так то. Большинство не будут вникать сами , им некогда. Одно дело накидать по образцу парсер с четким ТЗ, другое дело заниматься реверсинженирингом кривого метода пересчета рейтов сборки без исходов. это раз в 50 по времени может отличаться и по цене.

Так что тебе задание:
1. ставишь рейты х1, и идешь ДЕ магом 5 уровня , поставив exp off, убиваешь 100 Goblin. Они около ДЕ деревни , справа, если бежать от точки появления новых ДЕ к городу. пишешь сюда ВСЕ сколько и чего набил. желательно наделать скринов с каждого моба, чтоб потом , если понадобится можно, было увидеть распределение по конкретным ситуациям
2. ставишь рейты х10, и делаешь то же самое.
3. копируешь сюда из датапака сборки дроп этого гоблина, id 20003

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

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


Sunday написал(а):
Увы, человек занят. На месяц
Тема остается актуальной
Нажмите, чтобы раскрыть...

забей, чел мутный, он адекватному сообщению клоунов ставит, а сам по делу даже не удосужился отписаться, хотя явно почитал тему. - Нужен совет.
 
BladeRunner написал(а):
Почему не прописать просто шансовый список?
Нажмите, чтобы раскрыть...
Ну посмотри у мобиуса...
Просто шансово список и все. Там шанс выходит за 100%, а у него рандомится шанс от 0 до 100.
У него даже есть конфиг, который увеличивает шанс выпадения предмета. ТОЛЬКО. Он увеличивает шанс, а не потолок, по-этому условно группа где:
* адена 70%
* сундук 50%
и будет повышен шанс на адена, там на 50% - то это уже 130% и адена, возможно, будет падать постоянно.

Группы же помогают разделить предметы, которые игроки должны получить.
Условно ОДНА из КНИЖЕК, а не все книжки в одном списке и пусть падают по 20 штук, ОДНА или НЕСКОЛЬКО частей брони, обязательно чтоб была адена или другие предметы.
 
Статус
В этой теме нельзя размещать новые ответы.

Похожие темы

  • Закрыта
Нужен ваш совет по серверу Interlude+
2
Ответы
27
Просмотры
1К
Getooo
  • Вопрос
Нужен совет от добрых людей!
Ответы
1
Просмотры
360
Maksim
DDOS - Нужен совет
2
Ответы
29
Просмотры
3К
iScream
Z
Нужен веб дизайн + верстка на ммовеб
Ответы
9
Просмотры
946
crossover
  • Вопрос
Нужен совет по ОБВЯЗКЕ!
2
Ответы
32
Просмотры
2К
Devilart
Меню
Вход
Регистрация