Gaikotsu

немного конструктивной критики на тему доп. вещей получаемых при кристаллизации. у тебя в корне неправильные шансы выставлены на все это дело. даю подсказку - шансы и количество вещей при кристаллизации напрямую зависят от количества кристаллов в кристаллизуемом предмете и считаются по простенькой формуле. хотя для понятности просто покажу фрагмент кода, в котором это считается. for (CrystallizeItem item : _rewards.get(template.getItemGrade()).get(template.isWeapon() ? 0 : 1)) { double chance = item.getChance() * crystalAmount; int count = item.getCount(); if (chance > 100.0D) { double countMul = Math.ceil(chance / 100.0D); chance /= countMul; count *= countMul; } rewards.add(new CrystallizeItem(item.getId(), count, chance)); } где item.getChance() - шанс получения предмета в пресчете на 1 кристалл. шансы и т.д. для каждого предмета в каждой комбинации грейда и типа кристаллизуемой вещи говорить не буду - это все легко высчитать руководствуясь хотя бы теми же скринами с оффа на которых видно какие шансы получения идут для разных вещей. В итоге, по крайней мере у меня, получилось что для любой вещи A - R99 грейдов результаты почти в один в один совпадают с тем что имеется на оффе - без небольших погрешностей в доли % конечно не обошлось, но это уже сущие мелочи. и мне для этого совершенно не требуется расписывать награды для каждой кристаллизуемой вещи - достаточно одного маленького файла, в котором перечислены награды для всех нужных комбинаций грейдов и типов вещей. З.Ы. и еще уточню - в качестве количества кристаллов всегда используется базовое количество, а не то что есть реально у вещи на данный момент - я про ситуацию с заточенными вещами (в них количество кристаллов при кристаллизации увеличивается по немудреной формуле).

обычное 32битное число. переведи в хекс и будет тебе более понятный код цвета, в виде FFFF77 а в каком это формате - RGB или BGR - зависит уже от того как именно в серве формируется это дело, но чаще всего клиентом вроде используется BGR.

блин, что за привычка создавать все эти костыли в виде подсчета онлайна и всего такого через запросы в БД?.. для кого вообще сделан в сервере специальный пакет, получить который можно сделав запрос с сайта на игровой порт сервера и получив в ответ данные об онлайне, притом с детализацией типа: сколько всего народа в онлайне, сколько сидит в трейде и т.д.?

ну дак проблема в геодвижке - недоработанный он у тебя в сборке, коли пути для мобов не строятся.

все от сборки зависит и геодвижка в ней - не во всех патчнод требуется, зачастую пути и на лету создаются

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

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

кинь сюда исходный EnterWorld.class

geo - https://mega.co.nz/#!RBFXWTQI!ThTGIyeY-TOwGVIujhcINQIgf3ANF7fn81pk6-uDWAg idx - https://mega.co.nz/#!QY1VHJwQ!DraIBhOJSr0NUXSM0UePOxsNNqAykvaLeNMMc9YkYjQ

вырвиглазный декомпил... дай угадаю - JD или DJ Java Decompiler? в любом случае после декомпила подобными вещами сразу же обратный компил без ошибок почти нереален - требуется тщательно выправлять все внесенные декомпилятором косяки. к примеру вот этот бред с меткой label150: boolean bool1; и т.д. З.Ы. более чистый декомпил делает fernflower - чаще всего после его работы результат без корректировок обратно компилится без ошибок.

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

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

ну-ну... учитывая еще что у тебя в сборке и скрипты датапака скомпилены и собраны в jar (и наверняка java-файлы из датапака сервером при загрузке уже не подхватываются) всем страждущим, для добавления любой новой распаковываемой вещи придется искать тебя и просить чтобы ты добавил хэндлер для данной вещи - это да, конечно, очень "удобно". З.Ы. вообще если честно не понимаю такого стремления все запихать поглубже, не давая возможности пользователям сборки самим что либо менять или добавлять. со стороны автора сборки конечно полная зависимость во всем от него хороша, но только до того момента, пока ему не надоест работать над сборкой или до момента ухода в приват. в итоге пользователи сборки встают перед выбором - или искать новую сборку или платить за новые версии.

http://www.l2jserver.com/forum/viewtopic.php?t=28165

при заходе слать ему пакеты с инфой о пати

а вот и нифига на офф форуме l2jserver полная и вполне качественная геодата для линдвиора уже больше полутора месяцев как лежит, доступная для скачивания. З.Ы. там же и от того же автора имеется полная гео для хф.

по мне дак что этот способ, что способ с extractable_items.csv - та еще извратность. первый в силу того что для каждого распаковываемого предмета надо писать отдельный метод, внутри которого перечислены ид предметов и шансы + вызов extractRandomOneItem, а потом регистрировать эти методы в хэндлерах. ну а второй в силу своей достаточной примитивности и посему сложности описания каких-то особенных распаковок. лично мой выбор давно уже - уинверсальный хэндлер для всех подобных вещей + xml'ка, в которой все эти вещи расписаны с деталями, как конкретно их распаковывать и данные из которой этот хэндлер использует. что-то типа такого: парсер и обработчик подобных данных делается на раз, максимум за пару часов. и таким образом у меня расписано уже более 2к итемов + на очереди еще около 1к, просто никак руки не доходят доописать их.

вобще, логичней было бы наваять текстурки с отдельными буквами, чтобы народ сам мог собирать необходимые фразы

и чего все зациклились на этих fileedit'ах то? для правки dat-файлов клиента ничего лучше связки l2encdec + l2asm/l2disasm + блокнот или аналог + несколько cmd-файлов для автоматизации шифровки/дешифровки - не существует. и быстро начнешь разбираться что и как в этих файлах и такие проблемы будут решаться на мах. к примеру в данном случае я подозреваю что отредактированный файл тупо fileedit'ом сохраняется не в той кодировке (скорее всего требуется utf8, а сохраняется в обычном cp1251).

как вариает - косяк в пакетах, отсылающих инфу о вещи - в полях с инфой об эффектах от энчанта шлется мусор.

А я и не пишу что это полный дроп. Здесь все что есть на л2он, в данных об нпс.

Спарсенный мною вчера с l2on дроп и спойл для линдвиор. Само собой данные эти без коррекций пихать в сервер глупо, но как основа, с последующей доработкой напильником, вполне подойдут. Ссылка для скачивания: http://rghost.ru/private/49038636/eb7879e884e470e2cffc2ed57ba2d7c2 данные в файле хранятся в строках следующего вида: npc_id drop spoil столбцы drop и spoil содержат в себе записи следующего вида: item_id,min_count,max_count,chance; ... ;item_id,min_count,max_count,chance

обычный пакет Snoop (0xDB), он даже в С4 уже был. и реализация всего этого там вобще примитивная, если конечно исходники есть.

а с сайта автора то скачать не комильфо? http://dstuff.luftbrandzlung.org/l2.php

5 трансформ, в которых доступны функции приват трейда/крафта. в обычном режиме это просто кошечки, при переходе в торговый режим превращаются в такие вот статуи на постаментах http://l2central.info/home/ruoff/737-innova-im-beri-ot-igry-luchshee - почти в самом конце статьи