Salty Mike

I'm interested in the solution too, out of pure curiosity. The flood protector will work only if the macro is being sent non-stop, which I don't think any Client Dev would be stupid enough to do. Instead, I'd expect that it is being sent every X ms, which would mean you wouldn't be able to reasonably differentiate between genuine MacroSpamming and auto-macroing. One rather reasonable assumption would be to monitor and record the difference between UseMacro requests for each individual player and to disconnect them based on certain criteria. Example - (MarcoUseRequestTime_1 - MacroUseRequestTime_2) != (MarcoUseRequestTime_3 - MarcoUseRequestTime_4) + X_miliseconds_to_account_for_network_delay. [note]: Just note that a skilled client dev could simply add a random delay to macro-looping to bypass the above method. As far as my knowledge goes, the ultimate solution should be in the client. Maybe you can add something to your interface, some check that will be done through a packet every X seconds, similarly to how pinging works, but this one will just make sure that the player is using your interface and not another modified version.

1. Replace the int votes expression with this: int votes = Integer.parseInt(line.split("\"")[1]); 2. expand your IF(line.contains(...)) with an additional condition - || line.contains("vote-count") 3. Finally, make sure that you exit the loop on the first match, just in case.

You send a server-to-client packet named "S_EX_REDSKY" with a single INT parameter for duration.

Buying a ready-made thing is never a good idea, because you leave yourself exposed to scammers, who are always lurking in the shadows, as you've probably already noticed. Moreover, you can never be sure of what you are buying, how good it is, even if they show "proof" or offer tests. You can never know how many backdoors they have implement/left, or if they have actually done anything notable to the source. The cheap usually costs you more in the end, so you should be extra vigilant. With that being said, I would go for one of the well-established names in the community - L2jSunrise and/or L2jEternity, if I were you. They offer cheap and stable builds, as far as I know, with a bunch of custom features, probably most, if not all, of what you've described above. For the features they do not have, you can always pay a reputable developer to write and/or implement the feature to your source, or adapt from a similar one. This way you may pay as much as you would for a ready-made server, but you will establish connections (with programmers and developers) and have access to updates and technical support for several months, at the very least. The last thing I'd like to add is that you CAN, in fact, find good developers here, as long as you opt for a well-trusted and reputable one. You can always ask for opinions in the discord server or here.

Apologies for my ignorance, but I could not quite get what you are looking for, apart from several functionalities, which are present on 99.9% of the servers/cores. Like, could you define what bugless means to you? Also, does the quote below mean that you are NOT providing the source, and instead, the DEV would have to have a "bugless" source that they would then be giving to you? Would you be paying for the source that they would be working on? If not, then it makes little to no sense to me, personally, since such a core/source would probably cost more than what the DEV would be getting for the work they would be doing for you.

L2g is a custom type, similar to how L2d and L2s are. As such, they have their own custom converters. If the converter has never been leaked or isn't open source, nobody can have it, as simple as that. I would suggest you go through the configs and make sure that there is no way to change the default geodata format from L2g to L2j or L2off.

You keep referring to me and you are forcing my hand to respond. You are the one being toxic and trying to blatantly scam people. And the only response you have is - if you are not interested - don't spam, which is the typical response of a low IQ, high self-esteem individual (with nothing to show for it) who thinks everyone is as dumb as they are and would fall for something like this. Fact of the matter is that if you've been doing it for 10 years, you should have obtained a very very good knowledge in programming. And if you had that, it would've been a matter of accepting 2-3 freelance jobs for the random Joe here on the forum, of which there are many, and gathered the needed 200e in a matter of 1-2 weeks. Fact of the matter is that you haven't done so, which begs the question why would you be willing to share the profits of your 10-year-old "child" instead of doing the odd-job for the needed funds if it wasn't a scam? Not to mention that a 10-year-old source is probably full of unpatched holes, since you've obviously spent your time implementing the customs. In fact, I'm even willing to wager 10 euro that you didn't even implemented these yourself. You've most likely took some free-shared pack with a sh1t-load of custom add-ons, such as L2j-Master, and appropriated it by renaming each and every reference to the original developer, so that it looks like yours. This is my last response to your provocations. Have an enjoyful life!

My sense of duty to the community would not let me stay quiet. Instead, I feel obligated to call this for what it seems like - a scam, until proven otherwise.

You have been working on it since 2013 and you are creating an MxC account just now? Newly created account (today), 0 credibility, 0 status, 0 return on investment in the near term, 0 protection for the potential whale. Yet you claim to have EUR 300 of client modding. Even if that was the case, the fact that you've just made your account is SUS AF. It suggests that you are hiding your true identity. In conclusion: You offer nothing, you lose nothing, the entire risk is on the potential investor with nothing to even resell in case of a fraud. Why do you think anybody would agree to support you under these conditions?

Long story: Open this LINK and at the TOP of the page click DISCORD. Join the server, and read through the channels named #download and #subscribers. Short story - there are 2 options: - entirely free version, accessible here: BITBUCKET_DIRECT_LINK - Premium version, for which you pay 1-time fee of EUR 120 (i think), and then a monthly fee (EUR 20, i think?). And if you fail to pay the monthly fee, you would have to pay another EUR 120 to rejoin.

Both errors are indicative of your ant BUILD configuration being messed up. The first one indicates that your ${manifest.libs} variable is either not defined or being resolved properly. The second one indicates that the <javac /> element's bootstrap class path is not properly configured - it should point to the libs folder within the MAIN java folder.

You won't find sources, and even if you do, they come with HWID/IP binding. I'm fairly certain that nobody, even if they do have it and are willing to sell it, would do so with the binding removed/disabled. It would make no sense, since that would allow you to resell at will. In fact, if they did, the price would have to be greater than what you would have to pay the owner of L2jEternity to buy lifetime access to SVN, but with bindings. Regarding the leaked version you mentioned, I've extracted and rebuilt the sources. However, I'm not distributing it.

There are no small fixes on Scripts in particular. I know from experience. What may look to the untrained eye like a small task, could involve rewriting half of the logic of the feature. Been there, done that.

https://l2-scripts.com/index.php?productID=670 Alternatively, I can sell a much better H5 working on new client for less than half that price.

You can get access to the SVN for €180 Euro with the clean H5 and €270 with the Multiprotocol version. I don't know where he sources his information, but it is outdate by no less than 4 years.

If you buy all extensions you get access to the sources (from SVN turned into GitLab repo from this year) + updates (allegedly for life). And all extensions plus the pack itself happen to amount to roughly USD 400.

Sunrise = Budget option in the short term (works on Subscription basis, so it adds up); Eternity = Awesome if you have EUR 400 to spend for access to updates/sources (one-time price); Scripts = They are not actively developing HF5 also too expensive for my taste.

It is a very very basic system, but it would do the trick. The main issue with it is that players would be able to change their titles. This will simply execute the manual Title change and when it is time to broadcast the change, it will set it back to PVP/PK. A better approach would be instead of setting the title like this, you should apply the logic within the CharInfo and UserInfo packets. For example, a simple if statement would do the trick just fine. IF Config.ALLOW_FIGHT_STATS_SYSTEM, _title = "PVP \ PK", else _title = activeChar.getTitle(). But you also need additional checks for when players try to alter/remove their titles. This second check should be done at the RequestChangeTitle packet and it could be as simple as: if (Config.ALLOW_FIGHT_STATS_SYSTEM) { player.sendPacket(ActionFailed) return; }

The fact that you are asking for more directions leads me to believe that you might not be able to do it by yourself, regardless of how many directions you are given. Anyway, here you go: 1. Locate the UserInfo packet in the core of your server. This packet is responsible for what is sent from the server to your active game client/character, or in other words what you see on your character. 2. Locate the CharInfo packet (responsible for what is sent/shown to everybody else) 3. In both packets, locate the "writeS(_title)" or "writeString(_title)" if you are using Mobius 4. These two packet elements send a string of characters to the client. Manipulate them at will.

A hint: look for the title element in CharInfo.java and UserInfo.java.

IntelliJ IDE has native support for Gradle, as far as I'm aware.

By sending the appropriate packet to the client, in your case: /* 0x48 */ MagicSkillUse,

You cannot just push the HTML and hope it works. It might for static htmls, which are htmls that do not have a dynamic part that has to be replaced with something within the core, such as the %menu%. In this particular case, you would have to "create/request" a new instance of the ClassManager and call the proper method of the ClassManager instance to show the available classes. Worst-case scenario, you would have to change the logic in the ClassMaster a bit (build upon the existing logic) to make sure that it could work without a particular NPC (or in other words to work with NpcObjID = null) under certain conditions, such as an additional Config.MY_CUSTOM_CLASS_MASTER_ENABLED (just an example). Here is what it might look like: if (Config.ALLOW_CLASS_MASTERS && Config.MY_CUSTOM_CLASS_MASTER_ENABLED) { // ADD_SOME_ADDITIONAL_CHECKS_FOR_CLASS_CHANGE_ELIGIBILITY_HERE new ClassMaster(_actor.getObjectId(), null).showChatWindow(_actor); }

Take a look at Tooltip.uc

<td align="left/right/center"> </td> Only 1 of the three, not all three...