Tryskell

Fix the import, that's the first recommended line.

I don't see anything blocking, even on latest. I don't even think there is a single import edit to do : IXmlReader is on since multiple dozens revs (377), Player aswell (367). If you got issues applying on network packets (because of lines edition), simply read the actual content and apply manually...

You can first try delete the import and fixing imports (ctrl+shift+O), you can also try to copy-paste the faulty import from a valid class to the lacking class. You seem to use post-367, since Playable isn't named L2Playable and I did it everything in rev 367-368. So Player class is supposed to already exists in your temporality (you can make a search and see if it exists).

For me, it's definitively not. Whatever is shared as a library must be shared as a source. There is strictly no reason to not share sources, since Java is extremely easy to decompile - the 2 only reasons are to try to make more money out of nothing, and to bother people. Anyway I stop the offtopic. ;)

Shortly said : yes, it is allowed and I got no problem about people reselling old customized sources, but you buy a second-hand product where I had strictly no control over it (introduced issues / missing features / backdoors). If you meet a problem, I won't be your man. Simply use basic morale, and if not, your empathy. If you lack both, consider you aren't a human. Also, and since I read the description (and except if the seller did an error) : I never recommend ANYONE to buy a precompiled pack without sources. It's a big red flag for me, and it should be for you aswell.

That's not something I have to take in consideration, also, in case of autobot/fakeplayers, nothing stop you to use the method used by the monsters (which actually use geopath). It looks like L2OFF "rewards" ppl for good positioning, that's simply part of the gameplay and I do as I see it. Since the time, you should know it's not the house's motto ;). Consider I generate some jobs for people. If you begin to add booleans for such things, it's a never ending path you decide to choose (and which I never considered, since people are enough clever to share themselves customs when they want to). You can also educate people to play the actual real game. PS : there's actual real cases where auto-attack is supposed to occur, like arenas. And they are normally respected.

if (player.isIn3DRadius(zone.getLastSpawn(), getInt("zoneRadius")) ...or 2D if you don't need Z check.

Client got nothing to do with used pack, and the answer is definitively no - if you speak about ExServerPrimitive packet, it simply accumulates until client can't handle it, and at my knowledge there is no counters, except disconnecting. If you manage to discover a pack where it properly works, feel free to show me some sources.

The localhost internal check was reintroduced in rev 404.

If someone wants to make a t-shirt : https://ibb.co/gdchrCz and don't forget royalties. Plot twist : Lucera is more or less customized L2Scripts.

lease and defaultBid from clanHalls.xml In a general matter, static data is ALWAYS on XML and dynamic data is ALWAYS on SQL. Exceptions can occur, but for 95% of content it's the motto.

The thread is simply an executable class, the ScheduledThreadPoolExecutor handles the management of it. How ? Who cares, it was optimized for you by some high-grade dudes years ago and added directly in Java. Seeing how much tasks are generated by seconds (network, AI, and random tasks), it probably costs almost none CPU/RAM. You only have to assure yourself to avoid to bottleneck the system. Not sure why you need this answer, your best bet is to make tests yourself because litteraly none did that before you (at least, I didn't).

If you properly use L2J ThreadPoolManager implementation, you simply pick a thread from an existing pool and once executed it returns to the pool - similar to a db connection factory. L2J implementation is nothing more than dedicated ThreadPoolExecutor / ScheduledThreadPoolExecutor, 4 of each types. You can read more on Google, as introduction : https://www.baeldung.com/thread-pool-java-and-guava https://www.geeksforgeeks.org/thread-pools-java/ And whatever related to ThreadPoolExecutor / ScheduledThreadPoolExecutor classes.

You shouldn't connect your server db to your website, it's extremely easy to down your server attacking your webserver (+ potential security breaches if you suck at webcoding). About the VPS itself, nowadays you can connect it to any VPS, from the moment you got 2G dedicated to JVM that's enough for 150-200ppl. You can even run it on a Raspberry Pi.

CharEffectList#add - if it doesn't exist, it's anyway in whatever class you found _buffs container.

Well, cycles 38 and 39 were built upon opportunities. Many ppl shared multiple refactors in same time : intentions and attack/cast (bowling4soup), movement (me/bowling4soup), pathfind (Hasha) and targethandlers (me/StinkyMadness). It basically pilled a lot of issues in the same time - for a long period of time. Cycle 39 was dedicated to "restabilize" the whole thing, and while there are still important issues, it achieved its goal. About making aCis "stable", well, the problem is, if I don't push it on master, none gonna test it. It will simply decay on a branch. All those reworks I just named wouldn't be directly commited, but would simply sleep in some branches, time some "non-existing beta-testers" test it. I have to rely on users to act as "testers". I test what I commit, and (try to) fix my own mistakes - but other sharers aren't me, and I have to fix sharers issues aswell. With the introduction of PTS, we can now aswell push it on a test server before committing it. That probably would have been really helpful when 389-390 occured, but well, no point to redo history. Finally, current latest revision is, imho, the way to go : You will find many issues on 382 which were fixed afterwards (and by many, I speak about 200 to 500 issues). Even on a PvP server, if you don't care about quests fixes, retail formulas are better than custom ; You can report issues and make the project more active ; If you got knowledge and/or money, you can eventually share fixes from your server to the mother project (either from an hired developer or yourself). Current cycle 40 is about spawns, of any type. Important steps were already achieved, as you probably read (or tested on PTS).

No problem, from the moment you are respectful, no reason I'm not. :). I wish you a happy new year ! You can also eventually test latest (405) aCis on its PTS, Blackbird, to see if it fits your needs or not.

Revs 383 to 399 got huge reworks impacting important part of the gameplay (cast/attack/move systems, intention system, pathfind, targethandlers,...). Revs 389-390 themselves added something like one hundred NEW issues, which were slowly soaked up during the whole 39th cycle. About stability, 382 is the last stable revision. You will miss tons of fixes, retail formulas, spawns suck, etc - but it's stable. Rev 401, while being "stabilized" compared to the whole 39th cycle, is still impacted by important issues (boat unstability, water movement issues, etc). There's still something like 10-15 issues introduced with cycles 38/39 which need to be adressed, but all in one, it goes in the right direction.

The behavior is normally driven by RelationChanged packet.

aCis 401 has been pushed as the new latest public version. It will replace revision 382 for at least one year, if not two. Almost 25.000 files were edited between this jump. Happy end of year holidays to everyone !

It is indeed the problem.

Provide the associated lines from GameClient, it's definitively not vanilla 399 (first line is a bracket, second error line is javadoc).

Your version of Java is wrong, your server is using JRE, while it should be JDK. Uninstall all your JREs and install JDK.

isLethalable was added recently (rev 404), for previous revisions simply edit the formula calcLethalRate, values were hardcoded here (instances types and npcId types).