BORDIR

RewardData выполняется уже после подсчета шанса предмета * на рейты. Поэтому теряется начальный шанс предмета. То есть на овере нерейтовость реализована через ограничение количества выпадаемых предметов, а не через х1 шанс. Могу привести практический пример: При любом х дропе, эпики падают 100%, разве это верно? Вот и пытаюсь колдовать)

Вы правы. Разобрался, почему в некоторых случаях все работало, а в остальных нет. Методом тыка) Распространяется на всю группу, поэтому и возникало ощущение, что иногда все работает ок. Когда предметы в разных группах.

Тоже так подумал, даже тему закрыл. Но isAdena же как-то не перекрывает всё еще в самом начале, верно? А также при некоторых условиях все работает. Поэтому все же решил, что решение возможно найти.

Да, это я понимаю, так как сам дописывал На овере немного по-другому в оригинале. Но там вообще нерейтовка на данном моменте не реализована. Сейчас сделаю скрины, а также продемонстрирую проблему.

У тебя х64 платформа?

Скачиваешь работающий дизайн sw13. Затем работаешь над своим index.tpl. Находишь неработающий тэг {тэг} и меняешь на работающий из рабочего дизайна) Все просто.

Ах да, забыл написать, что происходит при нерейтовости: public List<RewardItem> rollItems(double mod, double baseRate, double playerRate) { if(mod <= 0) return Collections.emptyList(); double rate; if(_notRate) rate = playerRate * mod; else rate = baseRate * playerRate * mod; double mult = Math.ceil(rate); List<RewardItem> ret = new ArrayList<RewardItem>((int) (mult * _items.size())); for(long n = 0; n < mult; n++) if(Rnd.get(1, RewardList.MAX_CHANCE) <= _chance * Math.min(rate - n, 1.0)) rollFinal(_items, ret, 1., Math.max(_chanceSum, RewardList.MAX_CHANCE)); return ret; } Может быть и в этом ошибка. В общем постарался расписать проблему по максимуму.

Код в теме с ошибкой выложил : public void addData(RewardData item) { _notRate = false; if(item.getItem().isAdena()) _isAdena = true; if((Config.NO_RATE_EQUIPMENT && item.getItem().isEquipment()) // отключаемая рейтовка эквипа || (Config.NO_RATE_KEY_MATERIAL && item.getItem().isKeyMatherial()) // отключаемая рейтовка ключевых материалов || (Config.NO_RATE_RECIPES && item.getItem().isRecipe()) // отключаемая рейтовка рецептов || ArrayUtils.contains(Config.NO_RATE_ITEMS, item.getItemId) // индивидаульная отключаемая рейтовка для списка предметов || (Config.NO_RATE_HERBS && item.getItem().isHerb()) // отключаемая рейтовка хербов || (Config.NO_RATE_ENCHANT_SCROLL && item.getItem().isEnchantScroll()) || (Config.NO_RATE_ATT && item.getItem().isAttributeCrystal()) || (Config.NO_RATE_ATT && item.getItem().isAttributeJewel()) || (Config.NO_RATE_ATT && item.getItem().isAttributeStone()) || (Config.NO_RATE_ATT && item.getItem().isAttributeEnergy()) || (Config.NO_RATE_LIFE_STONE && item.getItem().isLifeStone()) || (Config.NO_RATE_CODEX_BOOK && item.getItem().isCodexBook()) || (Config.NO_RATE_FORGOTTEN_SCROLL && item.getItem().isForgottenScroll())) _notRate = true; _chanceSum += item.getChance(); item.setChanceInGroup(_chanceSum); _items.add(item); }

Спасибо, не знаю, как я этого не нашел. Лови спасибки)

Где-то идет утечка. Могу скинуть скрины с различными вариантами рейтовости.

Мобы с ЛОА. Как я уже писал, некоторые обрабатываются нормально, остальные криво. При меньшем количестве условий нерейтовости, обрабатываются все (? не уверен).

Либо я вообще неправильно понимаю, что выполняется в данной части кода.

Проверял айди уже, там все в порядке. Возникает ощущение, что данный код проходит только несколько раз, а не через все предметы (не знаю почему) и последнее состояние нерейтовости сохраняется для оставшихся предметов. При пяти условиях, например, у некоторых мобов весь дроп нерейтованный, а у остальных все ок.

Обновил первый пост, моя идея оказалась неудачной, проблема осталась.

Там разные виды атов, так Кекес дописал, лень было просто исправлять. Думал, что разобрался, но не уверен. Сейчас может быть восстановлю текст первого сообщения.

.

UPD Извиняюсь, не разобрался. Всем привет. Уже удалял это сообщение, когда пришла идея в голову, но она оказалась неверной. Поэтому восстанавливаю тему. Буду рад всем, кто откликнется и решит попробовать помочь разобраться. Итак: Последние пару дней работаю над стандартной оверворлдовской системой расчета дропа (High Five) и хочу немного ее изменить, а также разобраться, как работает. Почти все понимаю, где и что происходит, кроме одного(RewardGroup.java): public void addData(RewardData item) { if(item.getItem().isAdena()) _isAdena = true; _chanceSum += item.getChance(); item.setChanceInGroup(_chanceSum); _items.add(item); } Думал, что это и есть фактически самое начало. Добавляются данные в некоторый список итемов. Так вот, для некоторых целей решил изменить данный код (Проверка на нерейтовость еще до выявления рейта из конфига): public void addData(RewardData item) { _notRate = false; if(item.getItem().isAdena()) _isAdena = true; if((Config.NO_RATE_EQUIPMENT && item.getItem().isEquipment()) // отключаемая рейтовка эквипа || (Config.NO_RATE_KEY_MATERIAL && item.getItem().isKeyMatherial()) // отключаемая рейтовка ключевых материалов || (Config.NO_RATE_RECIPES && item.getItem().isRecipe()) // отключаемая рейтовка рецептов || ArrayUtils.contains(Config.NO_RATE_ITEMS, item.getItemId)) // индивидаульная отключаемая рейтовка для списка предметов || (Config.NO_RATE_HERBS && item.getItem().isHerb()) // отключаемая рейтовка хербов || (Config.NO_RATE_ENCHANT_SCROLL && item.getItem().isEnchantScroll()) || (Config.NO_RATE_ATT && item.getItem().isAttributeCrystal()) || (Config.NO_RATE_ATT && item.getItem().isAttributeJewel()) || (Config.NO_RATE_ATT && item.getItem().isAttributeStone()) || (Config.NO_RATE_ATT && item.getItem().isAttributeEnergy()) || (Config.NO_RATE_LIFE_STONE && item.getItem().isLifeStone()) || (Config.NO_RATE_CODEX_BOOK && item.getItem().isCodexBook()) || (Config.NO_RATE_FORGOTTEN_SCROLL && item.getItem().isForgottenScroll())) _notRate = true; _chanceSum += item.getChance(); item.setChanceInGroup(_chanceSum); _items.add(item); } После данных изменений перестают рейтоваться все вещи. Но, если же оставить 3-4 условия, то все работает стабильно. Что-то зажевывается. Помогите, пожалуйста, найти проблему. Если необходимо, могу предоставить полные классы. Всем добра

Спасибо. Сегодня буду разбираться, об успехах отпишу.

Нужно выделить больше память под java приложения, тогда сможешь больше написать в батнике : http://ttyh.ru/topic/62/ (не реклама)

Там привязка только к названиям. А для названий расписаны отдельные условия. Как и какой чат существует. В лыже подобного не находил, там просто id и все отлично работает. А у FT, например для шаута: private static void shout(Player activeChar, Say2 cs) { int rx = MapUtils.regionX(activeChar); int ry = MapUtils.regionY(activeChar); int offset = Config.SHOUT_OFFSET; for(Player player : GameObjectsStorage.getAllPlayersForIterate()) { if(player == activeChar || activeChar.getReflection() != player.getReflection() || player.isBlockAll() || player.isInBlockList(activeChar)) continue; int tx = MapUtils.regionX(player); int ty = MapUtils.regionY(player); if(tx >= rx - offset && tx <= rx + offset && ty >= ry - offset && ty <= ry + offset || activeChar.isInRangeZ(player, Config.CHAT_RANGE)) player.sendPacket(cs); } } На лыже такого не нашел, ибо мне кажется, что там этого нету. Но тогда я не понимаю, как оно там работает О чем я тоже уже писал. Если сможете найти, буду очень благодарен.

Уже писал в теме, что в FT нету привязки к id чатам. Соответственно реализация совершенно другая.

Вы просто ответили на последнее сообщение, не читая темы?) Я знаю, что в лыже все работает. Но я с лыжой не занимаюсь, меня интересует реализация npc_shout на ft, не более)

В l2j там я уже пришел в тупик, дошел до хэндлеров и вызова функций с... "неба") Вот это и есть для меня край. Откуда они уже берутся, мне не ясно. Да, может быть, для такого глубоко погружения в java действительно стоило бы почитать книжки А на FT значительно проще. Там я уже давно нашел, где и как какой чат описывается.

Ну так ладно. На данный момент мне такую работу не осилить. В связи с этим новый вопрос: Я просто даже не могу представить, как все это работает? А именно на L2j? Попробуйте, пожалуйста, объяснить на пальцах К примеру чат тайп NPC_SHOUT. Все, что мы о нем имеем в исходниках это: public static final int NPC_SHOUT = 23; И все. Как серверная и клиентская часть определяют, что это действительно NPC_SHOUT и что его нужно писать именно в данном типе чата? Совершенно не могу этого понять...

Еще немного полазил по коду. На FT привязки к цифровым обозначениям чата нету. Соответственно реализация совершенно другая, чем у l2j. Поэтому либо писать все чаты с нуля, и то неизвестно как, либо искать другие исходники, где похожая реализация.