Vanilla

This is no vanilla error. I'm currently reuploading. In the future I'll provide a webspace from where the version check could be realized. Also there you can download the newest vanilla core. Oh and yes, download is in the second post of this thread as usual. Reup is coming soon since multiupload got some problems it seems. New download link: [Hidden Content]

I've deleted some unnecessary variables etc... But it's nothing big. I don't expect 4 inventories to work 100% but it's a problem every gamefile has. I can't fix these bugs unless I have 4 inventory pages in my client too (and I don't have that).

2.4.1 is out! I've edited the changelog a bit to fit with the new changes.

Sorry, I've made a typo. I meant that there will be no 2.4.2! If there are problems with 2.4.1, I'm just gonna make some hotfixes. But I'll not release a 2.4.2. Next version is 2.5. The update checking would be just a simple quest. The only thing made in the core would be a quest function to print out the current version - I'd made some clarity with this and additionally you're free to choose wheter you want to use the quest or not.. It's just a quest that's going to connect to a webspace, looking up for the newest version and comparing it with the current. If there's a new version and you've got IMPLEMENTOR-rank, then you're receving a message in the chat. It also won't check every login. It'll just check every new day when you log in. Also how about fixing a strange bug? If you're gonna make a new gm, why not be able to give him the rights without reloading the complete gmlist and just do it ingame? I'm currently thinking about something like the /op-Command minecraft uses. But! This command will only be able to be used by Implementor! And you'll have to specify the rank you want to give. As I told you. There're some problems with open source and no, they can't be fixed easily.

Sorry, I almost forgot to mention the changes made to the mounts. It'd of course work now since there's no upper limit anymore (therefore your mounts should work now as intended). I'm kinda thinking about the open source stuff. Not quite sure. Plenty points against it showed up that's why I'm still thinking about it. Planned for 2.5: Extracting more tables to text-files. This means that I'm trying to make things like the exp table outside of the game. It'd read a text file line by line and therefore set the maximum level and the exp needed. This could also work for horses (which would allow you to make more different horse skins). Also I'm trying to make it possible to let you include libraries from a special directory which will be the first step to a plugin system. Also quest functions could be enhanced by this mechanic - reading text files line by line and therefore allowing you to add more quest functions - which you can provide in your libraries. So 2.5 will be a big patch. That's the reason why there will be no 2.4.2, if there are problems I'm gonna update the current 2.4.1 download link with a hotfixed version. Also: What do you think about giving you the possibility to install a quest that checks your vanilla version every new day and notices you when there's a new version?

Changelog got edited! Mainly bug fixing and tuning, but this time there are also new CONFIG-options! ### Changelog vanilla revision 54250 ### Also known as version 2.4.1 * stands for changes + stands for additional content or features - stands for removed things -> general <- - Version_check will (when enabled) now check the client version when trying to log in instead of only when the player enters the game. It'll prevent people from selecting a character if a version mismatch is detected. * GCC update to 4.9.1 * Dbcache now compiled with -Ofast * Added some new compiler optimizations for the gamefile * Removed gdb support to lower the file size and allow linker optimizations + Linker optimization! LTO and gold are nor active * Rebuild the libraries with the new gcc and -Ofast * Encryption update to make it faster and easier to update! (algorithm change shouldn't require a huge dif by now) * Bypassed the tics_did_not_update-crash so the server will still continue running. Though I highly recommend to fix the errors on your server instead of relying to keep up with that! * Lowered down the default "exp needed" value for higher levels than the exp-table has. Now it shouldn't bug anymore with binaries that don't handle higher values of experience needed * Fixed some bugs with CONFIG options and cleaned up a bit * Raised limit of maximum exp needed to unsigned long long int -> CONFIG options <- + EXP_NEED_THRESHOLD: unsigned long long int Allows you to set the exp needed if your level is higher than the maximum level of the exp table + SKILL_MASTER_UPGRADE: int Sets the minimum level when your skill can jump to master. If it's set to 1 for example, then it'd happen that your skill jumps to m1 at any level. + SKILL_FORCE_MASTER: 1/0 Lets you define if your skill will definitely raise to m1 if it hits the minimum level for jumping. So if you're enabling this, then your skill will definitely (unless you set SKILL_MASTER_UPGRADE) raise to m1 when hitting 17. Expect download link within 24 hours. Older changelog updated to fit with the new changes.

empire_chat is marked broken right now. I reimplemented the global chat. Code's gotten a bit messy that's why two options were leading to the same thing: empire_chat and global_chat. But none of them actually made a change. However, in 2.4.1 empire_chat is removed and global_chat will work. New thing in 2.4.1: gcc now updated to 4.9.1 Also I've changed the compiler optimisations. Now everything except for the gamecore itself is compiled with the -Ofast flag. Additionally I've enabled gold to feature linker optimizations in combination with lto! however the game got some new flags. It's now building with -O2 and a few options from -O3 to keep the new performance gains without breaking the gamefile. Both tested and marked stable with the new changes. I'll make some further testing regarding to the changes I made and if everything's working now and then I'm ready for the release build. There's something more! Normally using lto and g together (g is for debugging) may cause some trouble. So that's why I currently deactivated it seeing a huge decrease in filesize! It's now shrinking down to 17mb (unstripped of course so you won't have to worry about editing the gamefile). I'm currently testing a bit. Maybe it'll hit in 2.4.1 too and it may be a huge step.

He already installed mysql55. You're missing the standard metin2 libraries. You can just download them from anywhere (I'm looking them up for you right now), there're offered many times. Any "pseudo-64-bit-libraries" will do, so just download a lib package you'd need to run any other gamefile.

10.0 is also stable. And I find it to be better. I kinda like the change from gcc to clang and I for myself use 10.0. But it's a personal thing. I don't think there's a clear "this is better than that"...

Currently updating the software on my building environment. GCC will also now be updated in a part of this process. If the libraries are updated, you may update them too (I'll of course upload the libs within the packaged). Furter information is coming regarding to this. Oh, and there are a bit more consequences. Vanilla just got a level up if you can call it like this. It's now bigger, approx. 50mb. This is caused by new optimization flags that're now pending test (Oh and don't think the bigger the file is the faster it is -> that's not true! The bigger file size is caused by new optimization flags that're now optimizing the code, making it bigger but faster. For example loops are getting unrolled so they'll be executed faster. The standard gamefile didn't use these compiler flags. They're big like this because they used a very old gcc version, that has nothing to do with an optimized code). In this version I'll also recompile the database. Maybe it'll get some love in this version too! At this point I also want to thank you for your contribution all the time. Appreciating my work is one of the best ways to show me how much you value this project and I wouldn't work on it right now if you wouldn't support the project that much. I want to thank you for that! (I'm not gonna copy pasta Pewdiepie to give you a brofist, but still you'd know that I'm really happy to have people like you supporting me! You'll get a wink instead!)

Of course, If you'd change it from XTEA to DES, then you're completely right. But XTEA is a modified TEA-Algorithm. That's the reason why it'd possibly be able to realize it. I told before, I'm not that sure about it, and it may be. But that's no guarantee that it actually does behave like this. But in fact, the XTEA encryption did have some influence since changing the algorithm would lead into not being able to connect to the server anymore. So it may be that xtea is still encrypting packets, but of course it's not everything done to the packets. I don't know how the new binary and gamefile works on this, but I know that every other binary/game-combination didn't work when I changed the algorithm in only one part and I was granted with invalid packet headers. I'm gonna try to create new txt-files to make more adaptions. Maybe it'll be that in 2.4.1 the MAX_LEVEL option will be thrown away and instead it'll read out a exp-table you simply install with creating the file exp_table.txt in your locale/localename-directory. The gamefile will read the file line by line and when there's a valid exp-value, the max-level will be increased by 1. Additionally I'm planning on letting you enhance the configuration more with creating such files. For example I'd think of making a way of letting you create a txt-file to specify some maps where people are not allowed to teleport (with marriage ring, warpscroll or group teleport for example). But let's hear your thoughts about it! At least: I realized what's the problem with raising the maximum inventory. It'd need more than just making a option. The equipment starts from MAX_INVENTORY+1 and if I set it to 180, like it's in the source, then the equipment would start at 181. But! The client will still behave like the equipment would start at 91, that's why it won't display the equipment correctly. Though the file where the max-inventory size is specified (and the other sizes too) does not include the config-file it's more complicated to edit the level afterwards. Additionally it's specified as an enum that's making it even more hard to get a rework. So it'll ake some time to merge the two gamecores (4_inventory_pages and 2_inventory_pages) into one.

I can. But currently it'd make no sense because I already installed a mysql implementation (to use queries directly from the core). And such a function would be easily realized in lua using this mysql-function. It won't have any sense to make it directly into the core, also not everyone would use it. Additionally I'm going to make some further changes regarding to encryptions. I've noticed that already a DES and a GOST-implementation is currently in the game source. I'll maybe be able to activate them and use them. But this will require some binary changes because the binary would need to handle the other algorithms too. Also the mismatch (client uses xtea, server uses tea) could've lead into some packet errors. Maybe the different way of encrypting/decrypting could possibly make some wrong en-/decryptions which could lead into packet errors. Now both are using xtea, that'd make client and game fully compatible (tested and works). Also the encryption should be now faster and more secure (xtea fixes some security issues discovered in tea)

He only wants to know where he can edit the exp table. You can simply open it with IDA and search for the exp table. Just go into ida-view and search for "exp_table_common". There you go!

Happy news to you! Vanilla 2.4.1 now uses a better implementation of XTEA to encrypt it's packets. Don't worry! Your client will thank you! The client already uses XTEA to encrypt the packets. So it'll be fully compatible with your binaries. But if you plan to change the algorithm, you'll notice that it's now by far easier to change it in the game then before! Because now it uses the same structure than in the client. Additionally I took some time and fixed a minor bug. In the game, there's a new size for the exp so it can go higher than approx. 2,100,000,000,000. But the client still uses the lower value. When you hit the maximum of the exp-table there'll be a new value that'll determine the new exp needed for further leveling. This exp was higher than the maximum in the binary. That caused some problems for some users. Now I tuned it down to the 2.1 mentioned before. Additionally there'll be a CONFIG option to tune it by yourselves. This will make sure there's compatibility with every normal binary but still makes you able to access all the cool features of vanilla 8)

Sorry, was a little unsure about where to post it since I'm still asking and trying to get other's thoughts about this topic. That's why I wasn't sure about it. Thanks for the move ^^

Hello dear dev's, I'm currently working on a bigger project (a server to be exact, but I won't mention it) and there I'm planning on reworking the way armor and magic resistance works. For this I've taken inspiration from a game you may know (LoL). I saw metin2 lacks a few balance issues: At first this is how armor/mres works in Metin2: Whenever you receive damage, your armor (or mres) will act like a shield. Nothing more. It'll prevent a fixed amount of damage. So you're receiving 100 raw damage, have the same level (and no buffs etc.) and got 50 armor, then you'll just receive 50 damage. If you have 20 armor, you'll receive 80 damage. This may sound easy and it is easy to calculate with. BUT! There's a huge problem with it. Let's look for example the way critical strikes work. Critical strikes double the raw damage. So what does this lead to? Normally a critical strike would double the output of the damage, so let's say we've got the same example as above with our 20 armor, but now the strike deals critical damage. In normal cases, you'd receive 160 damage (80*2). But the way critical strikes work is different in metin2 as I mentioned above. First the damage will be doubled: 100*2=200. Then the 20 armor will come in effect: 200-20=180. So we've got 20 more damage, the same value as your armor. This is the reason why the damage of critical strikes DOES indeed ignore the target's armor and it'll look like even if the victim builds up armor, he won't have a chance to actually defend against the critical strike damage. Next problem: Burst damage will easily counter armor. Completely. And effectively. So let's say you're using a magic skill which deals 4000 damage. Now that you know that it's always reducing for a flat amount, you'll get the point now. Let's say you have 200 mres (not in reality, but let's assume). So you'll just have 4000-200=3800. Was the magic resistance really that effective? Now let's say we build up everything we can toward magic resistance. In the current game it's really hard to get high values. I don't know the actual maximum but you won't even come nearly to 1000 magic resistance - taken that you're completely conentrating on magic restistance to defend against those bad burst mages. What effect will that have? 4000-1000=3000. Yeah. Totally worth it. That leads (in my opinion) to only one conclusion: Armor/Mres is totally broken in this game. And it isn't really fun to build magic resistance. That's why warriors can't tank, even if they really want to. Tanks are non-existent against burst characters, especially mages. And even building armor won't help you against boss fights where some bosses can easily knock you down even if you're damn tanky. While low values will help you get huge damage reduction against enemies who also don't have that high attack damage. So the current system allows you to easily take down low values of damage, but makes it nearly impossible to really defend against high damage values. How could we fix this? We'd easily recalculate how armor/mres works. As I mentioned before I took my inspiration to this topic not only from seeing the broken mechanic but also from seeing mechanics that actually work. In my case: LoL. There they use a new formular: 100 / (100 + armor) = damage factor So that'd mean that armor won't take a flat amount of your damage. Instead, it'd create a factor that will actually scale with the damage you receive. So you won't be able to tank lower, but consistent damage that easy as it was before, but you will be able to take down bigger amounts of damage when building up more armor. And! It'll also reduce the critical damage! Still don't believe me? Let's take the example from before! We said we'd have 100 raw damage incoming. And let's say we got 20 armor. Normally, you'd receive 50 damage in that case. But our new formular allows us the following: 100/120 = 0.833 => Our new damage factor. Now let's apply this to our raw damage: 100 * 0.833 = 83.33 => 83 will be the new damage we receive. And now to our bursty example to show how the new magic resistance actually would work. We receive 4000 incoming damage. And we have 200 mres. 100/300 = 1/3 4000 * 1/3 = 1333,33 => 1333 would be the new damage. Well, such a drastic change would need to actually change how easily it is right now to get armor/mres. Because we saw in the example that only 20 armor would reduce incoming damage down to 83.33%. So we can't let characters start with huge armor values. Let alone a shield that gives you 253 armor... If we'd rebalance the values, we'd enhance the fun for everyone and could make it possible to be a real tank. Why did I make this topic right now? Just to hear your thoughts about it! What do you think about such a drastic change? Would you like? Would you acutally try it? Or do you have other formulars you'd present that'd actually fit in more to the higher values metin2 uses? (side note: I've also rebalanced penetration to actually penetrate a % of the armor/mres and not providing a % chance to penetrate the whole armor/mres).

it's not that you get more damage from letting the enemy building up defense. It's just that your base damage gets doubled. That's all. The defenses of the enemy doesn't get doubled and that's why critical strikes seem to be stronger because they double the raw damage, not the calculated. It's not a bug, I think it's intended. Chaning it would possibly change the balance (if there is any) in the game. The whole thing about defense is getting weird because it only reduces the raw damage by a flat amount - your defense. To create a better balancing you'd have to recalculate how armor works. Same goes with magic resistance which is currently more than useless. But I've now added a penetration effect. When you hit someone and it's penetrating, then a effect packet will be sent to the client (it's up to you if your client is able to interpret it or not). SE_PENETRATE is the penetration flag.

Good idea, I'm gonna take a look. I don't think they'd do damage right now. I've now cleaned up old posts and remade the first two posts. They'd now be easier to read and understand. Especially for beginners I've written a short introduction what vanilla core exactly is and pointed out where to find the download link

I know they hate reading it. But not reading it leads to the same issues over and over. Like the lib problem^^ I promise you the install instructions aren't big ._. Oh, and brace yourselves for the upcoming 2.4.1 because I'm currently working on an implementation to set the inventory limit by CONFIG-option. At first this will lead to let users without 4 inventory pages have the same bugs than with 4 inventory pages. But now that I'm getting the same errors (because I don't use 4 inventory pages, that's why debugging that was hard for me) I can fix these bugs and make a clean implementation of this new system.

I acknowledge this bug and will do further testing. Sadly I cannot answer to every post made here. It's just impossible especially when you have probelms and post them without any further information. With posts like "I get connection refused" I can't do much. It's most likely that the db-cache or your mysql refuses the connections. But this is not a vanilla-problem so it shouldn't be mentioned here. That's why I'm not answering to it normally. Please refrain from posting non-vanilla-related stuff here, it's just confusing and people will think that this core is damn bugged and not stable at all. Please also read the install instructions, I didn't put them for fun in there ^^ I'm currently migrating every change to the first post and just link changelogs to the changelog-Post I've made. This will enhance new people to actually see what they get and advanced people to see how much got changed and how big the progress of the core is.

Edited changelog! See page 45 for a full list of the current changes cooking. This is just a list what got changed on the changelog! -> General <- * Fixed a bug where killing could trigger a quest twice * standard "mall url" is now a link to this topic! + Now allows the use of a new quest trigger! It's called execute! (You can disable it though) You can now send /execute "questname" to trigger the execute-event. In quests you can just use when execute begin to handle the triggers! -> CONFIG options <- * Fixed the CONFIG-options for max attack speed and movement + EMOTION_WITHOUT_MASK: 1/0 Default is 0. Lets you define if you won't need a mask to use emotions. + EMOTION_SAME_GENDER: 1/0 Default is 0. Lets you define if people will be able to use emotions on the same gender. Notice: This'd possibly look awkward because the animations doesn't match + CHECK_SPEEDHACK_ENABLE: 1/0 Default is 1. Lets you define if you want to use the speedhack/synchack check. Warning! Make sure you only use this for debugging purpose! You can fine-tune the variables for the speedhack in your CONFIG, so this should normally not be touched! + QUEST_TRIGGER_ENABLE: 1/0 Default is 1. Lets you define if you want to use the new execute-trigger. vanilla 2.4.1

As I mentioned earlier the changelog is only tentative to an upcoming version. 2.4.1 isn't released yet. It's still in progress, so the changelog will most likely be edited later. It's a time frame for you to make last suggestions for this version or disagree with some changes.

Read the install instructions. You also need to install the new libs.

### Changelog vanilla revision 54250 ### Also known as version 2.4.1 * stands for changes + stands for additional content or features - stands for removed things -> General <- + Version_check will (when enabled) now check the client version when trying to log in instead of only when the player enters the game. It'll prevent people from selecting a character if a version mismatch is detected. * Some minor bugfixes * Fixed a bug where killing could trigger a quest twice * standard "mall url" is now a link to this topic! + Now allows the use of a new quest trigger! It's called execute! (You can disable it though) You can now send /execute "questname" to trigger the execute-event. In quests you can just use when execute begin to handle the triggers! * GCC update to 4.9.1 * Dbcache now compiled with -Ofast * Added some new compiler optimizations for the gamefile * Removed gdb support to lower the file size and allow linker optimizations + Linker optimization! LTO and gold are nor active * Rebuild the libraries with the new gcc and -Ofast * Encryption update to make it faster and easier to update! (algorithm change shouldn't require a huge dif by now) * Bypassed the tics_did_not_update-crash so the server will still continue running. Though I highly recommend to fix the errors on your server instead of relying to keep up with that! * Lowered down the default "exp needed" value for higher levels than the exp-table has. Now it shouldn't bug anymore with binaries that don't handle higher values of experience needed * Fixed some bugs with CONFIG options and cleaned up a bit * Raised limit of maximum exp needed to unsigned long long int -> CONFIG options <- * changed empire_chat to global_chat * global_chat will now make a proper response when activated - EMPIRE_CHAT (it was accidently included but it had no purpose!) + BUGFIX_SURA_MANASHIELD: 1/0 Default is disabled. Fixes the sura manashield so it'll now scale with the proper value instead of always removing a third of the damage. Warning! When activating, you'd nerf the skill! Otherwise people with over 100 iq could prevent every incoming damage and even heal themselves or cause crashes! + VERSIONCHECK_KICK_DELAY: int Default is 10. Sets the time until the player is kicked when a version mismatch is occured. Takes only effect if the versioncheck is enabled. * Fixed the CONFIG-options for max attack speed and movement + EMOTION_WITHOUT_MASK: 1/0 Default is 0. Lets you define if you won't need a mask to use emotions. + EMOTION_SAME_GENDER: 1/0 Default is 0. Lets you define if people will be able to use emotions on the same gender. Notice: This'd possibly look awkward because the animations doesn't match + CHECK_SPEEDHACK_ENABLE: 1/0 Default is 1. Lets you define if you want to use the speedhack/synchack check. Warning! Make sure you only use this for debugging purpose! You can fine-tune the variables for the speedhack in your CONFIG, so this should normally not be touched! + QUEST_TRIGGER_ENABLE: 1/0 Default is 1. Lets you define if you want to use the new execute-trigger. + EXP_NEED_THRESHOLD: unsigned long long int Allows you to set the exp needed if your level is higher than the maximum level of the exp table + SKILL_MASTER_UPGRADE: int Sets the minimum level when your skill can jump to master. If it's set to 1 for example, then it'd happen that your skill jumps to m1 at any level. + SKILL_FORCE_MASTER: 1/0 Lets you define if your skill will definitely raise to m1 if it hits the minimum level for jumping. So if you're enabling this, then your skill will definitely (unless you set SKILL_MASTER_UPGRADE) raise to m1 when hitting 17. -> gameplay improvements <- * Poison damage will no longer draw monsters aggressive * All new mounts can deal damage. there's no upper limit anymore! Note that this changelog is tentative and there'd be changes anywhere at any time. This changelog will be edited. Feel free to post your thoughts as this is only an example how 2.4.1 could look like.

How about a new gameplay fix for 2.5? It's regarding to the manashield skill black mage suras got. Currently the manashield works like this: Every incoming damage will be reduced by a third. This reduced amount will be used as mana cost for the skill. When you rank up the skill or raise your iq, there'll be a %-value written on the skill. This percent-value does not affect the reduced damage (it will always reduce the third mentioned above). But this value will reduce the mana costs. So the third will be reduced by the percent value and then used as mana cost. Now what I planned to fix and rebalance this skill: The percent value will be used to reduce the incoming damage. So there won't be a "third"-rule anymore - what you see is what you get. So if you're seeing 30%, you'll remove 30% of the incoming damage But, to fix the mana cost: 20% of the reduced damage will be used for the new mana cost. If you don't have enough mana, the rest of your mana will be used and computed. This means that the rest of your mana will be the 20% of the damage you'll prevent. Now, that'd of course require to rebalance the skill value. Because if you're getting ~100 iq and your skill on P, you'd reduce over 100% and that's just impossible and would enhance the damage at last. So you guys would need to set new values for the skill. That's why I'm asking you: Do you want this in 2.5? If not, then I'll just throw this change away and not commit it. Tell me your thoughts.