Jump to content
metin2dev

Vanilla

Developer
  • Content count

    358
  • Joined

  • Last visited

  • Days Won

    46

Everything posted by Vanilla

  1. Welcome to the second part of my guide series. This time I'll tell you how you can compile with gcc48 or even gcc49 like it's the case in vanilla and how you can use c++11 which will allow much more and faster instructions than the old one. At first we need to have a look at our Makefile. Make sure you edited the Line SVN_VERSION so you won't receive any errors. Try it e. g. to SVN_VERSION = mt2 Next, you'll have to declare what compiler you want to use. Of course you first need to install the compiler, but I guess it's clear (if you haven't done so, just use cd /usr/ports/lang/gcc49 or even 48 and use make install clean). The line normally say: CC = g++ This is the standard compiler. You may want to change this line to: CC = g++49 Or if you're using 48, change it to CC = g++48 Now before you compile it, you'd recompile all needed libs with gcc48/gcc49 too! So change the compiler in the makefile and recompile the sources in the following directories: libgame/src libpoly libserverkey libsql libthecore/src And then you need to recmopile cryptopp with the newer gcc version too! It's located in the Extern/cryptopp-directory. Now you can compile your game and even your db source with the newer gcc version. You may experience a much smaller file size. The newer compilers will produce an even more faster and smaller gamefile than before. Oh and if you want to carry out the lib-files you're using on your compiling machine (to make sure everything runs smoothly) you may use the following CFLAG: -Wl,-rpath,/usr/local/lib32/metin2 You can change the path to whatever you want! If you specify this, you instruct the linker to use this path so whenever you start your game/dbcache it'll first look in the given directory for the right libs and then, if it can't find the libs there, it'll look elsewhere. Using c++11 is a must-have if you want to make new statements. The source code how to load the database without txt-files needs the newer c++ version, so you'll have to upgrade at least the dbcache for it. But you'll experience even more smaller file sizes with this change so it keeps up with more and more advantages. First you may want to specify the new CFLAG. It's called: -std=c++11 This tells the compiler to use c++11. Keep in mind that not every compiler can use c++11! The newer gcc version can deal with it without any problems. If you compile your source then, you may find a new error occuring! Open every .cpp and .h-file in Notepad++ and do the following things (you can use the mass replacement of Notepad++): replace typeof with __typeof replace auto_ptr with unique_ptr Watch out for the common-directory too! Then you can recompile the source and it's done! Oh and for this you don't need to compile every other sourcecode with c++11. You can e. g. only compile the dbcache with it. Last small hint: You can play with the tuning flags to get even more optimization. -O2 can sometimes be good, but sometimes it's better to use others flags. You can even use -O3 or -Ofast. But be careful with this and consider using -fstrict-aliasing so the compiler won't optimize instructions that'd lead into a crash if it'd optimize them. And always: Pay attention to the warnings your compiler throws at you! They aren't there to just "hang out". They'd lead into crashes, so care about them. Lastly I hope you enjoyed the guide. As in the last one, please tell me if it's good or not and if you have any questions: Feel free to ask.
  2. Hello everybody, since I've heard that a lot of servers (and even the most recent vanilla source release) have no fix for this hack I decided to release this. It's not too big, but I really would like to make it visible for everybody. I highly dislike hacks in every form and I'll gladly develop such fixes. So, the fix is quite easy. It's a bug from metin2. They decided to add a check if the target is too far away to be attacked and yeah, that works. Targets only receive damage once they're within range. But the problem is that modern moblock tools do that a different way. They send attack packets to every mob in the near surrounding which triggers aggr towards the player. You may ask: Why does it trigger aggr and let the mobs move to the player? Well, as mentioned, the source has a fix for that - but it's implemented too late. 1. Open char_battle.cpp and search for this function: CHARACTER::Attack First you may notice that there's literally no check for distance. The distance check is implemented in battle.cpp in the function battle_melee_attack. That's fine and we don't need to modify anything about this. 2. If you scroll down you'll see the following lines: pkVictim->SetSyncOwner(this); if (pkVictim->CanBeginFight()) pkVictim->BeginFight(this); Noticed something? Yeah, the check is - as mentioned before - in the function battle_melee_attack. The problem is, that these lines are executed before the check happens. So hackers will be visible in logfiles (syslog should spam distance errors) but they're still free to hack like they want to. 3. Move the lines below the battle type segment So, how do we fix this? We'd simply move it down below the battle type functions. So you'd move it just before the line "if (iRet == BATTLE_DAMAGE || iRet == BATTLE_DEAD)". But still that won't be enough since these lines would still be executed. We don't want them to be executed. So we wrap a condition around it. 4. modify these lines so they look like this: if(iRet != BATTLE_NONE) { pkVictim->SetSyncOwner(this); if (pkVictim->CanBeginFight()) pkVictim->BeginFight(this); } If we take a look on the battle type functions we'll notice that they return the BATTLE_NONE if something goes wrong - for example the distance is invalid. 5. you're done! The fix pretty much solves this issue. If you still know hacks that work feel free to write in this topic, I'll gladly share solutions once I've developed them. Enjoy!
  3. Vanilla

    c++ Fix Moblock/bravery cape hack

    Thanks for testing it. Can you send me a syslog snippet? You can also play with the values and adjust them to your needs. The fix for bravery cape hack doesn't involve a kick. The kick is only triggered by the speedhack detection, so there's either something wrong with it or the values need to be adjusted.
  4. Vanilla

    c++ Fix Moblock/bravery cape hack

    Care to enlighten me then?
  5. Vanilla

    c++ Fix Moblock/bravery cape hack

    I don't even remember doing this It'd be, but I honestly have no idea. @_Sielu Why so complicated? We already have a working solution and this is the speedhack check. It's working fine and I think a counter is better to store than walking through a vector every time a damage packet goes it's way.
  6. Greetings! The new beta is finished! I'm proud to present r71480. This time a few things have changed. And in this revision, we have a lot of new stuff. In the following I'll provide the download link along with the things I'd love you to test. *** DISCLAIMER *** The core is marked as stable. Anyway, I'll make it clear that I'm not responsible if you use this core since I can't give a warranty that I fixed every single security breach that potentially could happen - that's totally impossible. But we all together made the source great and secure so every public issue is fixed by now. You can use it in production environments now. So... What's new? boot-trigger for quests With this you can execute commands, timers, and all the stuff you'd like to have just on boot-time! revisioning of the 'unique class' (+ a ton of posibilities) added the functionality to create unique-groups temp-Variables for quests upgraded all libs moved completely to the newest clang version fixed some big security issues in the source code fixed the ingame ban and unban commands unified tables and gave them a new way: unify! file clean-up revisioned the makefiles gave the source a new, easier structure removed all external dependencies just install them by ports.. No external-folder necessary! removed 'boost' dependency (no boost lib needed yay) partial implementation of the wolfman (claws etc. are added, needs review) And basically everything that has been offered in the earlier versions of the vanilla core. Nothing should be missing. And if you miss something, just feel free to tell me! What needs testing? There are few things I'd love you to test out: Please check if the core is vulnerable to any security breaches you may know (also the public ones, don't know if I missed something) Please test out the new features! I'd really love to know if the new unique-functions and the boot-trigger does the job. Explanation to new features: Unique with container support Unique has evolved! This time you have a few new possibilities. Don't know what unique is? Here's a short explanation: With the unique-questfunctions you can spawn or set mobs, npcs and now even players to have a unique name. This name is stored into a unique-container. You can access this container and get all the vid's by their unique name (also called: the key) So for example you can spawn a boss with a key. Later on you can check if this specific mob has been killed or not. Or you can set his hp on-the-fly. There's basically no limits! And now with the revised system you'll have even more options. The new unique system works with containers. By default there are two containers reserved: __DEFAULT__ and __CHARACTER__. The first one is for all the basic stuff. And the second one is reserved for players. Now, as you may have noticed, there's a default one which means that the container-stuff is optional. If you just use the unique functions without specifying a container, it'll just use the default stuff. But you CAN use your own containers just as you want to. You can create, delete and list all the containers running. There is a list with all the quest-functions down below. boot-trigger This is pretty self-explanatory. With this release you can use "when boot begin" to specify a block of code that will be executed once the core has been booted. temp-variables With the new temp-variables you can set and remove player-specific variables. They are stored in the core and not written to disk or database. So be careful because they might get dropped once the core shutdowns. It's just a quick storage for people who want to have something like a cache for quick access. new quest functions nil unique.spawn_unique(string key, int vnum, string pos=unused, string container=optional) nil unique.set_unique(string key, int vid, string container=optional) nil unique.purge_unique(string key, string container=optional) nil unique.kill_unique(string key, string container=optional) bool unique.is_unique_dead(string key, string container=optional) int unique.get_hp_perc(string key, string container=optional) nil unique.set_def_grade(string key, int def, string container=optional) nil unique.set_hp(string key, int hp, string container=optional) nil unique.set_max_hp(string key, int maxhp, string container=optional) int unique.get_vid(string key, string container=optional) bool unique.exists(string key, string container=optional) table unique.get_container_list() this prints out all the unique containers table unique.get_container_list(string key) this prints out all the vids in the unique-container "key" nil unique.remove_container(string key) removes a whole container (flushes it when called on standard containers) nil pc.temp_var_set(string key, string value) string pc.temp_var_get(string key) nil pc.temp_var_delete(string key) Thanks a lot for participating! If there are any questions, this is the topic related to it. Further releases will be made public here too! If you'd like to contribute, just post code additions here. Changelog older changelogs Download Useful information: All necessary libs are included. If you're building your own vanilla binary you'll first have to move into every project of the Internal directory and rebuild the libs. The main makefile is not adapted yet, I was too lazy (ps: Still too lazy!) rev 71480 see this post: rev 70220 STABLE Core Sourcecode rev 70140 BETA Core Sourcecode Password for the archive is: vanilla Password for older source archives: vanillamt2 Best Regards Vanilla
  7. Vanilla

    c++ Fix Moblock/bravery cape hack

    you're right, probably this works with players, but the bug wasn't because of this. The speedhack detection should kick the player, that's the job for the hack you showed here. The lines you changed affect mob-lock/bravery cape hack. If you do this, you won't be able to draw aggr from monsters. Did you try that?
  8. Vanilla

    c++ Fix Moblock/bravery cape hack

    I don't think that's correct. If you do that, you'll make moblock/bravery hack work. The problem is that BeginFight() will be triggered even if the distance check fails. So normally the distance check returns BATTLE_NONE and therefore neither SetSyncOwner nor BeginFight() will be triggered. And since BATTLE_NONE is returned, there shouldn't be any damage. Are you sure you implemented it exactly as mentioned in the thread? Because I can't seem to trigger the bug you mentioned here.
  9. Vanilla

    c++ Fix Moblock/bravery cape hack

    I'm onto movement speed hack stuff. Gotta research a bit first (had a few rough days, so no time for that). I'll keep you guys updated once I've developed a fix. Shouldn't be too troublesome
  10. Vanilla

    c++ Fix Moblock/bravery cape hack

    As I said, it depends on your server. The calculation for attack speed and it's acual motion isn't quite correct, that's true. I dunno if it's possible to fix this at all. But it fully depends on your server if it works or not or if you have to fine-tune the value. I even saw a server allowing normal attacks to be faster than the hack would send it's packets. And if that's the case, then you have exactly this problem.
  11. Vanilla

    c++ Fix Moblock/bravery cape hack

    Nope, it's not bad code. The code is working fine. Some servers just allow absurd high attack speed values because they think it's cool or something.. The calculation doesn't add up at all. I've tested the code that's posted above and it seems to work without false flags, but there's no guarantee that it'll work with every server.
  12. Vanilla

    c++ Fix Moblock/bravery cape hack

    It looks like it's using a skill to attack or am I wrong? Because if these are basic attacks, they'd be triggered by the speedhack detection and therefore lead into a kick with the fix mentioned above. But it'd be that they're abusing a skill and mayb the check is missing there. I'll have a look and tell you once I've figured it out.
  13. Vanilla

    c++ Fix Moblock/bravery cape hack

    Speedhacks are already somewhat fixed. In battle.cpp look for the function IS_SPEED_HACK and replace it with this one: bool IS_SPEED_HACK(LPCHARACTER ch, LPCHARACTER victim, DWORD current_time) { if (ch->m_kAttackLog.dwVID == victim->GetVID()) { if (current_time - ch->m_kAttackLog.dwTime < GET_ATTACK_SPEED(ch)) { INCREASE_SPEED_HACK_COUNT(ch); sys_log(0, "%s attack hack! time (delta, limit)=(%u, %u) hack_count %d", ch->GetName(), current_time - ch->m_kAttackLog.dwTime, GET_ATTACK_SPEED(ch), ch->m_speed_hack_count); if (test_server) { ch->ChatPacket(CHAT_TYPE_INFO, "%s attack hack! time (delta, limit)=(%u, %u) hack_count %d", ch->GetName(), current_time - ch->m_kAttackLog.dwTime, GET_ATTACK_SPEED(ch), ch->m_speed_hack_count); } SET_ATTACK_TIME(ch, victim, current_time); SET_ATTACKED_TIME(ch, victim, current_time); if (ch->m_speed_hack_count >= 10) ch->GetDesc()->DelayedDisconnect(3); return true; } } SET_ATTACK_TIME(ch, victim, current_time); if (victim->m_AttackedLog.dwPID == ch->GetPlayerID()) { if (current_time - victim->m_AttackedLog.dwAttackedTime < GET_ATTACK_SPEED(ch)) { INCREASE_SPEED_HACK_COUNT(ch); sys_log(0, "%s Attack Speed HACK! time (delta, limit)=(%u, %u), hack_count = %d", ch->GetName(), current_time - victim->m_AttackedLog.dwAttackedTime, GET_ATTACK_SPEED(ch), ch->m_speed_hack_count); if (test_server) { ch->ChatPacket(CHAT_TYPE_INFO, "Attack Speed Hack(%s), (delta, limit)=(%u, %u)", ch->GetName(), current_time - victim->m_AttackedLog.dwAttackedTime, GET_ATTACK_SPEED(ch)); } SET_ATTACKED_TIME(ch, victim, current_time); if (ch->m_speed_hack_count >= 10) ch->GetDesc()->DelayedDisconnect(3); return true; } } SET_ATTACKED_TIME(ch, victim, current_time); return false; } Note that the only thing I've changed is that the loggin always happens and that you get disconnected if the speedhack detection is triggered too often. The "10" is subject to change. Also make sure that you visit the function GET_ATTACK_SPEED which is also in battle.cpp. Remove these two lines: if (item && item->GetSubType() == WEAPON_DAGGER) real_speed /= 2; and set the variable "default_bonus" to something like 70 (which is a quite good value in test environments). You can fine-tune this value. Make sure you also remove the * 3. You may just want to have a simple value like 70 (default: 80 which is too much in some conditions, depending on your server). This should trigger all those hacks and still make your game playable without false-positives. But this indeed needs further testing, for live servers I recommend choosing a higher threshold (at least 80) until it's confirmed to be working on your server.
  14. Vanilla

    Someone who's willing to write a system 4 me

    tell us what exactly you want and I'll probably write it. No need to pay.
  15. No one can give you a PF script that's magically working for you. You'll have to open the ports needed and apply rules for them. I don't know what software you're running, which ports you are using, etc... So yeah, I'd give you a sample script which will of course work.. But then again the expected results won't appear.
  16. Vanilla

    Metin2PackMaker

    You can remove reducio. It's not needed anyway. Just throw it out of the source and you'll have a working Metin2PackMaker with the most recent toolset.
  17. Vanilla

    Update Your FreeBSD For C++2a

    ah, yes, I was referring to lzo. And yeah, if you mention that he might still have a point - only people knowing how to code will be able to use these, if they wish to But yeah, the thing still holds that bugs have been fixed and there might be cleaner and - probably - faster code due to the updates. So it's still worth it in any case.
  18. I recommend using PF which is a builtin packet filter for FreeBSD. Configure it, limit connections and write exceeding connections into a blacklist. And tune your sysctl variables a bit if you haven't done so in the past. There are some options you can add safely but for a real hardening you'd know what you're doing.
  19. Vanilla

    Update Your FreeBSD For C++2a

    NO, it DOES improve performance to update your software. I did not say that necessarily updating boost brings you a performance boost, but there's clearly a lot of documentation and benchmarks that prove that more recent compilers outclass the older ones, not only in compile-time but also in binary performance. I even gave you an example and if you want, go ahead and compare the builtin gcc version with the most recent one. Yeah, metin2 is crap blablabla. That's why compilers are all unable to optimize out the code, right? That really sounds like a dream world and you'd provide proof if you gonna claim something like that. It is shitty code, but that doesn't mean compilers can't work with it and optimize it. And regarding to other libraries like cryptopp: You said it yourself. Bugfixing. Also some libraries were updated to use newer toolsets, I think boost utilizes c++11 by now and is compatible with c++14, but I honestly don't know if that affects the performance in any way so I'll keep shut about it. Also, obviously, if you gonna rewrite some parts of the source you're probably going to do it right... There's no sense in rewriting shitty code with other shitty code. Who are YOU to claim that we do such things? You're generalizing a lot in an unfriendly tone. Experimental != entirely broken. It is what it is - experimental. And even I utilized some of these experimental features back then (when c++17 was experimental) and - wow, such a wonder, it's working flawlessly even with this shitty code... @flygun No, he has a point there. The algorithm is still the same, it's only about the implementation of it. But that's not the point in this discussion.
  20. The only efficient way of blocking a DDoS attack is by using a hardware firewall. Without it, you can't win this fight. What you can do is blocking DoS attacks with a software firewall. But unlike a DoS-attack, the DDoS attack is effective as soon as it hits your machine. The only thing you can do is try and harden your system and configure a software firewall. But it probably won't do much.
  21. Vanilla

    Update Your FreeBSD For C++2a

    It's sad that most people still use deprecated software. I often hear about people still using freebsd 9.2 and it's builtin gcc. Upgrading from this will result in a performance boost, although - as you said - rewriting the code has obviously more impact. I like it that there's someone writing a guide how to upgrade and hope to see more people using it. It's about making progress with metin2, not standing still and keeping everything as it was.
  22. you need to build liblua which is located at the 'Internal' directory of the source.
  23. Vanilla

    open Core Crash

    I recommend you fix some of those errors first. These are easy to fix. E. g. you have a bad quest there (devils_catacomb quest) as you may see in your syserr. Also check that your skill_proto is having all the necessary entires (skill 236 missing?). Fixing errors is essential and you'd spend some time doing it, it's not that much as far as I can see. Now to your crash: If you wanna find out what's crashing, use gdb and post a backtrace here. Otherwise it's hard to find out what exactly crashes your core with certainty.
  24. No need to re-upload. Next version is already distributed to a few people for testing. If everything works it will be released Just waiting for feedback. If someone wants to test it, feel free to drop me a message.
  25. Hey everyone, sorry for the lack of updates. Real life and stuff. Anyway, I'm preparing a bigger update. Lots of code cleaning and error fixing. I read what you wrote and will try to fix what you reported. Thanks to you all for reporting bugs and suggest changes. Though I will start upgrading the code to c++17 standard which means that I'll most likely not make changes to macro definitions like mentioned above. People should build the project like it's meant to be and under the same feature sets and compilers like I did, to make sure there's less room for errors. If you want to port the code, you can do so of course, I don't mind that. But for 'official' release they won't be included.
×