Tryskell

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.

I see you created a reddit about it 2y ago but nothing inside. "A D2 mod for L2" -> how does it even work ? Just curious.

I heard a lot about Ashes, if you manage to make a MxC guild I would eventually join when it's up (I'm support, generally healer, btw). Hopefully, we don't wait for nothing. Those days, games are launched while they're not even ready.

I played L2 mostly on C3/IL private servers (Dragon Network x5, Dragonians L2OFF), then on retail when GoD was released (around lvl 86) and except few hours on L2OvC (released by my laboratory monkey Sahar), I never played again on a server. I play TESO, some Satisfactory and I was on the Dark and Darker playtest (unfortunately it was only one week of game and I played for 3 days) those days. Most of my MMO experience is on non-Steam games : Warhammer online (where the private server state is way worst than L2J btw - mob don't use any skill), Rift, Dungeons & Dragons Online, Star Trek Online, Aion (private server), Fallen Earth, Black Desert Online, Lord of the Rings online (was collecting the Turbine Points to unlock multiple zones), Vindictus, APB Reloaded, Defiance, Planetside 2, Perfect Online,... I got probably multiple thousands hours of games on all those MMOs, played more than 15 for sure with heavy hours spent on.

It's not the packet which generates the issue, it's what happen after - IN RESPONSE OF that DeleteObject packet. Which explain why laRoja/AbsolutePower use ThreadPool to differ execution.