Jump to content
metin2dev

Vanilla

Developer
  • Content count

    352
  • Joined

  • Last visited

  • Days Won

    46

Vanilla last won the day on September 10

Vanilla had the most liked content!

Community Reputation

943 Unstoppable

About Vanilla

  • Rank
    Noble

Profile Information

  • Gender
    Female
  • Location
    Germany

Recent Profile Visitors

9,352 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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!
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. you need to build liblua which is located at the 'Internal' directory of the source.
  15. 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.
×