Salty Mike

A couple of questions for the L2OFF devs out there: 1. Where are the packets encoded and decoded (or their structure saved) in the core, in the sense of - is there a file which lists the structure of packets, similar to L2J or the UIPacket.uc in the interface? 2. Is it possible to track (and record) SERVER<->CLIENT packet communication/exchange, and if so could you share how?

What I sent is something you have in your server's core. You don't need to modify the client.

You need to utilise the following packet: `const S_EX_SEND_UI_EVENT = 398;` It's structure is as follow, or at least on new chronicles: writeD(_objectId); // EVENT IDs: // 0 - Timer: MM:SS (Description on bottom) // 1 - Disable Timer // 2 - Green Line with percents and timer // 3 - Number of residues collected (N pcs.) // 4 - Timer: MM:SS (Description on top) // 5 - Blue Line with percents and timer // 6 - Yellow Egg progress // 7 - Red Egg progress // 5 - Line with gears, percents and timer writeD(_type); // EVENT_ID writeD(0x00); // int ASK writeD(0x00); // int REPLY writeS(String.valueOf(_countUp)); // 0 = count down, 1 = count up timer always disappears 10 seconds before end writeS(String.valueOf(_startTime)); writeS(String.valueOf(_startTime2)); writeS(String.valueOf(_endTime)); writeS(String.valueOf(_endTime2)); writeD(-1); // what message to display by id, if any - NPC String Id // you can string several writeS() below, depending on the amount of variables in the npc string. only 1 line if NPC String ID = -1 writeS("Custom Text To Display or fill in variables in the NPC string by id"); // works in conjunction with the above line

No such file was present in the share you mentioned, nor has such a file ever been publically shared, as far as I know. As a matter of fact, the whole system in l2aepvp was different. It was allegedly an earlier version and it used something called Player Passport or something like that. Anyway, the only way is to reverse-engineer (reconstruct) it by looking at the calls and imagining what it is used for and what it should consist of.

You sure can. You just gotta send them with the Insignia/Emblem packet, and not the clan/ally crest one. The images are saved exactly as PNG files in L2jEternity and they show up just fine. Sure they are not MB in size, but up to 150kb each, which is not that small in terms of dimensions - 256x256 px. In comparison, the crests are 20-30 times smaller. So, to cover the entire background of the Community Board, you'd need like 2 rows of 3 images. Not terribly bad, imo.

What about Clan Insignia (emblem), is it not available on Interlude? We can send picture from the server to the client like that on HF, which are then stored in, and acceessible from, the Crest.utx. Disclaimer: I haven't played interlude for 15+ years, so pardon my memory lapse.

You've got a few options, in no particular order - L2J Eternity, L2J Sunrise, Mobius.

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.

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.