Никак не сказывается. Это обычные арифметические операции, которые даже в сотнях тысяч повторений выполняются за пару десятков миллисекунд даже на простом процессоре. Дроп выдается один раз, по итоговому результату.
Нужен совет.
- Автор темы Sunday
- Дата начала
- Статус
В оверовском классе Rnd, который юзается по сути везде в сборке для рандомайза, такой же юзается.
Ну и не думаю что явовская реализация оного ГПСЧ сильно отличается от сишной.
З.Ы. я когда у себя озаботился вопросами вероятностей выпадения и того, правильно ли дроп считает в зависимости от разных рейтов и т.д., просто запилил у себя возможность симуляции дропа - т.е. идут все те же расчеты и т.д. что и при обычном дропе, но сами предметы не дропаются - просто отдается инфа о том что выпало. Ну и тестировал, к примеру симулируя 1кк попыток дропа с моба, подсчитывая сколько раз в итоге выпало за столько попыток разных предметов из дропа. ну и из полученных данных легко вывести, с каким шансом они нападали. и чем больше попыток - тем более шанс стремится тому что и задан.
Последнее редактирование:
Чет я не помню у оверов реализации вихря Мерсенна. Глянул JTS - там ThreadLocalRandom на XORShift
64-битную версию тяжело корректно реализовать прямым портом с Си, т.к в яве нет аналога беззнакового int64, а long покрывает только половину диапазона. Я использую 32-битную версию из библиотеки math3. Разницы нет, кроме потери пары процентов производительности.
Последнее редактирование:
Да, я тоже использую реализацию из этой библиотеки, но у меня не овер.
На практике 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%.
Это всего лишь галки, которые можно проставить, чтобы при установке рейтов некоторые типы дропа не множились. чепуха. перекореживает и так кривую корейскую экономику произвольным образом.
Да, естественно разницы ноль. Это картинки клиента. Они никакого отношения к твоим данным на сервере не имеют. Или у тебя есть патч, который переписывает описания в клиенте исходя из настроек рейтов сервера? ты уверен, что этот патч полностью совпадает с формулами ядра сборки?
а) Как определяется разделение по группам? Была бы логика, например целиковый шмот отнести в одну, а ресы, куски и рецепты в другую. но тут намешанно.
б) Как тогда посчитать объективный шанс выпадения айтема? ибо в случае с группами мы имеем не только условие что повезло с результирующим шансом выпадения, равным произведения шанса группы на шанс айтема в группе, но и условие, что этот шанс не должен совпасть с другими шансами из группы? Зачем вообще сделанны группы, если они режут реальные шансы дропа? ЗЫ, душевные терзания вслух: какая же убогая ЛА2, если у тебя с моба 60 лвл шанс выпадения сраной ветки стема - 17%... а авадон робы 1 из 20тыс... симулятор бомжа-терпилы...
А ты и не увидишь в датапаке изменение процента. Он меняется при рассчетах в ядре, в исходах, которых походу у тебя нет.
А рейтовая и не рейтовая группа это про другое. это запрет на применение увеличенных рейтов дропа к некоторым айтемам. то есть ты хоть Хмиллион поставь в настройках сервера, а этот айтем с этого моба всеравно будет х1.
Невозможно заруинить то, чего нет. она изначально космически кривая, но все привыкли считать баг - фичей. у Акиса мне вроде понравился метод пересчета дропа. он там грамотно переводил шансы в количество в случае превышения шанса дропа айтема больше 100%, но там и этой дурацкой системы с 100%й суммой шансов в группе нет. а вот есть ли там выбор только одного айтема в группе- это вопрос, позже найду этот метод, надо глянуть. вообще мне эта система групп кажется предельно уепищьной и попыткой какой-то оптимизации сервера, чтобы он не считал на 20 айтемов шанс, а только на 3-4 группы, а если вдруг выпала группа - только тогда уже шансы в ней, что гораздо реже. абсолютно неактуальной при современных мощностях.
Нет, в случае автора - это именно реализовать.... костыль к кривой сборке.
1. с какими исходными данными датапака она работает? с группами с сумарным шансом 100%, или с произвольным сумарным шансом в группе?
2. какой метод пересчета дропа от рейтов, при превышения шанса 100% дропа айтема из шанса в количество?
1. какого Х в птс выбирается только один предмет из группы? то есть вы фактически теряете дроп, когда у вас выпадает совпадение удачное, например в примере Аристо из Кровавой Королевы не дропнется одновременно несколько ресурсов, хотя шансы даже на х1 достаточно высокие, и периодически идет совпадения 2, а то и более ресов, которые должны выпасть. Получаем и неравномерность дропа, и ниже шанс. то есть по терверу у нас добавляется некорректное условие, что должно настать не только само событие шанса, но и то, что предмет не должен совпасть по группе с одногрупниками. А это урезание шанса выпадения
2. Какой в итоге алгоритм подсчета дропа именно у этой сборки автора? так как автор говорит, что похожий на ПТС, но в его примерах ХМЛЬки явно не так, и нет суммы шансов 100% в рамках группы.
3. зачем вообще в ПТС введены эти группы дропа? ну рассчитывали бы шанс по отдельности на каждый айтем, зачем сложности и урезание дропа такой группировкой?
4. Автор, какая именно у тебя сборка Люцеры, актуальная Дизеровская? или это древняя пародия на нее? Ты вообще уверен, что у тебя дроп на х1 слишком мало, а на х10 - слишком много? может ты х10 и на шанс, и х10 и на дроп ставишь? скинь кусок файла с настройками рейтов сервера, когда ты ставишь х10.
Какая лютая кривота это ваш мобиус... это свежие релизы или калл мамонта? убогий костыль в попытке избежать перехода при некоторых рейтах дропа из шанса в количество, вместо грамотного обработчика.... который при этом работает некорректно. так как допустим захочешь распределить рейты х25 как х5 к шансу и Х5 к количеству, но будет некорректный просчет там, где х5 шанс уже дает шанс выше 100%.
Это всего лишь галки, которые можно проставить, чтобы при установке рейтов некоторые типы дропа не множились. чепуха. перекореживает и так кривую корейскую экономику произвольным образом.
Да, естественно разницы ноль. Это картинки клиента. Они никакого отношения к твоим данным на сервере не имеют. Или у тебя есть патч, который переписывает описания в клиенте исходя из настроек рейтов сервера? ты уверен, что этот патч полностью совпадает с формулами ядра сборки?
а) Как определяется разделение по группам? Была бы логика, например целиковый шмот отнести в одну, а ресы, куски и рецепты в другую. но тут намешанно.
б) Как тогда посчитать объективный шанс выпадения айтема? ибо в случае с группами мы имеем не только условие что повезло с результирующим шансом выпадения, равным произведения шанса группы на шанс айтема в группе, но и условие, что этот шанс не должен совпасть с другими шансами из группы? Зачем вообще сделанны группы, если они режут реальные шансы дропа? ЗЫ, душевные терзания вслух: какая же убогая ЛА2, если у тебя с моба 60 лвл шанс выпадения сраной ветки стема - 17%... а авадон робы 1 из 20тыс... симулятор бомжа-терпилы...
А ты и не увидишь в датапаке изменение процента. Он меняется при рассчетах в ядре, в исходах, которых походу у тебя нет.
А рейтовая и не рейтовая группа это про другое. это запрет на применение увеличенных рейтов дропа к некоторым айтемам. то есть ты хоть Хмиллион поставь в настройках сервера, а этот айтем с этого моба всеравно будет х1.
Невозможно заруинить то, чего нет. она изначально космически кривая, но все привыкли считать баг - фичей. у Акиса мне вроде понравился метод пересчета дропа. он там грамотно переводил шансы в количество в случае превышения шанса дропа айтема больше 100%, но там и этой дурацкой системы с 100%й суммой шансов в группе нет. а вот есть ли там выбор только одного айтема в группе- это вопрос, позже найду этот метод, надо глянуть. вообще мне эта система групп кажется предельно уепищьной и попыткой какой-то оптимизации сервера, чтобы он не считал на 20 айтемов шанс, а только на 3-4 группы, а если вдруг выпала группа - только тогда уже шансы в ней, что гораздо реже. абсолютно неактуальной при современных мощностях.
Нет, в случае автора - это именно реализовать.... костыль к кривой сборке.
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 "образно". Хочеться наслаждаться фармом и качем... а не за неделю ити на хиро фуловым....
Flylink
Напиши ему лс, много лет назад мы обсуждали парсер дропа под яву с птс с рейтовкой.. (правельную)
как что точно я не помню) но думаю скрипты у него остались!
пс. отписал ему лс в мессенджерах, что бы обратил на тебя внимание.
Спасибо.!
Увы, человек занят. На месяц
Тема остается актуальной
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 "образно". Хочеться наслаждаться фармом и качем... а не за неделю ити на хиро фуловым....
Вот тебе и Люцера... Я все больше начинаю любить шарный Акис...
Смотри, если тебе надо исправить что-то через задницу, то тебе надо думать как человек, это сделавший)
Как минимум для того чтобы нанять человека - тебе надо четкое ТЗ, а для этого самому разобраться в шизе автора исходов. Чтобы конкретно сказать человеку, что скрипт должен делать вот так-то и так то. Большинство не будут вникать сами , им некогда. Одно дело накидать по образцу парсер с четким ТЗ, другое дело заниматься реверсинженирингом кривого метода пересчета рейтов сборки без исходов. это раз в 50 по времени может отличаться и по цене.
Так что тебе задание:
1. ставишь рейты х1, и идешь ДЕ магом 5 уровня , поставив exp off, убиваешь 100 Goblin. Они около ДЕ деревни , справа, если бежать от точки появления новых ДЕ к городу. пишешь сюда ВСЕ сколько и чего набил. желательно наделать скринов с каждого моба, чтоб потом , если понадобится можно, было увидеть распределение по конкретным ситуациям
2. ставишь рейты х10, и делаешь то же самое.
3. копируешь сюда из датапака сборки дроп этого гоблина, id 20003
Из этой инфы попробуем отреверсить шизу метода рейтовки дропа. а далее подумаем, как с учетом этой шизы можно перепарсить датапак, чтобы через этот костыль одной шизой исправить шизу сборки, и сделать адекватное решение.
по поводу 8-9: забудь про 13 лет., их не вернуть. а если вернешь - то тебе это не понравится, столько времени всирать на пиксели и гриндить часами. создавать надо что-то, что будет интересно и кайфово играться с учетом нынешнего свободного времени и имеющегося опыта.
Увы, человек занят. На месяц
Тема остается актуальной
забей, чел мутный, он адекватному сообщению клоунов ставит, а сам по делу даже не удосужился отписаться, хотя явно почитал тему. - Нужен совет.
Ну посмотри у мобиуса...
Просто шансово список и все. Там шанс выходит за 100%, а у него рандомится шанс от 0 до 100.
У него даже есть конфиг, который увеличивает шанс выпадения предмета. ТОЛЬКО. Он увеличивает шанс, а не потолок, по-этому условно группа где:
* адена 70%
* сундук 50%
и будет повышен шанс на адена, там на 50% - то это уже 130% и адена, возможно, будет падать постоянно.
Группы же помогают разделить предметы, которые игроки должны получить.
Условно ОДНА из КНИЖЕК, а не все книжки в одном списке и пусть падают по 20 штук, ОДНА или НЕСКОЛЬКО частей брони, обязательно чтоб была адена или другие предметы.
- Статус
