Salty Mike

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.

Original post of L2jRoboto HERE. Subsequent release of the Roboto 2.0 or as they are known, the Autobots HERE.

I've been getting similar for as long as I could remember, usually from random IPs. The one I could track in its entirety led me to a cyber-security firm, who was making random requests to test for vulnerabilities, as per their website. As such, I came to the conclusion that these random packet requests were just automated scanners looking for unsecured connections and/or vulnerabilities they could exploit. Could it be a malicious request - I'd say totally! Is there something to worry about - I wouldn't give 2 fks about it since they couldn't get through. The server closed the connection, and that's what matters. They'll prolly receive an `attempt failed/connection refused` response in their logs.

Can't be done without Java knowledge. You need to push and pull info from the DB table, which is done by SQL queries through the java core. You would need at least one method to SELECT (extract) the existing data. If such a method was not provided with the said package of weapons and armors, I'd assume that it was created for a particular set of servers, which use DB to store static data, quering it every single time it is to be used, as opposed to XMLs and keeping the data in memory for future use, thus reducing DB usage. There are pros and cons in both approaches, but I personally prefer using XML over SQL for such type of data, especially considering the difference in the amount of RAM servers had back then vs now. The overhead shouldn't be a problem if handled carefully/properly.