Gaikotsu

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

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

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

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

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

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

http://www.l2jserver.com/forum/viewtopic.php?t=28165 - эта что ли?

// удалено, т.к. это был ответ на сообщение, которое автор удалил, видимо осознав насколько оно дурацкое

головой и руками, имея хоть какие-то познания в яве З.Ы. какой вопрос - такой и ответ.

ну по этим двум коррекциям я не вижу чтобы где-то из _accountsInGameServer аккаунт удалялся при выходе. мейби в этом дело? З.Ы. а вобще, фикс тот еще...

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

стэктайп одинаковый у скиллов, вот и заменяют друг друга

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

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

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

Да по моему тут решение то очевидное, вполне понятное из текста ошибки, так что тут разъяснять то? Если метод просит числовое значение, то по логике в данном случае там надо передавать не имя персонажа, а скорее всего его objectId.

Вешаешь слушатель на зону и делаешь в нем что хочешь с объектами, входящими в зону - что может быть сложного то? Пример для овера: package listeners.zones; import l2p.gameserver.listener.zone.OnZoneEnterLeaveListener; import l2p.gameserver.model.Creature; import l2p.gameserver.model.Player; import l2p.gameserver.model.Zone; import l2p.gameserver.model.Zone.ZoneType; import l2p.gameserver.scripts.ScriptFile; import l2p.gameserver.utils.Location; import l2p.gameserver.utils.ReflectionUtils; public class TeleportZone implements ScriptFile { private static ZoneListener _zoneListener; @Override public void onLoad() { _zoneListener = new ZoneListener(); for (Zone zone : ReflectionUtils.getZonesByType(ZoneType.teleport)) zone.addListener(_zoneListener); } @Override public void onReload() {} @Override public void onShutdown() {} public class ZoneListener implements OnZoneEnterLeaveListener { @Override public void onZoneEnter(Zone zone, Creature cha) { if (zone.getParams() == null || zone.getParams().getString("loc", "").isEmpty() || !cha.isPlayer()) return; if (zone.isActive()) ((Player) cha).teleToLocation(Location.parseLoc(zone.getParams().getString("loc"))); } @Override public void onZoneLeave(Zone zone, Creature cha) {} } }

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

может вычисляться по получаемому SP, т.к. получение экспы может быть к примеру блокировано. пример: //Хаотические персонажи могут получать репутацию когда получают опыт, при этом повышается только репутация а EXP и SP нет. if (!isCursedWeaponEquipped() && addToSp > 0L && _karma < 0) { _karma = Math.min(0, (int) (_karma + addToSp / (Config.KARMA_SP_DIVIDER * Config.RATE_SP))); addToExp = 0; addToSp = 0; }

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

эпичнейший фейл супер-пупер-одмина. З.Ы. я про автора темы.

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

ну там ошибка тупейшая, сам в свое время столкнулся с ней - в данном случае в качестве таргета берется сам кастующий и в итоге логично что проверка на расстояние до цели всегда проходит успешно. просто заменить на что-то типа: if (!player.isInRangeZ(flagPole, getCastRange())) { player.sendPacket(SystemMsg.YOUR_TARGET_IS_OUT_OF_RANGE); return false; }

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

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