Tryskell

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).

L2J team is aware of that issue since 3 days. About aCis, we never used that library no matter the revision, but I'm aware some forks of my project migrated to it. You can solve the exploit updating log4j lib ASAP to the version 2.15.x and superior. Added to @HyperBlown links, more infos here : https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/ PS : that library is used everywhere, so consider to review your whole server if you own and run multiple services holding Java projects.

New revision is out ! Thanks to all contributors !

The only possibility would be to use a Threadpool and call it every X times. That packet DRAWS things on client, there is nothing like "realtime". It stays on screen until you decide it mustn't stay on screen. As you say, more you use forms, laggier your client will be. At this moment, I don't think it's possible to dump all the "hidden" forms, even after a packet reset. Client properly cleanups when the Player actually disconnects to the lobby, which probably cleans all forms from client memory.

aCis spawnlist was parsed from L2OFF server startup on rev 308. The thing is, L2OFF has multiple spawnlists for 7s, and the competition wasn't set on the L2OFF, therefore the spawnlist with no stones was actually parsed. It was fixed with the introduction of SpawnManager and the rework of SevenSigns by Hasha, at rev 402, which now handle all 7s spawnlists properly. You can pick any random L2JIL spawnlist (even aCis spawnlist before rev 308 is ok for that) and add back the good catacombs ids. In any case, and whatever you will do, it won't be retail-like, since you will have only one spawnlist.

Hello back everyone to this historical topic ! aCis MxC subforums are officially given up, so this historical topic will be used to comment, share changesets, etc. Please continue to use either aCis forums or Git "Issues" tab to report an issue, your bug report will be lost in this thread. Eight years passed since last answer of this topic, but aCis didn't freeze its development to rev 308 ! Last news are : Freemium concept evolved from 1€/revision to 100€/initial fee and 10€/month (and 100€ re-subscription fee if you failed to pay one month). Your contributions allow you to earn cookies you can trade to "pay" initial / monthly fees. Best contributors can receive money. You are now set to Git as temporary user, revisions aren't delivered anymore by forums. Cycle 40 focuses on the proper implementation of SpawnManager (territory bound spawns). Regular, Castles, CHs, 7 Signs, day/night, bosses spawnlists are already handled with that new system. Revision 404 (2601) is actually the latest revision. 2255 commits were done over 58 revisions, for an approximative count of 38.87 commits per revision since rev 346. aCis got its own PTS, called Blackbird. You can test and experiment LATEST revision here. Characters are set with GM access. Next free revision is already know to be rev 401, and we be delivered at Christmas ! I won't share all changesets from 308-404 here (you can find them on aCis forums), but here is the latest, rev 404 content : Thanks to all people who contributed to make aCis what it actually is !

I actually participated to the rewrite of some of those formulas (actually : pdam, chargedam, accuracy, blow rate, lethal rate, blow damages and heal formulas), so I can confirm the ones I named match with AdvExt PTS testing.

Beta is useful to polish things and get reports. Testing things alone is almost impossible, you always forget something. It's also time you waste than you could use to solve issues of your server. Obviously you can edit things on the fly, during live server, but a really stupid issue can actually fuck up your whole server start from the very beginning. That can go from wrong economy, to an unfixed exploit, to a not enough good hardware... Such things can be fixed AFTER a server launch, but most of the time players won't be that much patient and will simply migrate to another server if your server got issues. I would even say lower your rates are, more the need of a beta you would need - x1 being the worst of all. A simple quest being repeatable instead of non repeatable is actually enough to fuck your server economy.

isStackable() is used on multiple packets, for exemple MultiSellList. Simply do a search over net.sf.l2j.gameserver.network.* with isStackable().

Actually it's the complete versus : L2JFrozen is based on a RU pack, and RU codes terribly wrong (globally speaking). L2JFrozen did nothing about that, for his short lifespan (1132 rev is 2013 or so). aCis is my project, btw :P. I added a lot of javadoc, names of methods are clear, and classes and general organization is clear aswell. I got only 100 admincommands with proper description for each, all data is unified between SQL/XML, there is no side JARs except the connection pooler,... I don't try to convert you, I know you already invested time into your project and since it's an hobby, you don't care. I just set back some reality :P. L2OFF is even more simple, you barely can't edit anything by yourself.

If it did the trick, then it was indeed, your client packet process queue which was saturated. I personally left it to 80 after seeing some strange artifacts with higher values. They are set on 20/80/80/20. Btw, you only repelled the problem. The problem will probably reappear if, let's say you got multiple ppl doing what one people was actually doing. Imho, you should still check exactly if something can be fixed on polearm uses (packets sent wise).

There is no reason to get such lags, even on IL, with so low amount of characters involved. It's definitively a server issue, not a client limitation. Since 2nd character isn't affected, I would say the first character packet queue is simply filled, packets are lost since queue is full, and when character dies there isn't anymore packets to send so queue can be finally cleaned and everything popups magically. A polearm attack normally uses only one Attack packet, filled with an array of Hits. If L2JFrozen is badly coded, than subsystems (startAttackStance, etc) can eventually be called on every character hit, launching the method multiple times (up to 20 targets on IL ?), but that has to be debugged. You could have more clue about what exactly happens with one pole hit launching L2PHX and seeing packets. There is some easy network configs to edit in order to improve packet send (you can see some tests on my own video here, answer in 1:13). In the video, the drop of ClientStats didn't help at all, the MAX_SEND_PER_PASS did everything. The default value was edited in 2017 on my pack.

Do the second client lags as the first one ? You can use L2PHX to see running packets. The code I posted is simply what you got in your own file. I simply shown that isDead() check was set here, there is even the reason in comment.

@Override protected void onEvtAggression(final L2Character target, final int aggro) { L2Attackable me = (L2Attackable) _actor; // To avoid lag issue if (me.isDead()) return; Seems you already got what I had in mind. If you type in chat during that lag, or move, is it properly working ? If not, it's probably packet queue flood. Which is strange is even death effect is delayed, but death itself isn't (and you seem dead, since HPs never go back by either HP regen or vampire). I never saw that. Also, if you got a second client (run in on a second computer or use a nosleep mode), what actually see the second client ? Can it move/speak/attack/whatever else properly ?

It's a basic issue, than L2J itself had for quite a time. You miss a isDead() check upon one of the AI event.

My point is to emulate a game, and even more particular, a chronicle. Not to build something convenient. L2J added geopathing for players chasing other players, while the chasing is in fact in straight line, in both extenders or Innova. At this point, it's not being convenient or not - you simply play another game. Also, I have to rely on something, being wrong or bad. L2OFF and any related forks, even if partially wrong, are still more accurate than any L2J (If L2OFF is 95%, L2J is 75%). The wrong part of L2OFF is about extended content (for IL, C5 and IL content then) and for that you can only rely on upper chronicles. Gameplay base was almost never touched.