Tryskell

Your character is obviously desync. If it happens on any cases, even simple ones, it's very likely something like a stopMove() is missing, or than the calculation part is flawed. With a debug concept based on ExServerPrimitive you can easily figure out if server is currently doing crap. About basic movement, no, it doesn't do that on aCis. Green dots show real desync based on what client expects. Desync stays low. Was attacking an elpy from great distance. https://imgbb.com/fCQBKKS On aCis, you can generate such desync if you frantically click on one direction and attack in another, but that's more a lack of locked movement state (during the 100ms updatePosition) rather than movement lacking itself. Movement still needs some love.

On C1 patch notes : When a pet is recalled, the items from the pet's inventory are added to the owner's inventory. If the owner's inventory is full, the items are dropped and the owner has priority to pick them up for fifteen seconds. If the NPC or main server goes down, the pet retains the items in its inventory. There is nothing about an edition of that behavior in chronicles up to at least IL, but I know than on higher chronicles, they save the items as pet inventory (L2J H5 does it, at least), so probably the concept evolved meanwhile. Also, as I tested L2OFF IL based on GF (you can actually do it yourself on AdvExt PTS), it looks indeed than pet inventories are shared. There is a common pool of items which is kept alive when you unsummon your pet with items in, and resummon another pet.

CastleManager.java:159 doesn't seem to be able to retrieve the Castle you try to pick. You probably manually deleted that castle.

The initial topic is refreshed concerning Cookies (to be shorter and easier to understand) and Bounty / Bounty Hunter concept is added (was added on Discord since few years, but not on main topics). I'm currently working over items : lazy SQL saving (1min single task, every modification is kept in a list and addBatch/executeBatch and list is cleared) instead of 1 query per item edition, which will save probably 80-90% of SQL server activity. That task handles item add/update/deletion, pet deletion and augmentation add/deletion. InventoryUpdate packet will be automatically filled and sent, there is no more savage ItemList or IU packet stacking on each other. Wrong uses of InventoryUpdate are indirectly fixed. It's also optimized for stackable cases in very short spans (getting proper values if I macro 50 Player#addItem, without InventoryUpdate spam). ItemList is only used on Player login or if inventory must be displayed. AI is on hold state from my side, one of my dudes currently struggles with Frintezza script.

Sorry, but I never did paid tasks for other people, I busy on my own pack since few years. I only help on those boards from time to time. About your first issue, you should check if something like an abortAttack / breakAttack() is called when you start to cast and remove it. It was probably added to hide another problem, so be aware you probably will generate another issue or even an unpatched exploit. About your second issue, if your "stuck over sleep" issue can be resolved by pressing esc on your keyboard, it's a missing ActionFailed packet to send during onEvtSleeping (and probably other types of onEvt like paralyzed, etc).

You have to queue the Intention to cast a skill when you do another action. Not all actions trigger that effect, for exemple moving is broken by a skill cast, but pickup should be queued, attack > attack is also queued, etc. If Sunrise store 2 intentions (at least current and future, you can also have previous) on AbstractAI, that would be easy to fix. Otherwise it's a complete missing system and you have to rework most of AbstractAI and children classes to use that system (pickup, attack, cast,...). On aCis it is stored into AbstractAI up to rev 401 https://gitlab.com/Tryskell/acis_public/-/blob/master/aCis_gameserver/java/net/sf/l2j/gameserver/model/actor/ai/type/AbstractAI.java protected Intention _currentIntention = new Intention(); protected Intention _nextIntention = new Intention(); I suppose than, currently, you enforce to stop the attack/move/whatever by calling stop() in the begin of the cast process.

Long time no see ! Rejoin fee deletion Since 21th October 2022, the "rejoin fee" concept has been deleted. The initial fee is still 100€, and you still have to pay monthly to get access. If you lose access and want access back, pay 10€ minimum. I reserve the right to refuse you access if you abuse the system. PTS is refreshed with feature/IU-update branch for a short time being ! This branch adds a unique way to refresh Pet and Player inventories, supposingly fixing any type of bad uses of InventoryUpdate packet, queuing changes and sending them after a short delay (333ms actually). Pet and Players also hold one unique packet per entity, avoiding the generation of thousands and thousands of packets. Finally, "lazy" uses of ItemList are dumped (crystallization and wherever places "complex" operations regarding inventory update was done and L2J decided to lazyfix it with a ItemList send), and ItemInstance doesn't hold anymore ItemState. All changes are automatically done and sent. Up to Sunday 12th Feb, reported issues regarding inventory management will reward you x2 more cookies (4-20 cookies max instead of regular 2-10 cookies), depending about issue severity. The branch will then be shortly commited into master branch. Triskl, when next rev plx man ? It's not because there is currently no "public" revision, there is no work done in background. We're currently at commit 2832, which is 162 commits above current release. For the changeset lovers (and I know there are), the next revision is currently 77 lines long (and obviously more with the introduction of InventoryUpdate rework). Happy candlemas !

1- You store a Future _spreeTask on the Player level (your impro variable should be named _impro, btw). 2 - You cancel it and relaunch it on every kill : if (_spreeTask != null) _spreeTask.cancel(false); _spreeTask = ThreadPool.schedule(() -> _impro = 0, 60000L); Basically, if you kill someone, it will cancel current task and reschedule it with a fresh timer. If you want to avoid to make one task per Player, you can also handled it using a Manager (similar to multiple other timed stuff : pvp, random animation timer, or even movement in default L2J...), where you register all Players on a 1sec task manager and test each of those every second.

Hiho, correct me if I'm wrong, but I don't think regular L2J handles that scenario too. Part of latest L2J LoginServer : InetAddress bindAddress = null; if (!server().getHost().equals("*")) { try { bindAddress = InetAddress.getByName(server().getGameServerHost()); } catch (Exception ex) { LOG.warn("The Login Server bind address is invalid, using all avaliable IPs!", ex); } } try { _selectorThread.openServerSocket(bindAddress, server().getPort()); _selectorThread.start(); LOG.info("Login Server is now listening on {}:{}.", server().getHost(), server().getPort()); } catch (Exception ex) { LOG.error("Failed to open server socket!", ex); System.exit(1); } And there is no reason it worked before, since no edition is made on that level, and it is identical to what latest L2J LoginServer delivers. Basically, hostname is translated into IP on server (being ls or gs) startup and I don't know any task updating it. As Trance said, server should use DynDNS plugins. (Btw I'm sorry, but I can't quote or got any format tool for the message since few months already).

Don't use FBIAgent's TvT, it is at least 10y old and since BRs (=Sarada) don't know how to code, they simply re-share with 0 added value (or bad written configs addition).

You tried to summon a SummonCubic but couldn't initialize an instance of tha Npc because it requested "cubicLvl" integer value but didn't find it. Verify your data.

1 - Use a Map to store content, ppl can flood your server simply pushing one button (put command in macro and voila, ask your clan to do that). Db should be used only to load/save at start/stop, or eventually for important stuff (character/inventories). Tbh, characters got no reason to store that info it should be a specific table (or even better, PlayerMemo). 2 - Make a new Npc instance or, even better, a new script with onFirstTalk event.

@Ugleethyn Setting the TeamType isn't enough, if you only do that it will be sent the same way for everyone. That's basically what does Duel. If you check shares, you will see isInSameParty check over CharInfo, which enforces conditional appearance depending if being part of the same Party or not. So sending the "same" packet generate different output, due to inner packet conditions.

Movement is a complex (not the hardest, but still) code, unfortunately giving you an "exemple" would be basically coding it for you. And launching yourself on such thing without experience is bad aswell. Eventually, read old L2J code, movement is working "ok" - at least it doesn't have your type of issue. Try to mimic what exists, on whatever pack the feature is working on. You can begin to quote moveTo and unquote moveToPawn and figure if it works better or not.

As says Nightw0lf, classes in general got "L2" dropped and the instances were renamed in a single revision during rev 367. General rule is to drop "L2" and "Instance" out of it, the exceptions are listed in changeset 367. About regular classes and methods, they also can be renamed, merged, refactored - it's largely splitted over aCis history - 36th cycle was almost only about it, and laterly was regrouped under Organization tab since rev 382+ (package holding all enums, addition/removal of methods, etc). If you manage to re-adapt a code, consider to share it back on the associated topic. People forgets to do that, those days.

moveTo goes on the exact same spot than X/Y/Z. It uses MoveToLocation packet, which got no specific content about offset. Use moveToPawn to set and handle an offset. If you can't use moveToPawn (for no reason, but let's say you can't), edit updatePosition in order to handle offset and call a stopMove if you reached the place (if offset > 0 and dist < offset return true). It's definitively not what L2OFF is supposed to do, but it will work. Without proper offset calculation/handling, everything like bows etc will make you melee.

@xJustMe answer is fine, eventually make the difference between leader (in red) and regular members (in blue).

Just as a sidenote (for aCis), the AI thing takes a longer time than expected because L2OFF data isn't reliable at all and we struggle to find decent data to parse (current version is like 15+-1h respawn time for boss and 3x the amount of spawns sometimes, for something tagged/shared as "untouched"). C5/IL content is handwritten as if you or me had it written manually - and we probably could do a better work. L2OFF IL is a fucking clown, if you ask me. I'm sad to be an IL lover, that would be far more simple with C4/GF (probably would be already done with C4 since they got far lesser systems/AI types). The parsing itself is done and repeatable at will, the core logic is mostly done (regular/regular bosses/70% grandbosses). The leftover will be AI exceptions (particular individual AI), which won't run any AI time we find/do them.

for (WorldObject object : getKnownType(Player.class)) { if (object instanceof Player) { sendInfo(object.getActingPlayer()); } } > getKnownType(Player.class).forEach(p -> sendInfo(p));

Name appearing as null is fine, since it's the name the pet owner decides to put which is taken in consideration - and by default, no pet got any name. The "null" appearance only occurs on custom (admin) messages, so it's not problematic aswell since nowhere else client finds such info. We can use template name if no personal name exists, but that's only for aesthetic purpose. I will make a commit for that. The inventory flute with "no name exists" is also, perfectly fine from the moment the owner didn't set any name (same on L2OFF aswell). If he sets a name, the value is edited. About the interaction itself, I tbh don't remember if I had to fix such issue between rev 401-latest. It works as intented on the PTS, which uses latest..

You probably make something wrong, since everything is on the good place. https://gitlab.com/Tryskell/acis_public/-/tree/master/aCis_gameserver/config ---- About aCis we're working on retail AI implementation since almost one year, it will simply slap every single L2J project's face by a FAR, FAR margin on the AI question once it's fully operational. Lucera, until they made major changes, wouldn't compete anymore - since they use the basic L2J RU fork than any russian is using (eg. L2Scripts included). Regular monsters and few bosses are already testable on aCis PTS.

https://stackoverflow.com/questions/62637584/how-to-set-default-jdk-compliance-level-and-release-enabled-in-eclipse-jdk-prefe https://stackoverflow.com/questions/50734953/how-to-set-jdk-compiler-compliance-level-to-10 etc. Do some search, it's your environment which needs some fixes.

Edit your Eclipse compiler JDK compliance. Also be sure to use latest Eclipse.

Delete JRE (which is version 8 btw) and install JDK 11.

Well, you're kinda heroic to edit all those data to match your own needs. I wouldn't get the same patience :D.