Gaikotsu

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

нда... на что только люди не идут, чтобы не работать с xml самым удобным и простым способом - в обычных текстовых редакторах.

а зачем доставать? их можно узнать банальным перебором ид абнормалов - отсылая их скажем в пакете с инфой о персонаже/нпс и смотря как это выглядит, благо ид у них идут последовательно. точнее до GoD Tauti не ид, а значения для битовых карт (в виде которых и слались клиенту наложенные на объект абнормалы), а уже дальше просто в виде обычных ид. ну а названия их конечно придется придумывать самому - смотря как абнормал выглядит.

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

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

как же народ на халяву падок - столько набежало "дай ссылку"

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

какой skillType у скилла зоны задан?

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

[sarcazm]офигенно много[/sarcazm] пусть даже для каждого игрока будет отдельный счетчик, т.е. скажем по 100 записей за час будет в бд появляться, 2400 за сутки. конечно же прибавление по паре десятков килобайт в сутки (полезные данные + служебные) - это вобще неподъемные объемы для бд.

есть ли в сборке возможность отложенной выдачи предметов? ну как в фениксе/овере delayed_items?

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

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

пример реализации - http://forummaxi.ru/index.php?showtopic=36913

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

Простая реализация выдачи геройства до определенного времени и с автоматическим его отбиранием по истечению этого времени. Реализация дял сборок на базе овера, так же с минимальными переделками подойдет и для сборок на базе феникса - надо лишь названия нескоторых классов переименовать и все. Добавляем в класс Player следующее содержимое: private boolean _isTemporalHero = false; private Future<?> _deleteTemporalHeroTask; /** * Выдает игроку временное геройство * * @param endTime - время окончания геройства в мс * @param broadcast - броадкстить или нет пакет с социалкой Victory */ public boolean setTemporalHero(final long endTime, boolean broadcast) { if (isHero() || isTemporalHero()) return false; _isTemporalHero = true; setHero(true); Hero.addSkills(this); sendPacket(new SkillList(this)); updatePledgeClass(); if (isHero() && broadcast) broadcastPacket(new SocialAction(getObjectId(), 16)); broadcastUserInfo(true); setVar("temporalHero", endTime); if (_deleteTemporalHeroTask != null) { _deleteTemporalHeroTask.cancel(false); _deleteTemporalHeroTask = null; } _deleteTemporalHeroTask = ThreadPoolManager.getInstance().schedule(new DeleteTemporalHeroTask(this), endTime - System.currentTimeMillis()); return true; } /** * Возвращает признак того, является ли игрок временным героем */ public boolean isTemporalHero() { return _isTemporalHero; } /** * Досрочно забирает временное геройство у игрока */ public void forceEndTemporalHero() { if (!isTemporalHero()) return; if (_deleteTemporalHeroTask != null) _deleteTemporalHeroTask.cancel(false); _deleteTemporalHeroTask = ThreadPoolManager.getInstance().schedule(new DeleteTemporalHeroTask(this), 500); } /** * Задача на удаление временного геройства */ public class DeleteTemporalHeroTask extends RunnableImpl { private final Player _player; public DeleteTemporalHeroTask(Player player) { _player = player; } @Override public void runImpl() throws Exception { if (!_player.isHero() || !_player.isTemporalHero()) return; _player._isTemporalHero = false; _player.setHero(false); Hero.removeSkills(_player); sendPacket(new SkillList(_player)); _player.updatePledgeClass(); _player.broadcastUserInfo(true); _player.unsetVar("temporalHero"); } } что какой метод делает понятно из комментариев. так же добавляем в метод restore() этого же класса, куда нибудь в конец следующие строки: if (!player.isHero() && player.getVar("temporalHero") != null && System.currentTimeMillis() < Long.parseLong(player.getVar("temporalHero"))) player.setTemporalHero(Long.parseLong(player.getVar("temporalHero")), false); это для того, чтобы имеющийся статус временного геройства восстанавливался при входе в игру. пример использования: /** * Выдача временного геройства */ private final static boolean getHero(final Player player, final int idx) { if (!checkConditions(player, Service.GET_HERO)) return true; if (idx < 0 || idx >= Config.CB_GET_HERO_DAYS.length) return true; if (player.isHero() || player.isTemporalHero()) { player.sendMessage("Вы уже герой."); return false; } if (!ItemFunctions.checkRequiredItems(player, Config.CB_GET_HERO_ITEM[idx], Config.CB_GET_HERO_PRICE[idx])) return false; ItemFunctions.removeItem(player, Config.CB_GET_HERO_ITEM[idx], Config.CB_GET_HERO_PRICE[idx], true); player.setTemporalHero(System.currentTimeMillis() + Config.CB_GET_HERO_DAYS[idx] * 24 * 60 * 60 * 1000L, true); player.sendPopupMessage("Вы получили статус временного героя на " + Config.CB_GET_HERO_DAYS[idx] + " дней.", true); Log.add("get_hero|Character " + player.getName() + " acquired temporal hero status on " + Config.CB_GET_HERO_DAYS[idx] + " days.", "services"); return true; }

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

гляди в henna_tree, если у тебя там вобще записи для класса 95 (соултакер) sql-запрос для просмотра этого думаю додумаешься какой сделать

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

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

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

и что все на всякие L2FileEdit и т.п. то подсели... l2encdec + блокнот - и ничего больше не надо для правки dat-файлов клиента.

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

дак допиши в условие выдачи, что если КЛ - выдавать одну корону, если нет - другую. или исходников нет?

SysTextures/L2UI.utx SysTextures/L2UI_CH3.utx