Gaikotsu

у меня друг уже побегал за новую расу на оффе - впечатления говорит двойственные. да, сначала как-то необычно, но в итоге по идее какие-то это опять однокнопочные классы... http://i66.fastpic.ru/big/2014/0730/bb/e7f920a25af6af46a5365c1abb9248bb.jpg - вот, зацените - это все активные скиллы на 54 уровень и как он сказал, до 3 профы новых не прибавится.

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

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

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

а зачем просчитывать время? спавн можно привязать к событию "корабль прибыл в заданную точку" - так даже более надежно будет, чем привязываться к времени потраченному на маршрут.

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

ух, ну и кошмарный код посмотри, может тут что почерпнешь

интересно вот только зачем данный апдейтер пытается лезть в реестр и изменять там настройки интернет-соединения?

в хф от 1 до 3 (нормальное/мастерворк/легендарное), в ГоД значений больше.

можно только предопределенные цвета использовать, указывая его номер (последний параметр в itemname) - свои цвета указать нельзя.

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

Раскрашивание описаний предметов во всякие цвета клиентом не поддерживается

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

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

тут - никак. данная ситуация обрабатывается в ядре сервера.

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

вешай на зону листенер и при выходе из зоны снимай в этом листенере нужный бафф пример ReflectionUtils.getZone("[oren21_2220_a05_3]").addListener(new ZoneListener()); ... public class ZoneListener implements OnZoneEnterLeaveListener { @Override public void onZoneEnter(Zone zone, Creature cha) {} @Override public void onZoneLeave(Zone zone, Creature cha) { if (cha.isPlayer()) cha.getEffectList().stopEffect(6429); } }

нет исходников ядра - не сделаешь

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

Еще чуть дополню на тему удобства хранения данных в файлах формата xml. В них удобно хранить еще данные тем, что необязательно перечислять все значения данных для каждой записи в файле. Если в том же csv необходимо перечислять все из-за того что в парсере таких данных жестко задано, что на такой-то позиции в строке обязательно должен лежать такой-то параметр. Т.е. банально нельзя пропускать и не указывать некоторые параметры в данных. В xml же мы такими условиями не ограничены - если какой-то параметр для большинства записей данных имеет одно и то же значение - мы можем его не указывать вобще, а при чтении данных, просто подставлять значение по умолчанию в таких случаях.

структура данных более наглядная и удобная для редактирования Чтение же таких файлов сервером ненамного сложнее чем чтение обычных текстовых файлов (коим является csv) - стандартных классов для работы с xml хватает. Перевод делать можно самыми азными способами, начиная от ручного переделывания, если данных мало, и кончая написанием простых скриптов на чем угодно, которые прочтут csv и сгенерят xml нужной структуры с данными.

а не 1.05? ибо ты же тут делаешь умножение, а значит с 0.05 у тебя по логике отсанется 5% от оригинального значения.

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

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

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