LTGT

Added <Renewal Regen>

what do you mean with "high player" ?

Made by KaiaProduction, permissions to post have been given. Hello all, attached are about 150 animations. (about 20 for each class+ gender) Wolfman not included. Some of the animations are intended as AFK stances and must be set as loopmotions in the source. Since the animations are from a free motion capture library, you may have seen some of them before. If there is already a pack of this size (correctly adapted to gender and race), the post can be deleted. Otherwise have fun with it Big thanks to @Steap who taught me a lot about the .gr2 format and to @CYN3 for the source customizations. [Hidden Content]

double the gun, double the fun

Main post has been adjusted to support them as well.

Hey, more systems will be added from time to time. Dont care if systems are public or still on sale. (The releases here are recodes) If you want a better UI-Design do it yourself. Code is by @CYN3, so don't even try to report. Systems are tested on Fliegev3. No support. Renewal Regen: Mega or M2DL Advance Items: Mega or M2DL MobileSell: Mega or M2DL Direct-sell: Mega or M2DL Inventory-sidebar: Mega or M2DL Add time to costumes: Mega or M2DL Minimap-Date & Time: Mega or M2DL Give item & equip quest-function: Mega or M2DL Thanks to everyone from sura-head. esp @CYN3 for putting in his time.

Hello, today I saw that people are using the old collsion rendering code from ymir and I think its disgusting and useless to be honest. The new method is using wire framed 3d meshes instead of weird circles that look like a psychosis. You enable the collision rendering by opening the console and run the "collision" command Before: After: [Hidden Content] Once again thanks to everyone from sura-head. esp @HelloBrightness ( Amas ) and @CYN3. and thanks to @ TAUMPfor testing it.

This itemshop is an open source project written by CYN3 with the assistance of the sura_head community. Special thanks to: CYN3 Amas KaiaProductions Installation guide: [Hidden Content]

the sectree in metin2 is scary and not even the old korean wizards know what the fuck is happening over there so I took a deep breath and started to change some stuff around. While doing so I found something strange, after around 2.5-5k mobs the ram is exploding and its getting extremely laggy. I noticed that every `server-source/game/src/entiy.h` -> `CEntity` has its own `ENTITY_MAP m_map_view;` But what is a ENTITY_MAP? In short, it's a container of every currently-visible entity. This is useful to see things but has a small issue: every entity sees every entity in proximity. In other words: the amount of currently tracked entities is growing exponentially. 1 mob -> 0 entries 2 mobs -> 1 entry per mob / 2 entries 3 mobs -> 2 entries per mob / 6 entries 4 mobs -> 3 entries per mob / 12 entries 2500 mobs -> 2499 entries per mob / 6247500 entries This is not good, but we have to see things, we can't just remove it completely. Introducing, my pseudo fix: search for `CFuncViewInsert` in `server-source/game/src/entity_view.cpp` my change would be to avoid calling `m_me->ViewInsert(ent);` every time, so it would look something like that [Hidden Content] We check if both entities are of the "character" type and if so we cast them to `LPCHARACTERS`. If the current view is of a player, he has to see everything if the current view is of a NPC, he has to see only players This fix has some issues, with newer versions of the game there are a few mobs that heal each other - I haven't tested those neither have I tested this change throughout, but I'm fairly certain that it will work. If there is a problem you could add a type/subtype check or even hardcode the vnums since I think that there are only a handful of NPCs that have to see other NPCs (i.e. jotun) good luck Thanks to everyone from sura-head. esp. @CYN3 and @HelloBrightness ( Amas ).

This is a fix for a DoS Vulnerability where invalid player ids are spammed (i.e. HEADER_CG_CHARACTER_SELECT), you can confirm this by looking in the syslog for a bunch of [PLAYER_LOAD] Load from PlayerDB pid[0]. to fix this: [Hidden Content] this fix will make sure the player gets disconnected upon choosing an invalid character, making it harder to spam and making rate limits effective again Thanks to everyone from sura-head.

My anticheat doesn't rely on any metin2 specific functions. regarding to the comment of the code, yes its not practical, but there are more then enough servers with no anticheat, where a bad solution is better then none.

Moin, I had some time again and wanted to try out an idea. The code checks if the client is in focus and only then allows input. Video: [Hidden Content] Code: struct handle_data { unsigned long process_id; HWND window_handle; }; BOOL is_main_window(HWND handle) { return ((GetWindow(handle, GW_OWNER) == (HWND)0) && (IsWindowVisible(handle))); } BOOL CALLBACK enum_windows_callback(HWND handle, LPARAM lParam) { handle_data& data = *(handle_data*)lParam; unsigned long process_id = 0; GetWindowThreadProcessId(handle, &process_id); if (data.process_id != process_id) return TRUE; if (!is_main_window(handle)) return TRUE; auto s = GetWindowLong(handle, GWL_STYLE); if (!(s & WS_VISIBLE)) return TRUE; data.window_handle = handle; return FALSE; } HWND find_main_window(unsigned long process_id) { handle_data data; data.process_id = process_id; data.window_handle = 0; EnumWindows(enum_windows_callback, (LPARAM)&data); if (data.window_handle != 0) { if (IsWindowVisible(data.window_handle)) { return data.window_handle; } } return 0; } bool CPythonNetworkStream::SendCharacterStatePacket(const TPixelPosition& c_rkPPosDst, float fDstRot, UINT eFunc, UINT uArg) { NANOBEGIN if (!__CanActMainInstance()) return true; if (GetActiveWindow() != find_main_window(GetCurrentProcessId())) return true; This is a very bad method, e.g. you can't tab out and farm metins now. However, it should stop any botter who is not actively "playing" and multiboxxer. A proper solution is a good anticheat.

Yes, never said anything else. but it should keep most shitty botters away.

Moin, I wrote a small system out of boredom which helps to block multiboxxing, you can define in the clientcode how many clients can be open at the same time. The whole thing works with windows mutexes and is completely "clientside" i.e. it's not an "ultimate" solution, but should stop every shit botter and similar. Do note: The code is not perfect. just paste the code into UserInterface.cpp: bool genMutex(int id) { std::string mutex_name = "MultiBoxBlock"; mutex_name.push_back(id); HANDLE Mutex = OpenMutexA(MUTEX_ALL_ACCESS, 1, mutex_name.c_str()); if (!Mutex || WaitForSingleObject(Mutex,500) == WAIT_ABANDONED) { CreateMutexA(0, 1, mutex_name.c_str()); Sleep(INFINITY);//locks mutex return true; } return false; } int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { bool ret = false; for (int i = 0;i<3;i++) { ret = genMutex(i); if (ret) break; } if (!ret) { MessageBoxA(NULL, "MultiBox detected", "", MB_OK); ExitProcess(0); } You can define the number of allowed clients in the "for loop". in my case 3. Video: [Hidden Content] Enjoy.