Salty Mike

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.

If you want to learn how to edit the Interlude client by yourself, I suggest you start searching and reading ancient posts since the client is ancient itself and the topic is multi-faceted, but has been raised numerous times over the years. Mobius already comes with some basic fake players engine, which can be built upon. As far as I'm aware it was a client contribution the development of which has been discontinued, but I could be wrong. In any case, it is more of a proof of concept than anything. Regardless, if you insist on the L2JRoboto, you should be aware that the project has been discontinued and has been replaced by the "Autobots", written by the same person, which are more complex and not written in java. As such, judging by the abstraction of your questions, your best course of action would be to pay someone to do it for you. There's no shortcut! It was written for a different platform/development/build/pack. As such, it is not compatible with Mobius builds "out of the box". Also, adaptations of complex features like that require many portions of the code to be reconstructed, or completely rewritten based on logic, which takes time and several iterations until you get it JUST RIGHT.

The PayPal Buyer Protection has an expiration time of 180 days after transaction completion. On top of that, intangible goods (such as digital goods) are now also covered by the Buyer Protection, as evident HERE.

You don't downgrade, you upgrade HF to Assassin. Anything different than that is not HF any more - they call it Classic HF, HF Improved and what not. It is not HF any more, because, at the very least, the damage calculation formulas are different, and a whole bunch of other stuff. Overall, upgrading HF to the newest chronicles would take no more than 2 months, at least for a team of 2 well-versed devs - 1 for the server and 1 for the client.

If memory serves me correctly, it had something to do with the compression that you choose/use - DXT1 and DXT3.

It is just semantics. Doesn't matter if you haven't developed it on your own. Fact of the matter is that you are introducing a modification of the original game, hence the term `mod`.

I will allow myself to make the assumption that you are versed in JAVA. As such, I'll give you the following reference in hope that you understand it better. XSD to an XML file is like an INTERFACE to a JAVA CLASS. It lists all of the required elements/methods that the XML which implements the XSD must have. However, unlike INTERFACE, XSD has a way to label certain elements/attributes as optional. With that out of the way, you should've already concluded that they are not related to the CLIENT in any way, but are rather used in tandem with the XMLs in your server's DATAPACK, and by extension, are used by your server's XML parsers.

The solution is what the guy before me said. You need to either place the higher value before the smaller value or limit the range. Ex. 1: if (item.getEnchantLevel() >= 12) { // do whatever } else if (item.getEnchantLevel() >= 8) { // do whatever } else if (item.getEnchantLevel() >= 4) { // do whatever } Ex. 2: if (item.getEnchantLevel() >= 4 && item.getEnchantLevel() <= 7) { // do whatever } else if (item.getEnchantLevel() >= 8 && item.getEnchantLevel() <= 11) { // do whatever } else if (item.getEnchantLevel() >= 12) { // do whatever }

Sublime Text + UnrealScriptIDE plugin is much better. You can follow declarations/definitions, search in all UC files in folder, etc. https://packagecontrol.io/packages/UnrealScriptIDE

The H5 client does not support multiple servitors. As such, you would have to pay to someone to make the client support multiple servitors, and then write the java code to make them a reality.

Just do it the old-fashioned way.

While not particularly active over the years, I've been around for as long as I could remember, so here are my 2 cents too. On top of what has already been said, I'd like to touch on a few thing that might be improved upon. While it is easy to notice and say "there's lack of engagement" or "community has outgrown the ganre", I've seen numerous forums get forgotten and die while others continue to thrive to this day. The main issue, in my humble opinion, is that the sector has been commercialised to an unsustainable extent. When nobody is willing to share anything, even if it is just a rework of an open-sourced or already-shared resource, the sense of "community" gets deminished. Now back on the pressing matter. From what I've seen, the lack of engagement could be circumvented with a redesign and functionality expansion that would/could/should include: - a built-in chat functionality. - incentives for engagement/interaction, ideas of which I'll list as separate pointers, as not to limit your creativity. But just as an example, from a more user/human perspective, having an easily identifiable way to get into "the club of the cool kids on the block", figuratively speaking, is an incentive on its own. - separation of the reputation into reactions and reputation. One to be used to posts, such as up-vote and what not, while the other to be awarded as means of appreciation. - automated ranks with actual benefits/perks, not like the current ones providing nothing. - the ability to hide text for user/group of users, not just premium/no premium. - increased visibility of the HOT topics and the RECENTLY ACTIVE threads/posts. Can be also expanded to most liked posts, etc. ps.: I'll update my post when I have some free time on my hands.

I've heard it was a feature of Active Anti-Cheat. I could be wrong. It might be a custom interface feature.

I wonder, is security under consideration, at all? At the very least, they would need to have the SQL table structure of your already-implemented system or some other table and write access to it, which leaves you exposed to exploits and foul play. Just for context, you don't need the source to make core corrections, if we are talking about java-based projects.

But does it need client modding, really? I have 0 skill on editing the client. As such, I haven't touched it, but I still see the shots and they change depending on weapon grades too. Main - https://imgur.com/NaFlOeK Classic - https://imgur.com/oi9REuD

I'm making an educated guess here, but I'd say it won't without client modding.

To cut a long story short - yes, it is very much possible to do whatever you like, as long as you know what you are doing or at the very least know how to code. This guide is more of a general one on how to use what is already there, at that particular point in time, 9 YEARS AGO, and on a non-specified build on the Acis platform. It does not delve into the inner workings of the server core, kernel, or however else you wanna call it. It does not list what the available zone types are nor how the different zone types are handled in the core. These could differ not only from project to project and developer to developer, but also from the version to version by the same developer/project. As such, the guide won't be much of a help for your particular case, unless your source supports the features you are asking for. To this end, you should search for explanations on how each zone type is handled, or even better - look for yourself. 1. Download and open the source, preferably with IntelliJ due to its user-friendliness. 2. Locate the Zone and ZoneType classes. 3. Look where and how they are used until you find the "PARSER", which takes the info from the XML and stores it on the running server. 4. Follow the crumbs trail from there until you discover the file(s) handling each individual zone type or the info of all of their available options, also known as "HOLDER". 5. Once there, you would have to create and implement the new option(s) for your particular use-case. 6. From there, you have to back-track your steps all the way back to the PARSER class and add the new options there too. 7. Then you would have to check if the XML file in your datapack is linked to an XSD file, and you would want to add the new option(s) within the XSD too, branding them as OPTIONAL so that they are not considered mandatory in all entries. Although the list might look lengthy, and scarry, at first, it is actually an extremely easy thing to do. Regarding point №5, namely creation and implementation, you either know how to do it by yourself or you dont. If you cannot do it and you are not willing to learn java/coding/programming, pay someone to do it for you, but be EXTREMELY vigilant and adamant about NEVER paying up-front, especially in full! Have a nice one, and most importantly, enjoy the process!

You are contradicting yourself! In your first message you clearly state "I want to create a GF server on the latest client". What this means is you want a GF server that is working/running on the latest client. You didn't say "not exactly like GF". You explicitly stated that the server would be GF and the client will be whichever new client you could find. You never asked for servers either, as evident from the following excerpt: "to link Gracia Final Pack to that client". You asked how to do it, and more specifically: "Do I just get a clean install and edit ini in the client", which brought me to the conclusion that you were completely oblivious and/or delusional, hense my EXTENSIVE and ON-POINT response, if I say so myself.

Thanks! I'll take a second look and let you know if my implementation of the clearCircle() helps with the stuttering once I find time for some extensive testing.

UPDATE 1: My bad! I didn't notice that this is published in the L2OFF section. The statement below is only relevant for L2J. (Yes, there is another, very simple, efficient, and quite elegant, way to do this. What you need is: - create one Config of type Boolean, lets call it MOB_DROP_ONLY_ADENA, which will act as the trigger point for this feature. - locate the method which is responsible for parsing the drops of the monsters from XML. - in this method, there should be a loop for each of the parsed items and there we add a simple check: if (Config.MOB_DROP_ONLY_ADENA && item.getItemId() != 57) { continue; } And we are done. Now, every time the server tries to parse a drop item, it will check if the ID of the item is 57 (adena) and skip it if it isnt. You should add a further check to make sure that the NPC you are parsing the drop for is of type Monster and not of type RaidBoss or GrandBoss (or any other custom type you might have). The easiest way is with with a lookup into the NPC/Monster Template, if there is one on your assembly of choice. What these templates do, usually, is to provide some lookup options for certain features of theirs, such as level, type, etc.)

The heavy lifting is done in the client, because while you can get away with small imperfections in the java, everything in the client must be impecable. So, if you haven't touched the client, I'd say pick the newest protocol version you can find the client editing tools and Interface.u (mandatory) / NWindow.dll (better to have it) / Engine.dll (optional) sources for. At the very least, you need the Interface.u to fix the Clan Window and enable skill enchanting on Classic/Essence versions, if you decide to use one of them instead of MAIN/LIVE.

Upgrading to Salvation is exactly the same as upgrading to the newest client with the only difference being access to free-shared client editing tools and resources. I am speaking from experience. I have upgraded my HF source to one of the newest clients by myself (in terms of server side. got help with the client) and hit every single wall there was in the process. Now, I already have several multi-protocool server cores so I can easily compare different approaches to tackling the same issue, which also helped the learning process. Best way to learn would be to use this one (link below) to snoop around and figure out what has been changed in the server side (the packet structure will be different, for sure, but works for understanding/figuring the process out in general terms). https://github.com/iBezneR/L2J_SunriseProject_Purity The client side will always be the same, always the same files, only the DAT structure will be different. I personally wrote myself some parsers for the data of the DAT files from OLD -> NEW client.

Guys, if you'd let me be the bearer of bad news, No amount of "break from server development" can justify your complete lack of idea how things work. If it was this easy, you should've been seeing 90% of the servers of the popular old versions, such as IL and HF, running on the newest client. For this task, you would need a lot of time - think at least 2 months, if you can code, have access to all the necessary tools for client development, and you have a relatively good idea of how server<->client communication works. f you don't, then you either find yourself a well-paying job and find someone who would do it for you or you put the idea aside (for no less than 1-2 years) and start reading and learning asap. Let me give you a little preview/breakdown of what some of the work includes. The work can be split into two parts - SERVER side and CLIENT side. The server and the client communicate through packets. Each of these packets has a defined structure. Both, the server and the client MUST know this structure and MUST use the same structure, otherwise they won't be able to "understand" each other. - The server side predominantly includes the alteration of existing packet structure and the creation (from zero) of missing packets that the client requires. Then you also have to take these changes into account and alter the existing features of your server to match the changes. A good example for this is SKILL ENCHANTING. On older chronicles, the enchant level is determined by the LEVEL value of the skill and on the new clients, it has been taken out into a separate value. What this means is that you would have to figure out a way to adapt the old system to the new requirements. - Now that we mentioned the client, you would also need to edit a bunch of files, such as Interface, UTX, UNR, as well as DAT files, including those related to ITEMS, SKILLS, QUESTS, NPCS, and AUGMENTATION STATS and DESCRIPTIONS, etc. For some of those, you would also have to figure out how to check for missing entries and how to parse data from the older client to the new. The best example, again, would be the SKILLS. On the latest clients, the skill enchanting was limited to only +20. As such, even if there were some matching skills between the two different client versions, you would still need to add the missing 10 levels to +30. And once you complete all of that, you start testing and fixing bugs and sh1t. And once you have fixed all of that, you can start adding new features from the new client, because otherwise it would be one big mess and a waste of time and/or money.

As far as I know, these are not linked to the server. What I mean by this is - there is no server <-> client communication for these two features. If that is indeed the case, you would need the Interface sources in order to create a custom function which you can trigger with a SERVER_TO_CLIENT packet.

Open github. Find sdark94 account. Enter sdark94/trinity repository. Search for the DB backup. It is still there. I would've posted it here, if there was a HIDE_FOR_USER(S) feature, but there isn't one. You can DM me on Discord and I'll slip you a STRUCTURE-only DB export. Yall lazy to even search the web bro. See the old videos from 3 years ago -> YOUTUBE Regarding java version, it is also visible in the source: