Vanilla

You need to edit the binary for seeing more than 2kkk. It's not only the game, but also the client binary. In this case the game can handle over 2kkk so you'll be able to store such high values. But the client can only use up to 2kkk.

Expect some bug fixes in 2.4 I'll add some changes like fixing the StunBug, but first I'll have to take care that everything works with these changes.

Look at your CONFIG: YANG_MAX: 5.000.000.000 That's not a valid number. You shouldn't seperate them with . Change it to: YANG_MAX: 5000000000 That'll do. Otherwise your gold limit will be 5. And that's why the command doesn't work.

There's no need for item2. There are already plenty of those functions implemented. item.get_attr_value(index) item.get_attr_type(index) item.set_attr(type, value[, index]) index is the position you want to address. 0 would be the first bonus, while 1 = second, and so on... In the last function you can see that index is in []. This means that you're allowed to not provide an index. If you do so, it'll automatically use the index 0 (means: first bonus).

Since someone started to "share" this game in an inappropiate way I want to clarify that I'm not supporting this! If there's a board clearly stating that a release is not allowed then please don't do it! Another critical point is that people could also modify the gamefile. Please download vanilla only from valid sources! And there's no other valid source than from myself! Everything you do with the core will also fall back to me and if you're still into making trouble with it then I'll just stop making further versions.

~~~Vanilla v2.3 rev52410 CHANGELOG~~~ * Guild war with negative type will no longer crash the server * You can not bypass the level and yang limit when creating a guild anymore * Invisibility bug fixed * empire exploit fixed (empires > 3 will always be handled as the third empire) * fixed yang-limit CONFIG option * fixed level-limit CONFIG option * rebuilt the complete source with edited tables so it won't cause bugs anymore * Fixed hp overflow: Now it's new size is long int which won't cause any overflow bugs anymore * Fixed yang overflow: Now yang won't overflow anymore. If you hit the limit your gold will automatically set down to the limit so it can't bug or go into negative values * Fixed SKILLBOOK_STEP_LEVELING. It'll now work as intended * Fixed level size to long so it may go higher than 255 * Fixed ITEM_DROP_TIME. It'll now work as intended. * Fixed belt_allow_all_items: It'll now work as intended. + Added version info on startup + Added new CONFIG options: - removed pet.is_mine() function since it destroyed the pet system. This should let the pet system work again. * Rolled back pet-system so it'd work again. pet.is_mine()-function stayed in this version cause it's not toxic to the pet system and should work. This post will be merged to the changelog-post to let it match with the new version. €: Download is here! [Hidden Content] Password: vanilla Pet system and options tested, they'd all work now. If there are any flaws or bugs, just feel free to post them here as always. I may not fix every bug within one patch - sometimes some bugs may be overlooked if they're minor. Just post them again if they're still existent in the new version. There's also a new dbcache. vanilla v3 requires the new dbcache which is in the download package! Older dbcaches do NOT work! Don't try it! Same goes with the dbcache, it'll only work on vanilla core! Best Regards, Vanilla

First, I'm thinking about making standard serverfiles running with vanilla. But that's only things for the future, now I've too much work to do on the gamecore itself. You can use any database beginning from the 2011 versions. The more recent the better. You can use every 40k client for this core. It's compatible with them. "no-txt-db"-lib isn't needed. TXT-Startup is handled by the dbcache and in vanilla it's disabled by default. So you won't need txt-files anymore. If you still wish to use them, then add "TXT_STARTUP: 1" to your conf.txt so it'll read and use the txt-files. €: I've fixed some more bugs. Finally some annoying things won't happen anymore. And yang_max should work now, still testing it.

V2.3 is coming soon. I've removed the pet.is_mine()-function that caused trouble with your pet systems. There'd be more config options now, this version is mainly a bugfix-version so vanilla will become more stable without problems. Oh and I'm going to rewrite the yanglimit-procedure so it won't bug anymore. Now I've got enough time to continue my work.

Wait, didn't I edit my post and apologize for my mistake? Hm, obviously I should've been a dick instead of clarifying that it's my fault. And if I don't respond, then it's clearly a fact that I don't really have much time to reply to everyone. If you want to play the defiant one, please go ahead and stop using vanilla core. I'm not into "everyone needs to use my work", it's a thing FOR EVERYONE. If it's good, feel free to use it, if it's not good, then just don't use it but don't think you'd provoke me by not doing so.

Please, stop posting questions regarding to your own gamecores in this thread. It's for vanilla core and not your own creations. It's not that I don't like to help you but people start seeing errors and may dislike vanilla for "being unstable". Create your own thread or send me a private message, otherwise I can't help you. It's not offtopic here. €: Sorry, thought it's not regarding to vanilla core. I don't have this bug and unless I can't reproduce it, I'm unable to fix it in a proper way.

I'll leave your post better uncommented, otherwise you won't be happy about what I'd reply. If you want I can rewrite the code so you won't have to go through lua.

You don't need to change to unsigned and hope for it to work. You can even make greater changes from tinyint to int so you won't have any problems.

Found the problem with yang limit. Don't use it unless I've fixed it. Official client works, it'd work with freebsd 9.x 64 bit. You can either use 32 bit or 64 bit, it doesn't really matter. I'll create example (!) serverfiles soon. They won't have any features except the vanilla core! They're just an example of stable and working files so you can modify them as much as you want. GLASS_NEEDED is already implemented but not mentioned due to it has no affect in this version. Next version it'll work. Global chat'd be possible too. I guess I'm making it in future versions, if I've enough time left, it'll be in 2.3 too.

Got the same problem atm. Got some problems with the name declaration that's why it doesn't work. Will be renamed correctly so it should work again. Sorry for not making huge progress as I did before but it's just school and therefore no time left to do that much on the gamecore. As soon as holidays come, I'll have huge time spending on the vanilla project. I've fixed some issues related to guild creation, guild_war exploitation and the invisibility bug is fixed now. Expect a empire checkup, so people can't crash your server with high empire id's. Auto-Unstucker works fine as you may have already seen, I'm thinking about expanding this feature to other errors and let a new CONFIG-Option decide if it's enabled or not (so on test servers you can disable it to make further development and on your live server it's best to activate it. But it'll take some work so it won't cause any bugs). I'm thinking about creating a new way to make vanilla more professional. If there are some developers with too much free time and nothing better to do than working in a small (and when I say small I mean small!) group. Let me hear your thoughts: Everyone is free to tell me if it's a stupid idea or not. If it turns out to be bad, I won't do it. Easy as this. Only trustworthy developers could work in this small group. I hope you understand my point and I apologise for the lack of updates in the past. I'm seriously on working with the project but it's just the time problem. As I mentioned: Soon I'll have some weeks free for doing what I want to. And that clearly contains further developing.

Thank you very much. I saw the difference: The new patcher has a custom manifest. I'm going to look for it and maybe I can fix the problem.

I already removed the line, still nothing changed. 1.) Visual studio as Administrator Running Visual Studio as Administrator works. If I run my application there it works too. But building it and running the created executable without VS will cause the error to appear again. 2.) Prepatcher as Administrator Works without any flaws. If I don't run it as Administrator, it'll throw out the error again. 3.) Patcher with double click I need to rename it to metin2client.exe If I do so it runs without Admin privileges. So yes, it's working.

Yeah, just edited a code, the original patcher is from hanashi. I'm fixing it, didn't saw that. To the error: No, the procinfo.Verb = "runas"; doesn't cause the error. I only implemented it after I already had the error but it didn't solve it. And there's no UAC message and still the error remains.

Hello everybody, I've got a new problem here. I'm trying to write a prepatcher which downloads the patcher music (very epic if you ask me ) and - of course - the patcher itself if they aren't up to date. To clarify: It's a WPF application. This is the code: The variable pathexec consists of the absolute application path and the patcher downloaded (it's called metin2client.bin and yes this is the patcher). The error is simple: It states that the program needs higher privileges to execute Process.Start(procinfo); This is the error in german: System.ComponentModel.Win32Exception (0x80004005): Der angeforderte Vorgang erfordert erhöhte Rechte Google didn't help. It always tells me how unusual the error is and that I need to run the program as Administrator. Yes, it's running if I start the program as administrator, but it doesn't solve the problem itself. It's completely unusual and it should not be. And I can't expect from everyone who wants to use the prepatcher to run it with Admin privileges. No one with a little bit cautionousness will do that and that's the right choice. The path exists and is accessable. The funnies thing: If I use an older version of my patcher, the prepatcher will download and run it without any problems! It's just the new application that won't start (but the error is still in prepatcher since it's the Process.Start()-Error that's causing trouble). Running the patcher alone (old or new version doesn't matter) works fine without any flaws. Even these two lines won't help: procinfo.RedirectStandardError = false; procinfo.RedirectStandardOutput = false; Still the same error. I hope someone out there can help me since nothing worked so far. Greetings, Vanilla

To upgrade: freebsd-update upgrade -r 9.2-RELEASE then: freebsd-update install follow the instructions and be careful. Oh and I suggest you don't upgrade vom 8.0 to 9.x. I'd do it in small steps: First upgrade to 8.4-RELEASE and THEN to 9.0-RELEASE. After that you can jump to the release you want. I guess that's the safest way to jump to another branch of FreeBSD.

You'd get hp from players too. I refer to both mobs and players. The point is: You can't damage a already defeated character/mob. But as I said, if you overkill him/it, you'll surely make his hp go < 0. You can see it in duels, just make one and after you died you'd check your hp before reviving -> there you can see the negative values. Same goes with mobs. And as soon as you hit the hp into negative values, you'll loose hp. And that's not fair, you made the damage and you'd be rewarded for the things you managed to do. That's why I reverted it back, so if you manage to overkill someone (which happens everytime) you shouldn't be punished by not getting the bonus you earned from maxing your magic sword.

Jamaica: You can only run up to 35 maps, that's because running too many maps will cause instability and may reduce responsiveness of the core. So it's not remmonended raising the maximum. Remember: They didn't implement it without any thought.

That's for example if an overkill is happening. The bug with the sura skill is when you overkill an enemy, the hp of the enemy goes > 0 and that's influencing this calculation as you can see: You loose hp. My fix will allow sura's to get the hp they earned by overkilling an enemy. Remember: You can't deal < 0 damage, as if it's < 0 it'll be normalized to a number between (afaik) 1-5. The overkill is the only thing producing this bug and the fix will not only prevent the bug but still letting suras get what they earned (if you choose to have the other fix you'll still have a bug: The bug that if you overkill an enemy, you won't get the hp even if you should). the bug he meantioned is simply the bug that's occuring when you overkill an enemy (which happens at least.. 99% of all kills you make since your last hit won't to damage equal to the hp left so you nullify his hp exactly). If you're leveling, you'll get hit hard by this bug if you're going to level at places where the enemies are low on def but high on damage.

Taken from vanilla core: if (pAttacker->GetPoint(POINT_HIT_HP_RECOVERY) && number(0, 4) > 0) // 80% Č®·ü { int i = MIN(dam, iCurHP) * pAttacker->GetPoint(POINT_HIT_HP_RECOVERY) / 100; if (i) { if (i < 0) i *= -1; CreateFly(FLY_HP_SMALL, pAttacker); pAttacker->PointChange(POINT_HP, i); } }

You can install compat for getting further libs if you're running FreeBSD >= 10. I'll add them in a new package soon. Until then you just have to download them by yourself. Sorry for the late response. I'm still on it but I've got less than no time. I'll finish it ASAP.

It's quite easy, doesn't require a new thread for it. Sorry for the late answer I didn't noticed you replying (need to get used to the board). Opfen char_battle.cpp and search for POINT_HIT_SP_RECOVERY You'll find this one: The problem with this is, as you may noticed, that if you manage to overkill someone his tp goes < 0 and the hp drained will become negative too. An easy way to go around this is the following: if(i<0) i *= -1; This will check if the value you'll get is lesser than 0. And if it's the case, your core will multiply it with -1 so it won't be negative anymore and you'll still be healed. Just put it before you create the Fly event.