Jump to content
metin2dev
Ekstasia2

Vanilla

Developer
  • Content Count

    362
  • Joined

  • Last visited

  • Days Won

    46

Vanilla last won the day on September 10

Vanilla had the most liked content!

Community Reputation

954 Unstoppable

About Vanilla

  • Rank
    Noble

Profile Information

  • Gender
    Female
  • Location
    Germany

Recent Profile Visitors

9,578 profile views
  1. Vanilla

    open freebsd 13.0 source compile

    You can safely remove the source files but you need to keep the header files inside the include folder. Otherwise your source won't compile. And, obviously, you need the built libraries.
  2. Vanilla

    open freebsd 13.0 source compile

    yep this looks like it. CryptoPP utilizes c++17 which you don't use. I've had the same issue. You need to add -std=c++17 to your compiler flags, linking should work then. But you're probably gonna end up having another issue because compiling will fail on some files due to removed functions (std::mem_fun for example).
  3. Vanilla

    open freebsd 13.0 source compile

    Are you using a more recent std? Probably c++17? Because cryptopp 7.0 is meant to be used with that and it'd explain an issue I've got when upgrading this stuff.. I can't see the screenshots you posted. Could you please reupload?
  4. I did not abandon the project but due to personal rl issues I wasn't able to do much. I'm sorry for the lack of updates. Things will change starting next year. So stay tuned, I'm gonna release a new version once I'm done with the rl stuff.
  5. 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.
  6. Vanilla

    c++ Fix Moblock/bravery cape hack

    Care to enlighten me then?
  7. 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.
  8. 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?
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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!
×