Tryskell

Well, calling 6 times (for 2nd and 3rd classes) a method is what I would call messy :). You can eventually put parameter as "ClassId..." to cut the calls. Also, in your exemple canClassIdJoin can be return getMemberCount(classId) < classId.getPartyLimit();

Edit and introduce getClassId() checks here : if (activeChar.getParty() != null) { for (L2PcInstance player : activeChar.getParty().getPartyMembers()) { if (player != null && player.isHealerClass() && !player.isInStance()) { healers++; if (minus != 2 && (player.getPvpFlag() != 0 || player.getKarma() > 0 minus = 2; } } } There are no easy ways to do it, so it gonna be messy if your point is to checks all classes.

You will probably end breaking another part of the geodata simply checking one spot. A geodata file is a huge square, so you better have some visual tool to directly see (and an easy one is the ///geodata client tool). Also, fixing one invisible wall doesn't mean you don't have another issue elsewhere. As said others, geodatas are basically the same (since generation is easily done, and always produce the same result). The only different versions are handmade, and depending about your project's geoengine, they will also be handled differently depending about what people actually did. Understand a "good" geodata on an edited geoengine which use different rules can be simply "terrible". Finally, some invisible walls can be explained by : - you use an invalid geodata for the client version (a simple exemple on IL, around Gludio there are some rocks in some versions, and in another client version there aren't those rocks). So if you use a geodata from one version to another, you can either lack geodata if your client got rocks but your geodata was made on old client revision, or you can have invisible walls if your client doesn't have rocks but your geodata was built on a higher client version. You should check with a visual tool exactly what happens, because an ivnisible wall with the shape of a rock would mean your geodata is definitively not made for your current client, and you will have issues elsewhere for sure. - NCSoft itself added walls.

Do you still have some errors ? Sido moved the forums to another host, it's known from past host change than DNS are broken for some days, even after the move itself. Also, we got some banrules with either IP range / entire domains because of spambots. The forums itself isn't shutdown, aswell as the project. You can also join our Discord, to get access to the main infos, or simply chat. Hopefully, the forums design will be edited soon.

Well, I speak about "project", and such denomination should be clearly defined. The minimum should be : - one "active" timeline - an external forum/blog/discord/media publically reachable I don't think "one shot pack" can/should be considered a "project".

Hiho, here are my feelings about it (already expressed to @Celestine by Discord PM) : Packs are splitted on different categories, that's a good way to harmonize it in this "new" board and make it somewhat useful/active. - Should be opened to anyone, paid or free pack owners. - Topic should be made / controlled by a team member, or project owner directly only. - Someone (one moderator) would need to extract (active) "packs" topics from "Marketplace" and "Share" sections (mine is already there). - No specific board (drop the old aCis board, since the important topic is already extracted), one topic per pack. - Two tags to help users searching : "chronicle" and "paid/free/paid & free" tags. - Can pay a small fee to be pinned/color size (you can ask far lesser money for "free" packs than for "fremium/paid" to promote "open-source" projects/philosophy). About the board itself, consider to reset the rights, since I'm currently unable to modify, edit, or even answer in my own aCis topic. If any high head such as @Maxtor or @Celestine could handle it - I wait to edit my 2013 topic and make it anew alive. If any member got ideas to improve that board, consider to reply here. Ty in advance.

Next rev, currently under debug and accessible by Donator/Inner Circle.

One threadpool task which caches the String from the db query would be enough - It doesn't need to be called below 1 hour, imho.

Maybe think about what YOU can do for this community. I got my own schemes, and my own life - I already dedicated some of my time to MxC, mostly from 2011-2018. Added to my project, I also have a job (well, until September, then I will have more time for aCis), a girlfriend and a little garden (soon cucumber time). You maybe are still "young" and got spare time - or simply are jobless and lonely, which I actually was few years ago - but I'm almost 35y old and got multiple hobbies. Ah, and I also play video games. If you are the one asking for changes - be the change. Don't try to charge other shoulders for something you are incapable of. I don't have a solution for MxC, it's not my forums, I'm already in charge of my own project - I'm a part of this community, like you, and already offered and still offer some L2J content, via aCis ecosystem - my project indirectly generated a lot of views for MxC forums. As zemaitis stated, I don't really understand why project boards were set as paid - I believe the generated traffic is enough as a "payment", while projects themselves had some basic "advertisment". You basically cut some opportunities to make MxC "project-friendly" and gather some developers together. That's a choice. And if people don't make new projects, it's not my concern - but everyone else responsability to simply "sit and watch". There are multiple unexploited chronicles, which await a big number of teams.

Out of all my posts, I made maybe 1500-2000 topics upon Help request section, without any harmful words, toxic answers, scam attempts, or even forced promotion of my own files. I never asked for L2J moderation position, but I have been actually rewarded twice with this position. My actions were rewarded without the need to ask for a reward. About my own time and my contribution to those forums, I help when I can/want to help. I'm not forced/bound/linked to help anyone (as anyone serving as moderator, tbh - we aren't paid for that work), and some answers are either already answered elsewhere, part of things I don't even bother with (client side), or from people I don't want to answer. Also, most of current Request help section is really not interesting to answer. I got limited time, and choose which topics I want to contribute about. I don't believe giving full answer actually help someone to build his own logic. It's my own conception of learning, you maybe got another, but I believe you don't learn if you don't actually try. I'm not here to build your server, I'm here to grow your brain. That's what aCis is, aswell. I don't offer shiny customs with false/true configs for that reason. People add what they want to add, I offer a vanilla experience. I'm aware my project and my approach actually raised some real life developement careers, and globally raised the quality of projects (code quality wasn't even taken in consideration before 2010). That's enough for me to tell me I did the good choices, and than my scholar approach (aka, give some hints but not the answer and you copy-paste like a retard) is the good way to answer. Giving the answer is basically insulting your own intelligence. About aCis, you maybe are stucked into cycle 37 - which focus WAS rename and reorganization. Cycle 38 was about movement, 39 was about movement/AI, 40 will be about SpawnManager. Each cycle got a main goal, and cycle 37 was about reorganization. What can I say more about it ? It's maybe time to move on, you know, as death - mourning phases: Shock and denial. This is a state of disbelief and numbed feelings. Pain and guilt. ... Anger and bargaining. ... Depression. ... The upward turn. ... Reconstruction and working through. ... Acceptance and hope. Some of you, people, are stucked into phase 3 since few years. It's maybe time to pick some real life psychologic. aCis isn't a single man work, many people worked over those files (and they are "thanked" into changesets) - I'm the main head, which give the main objectives, unify the logic. If Inner Circle was a brick builder, I would be the architect, and basically all lines without any thanks are basically "Thanks Tryskell". You can see the whole teamwork on aCis Hall of Fame. In the end, you say you're an old member, but what have you actually offered to this community ? I only see one "spectator" asking for some action. Why wouldn't you be the one making guides, instead of being the one asking for it ? I followed my own path, and hopefully my actions generated a lot of emphasis for L2J, and Interlude in particular - my beloved chronicle.

So someone before you broke the rules for you, since he edited the client and it's not allowed (and as many games, the punition is generally player account ban), but it's not because you don't see it it doesn't exist :). That's also why on L2J forums you aren't allowed to speak about client modification. The emulator itself is legal. Not sure how they handled the fact the reverse-engineering to gather datapack/formulas is legal, but it looks like either that wasn't disputed, or L2J won over it. Client is NCSoft intellectual property, therefore that's the only part where you can lose. And since L2OFF is also tagged as intellectual property - except the extender part, which is intellectual property of whoever developped it - then basically, NCSoft can attack whoever use their materials without their consent. The only viable targets are top 10/20 servers, since that playerbase is missing cash for NCSoft / Innova, and lower playerbase amount is probably not worth to attack, economically speaking.

L2J is legal, and won some judgment court regarding it (at least that's what Zoey76 states). Client is clearly marked as being ncsoft property - while it's probably ok to share it as it is (and maybe, even not), it's not ok to edit it and can't be used to access other servers than NCSoft ones. L2OFF is based on stolen material, it's probably extremely easy for NCSoft to win if they decide to attack someone. @xDarkDelux You basically accepted NCSoft rules probably hundred of times, when you click on the "I agree" button over licence on client. Not reading it doesn't mean it doesn't exist. All in one, it's not really "devs" which steal playerbase, but server owners. Those are the only ones to be tracked/hunted by NCSoft/Innova. And your server is probably out of the radars until you become a "threat".

If you use aCis, it's Creature#getKnownTypeInRadius : while being compact, it also delivers the good type of instance without the need to manually cast it. // Find all Players associated to "player"'s knownlist. final List<Player> knownPlayers = player.getKnownType(Player.class); // Find all ChristmasTree in 1200 range around "player". final List<ChristmasTree> trees = player.getKnownTypeInRadius(ChristmasTree.class, 1200); If you use regular L2J, it's CharKnownList#getKnownPlayersInRadius. You got only the choice between "Player" and "Character" (it is then getKnownCharactersInRadius). If you need another instance type, you have to make another filter / conditional check. final List<L2PcInstance> knownPlayers = player.getKnownlist().getKnownPlayersInRadius(4000); Note : the distance is limited by your pack. On aCis, you can see "only" in 6k range, no matter what you try to check. On L2J, there is no fixed range, it depends about what you try to look (vehicles are something like 15-20k range, while Players are far lower). Also, not sure when (or even if) L2J added the possibility for Npcs to see others Npcs - which is sure is, from memory basic L2J IL isn't able to do that.

I have been demoted few weeks/months ago. Also, requesting lock won't solve anything, but I personnally agree, as a regular forum user, it should have more point to be shared around "Request help" section rather than "share".

Well, the initial post was about "all" types of "errors". Until you speak about "performance" "errors" (which actually can have an impact and should be set to at least "warning", and whom 99,99% packs normally already use them), it's all about how a developer (or pack owner) would "feel" Java. Nothing more. I *personally* "hide" "errors" which got no point, are impossible to fulfill due to the very nature of the content, etc. You probably can "fix" all "errors" from Eclipse, but since you don't get any XBox achievement for that, I don't see a point someone would do that. About xdem, pick what it is needed to be picked in his answer (and mine), throw the leftover, and move on. You shouldn't feel offended about what could say an internet randomer (xdem, me or another) to you.

Well, xdem is kinda right - not for the "idiots" part, but for the fact than the user is free to choose from all possible "error types", the way he wants it to be handled. Any "error" can be set as ignored, warning or even error. The initial post is kinda "naive" - there is no proper way to handle "errors", some of those "errors" are also "pointless" at best, "annoying" at the worst. A simple exemple can be illustrated with the "unused method parameter" error, which will be basically triggered on almost any "super" method, because most of the time the use is on the overriden method - a live exemple with sendPacket(L2GameServerPacket) method, which is blank in Creature class, so it will throw a warning here because the implementation is actually on Player/Playable. That "error", if activated, would probably trigger one or two hundred of warnings by itself - while there is strictly nothing wrong to begin with. Generally speaking, you set at least all performances types "errors" to at least "warning", but the leftover is basically up to how the developer see (or feels) Java. There is simply no point to activate everything.

I'm using Eclipse 2019-12, those enum warnings don't exist, and I will eventually edit my environnement when next Java LTS is reached. Some warnings are eventually hidden because they got no real point to be activated (I notably think about the switch "default" warning, which is desactivated). I won't answer to other replies, since they are at best naive, at worst dishonest. You only have to know than when some people don't like something, there is a little chance than many others actually like it.

Everything already exists, than's the whole point of AggroList, storing both damage and hate for each hitting instance. It's notably used to calculate which got loot priority.

Well, it somewhat does matter, since more work is involved into initial project, less work you, as server admin/ server developer, will have to do. But yes, in the very big lines, even basic L2J IL is "fine" to use and can handle hundreds of people, if you fix the 5-6 default exploits. Simply don't do a x1 "retail behavior" with it, or you will have around 200+ pages of bug reports in few weeks.

Nope, "1" or "0" is the default value for most, if not all stats. That level stuff with restore posted by melron isn't part of regular L2JIL, nor even any L2J branch - until I missed something. @L2RAPTOR not sure why you compare L2OFF and L2J - they are completely different. While L2J forks try to imitate L2OFF, they are still far from L2OFF. And L2OFF is, also, far from retail (C5-IL content was mostly "guessed", as L2J "guessed" content aswell). So basically, IL is "not achievable", since we rely on flawed L2OFF. See, after 10y of developping, 20+ devs, 400+ customers, aCis is still far to be perfect - even though, it goes on the right direction. Any randomer can "hotfix" a server and "imitate" L2OFF behavior - the difference between a good and a bad pack is about that "hotfix" policy, imho. When you pill up temporary solutions, that's like RooT's image - a terrible building with nice facade. Which doesn't mean your pack won't be popular - L2JFrozen being the best exemple of that "temporary solution" policy. If you check their dev timeline - as I actually did when it was active - you would figure out they did almost nothing as rework/rewrite. They mostly hotfixed things. And well, it looks it's enough for many people. As an admin and a player, you probably won't have to care. As a developer, it's the night and day comparison when you "read" a code with unified syntax, javadoc, correct conventions, etc... The difference can be so important than the time factor to understand "something" out of a source can increase by a factor of 2 to, easily, 10 - depending about code quality. I won't join the "aCis vs Lucera" battle :P. You only have to know they do different things, for different people. Simply use what appeals you better.

Normally, it's handled by passive skills.

lethal1 and lethal2 are 2 effects of lethal system. Those values (5 and 1) are % of being triggered, nothing more. To edit mechanisms themselves, edit Formulas.java (method should begin by "calcLethal"). Both work differently for Players and Npcs. Check for "lethal strike" here : https://l2industry.com/Home/C5

One dude on aCis forums needed transformations, and so moved aCis to Hellbound. You can eventually work with him to implement all packets. You can also downgrade actual latest H5 to HB.

Changeset 398 (2308) Admin commands - part II, Petition, TradeList, TargetHandler, Community Manager, Olympiads, Formulas, Bugfixes, Organization Admin commands - part II MovieMaker - Fully rewritten, merged under //movie and //sequence. Delete MovieMakerManager. - Sequences are stored under TreeMap for automatic sort based on index. - Work even if indexes aren't following each other. - Sequences parameters are set on individual columns for easier read. Delete AdminNpc, AdminCamera, AdminShop admincommandhandlers. - Delete //walker, merged with //show (walker). - Delete //gmshop, merged with //buy (no params needed). - Delete //show_shop, merged with //info (shop). - Delete //show_shoplist, replaced by simple //buy. - Delete old //camera (redundant with //movie, almost impossible to use) - Rename //cameramode > //camera. Fix 2 issues (knownlist is properly refreshed, the camera doesn't bounce back to initial position anymore). AdminPetition - Merge all admin commands related to petitions to //petition (show, unfollow, reject, join, reset, view). - Implement //add_peti_chat and //force_peti from ALT+G panel. - //setnoble is merged with //set (noble). - Add missing checks for //remove. Ty StinkyMadness for report. Petition - Overall cleanup (merge containers, Stream usage, Javadoc, multiple checks added, unhardcode HTMs, improve HTMs details). Rework ChatPetition to avoid to iterate upon sent message. - Allow petitions to be saved over server shutdown (lazy save), and properly loaded back (both responders and petitioner receive the Petition window with stored messages). - Implement the petition feedback system, and show it upon CLOSED state. - You can now add multiple users over a single petition (//add_peti_chat). If such added user "cancels" the petition, he can either cancel it if GM, or simply leaves it if regular user. - You can now enforce your target to petition with yourself (//force_peti). It will generate a perfectly regular Petition. - Add the possibility to switch from one Petition to another (active petition returns as PENDING if none active GMs are part of responders). - You can now move from one Petition to another simply joining another Petition - previous Petition will return as PENDING. - You can now unfollow current Petition without having to end it - it will return to PENDING if no left responders are GMs. - Set back the Petition as PENDING and remove associated responders if state is IN_PROCESS but no messages were sent. - Multiple integrity/sanity checks were added (avoid to reject if already REJECTED, etc). TradeList - Add Javadoc. - Add missing sysMsg ONCE_THE_TRADE_IS_CONFIRMED_THE_ITEM_CANNOT_BE_MOVED_AGAIN over self-locked TradeList. - Add missing sysMsg PRIVATE_STORE_UNDER_WAY over you/partner manage store mode. - Add missing sysMsg EXCHANGE_HAS_ENDED over unsuccessful trade - the most common unsuccessful trade being 2 empty validated TradeLists. - Fix an exploit moving distance check from trade request to validation. Ty StinkyMadness for report. - SendTradeDone packet now uses a static approach. TargetHandler - Add noicon over Recover Force. - Fix Signets symbols. - Delete TargetHandler PET. - Fix Treasure Keys. - Clear charges over Player death. - L2Skill addSummon/addCharacter methods aren't static anymore. - Rework canDoCast concept. Introduce ITargetHandler#meetCastConditions for Playable conditions, fixing numerous target issues over cast. Community Manager MailBBSManager - Move "Mail" class out of it. - Don't lazy load mails anymore, everything is done on startup - which avoid to db query to find last mail id. - Use PlayerInfoTable to retrieve isGm() instead of db query. FavoriteBBSManager - Introduce Favorites management (loading, saving, deleting being functional ; proper bypass saving being NOT due to the system chaos - mail coded in a way, memo in another, etc). Misc - Rename Manager > manager and bb > model packages. - Fix NPE over ClanBBSManager access upon clan creation. Ty Gigi85 for report. - Add the possibility to close Community Board using static approach (ShowBoard.STATIC_CLOSE). - Rename all related SQL tables to "bbs_". - Create ForumType, ForumAccess enums. Delete TopicType. - Rework the Forum/Topic/Post management and move it from "BBSManager"s to "CommunityBoard". Delete CPost concept. Structure isn't lazy loaded anymore, db connections are far, far lesser. Olympiads - Rename queries, tasks. - Remove synchronized, put _nobles as ConcurrentHashMap. - Drop _heroesToBe List (no use to retain it), compute it directly on HeroManager#computeNewHeroes. - loadNoblesRank() > processRankRewards(), use Entry to iterate data instead of keySet()/get(). - saveNobleData() "to_save" concept is removed, instead use INSERT ON DUPLICATE KEY. Also use addBatch/executeBatch instead of generating multiple PreparedStatement. - Merge few one-shot methods with their calls (scheduleWeeklyChange/addWeeklyPoints, init/updateCompStatus, olympiadEnd/updateMonthlyData). - Delete _nobles == null checks (impossible). - OlympiadStat doesn't call 4 times the same content anymore. Formulas - Hit accuracy calculation : Raise the lowcap from 20% to 30%. Modifiers are now directly applied over acc/eva diff rate (which x2 the impact). Base rate is 90, not 80. - Blow damage : fully rework the formula. - Blow rate : fully rework the formula. - Pdef calculation : Full Armors don't count LEGS bonus anymore. - Shield rate versus bows is now x3, out of 30%. Bugfixes - Fix pole attack over Players on peace zone. Ty StinkyMadness. - Fix CCE over Infinity Axe "Discord" effect. Ty Sahar for report. - Rework EffectConfuseMob > EffectDistrust. Only affect Monsters, add a radius check, called only once. - Fix 80+ Quests being broken prior to rev 396 Hasha refactor. Ty StinkyMadness for report. - Add few missing IdFactory cleanup (bbs_mail<>playerId, bbs_favorite<>playerId, bbs_post<>topicId, bbs_post<>playerId). - Don't spend SS over failed Blow. Don't show ATTACK_FAILED message aswell. Organization - Add Recovery Scrolls upon //buy "Scrolls" tab. Ty Somename. - Implement TeleportMode enum.