Gaikotsu

Эй археолог, ты слишком глубоко копаешь.

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

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

я конечно не знаю как там в этой сборке, тем более автор так и не сказал что это за сборка, но как варинт может так sendPacket(new SystemMessage(SystemMessageId.YOUR_KARMA_HAS_BEEN_CHANGED_TO_S1).addNumber(karma));

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

Ну или допиливай сам процесс крафта + хранение данных о том что можно скрафтить

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

вижу в пвсофт все традиционно делается через жопу...

Видимо с запретом использовать точеные вещи или например вещи выше определенного грейда

тоже даю свое разрешение на правку

вобще-то, если потребление мп скиллом указано, то оно при попытке каста нпс/мобом все равно учитывается и каст не производится если мп недостаточно.

в клиенте вобще-то потребление мп/хп всеми скиллами указано, в SkillGrp

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

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

ИМХО из бд вобще все хранение статики есть смысл выпиливать и переводить на хранение в XML ибо это банально удобней в плане той же расширяемости и т.д. Расширяемости в плане добавления к примеру новых свойств тех же спавнов например. В случае с бд к примеру это потребует добавления еще столбцов в таблицу, даже если новые свойства нужны будут не очень большому количеству нпс/мобов. Можно конечно извратиться и вместо добавления новых столбцов в таблицы спавнов писать отдельные аи для нужных нпс/мобов и там задавать нужные свойства, но как быть в случаях когда для части спавнов свойства должны быть одни, а для части - другие? Можно конечно городить условия в аи, определяя по координатам конкретные спавны, но это же изврат... Тогда как в XML при желании можно тонко настраивать отдельные спавны одного и того же нпс, и он в зависимости от этого будет вести себя по разному. Чисто для примера - 4 спавна одного и того же нпс (невидимого нпс 18919 вобще любят корейцы использовать в куче мест, как контроллеры различных событий в локациях), действующего по разному в зависимости от конкретного спавна: <spawn count="1"> <npc id="18919"> <set name="ai" value="superion.EnhancedBossController" /> <set name="index" value="1" /> <set name="normal_boss_id" value="26137" /> </npc> <point x="191960" y="56420" z="-7630" /> </spawn> <spawn count="1"> <npc id="18919"> <set name="ai" value="superion.EnhancedBossController" /> <set name="index" value="2" /> <set name="normal_boss_id" value="29006" /> </npc> <point x="17740" y="109670" z="-6480" /> </spawn> <spawn count="1"> <npc id="18919"> <set name="ai" value="superion.EnhancedBossController" /> <set name="index" value="3" /> <set name="normal_boss_id" value="25772" /> </npc> <point x="-114712" y="150450" z="-13870" /> </spawn> <spawn count="1"> <npc id="18919"> <set name="ai" value="OmegaGolemSpawner" /> <set name="targetable" value="false" /> <set name="undying" value="true" /> </npc> <point x="199482" y="84497" z="-191" /> </spawn> А насчет "сложностей массового изменения данных" в XML я даже не парюсь - мне не сложно в том же пхп по быстрому накорябать скриптик, который мне все что необходимо в хмлке поправит, благо хмлку в пхп загрузить в память в виде объекта, с которым после этого можно делать что угодно, можно буквально одной строчкой. Обратное сохранение измененного в виде хмл тоже особой сложности не составляет - уж один раз написать функцию сохранения этого самого объекта в файл как небходимо написать несложно...

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

package l2p.gameserver.enums; public enum Relation { BATTLE_ZONE(1 << 0), PVP(1 << 1), PK(1 << 2), PARTY_MEMBER(1 << 3), // party member PARTY_LEADER(1 << 4), // true if is party leader HAS_PARTY(1 << 5), // true if is in party CLAN_MEMBER(1 << 6), // true if is in clan CLAN_LEADER(1 << 7), // true if is clan leader CLAN_MATE(1 << 8), // true if is in same clan IN_SIEGE(1 << 9), // true if in siege SIEGE_ATTACKER(1 << 10), // true when attacker SIEGE_ALLY(1 << 11), // blue siege icon, cannot have if red SIEGE_ENEMY(1 << 12), // true when red icon, doesn't matter with blue UNK_13(1 << 13), CLAN_WAR_1_SIDED(1 << 14), // single sword CLAN_WAR_2_SIDED(1 << 15), // double sword ALLY_MEMBER(1 << 16), // clan is in alliance ALLY_LEADER(1 << 17), // ally leader DUEL_ENEMY(1 << 18), TERRITORY_WAR(1 << 19), // in erritory war TERRITORY_WAR_ENEMY(1 << 20), // territory war enemy? BLOCK_CHECKER_BLUE(1 << 21), // block checker blue? BLOCK_CHECKER_RED(1 << 22), // block checker red? PVP_BLUE(1 << 23), // blue sword PVP_RED(1 << 24), // red sword PVP_MASTER(1 << 25); // blue/red sword + this = blue/red crown private final int _mask; Relation(int mask) { _mask = mask; } public int getMask() { return _mask; } } package l2p.gameserver.network.s2c; import static l2p.gameserver.network.s2c.ExSetCompassZoneCode.ZONE_PVP_FLAG; import java.util.ArrayList; import java.util.List; import l2p.gameserver.enums.ClanUnitType; import l2p.gameserver.enums.Relation; import l2p.gameserver.enums.TeamType; import l2p.gameserver.managers.games.HandysBlockCheckerManager; import l2p.gameserver.managers.games.HandysBlockCheckerManager.ArenaParticipantsHolder; import l2p.gameserver.model.Party; import l2p.gameserver.model.Playable; import l2p.gameserver.model.Player; import l2p.gameserver.model.clan.Clan; import l2p.gameserver.model.entity.events.GlobalEvent; public class RelationChanged extends L2GameServerPacket { public static final byte SEND_ONE = (byte) 0x00; public static final byte SEND_DEFAULT = (byte) 0x01; public static final byte SEND_MULTI = (byte) 0x04; private RelationData _single; private List<RelationData> _multi; private byte _mask = (byte) 0x00; public static class RelationData { int _objId; int _relation; int _autoAttackable; int _karma; int _pvpFlag; } public RelationChanged() { _mask |= SEND_MULTI; _multi = new ArrayList<RelationData>(); } public RelationChanged(Playable playable, boolean autoAttackable, int relation) { _mask |= SEND_ONE; _single = new RelationData(); _single._objId = playable.getObjectId(); _single._relation = relation; _single._autoAttackable = autoAttackable ? 1 : 0; _single._karma = playable.getKarma(); _single._pvpFlag = playable.getPvpFlag(); } public void add(RelationData data) { _multi.add(data); } @Override protected void writeImpl() { writeC(0xCE); writeC(_mask); if (_multi == null || _multi.isEmpty()) { writeRelation(_single); } else { writeH(_multi.size()); for (RelationData data : _multi) writeRelation(data); } } private void writeRelation(RelationData data) { writeD(data._objId); if ((_mask & SEND_DEFAULT) == 0) { writeD(data._relation); writeC(data._autoAttackable); writeD(data._karma); writeC(data._pvpFlag); } } /** * @param targetPlayable игрок, отношение к которому изменилось * @param activeChar игрок, которому будет отослан пакет с результатом */ public static L2GameServerPacket update(Player sendTo, Playable targetPlayable, Player activeChar) { if (sendTo == null || targetPlayable == null || activeChar == null) return null; Player targetPlayer = targetPlayable.getPlayer(); int relation = targetPlayer == null ? 0 : getRelation(targetPlayer, activeChar); return new RelationChanged(targetPlayable, targetPlayable.isTargetable() && targetPlayable.isAutoAttackable(activeChar, null), relation); } private static int getRelation(Player player, Player target) { int result = 0; if ((player.getZoneMask() & ZONE_PVP_FLAG) == ZONE_PVP_FLAG) result |= Relation.BATTLE_ZONE.getMask(); if (player.getPvpFlag() != 0) result |= Relation.PVP.getMask(); if (player.getKarma() < 0) result |= Relation.PK.getMask(); Clan clan1 = player.getClan(); Clan clan2 = target.getClan(); if (clan1 != null) { result |= Relation.CLAN_MEMBER.getMask(); if (player.isClanLeader()) result |= Relation.CLAN_LEADER.getMask(); if (clan1 == clan2) result |= Relation.CLAN_MATE.getMask(); if (clan1.getAllianceId() != 0) { result |= Relation.ALLY_MEMBER.getMask(); if (clan1.getAlliance().getLeader() == clan1 && player.isClanLeader()) result |= Relation.ALLY_LEADER.getMask(); } } if (clan1 != null && clan2 != null) { if (target.getUnitType() != ClanUnitType.ACADEMY && player.getUnitType() != ClanUnitType.ACADEMY && target.getChaosFestivalMode() < 2 && player.getChaosFestivalMode() < 2) { if (clan2.isAtWarWith(clan1)) { result |= Relation.CLAN_WAR_1_SIDED.getMask(); if (clan1.isAtWarWith(clan2)) result |= Relation.CLAN_WAR_2_SIDED.getMask(); } } } Party party = player.getParty(); if (party != null) { if (party == target.getParty()) result |= Relation.HAS_PARTY.getMask(); result |= Relation.PARTY_MEMBER.getMask(); if (party.isLeader(player)) result |= Relation.PARTY_LEADER.getMask(); } if (player.getBlockCheckerArena() != -1) { ArenaParticipantsHolder holder = HandysBlockCheckerManager.getInstance().getHolder(player.getBlockCheckerArena()); int team = holder.getPlayerTeam(player); if (team == 0) { result |= Relation.BLOCK_CHECKER_RED.getMask(); result |= Relation.PVP_RED.getMask(); } else if (team == 1) { result |= Relation.BLOCK_CHECKER_BLUE.getMask(); result |= Relation.PVP_BLUE.getMask(); } } if (player.getPvPEventMode() > 0) { int mode = player.getPvPEventMode(); TeamType team = player.getTeam(); if (mode == 2) { if (team == TeamType.RED) result |= Relation.PVP_RED.getMask(); else if (team == TeamType.BLUE) result |= Relation.PVP_BLUE.getMask(); } else { if (team != TeamType.NONE) result |= Relation.PVP_RED.getMask(); } } for (GlobalEvent e : player.getEvents()) result = e.getRelation(player, target, result); return result; } } Ну и дополняется маска еще в глобал эвентах, упаравляющих разными видами осад Например вот так public int getRelation(Player thisPlayer, Player targetPlayer, int result) { Clan clan1 = thisPlayer.getClan(); Clan clan2 = targetPlayer.getClan(); if (clan1 == null || clan2 == null) return result; SiegeEvent<?, ?> siegeEvent2 = targetPlayer.getEvent(SiegeEvent.class); if (this == siegeEvent2) { result |= Relation.IN_SIEGE.getMask(); if ((thisPlayer.getZoneMask() & ExSetCompassZoneCode.ZONE_SIEGE_FLAG) != ExSetCompassZoneCode.ZONE_SIEGE_FLAG) return result; SiegeClanObject siegeClan1 = getSiegeClan(SiegeEvent.ATTACKERS, clan1); SiegeClanObject siegeClan2 = getSiegeClan(SiegeEvent.ATTACKERS, clan2); if (siegeClan1 == null && siegeClan2 == null || siegeClan1 != null && siegeClan2 != null && isAttackersInAlly()) result |= Relation.SIEGE_ALLY.getMask(); else result |= Relation.SIEGE_ENEMY.getMask(); if (siegeClan1 != null) result |= Relation.SIEGE_ATTACKER.getMask(); } return result; } Сразу говрю, что тут у меня скорее всего немного избыточный список типов релейшнов, т.к. это с более свежих хроник - не факт что все из них были в ГФ.

Тут экстрасенсов нет, чтобы догадаться по одной строчке из скрипта

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

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

А, аналог комиссионки, как в новых хрониках. Ну так изучай скрипты этого дела, если исходники конечно есть. Ищи где идет отправка на почту и замени выдачей в инвентарь и все.

А нафига? В любом же случае придется слать на почту, если на момент выдачи победителя в игре не будет.

L2FileEdit или L2ClientDat

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

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