Vanilla

I'm not 100% sure if you can do this on Metin2, but lua has a goto statement too. [Hidden Content] If that's possible there you can just use it and "return" back to the prior code. But I absolutely hate goto stuff... So use it at your own risk, I'm not even sure if Metin2 can handle it

There are many options how to approach this. You'd write this stuff into a function and just call it again once the player chooses "Close". Note that you'd at least give the player an option to properly exit the function, otherwise you're calling it recursive with no getting out, trapping the player in an endless loop of hopelessness. People start to forget the player's name as they're fading into oblivion, down the spiral of endless torture as they loose their understanding of time and space and their existence enters nothingness. tl;dr: Recursive function is the key, but make sure you let the player exit it somewhere.

I'm sorry for the inconvenience. I'll definitely make one new rev and upload it. If there's more interest, I'll make further development. This new release focuses on another security batch and more stability since the last release indeed had some problems. I've fixed the query stuff and changed a bit here and there... I also added a new GM Rank that will help server admins keep control over the environment even if things are going bad (like e. g. some GM/Admin going crazy and stuff..) For now the new featureset looks like this: * c++2a compatibility * cryptopp 8.2.0 * boost 1.7.0 * changed DirectQuery implementation to always return unique pointers * DirectQuery: dropped variables for proper deallocation once they are no longer needed * Some minor and major code fixes (new rev was in development for a long time, couldn't get all the stuff that I changed) * Changed warning "not in unify mode" to just a small attention on boot-up. This makes it less "Oh no please stop!" and more like a hint * New GM Mode SUPERADMIN * Added compatibility to MySQL 8.0 which will be used in the future. * Removed unnecessary library dependencies * Changed Makefile to now compile and include debug/release libraries correctly SUPERADMIN is a new keyword. You can add it to your gmlist. It has all the privileges IMPLEMENTOR has but it has some protections to make sure you keep access. SUPERADMIN is protected against demotion for example. He does not have to elevate and can use GM powers without limitation. Additionally, the /promote command can not promote someone to SUPERADMIN. The only way to add it is via gmlist. Also /reload a does not affect Superadmin, only a server restart can promote/demote a super admin. SUPERADMIN cannot be /dc and have a godmode, so they can't be killed. Also they'll have all IMMUNE flags no matter what. Note that players with SUPERADMIN status should only be used as an emergency account. It is not meant to prevent damage when an Admin goes rampage. It's meant to be used as a counter-measurement to take back control of the server if something really goes bad or maybe demote admins Quest functions: + bool is_superadmin() returns true or false depending if the player has the SUPERADMIN rank or not. Commands: + /demote [PlayerName] Removes and deactivates elevation for the target user. Does not work on players with higher rank and does not work against SUPERADMIN. Demotion also applies a status that prevents the player from elevating again unless he relogs + /exile [PlayerName] Revokes elevation and strikes him from the gmtable+gmlist thusrendering him unable to elevate again. This comand does not work against SUPERADMIN. Also, this command does not work against players with higher rank and minium rank IMPLEMENTOR is needed. * /ban /dc /kill /warp /transfer These commands do not work on players with SUPERADMIN status. Note that players with SUPERADMIN can still use these commands. So this is the changelog for now. This is planned and I need some people to test it. Just drop me a pm and I'll gladly send you a test build within the next few days. Also, if you have any thoughts/suggestions/ideas I'd love to hear them.

You're the only one that actually replied here to this. No PMs, nor anything else. I can do another build but as I said, the effort is not worth it if there's only 3-4 people using it... If there are more people interested, please let me know.. At least a pm or something so I can see that there's still interest in this project.

There's almost none interest in the project from the community so I stopped releasing a new build. If there's enough interest, I'll make another release but as things stand right now the time and effort put into this project just isn't worth it if only 3-4 people really use it..

Did you change anything on the source? Do you have logs from syserr/log at the time the CPU ramps up? If there's an operation that triggers such a behavior there's a chance it's written to the logs.

most likely a faulty quest that keeps the cpu in a loop. Check your quests, you can also run the server without having any single quest so you can see if the core still gets stuck.

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.

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).

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?

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.

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.

Care to enlighten me then?

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.

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?

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.

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

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.

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.

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.

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.

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!

tell us what exactly you want and I'll probably write it. No need to pay.

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.

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.