Salty Mike

I wouldn't be so quick to dismiss a claim, especially as strongly worded as mine because I might not be talking nonsense afterall. But I suggest you check for yourself, first. Line 195 looks pretty crucial to me: https://github.com/sdrak94/inertiax/blob/main/src/controller/InertiaController.java#L195 Yet, I don't see the L2PcInstance on the Github repo. Either I'm blind, or it is missing, and if I had to choose one or the other, I'd bet my life on the latter. Here's another example - the method below (Line 161), as crucial as it seems, looks empty to me: https://github.com/sdrak94/inertiax/blob/main/src/model/InertiaAct.java#L161

There are as many approaches as stars in the sky, for all I know. You could create a class variable in MonsterInstance.java, which will hold the Object_ID of its first aggressor/dmg_dealer. From there, you will have to add a check in the RequestAttack and RequestMagicSkillUse packets and/or in some doDamage()/reduceHp() method, which will check if the damage dealer is the first aggressor, and if not - reduce the damage to 0. But you also have to be mindful about special cases, such as: - what happens when a Warlord runs around an area, provoking everything just to trigger the aggression and then just goes to town waiting for someone else to kill the said mobs so that the WL can collect free rewards? You might have to play with the DefaulAI, or the AI of monsters and hook a function that would reset the aggressor_id value under certain conditions, such as - the aggressor is not in X range or the aggressor is dead, or the aggressor is not online, or the NPC/Monster's AI is in INACTIVE state, which would indicate they are not in combat. - what happens when the aggressor is in party? should the said aggressor/dmg_dealer variable be a List/Set of players which are all eligible to deal dmg or receive rewards?

It won't work on any, as is. It is missing crucial pieces of the puzle, which you'd have to figure out on your own. And no, I'm not talking about the path-builder.

I'm currently working on an advanced auto-farm compatible with older chronicles (C4, IL, HF, etc) and older L2J-Mobius builds. https://imgur.com/a/LJS2OMC

Protocol version? Server side only or client side too?

Pick one and your guess would be as good as any! // Checks for armor set for the equipped chest. if (!ArmorSetsData.getInstance().isArmorSet(chest.getId())) { player.sendMessage("Error: You can't visualize current set."); useVoicedCommand("dress-armorpage", player, args); return false; } L2ArmorSet armoSet = ArmorSetsData.getInstance().getSet(chest.getId()); if ((armoSet == null) || !armoSet.containAll(player)) { player.sendMessage("Error: You can't visualize, set is not complete."); useVoicedCommand("dress-armorpage", player, args); return false; } if (!chest.getArmorItem().getItemType().getDescription().equals(dress.getType())) { player.sendMessage("Error: You can't visualize current set."); useVoicedCommand("dress-armorpage", player, args); return false; }

<-- Can do, for a fee.

That is probably because on newer chronicles, the skills of pets were replaced by "ACTIONS". In any case, you can circumvent that like this: Find a packet titled something similar to "SkillList". It might be named differently. Depends on your build revision, I suppose. There, you can add an IF to check whether the character is mounted, then take the MOUNT ID, and fetch the skills of the player's summon/mount and add them to the list of available/known skills.

If you are this new to java, I would strongly recommend using IntelliJ Community Edition (free) instead of Eclipse since it indexes your entire source and makes it extremely easy to navigate forward and backward dependencies and method calls. Now, on the topic. Unless your Mobius sources are ancient, they should already have native support. It is called `DailyTaskManager`. It would be impossible to give you a mould without such a DailyTaskManager. I would suggest you parse/adapt it from a newer source version if you don't have it. The logic is rather simple once you get to understand it. 1. You need a handler to count the mobs and give rewards, etc. 2. You need to keep mission status for each individual player in the database. 3. You need to INSERT the data when a player takes the mission, UPDATE it whenever you like, be it on every single mob or not (I would only update the DB on player disconnect/log out, or on mission completion), and SELECT/extract it when the player logs in (EnterWorld.java). 4. You need a way to get the Mission Reset Type (Daily/Weekly), and you should call a reset method similar to the one at the bottom of my post from within the DailyTaskManager every day at 9am or whenever you like. Keep in mind that the above is not an exhaustive list, but some generalised approach aimed at helping you see the bigger picture. public synchronized void reset() { DailyMissionResetType reset = _holder.getResetType(); switch (reset) { case NEVER -> { return; } case MONTHLY -> { if (Calendar.getInstance().get(Calendar.DAY_OF_MONTH) != 1) { return; } } case WEEKLY -> { if (Calendar.getInstance().get(Calendar.DAY_OF_WEEK) != Calendar.MONDAY) { return; } } case WEEKEND -> { if (Calendar.getInstance().get(Calendar.DAY_OF_WEEK) != Calendar.SATURDAY) { return; } } case DAILY -> { } default -> { LOGGER.warning("Unhandled daily mission reset type: " + reset); return; } } try ( Connection con = DatabaseFactory.getConnection(); PreparedStatement ps = con.prepareStatement("DELETE FROM character_daily_rewards WHERE missionId = ? AND status = ?")) { ps.setInt(1, _holder.getId()); ps.setInt(2, DailyMissionStatus.COMPLETED.getClientId()); ps.execute(); } catch (SQLException e) { LOGGER.log(Level.WARNING, "Error while clearing data for: " + getClass().getSimpleName(), e); } finally { _entries.clear(); // resets the entries in the Manager. DailyMissionsManager.getInstance().clearEntries(); } } *Disclaimer: The provided code snippet is just an adaptation of Mobius' implementation on newer chronicles.

Newer clients have a feature called `itemtooltip`. High Five client does not support it natively, as far as I know. However, it should be recreatable by some skilled client dev.

The error says it all, buddy. You are trying to assign a value to an INT that is greater than MAX_INTEGER value. It won't work like this, and there will be so many more problems and places you'd have to touch. I'm even shocked that the client accepts these crazy-ass IDs, at all.

Sure you can change the weapon IDs. I can think of not one, but two approaches, outright. 1. The Icons are supposed to be stored in a DAT file and sourced from there by the client. If you are talking about icons in HTML, then you could alter the structure of your datapack's items, and respectively the Item Template and Parser structures in the java core. The structural change would involve adding a hard-coded string for icons. You could also write a parser to get the info from within the client DAT file and put it in the XMLs. 2. Alternatively, you could check if the `buildFastLookupTable()` method in the ItemData.java stores the item ID as an INT and change it to a LONG.

I only have one comment, the rest I agree with. If they are well-known, it means their core is top notch and their work ethic, community management, advertising, business practices, etc are top notch too. Assuming they were to start anew with a different core, it would mean they would have to first fix the core, in its entirety, else they'd lose their players. It all sounds quite a bit speculative and extremely superficial to me. The best way to keep the authenticity is to upgrade, as opposed to downgrade. Making an IL core working on new client is better than making a new chronicle "play like IL", just like "downgrading" your favourite newer BMW car, say a 2024 X5, to a look like/resemble an older version, say the 2008 variant, won't make it drive nor sound anything like the original you are aiming for, unless you completely take its insides out and rebuild them from scratch. While it will probably run much more smoothly, people who love the older version and cannot stand the newer versions, such as the IL-loving community, would never be happy and outright refuse to get taken on a ride. It is a bit counter-intuitive, I know. But people are who they are, especially the IL community. Too stubborn to get outside of their comfort zone, I suppose. Not shaming anyone here, just expressing an opinion. In any case, now you can #start_hating.

There is no code I could give that would do the job for you. It is quite tricky and depends on many unknown variables, mainly the source you use, the build version, etc. And before you spill the beans - no, I don't know each and every single build by heart, so don't bother. Just find a packet named "Say" or something similar, and search for an IF or a SWITCH case featuring a party check. Inside, you add a simple IF to check whether the player has enough currency or not and to take their money. This is as far as any guide on the matter could go, without providing a bunch of code that you wouldn't be able to use in 99.9% of cases.

You just intercept the chat attempt packet in the server, since it must go through the server to reach the other clients/players, and then set a couple of checks, if chat type is party or world -> do this and that, else do as before.