Tryskell

Limiting one client per HWID and enforcing a single client launch on your system already cut all the lowbies botters. For the hardcore using VM or multiple network cards, you probably want an active GM. You can also write some stats, like storing xp/player table on a Map, which would be cleaned every day. The same could be done on a hourly base. It's enough to see if someone botted /nolifed, and then you can investigate physically another day to see what currently happen. You can do the same logging system with quest success/player. If someone makes a repeatable quest more than 2 times per day, it triggers you an alert and then you can investigate yourself. The point is to mitigate the problem. I doubt than you can do better than that. Another, simple way is to make repeatable quest doable only once per day. It drastically limit quest botting.

If you meant multisell, the obvious answer is Ingredient#getEnchantLevel() isn't used where it should be used, or you got some "protections" blocking you to get what you want. Check regular L2J MultiSellChoose / MultiSellList and see where it's used (you must have 9 occurences). ---- If you meant regular player shop system, then the system is probably not implemented.

Use Oracle JDK 8 if using free revision, or OpenJDK 11 if you use latest and compile it with proper JDK. ByteBuffer#clear() seems to be dropped/edited/modified on later JDKs. Nothing related to MMCore, moreover when MMOCore is integrated since ages on aCis (and so, no needs of additional compilation).

It's not "half fixed", it's fully redone. That's different of your generic copy-pasta stuff and your 5 lines broken fixes. It was pushed to public to avoid people to wait longer, and to eventually help with the end of the developement - testing it, etc. You will be the ass copying it and speaking about leeching anyway once it's fully operational. Probably the same when SpawnManager will come. Etc. The story never ends, after all ! Even in the case I copy paste something from you - which would be the first time, cause generally I never copy paste form other packs except L2J/Unity - you still owe me few hundreds hours of developement - if we speak of equality. Not sure why you taunt me, I simply say your fix is bad and you need to rework it. That's giving you a service actually - and to other people aswell.

You can't do better ;).

It's not even a temportary fix, as it fixes 1/3 possible states. The exploit is still doable when swimming or flying, and the falling needs to be tested. It is simply incomplete and not worthy to be shared. But you are right on one thing, it is similar to all those 2009 "fixes" - best exemple is battle/spell force exploit fix.

It's client coded.

From the moment : - there is an economic system and a money to get and trade things from - you can actually make gold income due to automatization pattern (farming and questing is programmable) - you gain something from automatization (item, level) you will have bots. No matter disruptive actions, no matter rates (because adena is simply exchanged for Gliterring Medal or Gold Bar). It's as simple as that. Irrelevant botting ? Top level and top gear for everyone.

I simply inform other people to don't use it, and I said why. And I also find it ridiculous to be rewarded for such a bugged fix. Regarding leeching, I think you got more skills than me, since your whole script folder is basically aCis ripoff, and count for few hundreds hours of work. So yup, I will happily leech it when you will fully fix it, because I also shared 2 exploit fixes in the past than you probably applied aswell. The leftover is up to you. Peace haters.

That changes nothing for fly / water check, it's still "half a fix". The falling part simply shows you didn't really test what you share. It's not about me - I'm able to do better - it's about others, rewarding you with kuddos and appyling invalid stuff in their server thinking it works.

I didn't even check if right or wrong, but until I missed something, the issue still appears if the dude activates it flying or swimming, and I believe you perfectly know it (since you coded it that way). Not sure if sharing half working fixes is worthy. Also what happens with falling case ? You got spammed with "You aren't allowed to use PHX" ?

public void getRewardClanWinner() { final List<String> playerIps = new ArrayList<>(); for (Player player : World.getInstance().getPlayers()) { final String pIp = player.getClient().getConnection().getInetAddress().getHostAddress(); if (!playerIps.contains(pIp)) { playerIps.add(pIp); player.rewardClanWinner(); } } } I don't think it's needed to say to someone who tried to exploit, he exploited. Simply avoid the behavior. ArrayList because second parameter got no use. No concurrency because no needs to remove or delete in same time than add, and only one iteration is called. Inner container instead of class, because no use to keep retained info. Always keep variables in lowest scope possible. Another thing, you should iterate MEMBERS of WINNING CLAN instead of World.getInstance().getPlayers() and rework rewardClanWinner accordingly. The easiest way is to add parameter Clan into getRewardClanWinner, and use it inside the method instead of World.getInstance().getPlayers() . Another thing, you don't reward OFFLINE members. No clue why you wouldn't, since all ONLINE members probably didn't participate to siege. So you have to either keep track about who participated, or reward everyone (OFFLINE included).

https://stackoverflow.com/questions/22381202/a-jni-error-has-occurred-please-check-your-installation-and-try-again-in-eclips Delete all your JDK/JRE versions, and verify links to it under JAVA_HOME (google it). If you use a compiled pack (which you shouldn't), ask to whatever compiled it which JDK he used. Once it is done, verify your JVM configuration on Eclipse. You can also see current Java compliance of the project using alt + enter on your project > Java compiler > Compliance level.

Downgrade your mySQL, according to Reynaldo some version of mySQL introduced a keyword than it is currently used by this table (privs). With 5.7 (for example) that query is ok.

Changeset 383 (1388) Movement is still experimental. The status IS NOT OK for LIVE servers. Boats and MoveToPawn behavior still need to be fixed. Movement rework - Part I, Sit / Shop fixes, Safe fall height, Bugfixes, Organization Movement rework - Part I - Fix following issues, plaguing aCis since a while : - Clicking fast enough on ground while moving was increasing the distance between the player and its actual real point. - Fix the pathfinding issue for monsters, blocking on the first encountered obstacle. - Introduce pathfinding for returning to spawn monsters, to avoid they stuck in middle of nowhere or got Z layers issues. - Rework most of the offsets to fix issues with move to pawn concept. - Introduce a 0.5s delay where player walks instead of run on start of a movement, to fit client animation. - Introduce CreatureMove, a complete replacement of MoveData. It's now bound to a Creature, and not generated on every single move. Children exist for PlayerMove and BoatMove. The whole movement logic is moved here (extracted from Character and CharacterAI). - Drop MovementTaskManager, every running task is now individual to avoid to register on a clock wall, which means the 100ms granularity is guaranteed without calculations or sync needs. - Avoid to process a movement if a movement is already launched with same destination and offset (huge performance boost upon spam pickup action). - Add a debug for movement system using ExServerPrimitive packet. It offers a good sight of what happens during movement process. Sit / Shop fixes - sit/stand is now backed by _sitTask, to track delay between sit and stand position. - shop stand up is now instant to fit with retail and avoid exploits. - Player#canOpenPrivateStore is now used on 2 different places (shop opening and validation) and handle more checks. Fix multiple issues/exploits, like being able to shop while being mounted. - StoreType is renamed OperateType, and now include missing MANUFACTURE_MANAGE and OBSERVER. All getters/setters are edited. - MANUFACTURE_MANAGE is implemented, it's not possible anymore to open both (buy or sell) and manufacture panels. - All buy/sell/manufacture player lists are now generated on Player creation (no more lazy initializations / container creation, no more null checks). - Improve Player#instantStandUp(boolean) a little (don't bother with stand up if already stand up). - Add NO_RECIPES_REGISTERED check upon MANUFACTURE_MANAGE ; call the empty window. Add ManufactureList#_isDwarven, which allow us to call back previous state without error. - Don't set OperateType.NONE on invalid item count for both sell/buy manage (was leading to invalid store state). Add retail messages. - Fix the fact you aren't supposed to open a shop when already sat. - Fix the buy/sell/manufacture tryOpen methods : Don't bother with manage case, and tryOpenWorkshop only care with right OperateTypes. - isInStoreMode() is modified to only returns real cases of store mode. Manage cases aren't part of it. Safe fall height - Added retail values based on classes and sex (was semi-implemented core side using default value 333). Ty RooT for dp side. - Add CANNOT_DISMOUNT_FROM_ELEVATION wyvern check, making it impossible to dismount a wyvern if not in a valid safe fall height. Bugfixes - Fix Q009 reward itemId. Ty p0w3rf1y. - Fix Q621 / Q622 haste potion itemId reward. Q621 giveItems recipe instead of rewardItems. Ty Idontknow1. - Add retail behavior regarding teleporting to nearest town if wyvern feed task ends. - Seeds works anew (was due to invalid handler name on XML). - Edit few mercenary tickets SystemMessage to use retail ones. Ty RooT. - Fix the delay for mass teleporter (no instant case if out of siege). Ty RooT. - Fix Baium zone (around door, to avoid teleport back to town) using L2OFF GF values, IL being buggy. - Fix the few cases of mispelling or miss on configs properties files. - Fix radius/height/level/stats of all NPCs, except summons and tamed beasts. Ty StinkyMadness. - Add few missing Manor Managers on relatedNpcIds (was leading to NPEs). - Fix a MinionList NPE, prior to minions rework. - Add few missing Seven Signs event sounds. Ty RooT. - Drop calcFestivalRegenModifier system, which was leading to negative values and isn't retail. The only affected stat is MP regen, and it's positive, based on MotherTree zones. - RaidBossManager#cleanUp fix prior rev 382 edit. - Fix multiple SpotBugs reports (18 or so), from invalid equals/hashCode contracts to missing switch break. - Fix RequestListPartyMatchingWaitingRoom, RequestAskJoinPartyRoom : variables aren't set as static anymore. - Fix the client crash when clicking "projection" button on the "record of seven signs" (introduced on rev 239). - Upon SA activation on magic use, S1_HAS_BEEN_ACTIVATED message is now working and called BEFORE resist attempt. - FleeingNPCs / 4s victim scripts flee behavior are enhanced. - AI is correctly flushed upon IDLE case, leading to proper global aggro value reset (10sec aggro cooldown on respawn). - Fix party duel CANCELED state for ZoneId.PVP. - Boat _passengers is now concurrent to avoid CME. Organization - Move _isNoRndWalk from Creature to Attackable, _isChampion from Creature to Monster. - Slight edit of Creature#isInsidePeaceZone (no static, first param is self). - Rework WorldRegion#setActive, it now uses an AtomicBoolean. Add WorldObject onActiveRegion() / onInactiveRegion(). Behavior is normally exactly the same than old setActive, but cleaned up. - AttackableAI#changeIntention getKnownType(Player) check is now replaced for getRegion().isActive(), probably leading to a lot of saved garbage. SiegeGuardAI#changeIntention override is dropped. - Remove GeoEngine.getInstance().canMoveToTarget pre-optimizations (it's already handled by moveToLocation). - Add missing onEvtAfraid and AFRAID AiEventType use. Rework Fear effect to use it. - Merge Instance#doPickupItem(WorldObject object) with AI#thinkPickUp() (single use). - Add Location#equals(int x, int y, int z), Location#setUsingPositiveOffset, Location#setUsingRandomOffset and Location#setFleeing methods. - Addition of StatsSet#getIntIntHolderArray. - ItemTable cleanup (renamed ItemData and moved to data.xml, CLogger, move temporary containers to good place, move _slots Map to Item, javadoc). - Item cleanup (drop Logger, correct use of StatsSet methods to feed Item values, javadoc) - Rework both Weapon#getSkillEffects (Fix the multiple calls upon getSkill() and getFirstEffect, rename those methods castSkillOnCrit / castSkillOnMagic for easier understanding). - Fix one strange use of StatsSet upon FestivalOfDarknessManager. - Rename all items handlers to keep naming convention logic. - Add warning regarding missing property key on configs. Ty StinkyMadness. - Add UseBlowfishCipher config. Limit the byte array size on VersionCheck packet. Ty RooT. - Drop few skills parameters duplicates, ty bowling4soup. - Addition of RaidBossManager#getBossSpawns() and BossSpawn#toString for easier customs implementation. - Numerous packet reorganization : - Few packets rename to fit NetPro. - "activeChar" naming is replaced for "player". Final keywords added here and there. Variables naming is more friendly and/or conventional. - NewCharacterSuccess uses a static approach for now. - Deletion of SuperCmdCharacterInfo, SuperCmdServerStatus && SuperCmdSummonCmd packets (custom, unused). - Implement SendTimeCheck / RequestTimeCheck packets. Ty RooT. - AdminCommands - Delete AdminMammon and associated admincommands. - Merge all cursed weapons admincommands into //cw. - Cleanup //admin2 panel (game_menu.htm). - Delete //adminX commands. It is now simply //admin. //admin can now answer to file names (ex. //admin server). PS : all items XML etcitem_type parameters are edited to reflect enum value (use of caps lock). Movement is still experimental. The status IS NOT OK for LIVE servers. Boats and MoveToPawn behavior still need to be fixed.

+ if (clan.getMembersCount() == 0) + { + activeChar.sendMessage("You don't have any members"); + return false; + } You probably meant getOnlineMembersCount(), because getMembersCount() can't be 0. That custom probably collides with retail clan notice. If you edit it form clanbbs, it will affect your usercommand. Also, a big text probably fucks up everything using ExShowScreenMessage.

The advantage of ChMap is if you want to pick a particular objectId/Player pair, otherwise it's not needed.

Still, I think it's still preferable to Collections.shuffle ONCE rather than doing 15 or 20 (let's say, up to 200/300 for specific servers) Rnd.get. And I don't like the fact to hide something. It basically means you didn't use the correct container for the correct job. But yes, it's the Rnd.get(_registered) solution. I don't think it's really appropriate for the location. You would generate one new ArrayList PER player team attribution. So, if you got 300 ppl to register - 300 arrayLists, 3000 players =3000 arrayLists.

A Set got no .get() method, and a Map would give you the key related value if you .get() it. I would use a ConcurrentHashMap (cause keys are probably useful anyway elsewhere), then generate a List based on values() with List<Player>registeredPlayers = new ArrayList(_registered.values()) then Collections.shuffle(registeredPlayers); Why shuffle instead of Rnd.get ? Simply because to avoid multiple Rnd.get. And in the end, .clear() the _registered, once all players are allocated (or even in the beginning, just after registeredPlayers creation). That would avoid to .remove everytime a loop is done. You .clear() only once. That would also avoid you that dangerous (while) loop (I'm not a big fan of loops). You only for loop, for the given shuffled internal List. It basically depends about what you do with leftover Players, if any. But your current writting means there is no leftover, otherwise you would end with infinite loop.

Was coded as tested on retail. A search with "isStackable()" upon gameserver.network package would lead you to answers.

You can check how returnHome() is implemented on aCis. If you already use aCis, simply edit it and edit needed conditions to fire it (AttackableAI / SiegeGuardAI). A simple teleportTo(getSpawn().getLoc(), 0) is enough.

On aCis we use GeoObject, a layer which adds dynamic geodata. Each fence is linked to a GeoObject. Doors use it too. If not, then you have to calculate it on the fly, similar to doors on L2J, based on dimensions. If you don't code it, it basically means server can go through, while client can't. So a simple relog means you can bypass the object, - even if on client side you stopped, you actually didn't.

The easiest is : for each teleport location, you also load the boss npcId (so, a new class extending TeleportLocation, with int _bossId). Then when you pick the TeleportLocation, you also interrogate the boss status related to the npcId, if _bossId > 0. That probably won't help you, but if someone wants to code that... Be free to do it. A zone check simply can't work.

ThreadPool.schedule(() -> finishChamp(), _endDate - System.currentTimeMillis()); In case you got a method to call, otherwise use following if you got some actions to do. _earthQuakeTask = ThreadPool.schedule(() -> { for (Player member : getAvailablePlayers(_party)) member.sendPacket(new Earthquake(member.getX(), member.getY(), member.getZ(), 65, 9)); }, jumpTime - 7000); As shown in last exemple, you can retain the task on a variable, in order to stop it when you want (notably used to delay a scheduled action, to avoid to get it twice). if (_earthQuakeTask != null) { _earthQuakeTask.cancel(false); _earthQuakeTask = null; } There's a huge amount of tasks here and there, simply read.

Got nothing related to server side, it's purely client.