Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нём некорректно. Вам необходимо обновить браузер или попробовать использовать другой.
Я когда у себя делал рейтовку дропа, то просто сделал число прогонов группы равным рейтам, т.е условно при рейтах на дроп х50, дроп считается так, как будто игрок убил не одного моба, а 50. Это полностью избавляет от проблемы с рейтами при ритейл-лайк реализации дропа-спойла. Возможно ТСу это как-то поможет, но без сурсов там тяжело чет будет разобрать, как и что считается.
Имхо сумма шансов в группе не обязательно должна быть равна 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%.
я про другое, я про то, что вообще из группы только один айтем выбирается, получается по одному проходу для каждой группы. В твоем примере шанс выпадения айтема равен произведению шанса группы, на шанс айтема в группе. Но на практике мы получаем по теории вероятностей еще меньший шанс, так как вводится дополнительнео условие, что айтем только один из группы может падать (верно для твоего случая? в некоторых сборках именно так). То есть при совпадении случая, когда повезло и выиграл по вероятности 2 айтема из группы- то получаешь только один. Получается фактическая вероятность еще ниже рассчетной. А с учетом правила, что вероятность выбить из 10 сундуков приз с шансом 10% в сундуке - нифига не равна 100%, а всего 65%, то получаем, что итоговая вероятность выбить айтем еще снижается. Это хорошо видно на высоких рейтах на некоторых сборках. когда должна была дропаться и пуха, а сыпет кусками
Далее, на месте автора, я бы сменил сборку, так как если она даже дроп криво считает при смене рейтов - каких еще гадостей от нее ожидать? Грамотные сборки в рассчете дропа при рейтовом коэффициента сначала повышают шанс дропа, а если он превышает 100%, тогда начинают увеличивать количество.
ну и вот пример хмлки дропа из акиса. Сумма шансов в группе даже близко не равна 100%.
Т.е тебе с этого моба на ПТС никогда не упадет например одновременно stem и suede. При этом, тебе с моба может вообще ничего не упасть, если не прокнет шанс ни у одной из групп.
Т.е тебе с этого моба на ПТС никогда не упадет например одновременно stem и suede. При этом, тебе с моба может вообще ничего не упасть, если не прокнет шанс ни у одной из групп.
У меня на сборке тоже так, если это рейтовая група дропа, там должно быть 100% и сума внутри группы не привышать 100%.
НО % от дропа там не меняеться.
А вот если нерейтовая группа то там вообще ничего не рейтуеться, выставляй как хочешь, на первой страничке скидывал это с гайда на сайте зборки.
угу, это я понял, что разные методы рассчета дропа. То есть автору не поможет просто выровнять сумарные шансы в группах до 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, а аналогично с моим примером Акиса
Это для понимания разницы с вашим вариантом реализации. Увеличение количества проходов в коэффициент рейта дропа сервера не дает ровно такого же умножения шанса дропа по теории вероятностей, как если увеличить не количество проходов, а сам шанс. Чем ниже шанс дропа - тем ниже погрешность, но для высоких значений шанса погрешность думаю может достигать 20-30%, что впрочем не критично
ЗЫ как сказывается на быстродействии такое умножение количества циклов в десятки раз? а если х1000?.... может всетаки отредачить метод, чтобы он шанс/количество пересчитывал от рейтов?
Шта? что ты подразумеваешь под рейтовой и не рейтовой группой? ты выше приводил пример, где у тебя на х1 в группах сумма шансов не равна 100, а аналогично с моим примером Акиса
Это для понимания разницы с вашим вариантом реализации. Увеличение количества проходов в коэффициент рейта дропа сервера не дает ровно такого же умножения шанса дропа по теории вероятностей, как если увеличить не количество проходов, а сам шанс. Чем ниже шанс дропа - тем ниже погрешность, но для высоких значений шанса погрешность думаю может достигать 20-30%, что впрочем не критично
Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?
Шта? что ты подразумеваешь под рейтовой и не рейтовой группой? ты выше приводил пример, где у тебя на х1 в группах сумма шансов не равна 100, а аналогично с моим примером Акиса
Это для понимания разницы с вашим вариантом реализации. Увеличение количества проходов в коэффициент рейта дропа сервера не дает ровно такого же умножения шанса дропа по теории вероятностей, как если увеличить не количество проходов, а сам шанс. Чем ниже шанс дропа - тем ниже погрешность, но для высоких значений шанса погрешность думаю может достигать 20-30%, что впрочем не критично
С корейскими шансами я бы вообще не игрался, т.к там есть неиллюзорный шанс напороться на какой-то корейский костыль, в одном из 20к мобов и заруинить экономику сервера. Поэтому я выбрал метод увеличения количества попыток группы, как наименее инвазивный метод, относительно датапака ПТС.
Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?
В ПТС используется ГПСЧ, под названием Mersenne Twister, который дает очень качественные случайные числа и практически не подвержен тому, о чем вы написали.
Разве последовательность % события с каждой итерацией не уменьшается? Мне казалось, что если мы рассмотрим классический пример броска монетки, где 50% на орла, то вероятность того, что мы два раза подряд получим орла уже составит 25% и тд. Или я ошибаюсь?
В ПТС используется ГПСЧ, под названием Mersenne Twister, который дает очень качественные случайные числа и практически не подвержен тому, о чем вы написали.
На данном сайте используются файлы cookie, чтобы персонализировать содержимое и сохранить Ваш вход в систему, если Вы зарегистрируетесь.
Продолжая использовать этот сайт, Вы соглашаетесь на использование наших файлов cookie.