Leaderboard

GF v20.3.3 patch (Metin2 Download) Contents: Some re-exported, new mob models. Simple GUI for WorldBoss event, Flower event. Removed FindM event perhaps by mistake. New skill icon for wolfman(?) Probably soon the new skills are coming too. root+dump, locales+protos

Required level : Beginner Estimated time : 15 minutes This tutorial is to explain how to install a map on Metin2. Needed : A map, you can find many maps here. You will need access to your server, with WinSCP for example, as well as a packer like EterNexus or PackMakerLite for depack your client. I. Serveur side II. Client side A category Questions and Answers is available. If you have a problem or question, feel free to post a request!

Ok, we'll find a day and i'll merge all of your topics with resources into one (per category) and the thread title will be? "3D Resources" and "2D Resources" ?

@Denis If you think that your reactions as a former staff, are fine just because this: he's greek he's using a public system he doesn't know english he's new on this forum he isn't a 'dev' and don't know anything about coding then, you're the bad person, not him, go and solve your problems in other parts and let'me show you the rules. Edit: Apparently Denis didn't understand what I wanted to say with the "bad person, so he take it wrong. I apologize. Rules (1.1) Language The language in this board is english. If you want to post something in your own language always add an english translation. The only exception for this rule is this section: Private Servers (1.2) Behaviour Don't flame at other users. We want this board to be the best possible experience. You maybe want help and everybody started with no or little knowledge. So help and don't flame! Also we don't want to see any racism or sexism. (1.3) Spamming Do not spam in this board. Posting a topic or a question once is enough. If you don't get an answer maybe your question needs more description. Or nobody is able to help you there. Double post aswell as double threads will be punished with an infraction. @perfect ^+ (2.2) Bumping Allowed bumping times: Q&A - 48 hours (2.5) Questions & Answers specific rules Don't modify your thread (or reply to it) to mark it solved, and not explain the solution to the issue. @Denis +2 infractions @perfect +3 infractions Topic closed.

M2 Download Center Download Here ( Internal ) PS: roses are red violets are blue my photoshop skills arent the same as yours

M2 Download Center Download Here ( Internal ) Hello, Didn't know whether to place this subject either here or on guides but since I'm gonna not only share the mitigation but also express my conclusion about this issue and further after-effects. Only part of codes are attached below. For methods definitions + headers jump here: [Hidden Content] 1. Vulnerability overview. Any kind of tcp application is required to have a server (anda client). Once a server is launched it's binded to appropriate socket and set on listening for further connections (in a cutoff, navigate here for more precise info) On the other side client is the one which is suppose to connect to server. It does it by connecting to server's socket and start to process a handshake. This is how it works in a big shortcut - or I should rather say, it does work if we deal with normal peer. In case of more-like modern apps the traffic is held by efficient algorithms that can carry even heavy traffic or eventual feeble attack. But since Metin2's core is not a state-of-art app and simply runs on old C style code (libthecore) without a real concurrency support that might dive us into some tricky issues. So let's imagine what happens if someone tries to pull off an attack and flood the server with enormous amount of packets. Since each of connection needs to be validated first, it goes through the handshake. Server catches it through the fdwatch function (jump to io_loop, main.cpp), then if no desc is presented moves it to AcceptDesc where the connection is validated. It is usually allowed unless the peer's ip is not in a banlist. Then desc is created and connection is saved for further handshake response. Sounds reasonable, right? Now imagine when thousands connection are accepted, validated, and expected to send handshake response. Does it still sound so optimistic? Additionally, when a desc is created it does allocated buffer for I/O traffic. Each connection. Each time. Each desc. Now do the math and try to conceive how much of memory is simply wasted. So that's the point we've been heading. That's our vulnerability. And btw, if so many agents are in the queue, do you think anybody will be able to connect your server? 2. Four major problems. Let's start from handshake itself. Imagine that someone approaches you and gives you his hand to shake it. And than second. And then third. Doesn't make sense, does it? Same applies to handshake process. Simply, only one handshake shall be ongoing for the host unless it completes it. So, let's jump to AcceptDesc in desc_manager.cpp and add this little code above: newd = M2_NEW DESC; // Let's check if a handshake from this host is already ongoing if (GetHostHandshake(peer)) { sys_log(0, "Handshake from %s is not permitted!", host); socket_close(desc); return NULL; } So let's consider this as solved for now. Then the second issue. Let's imagine yet another event. Someone shakes your hand but this time completes the handshake. But he does it again. And again. And again. Sounds exhausting? Let's add this 2 conditions below our recent code from above: static const int HOST_CONNECTION_LIMIT = 3; // In case if host completed handshake process let's check if it doesn't reach the limit if (GetHostConnectionCount(peer) >= HOST_CONNECTION_LIMIT) { sys_log(0, "Host %s connection limit has been reached!", host); socket_close(desc); return NULL; } // And block intrusive connections as well if (IsIntrusiveConnection(host)) { sys_log(0, "Host %s is intrusive!", host); socket_close(desc); return NULL; } First if checks if host doesn't reach the handshake limit and if it does - the host is dropped. Second if seeks for intrusive peers. That simply means if one tries to connect again, and again, and again in defined time lapse it probably turns out to be an attacking IP. Let's jump for a moment to desc.cpp, Initialize and add this variable initialization there: tt_creation_time = get_global_time(); Yet another problem solved. Still tho, all this code is considered to work more for authentication than for game's core. Why is so? Imagine a person how is not suppose to have any attention at all - a movie star for example. Usually when one walks on red carpet there are bunch of body guards sealing him/her out from the crowd around. Same should happen to game cores because why one would try to perform a handshake with game if hadn't even logged in? So that's we are going to do, simply whitelist players who were succeeded to perform through the login process and obtained login key. Firstly let's jump back to the desc_manager.cpp and add this little code above our previous alterations: // If it's not an auth server - check for validation first if (!g_bAuthServer) { if (!IsOnHandshakeWhitelist(peer)) { // sys_log(0, "Host %s has not validated through login!", host); socket_close(desc); return NULL; } } Now open input_db.cpp, move to AuthLogin function and add at the end: // Validating handshake TPacketGGHandshakeValidate pack; pack.header = HEADER_GG_HANDSHAKE_VALIDATION; strlcpy(pack.sUserIP, d->GetHostName(), sizeof(pack.sUserIP)); P2P_MANAGER::instance().Send(&pack, sizeof(pack)); And so on repeat it for AuthLoginOpenID if you use it. Now let's jump to input_p2p.cpp, move to Analyze function and after the initial syslog: // Auth server is not allowed for p2p if (g_bAuthServer) { // Clearing buffers for dynamic packets switch (bHeader) { case HEADER_GG_RELAY: { TPacketGGRelay * p = (TPacketGGRelay *) c_pData; if (m_iBufferLeft < sizeof(TPacketGGRelay) + p->lSize) iExtraLen = -1; else iExtraLen = p->lSize; } break; case HEADER_GG_NOTICE: { TPacketGGNotice * p = (TPacketGGNotice *) c_pData; if (m_iBufferLeft < sizeof(TPacketGGNotice) + p->lSize) iExtraLen = -1; else iExtraLen = p->lSize; } break; case HEADER_GG_GUILD: { iExtraLen = m_iBufferLeft - sizeof(TPacketGGGuild); } break; case HEADER_GG_MONARCH_NOTICE: { TPacketGGMonarchNotice * p = (TPacketGGMonarchNotice *) c_pData; if (m_iBufferLeft < p->lSize + sizeof(TPacketGGMonarchNotice)) iExtraLen = -1; else iExtraLen = p->lSize; } break; } return iExtraLen; } Since some of the packets might be dynamic, we need to ensure that data they hold is cleared properly. If you have more dynamic packets binded - add them as above. Move to db.cpp, find function SendLoginPing and replace with following: void DBManager::SendLoginPing(const char * c_pszLogin) { /* TPacketGGLoginPing ptog; ptog.bHeader = HEADER_GG_LOGIN_PING; strlcpy(ptog.szLogin, c_pszLogin, sizeof(ptog.szLogin)); if (!g_pkAuthMasterDesc) // If I am master, broadcast to others { P2P_MANAGER::instance().Send(&ptog, sizeof(TPacketGGLoginPing)); } else // If I am slave send login ping to master { g_pkAuthMasterDesc->Packet(&ptog, sizeof(TPacketGGLoginPing)); } */ } Avoiding clearing billing like that (wtf is that btw, shouldn't be executed at all). Now move to packet_info.cpp and add this code in constructor: Set(HEADER_GG_HANDSHAKE_VALIDATION, sizeof(TPacketGGHandshakeValidate), "HandShakeValidation", false); Jump back to input_p2p.cpp and add this case in Analyze function: case HEADER_GG_HANDSHAKE_VALIDATION: DESC_MANAGER::instance().AddToHandshakeWhiteList((const TPacketGGHandshakeValidate *) c_pData); break; Finally jump to ClientManager.cpp in DB. Find function QUERY_SETUP and if condition with bAuthServer and add there following code: peer->SetChannel(1); Sine P2P communication is allowed only for peers possessing any channel number greater than zero, we set it. Usually this practice should be forbidden but since we restrain the traffic for auth server (with code above) it should be safe. Beware that this might cause first login failed because of packet propagation that can reach the cores after player connects. Voilà, were mostly done with coding! Last but no least, we need to take a brief introduction into kqueue and tedious tour between sockets and kernel vars. Starting with kqueue. I would try to explain this but you better jump to this link. Freebsd documentation always appreciated. Since Metin2 implementation of kqueue wrapper has its size limit you may try to increase it a bit and seek for a feedback. If'd like to do so jump to main.cpp, start function and edit this variable: main_fdw = fdwatch_new(VALUE); Yet keep in mind! Do not try to over-optimize it! Try to experiment, put the different values. If you somehow screw it up it might drag you into the checkpoint issues and eventually crash the whole app. So now a few words about sockets and how the listening process works. When each connection aiming to appropriate port is detected it is dropped into the queue where it's waiting for application to pick it up. So simply we can consider this as a waiting queue like in a grocery store. The point is that this queue has it's limit and once the limit is reached, any new connection is declined at sight. The listening limit for Metin2 core is wrapped into variable called SOMAXCONN. If you dive into C socket documentation you can find something like this: /* *Maximum queue length specifiable by listen /* #define SOMAXCONN 10 As for me it was 128. Since it's a define the value is simply embedded into the app and you cannot manipulate it once a binary is built. So let's change it to let more connection be scheduled. You may ask, why? If player tries to log in it does connect the channel port. If the channel is unavailable you see fadeout and connection is terminated. It happens because there is no place in the queue thus connection is scheduled at all. But be careful! Do not set this value into some high-peak numbers! Be aware that our io_loop function need to iterate through these all events and manage to handle this during the heartbeat session. If you try to over optimize this value you can end up causing lags on the server, internal packets delays and more. In case you'd ask me, value around 1024 is acceptable but still it's better if you take some lecture and experiment a bit. And one more thing, don't forget to set this kernel option on the machine where your server runs: sysctl kern.ipc.soacceptqueue=1024 sysctl kern.ipc.somaxconn=1024 So we are done! Don't forget to add the code from my github repo! Epilogue Metin2's quite an old app and we should not forget about that. The netcode is old, rubbish and cumbersome thus this issue might be only one of many we haven't found just yet. Keep in mind tho that even that mitigation won't protect your server. Actually I doubt that even rewriting the code into more modern shape would do that if you don't get yourselves a good protection. Protection, filters, external firewalls are actually the key especially now when stressers and all this stuff are back and harmful again. Hope that this little thread will help you in your future development. Extra I manage to write a little collector for getting rid of handshakes that never completed this process (outdated). If you'd like to switch it on jump to desc_manager.cpp constructor and add there: CEventFunctionHandler::instance().AddEvent([this](SArgumentSupportImpl *) { desc_manager_garbage_collector_info* info = AllocEventInfo<desc_manager_garbage_collector_info>(); m_pkDescManagerGarbageCollector = event_create(desc_manager_garbage_collector_event, info, PASSES_PER_SEC(1)); }, "DESC_MANAGER_COLLECTOR", 1); Beware that you need this feature: And don't forget to add this to destructor: event_cancel(&m_pkDescManagerGarbageCollector); Regards Btw, credits for @Flourine for flooding my dev server with 20k packets per sec (asked for 2 btw). That helped me to analyze the problem.

M2 Download Center Download Here ( Internal ) Hello, Working on some new stuff I found out that current implementation of event looks a bit tricky. Due to this fact I basically deciced to re-implement it in C++11 providing up to date tech. Don`t forget to take a look at this topic before you start: [Hidden Content] So lets begin. Add include into the main.cpp: #ifdef __NEW_EVENT_HANDLER__ #include "EventFunctionHandler.h" #endif And add this into main function before: while (idle()); #ifdef __NEW_EVENT_HANDLER__ CEventFunctionHandler EventFunctionHandler; #endif Now add this at the end of idle: #ifdef __NEW_EVENT_HANDLER__ CEventFunctionHandler::instance().Process(); #endif Now search for: sys_log(0, "<shutdown> Destroying CArenaManager..."); And add before: #ifdef __NEW_EVENT_HANDLER__ sys_log(0, "<shutdown> Destroying CEventFunctionHandler..."); CEventFunctionHandler::instance().Destroy(); #endif Now open service.h and add this define: #define __NEW_EVENT_HANDLER__ That`s all. Now just download attachment and add included files to your source.

M2 Download Center Download Here ( Internal ) Hey, Today i will share how can you change the Whitemark in Minimap with a new one. I saw that there is a topic in Questions & Answers but seems not complete so. Minimap Whitemark - New Download:

Nice tutorial, it is good to sum up it for beginners Some things to mention: 1) Actually, dungeons are not good to be in ch99 at the most cases, because if the map where you want to teleport from, and the dungeon is not in the same core, it won't teleport. If you want to place a dungeon to ch99, you have to make a "lobby" level, like demon tower level 1. That level of demon tower is not a dungeon yet, it will be ported to dungeon after we destroy the metin there. Also the dungeon must be in same core with the map where you want to teleport to the dungeon. For example if you want to enter a dungeon from Map1 what is in ch1 core1, the dungeon should be in ch1 core1. If it's in core2/3/x, then it will not teleport, and you'll get a syserr like "cannot create dungeon". 2) If the coordinates of the map can't be divided by 256, it will cause a lots of problem. (2600000/256=10156.25 so it will be bad) For example the server_attr will be slided, so the block, pvp, water areas will not 100% there where you placed, also if you go to the slide's opposite side you'll get kicked out because there is nothing there according to the server, because it is slided in the other way (This is because the maps are stricted to areas, and 1 area's size is 256x256) Maybe it is hard to understand with just text so i gonna show it in a picture: If you check Ymir's maps, every default map can be divided by 256 to prevent this problem. This was not a criticism, please do not take it as that.

M2 Download Center Download Here ( Internal ) Download Here ( GitHub ) I know this is very old idea but it's better than quest flag methods etc.

Originally originated from Unreal Tournmanet 2004

1) Are you riding a mount or did you removed the movement speed cap when you're on foot? As i remember about ~180 movement speed the game caps it and you can't move faster on foot. If you're too fast (even with mounts, or even on foot with removed limit) this can happen. 2) The map where you are, the coordinates can divided by 256? If not, it produces a lot of problem, maybe this too. Exampe: (Just a random number to show...) 315136/256=1231 ~ Good 315137/256=1231.0039 ~ Bad 3) If it is not Ymir's map then dump a server_attr with WorldEditor Remix, maybe the creator used a default or not matching one. Disclaimer: I don't need money even if those solved your problem, i cannot accept it btw because of my country's strict laws. Once i sold a CS:GO skin for 90euro then i got a letter from the duty bureau 3weeks later that i should explain what was that ?

That sounds is from CS 1.6 hahah

I know you are good at this mapping stuff, but one thing doesn't leave me calm. Don't get me wrong but I will never understand this behavior to a free release.. Download the downloadlink which is password-protected. Then the link is a shortened link which downloads another file with another password. Why do you waste your time on this ? To hide your website? - It can't be true, because literally readable where the file came from in any download manager. Just for fun?

M2 Download Center Download Here ( Internal ) Hello, This time i grab an old stuff again and bring back to life: Bangsan & Imji Valley. (Jinno's and Chunjo's orc maps) Originally every empire would have had their own orc map, but Bangsan (Jinno) and Imji (Chunjo) never finished nor used. Video: -Demon Tower (Hwang Temple) placed -Heaven Cave's entrance placed -Attrs and textures corrected -Added trees, rocks where it felt too empty -Atlas dumped -Full serveride made with complete regens -Etc Everything included, even quests with the new coordinates. You don't have to make anything Download1: [Hidden Content] Download2: [Hidden Content] Download3: [Hidden Content]

The easiest example is python. On your client you will have either python24.dll or python27.dll You can take the python source, compile it as static (.lib file that you then place in your extern/lib of client and will be built with your .exe/.bin) instead of dynamic (.dll is a dynamic lib) That way you just eliminated the need for python dll without using 3rd party software

The tooltip in official pythons is not bug. You just need add the "OnMouseOverIn" and "OnMouseOverOut" in PythonWindow.cpp. Is not neccesary a lot of code for show it.

Hello everyone. Let me share these with you here. This post contains everything for the recent[v20.1.5.1 05.05.2020] item and mob proto structure. About the mob_proto it might be some false data, but it's okay , it is impossible to figure out totally from clientside only. I am going to explain my thoughts about the new AI Flags as well as about everything I know, or think. enum EMisc { CHARACTER_NAME_MAX_LEN = 24, MOB_SKILL_MAX_NUM = 5, ITEM_NAME_MAX_LEN = 24, ITEM_LIMIT_MAX_NUM = 2, ITEM_VALUES_MAX_NUM = 6, ITEM_APPLY_MAX_NUM = 4, ITEM_SOCKET_MAX_NUM = 3, CHARACTER_FOLDER_MAX_LEN = 64, }; Fist stop, this enum contains some basic informations which mostly the same, except one. ITEM_APPLY_MAX_NUM has been increased to 4 from 3. Why? Because of the new mounting system what they have done. The seal items of the mounts control everything about the mounting and its bonuses; - New APPLY_MOUNT bonus, its value is the vnum of the mount, stored into POINT_MOUNT. - The bonuses what the mount gives are in the rest of the applies. This why they had to add an extra apply because some mounts gives up to 3 bonuses. typedef struct SItemLimit { BYTE bType; long lValue; } TItemLimit; typedef struct SItemApply { WORD wType; long lValue; } TItemApply; Ho-ho-ho another stop here for a sentence. Might be you cannot see any new values, but if you check the datatypes in the TItemApply, you will see they have changed the datatype of the ApplyType from BYTE(unsigned char) to WORD(unsigned short). Why? The answer is easy; because of their number of the bonuses reached the 255 limit of the BYTE, above of 255 the data will overflow. This modification they made with the 6th 7th bonuses. They added lots of worthless bonuses to be different from the private section and to squeeze out the money of the players with the 6th 7th bonuses. enum EItemAntiFlag { ITEM_ANTIFLAG_FEMALE = (1 << 0), ITEM_ANTIFLAG_MALE = (1 << 1), ITEM_ANTIFLAG_WARRIOR = (1 << 2), ITEM_ANTIFLAG_ASSASSIN = (1 << 3), ITEM_ANTIFLAG_SURA = (1 << 4), ITEM_ANTIFLAG_SHAMAN = (1 << 5), ITEM_ANTIFLAG_GET = (1 << 6), ITEM_ANTIFLAG_DROP = (1 << 7), ITEM_ANTIFLAG_SELL = (1 << 8), ITEM_ANTIFLAG_EMPIRE_A = (1 << 9), ITEM_ANTIFLAG_EMPIRE_B = (1 << 10) ITEM_ANTIFLAG_EMPIRE_R = (1 << 11) ITEM_ANTIFLAG_SAVE = (1 << 12) ITEM_ANTIFLAG_GIVE = (1 << 13) ITEM_ANTIFLAG_PKDROP = (1 << 14) ITEM_ANTIFLAG_STACK = (1 << 15) ITEM_ANTIFLAG_MYSHOP = (1 << 16) ITEM_ANTIFLAG_SAFEBOX = (1 << 17) ITEM_ANTIFLAG_WOLFMAN = (1 << 18) ITEM_ANTIFLAG_RT_REMOVE = (1 << 19) ITEM_ANTIFLAG_QUICKSLOT = (1 << 20) ITEM_ANTIFLAG_CHANGELOOK = (1 << 21) ITEM_ANTIFLAG_REINFORCE = (1 << 22) ITEM_ANTIFLAG_ENCHANT = (1 << 23) ITEM_ANTIFLAG_ENERGY = (1 << 24) ITEM_ANTIFLAG_PETFEED = (1 << 25) ITEM_ANTIFLAG_APPLY = (1 << 26) ITEM_ANTIFLAG_ACCE = (1 << 27) ITEM_ANTIFLAG_MAIL = (1 << 28) }; Okay, here also there are many of new antiflags and I am going the explain the new flags only: ITEM_ANTIFLAG_RT_REMOVE : This one kind of funny, because this doesn't have any reference at clientside, but it should be ANTIFLAG_REAL_TIME_REMOVE. Which blocks the destroyitem function when the real_time_expire_event is executed. It is about 98% sure. Only the new pet system seals have this flag, and their transport box. Isn't it funny that I've just figured this out now when I wrote this? haha ITEM_ANTIFLAG_QUICKSLOT : Obviously blocks to attach the item with this flag to the quickslots. ITEM_ANTIFLAG_CHANGELOOK : This one will block the changelook process. That item which has this flag cannot be used for appearance for another. ITEM_ANTIFLAG_REINFORCE : Blocks to add new bonuses to an item. ITEM_ANTIFLAG_ENCHANT : Blocks to change the attributes of an item. ITEM_ANTIFLAG_ENERGY : Blocks to use the item for making Energy Fragment from it. ITEM_ANTIFLAG_PETFEED : This flag blocks the pet, to eat the item which has it. ITEM_ANTIFLAG_APPLY : This flag will make the item unstonable, you will not be able to put any stones into it. Or It blocks every applicable item to use on it, can be both too, dunno. ITEM_ANTIFLAG_ACCE : This flag will block theowadan to absorb the bonuses from the item which has this flag. ITEM_ANTIFLAG_MAIL : The flag will make the item unsendable via mail. enum EItemFlag { ITEM_FLAG_REFINEABLE = (1 << 0), ITEM_FLAG_SAVE = (1 << 1), ITEM_FLAG_STACKABLE = (1 << 2), ITEM_FLAG_COUNT_PER_1GOLD = (1 << 3), ITEM_FLAG_SLOW_QUERY = (1 << 4), ITEM_FLAG_RARE = (1 << 5), ITEM_FLAG_UNIQUE = (1 << 6), ITEM_FLAG_MAKECOUNT = (1 << 7), ITEM_FLAG_IRREMOVABLE = (1 << 8), ITEM_FLAG_CONFIRM_WHEN_USE = (1 << 9), ITEM_FLAG_QUEST_USE = (1 << 10), ITEM_FLAG_QUEST_USE_MULTIPLE= (1 << 11), ITEM_FLAG_QUEST_GIVE = (1 << 12), ITEM_FLAG_LOG = (1 << 13), ITEM_FLAG_APPLICABLE = (1 << 14), }; Small confess about the normal Flags, I'm too lazy to explain everything so I just put here the list of them Anyway they didn't add any new, just removed some unused from 2003 devphase. enum EItemWearFlag { WEARABLE_BODY = (1 << 0), WEARABLE_HEAD = (1 << 1), WEARABLE_FOOTS = (1 << 2), WEARABLE_WRIST = (1 << 3), WEARABLE_WEAPON = (1 << 4), WEARABLE_NECK = (1 << 5), WEARABLE_EAR = (1 << 6), WEARABLE_UNIQUE = (1 << 7), WEARABLE_SHIELD = (1 << 8), WEARABLE_ARROW = (1 << 9), WEARABLE_HAIR = (1 << 10), WEARABLE_ABILITY = (1 << 11), WEARABLE_PENDANT = (1 << 12), }; Here for a comment, they have just added the pendant as new, and changed the index of the unique with the shield. Also wondering when they are going to remove the unused wear ability flag, and its I dont know how many slots from the equipments .. Those were back in time couple of hidden items, for the collection quests bonus holder of the results, or whatever, stupid thing, unused, supposed to be removed. Done. The Immune flag is untouched, pf obviously because it is used for nothing at all rofl. About the LimitTypes, they removed the PC_BANG value, and its items, codes completely. typedef struct SItemTable { DWORD dwVnum; DWORD dwVnumRange; char szName[ITEM_NAME_MAX_LEN + 1]; char szLocaleName[ITEM_NAME_MAX_LEN + 1]; BYTE bType; BYTE bSubType; BYTE bWeight; BYTE bSize; DWORD dwAntiFlags; DWORD dwFlags; DWORD dwWearFlags; DWORD dwImmuneFlag; DWORD dwBuyItemPrice; DWORD dwSellItemPrice; TItemLimit aLimits[ITEM_LIMIT_MAX_NUM]; TItemApply aApplies[ITEM_APPLY_MAX_NUM]; long alValues[ITEM_VALUES_MAX_NUM]; long alSockets[ITEM_SOCKET_MAX_NUM]; DWORD dwRefinedVnum; WORD wRefineSet; DWORD dw67Material; BYTE bAlterToMagicItemPct; BYTE bSpecular; BYTE bGainSocketPct; BYTE bMaskType; BYTE bMaskSubType; } TItemTable; Okay, lets do this one too. So, as you can see here are couple of new values, compared to the old one from 2013. Let's roll over on the new values. dw67Material : This one will be the vnum for the 6th 7th bonus adder, which material is necessary to add the bonus to the item. You can read about this on the official wiki. bMaskType : This is used for the private shop search to categorize the items. bMaskSubType : This is also used for the private shop search to categorize the items. Last word about the item_proto: I will not put the types, subtypes, and their mask version and describe them because none of you will use it . Coming up the mob_proto. enum EMobEnchants { MOB_ENCHANT_CURSE, MOB_ENCHANT_SLOW, MOB_ENCHANT_POISON, MOB_ENCHANT_STUN, MOB_ENCHANT_CRITICAL, MOB_ENCHANT_PENETRATE, MOB_ENCHANTS_MAX_NUM, }; Yes this is untoucheed. No, they didn't add bleeding as enchant to the mobs. It is an effect of some skills of the monsters in the zodiac temple. enum EMobResists { MOB_RESIST_FIST, MOB_RESIST_SWORD, MOB_RESIST_TWOHAND, MOB_RESIST_DAGGER, MOB_RESIST_BELL, MOB_RESIST_FAN, MOB_RESIST_BOW, MOB_RESIST_CLAW, MOB_RESIST_FIRE, MOB_RESIST_ELECT, MOB_RESIST_MAGIC, MOB_RESIST_WIND, MOB_RESIST_POISON, MOB_RESIST_BLEEDING, MOB_RESISTS_MAX_NUM, }; Here you can see couple of new values, all of them obvious, and readable to understand. But if it isn't... MOB_RESIST_FIST: Resist to fist, so when you hit the monster without weapon equipped and it has this defence value, the damage will be reduced. MOB_RESIST_CLAW: Resist against claw attacks, come on, I don't want to do this. MOB_RESIST_BLEEDING: Same as resist_poison just against of the bleeding. enum EMobElementaryWhatevers { MOB_ELEMENTAL_ELEC, MOB_ELEMENTAL_FIRE, MOB_ELEMENTAL_ICE, MOB_ELEMENTAL_WIND, MOB_ELEMENTAL_EARTH, MOB_ELEMENTAL_DARK, MOB_ELEMENTAL_MAX_NUM }; Without serverside these values are not understandable properly. Naturaly those monsters which has elemental resists they have this values as well on the same elemental. Forexample: Lets see the Death reaper(1093). He has UNDEAD and ATT_DARK as RaceFlag, 50% resist fist(just telling ;]), ElemDark=1 and resist dark "-20%" But some monsters are having these values 100+ which is.... no idea why. Zodiac monsters only if I'm not wrong. enum EMobAIFlags { AIFLAG_AGGRESSIVE = (1 << 0), AIFLAG_NOMOVE = (1 << 1), AIFLAG_COWARD = (1 << 2), AIFLAG_NOATTACKSHINSU = (1 << 3), AIFLAG_NOATTACKJINNO = (1 << 4), AIFLAG_NOATTACKCHUNJO = (1 << 5), AIFLAG_ATTACKMOB = (1 << 6), AIFLAG_BERSERK = (1 << 7), AIFLAG_STONESKIN = (1 << 8), AIFLAG_GODSPEED = (1 << 9), AIFLAG_DEATHBLOW = (1 << 10), AIFLAG_REVIVE = (1 << 11), AIFLAG_HEALER = (1 << 12), AIFLAG_COUNT = (1 << 13), AIFLAG_NORECOVERY = (1 << 14), AIFLAG_REFLECT = (1 << 15), AIFLAG_FALL = (1 << 16), AIFLAG_VIT = (1 << 17), AIFLAG_RATTSPEED = (1 << 18), AIFLAG_RCASTSPEED = (1 << 19), AIFLAG_RHP_REGEN = (1 << 20), AIFLAG_TIMEVIT = (1 << 21), }; Here you can see many of new AIFlag values. I am not 100% sure about them, but here is what I think about these new values: AIFLAG_HEALER : This one is the healer, who will heal all members in its group. AIFLAG_COUNT : Who has this flag, you can make just 1 damage on it. AIFLAG_NORECOVERY : This will blocks the monster to recover its health. AIFLAG_REFLECT : <vice> With this flag the monster will be able to transform you into a monster, npc, or statue. AIFLAG_FALL : Ability to force you to fall off your mount. AIFLAG_VIT : <versa> Make your attack damage half, for 10 minutes, until the zodiac floor expires. AIFLAG_RATTSPEED : Reduces the speed of your attack. AIFLAG_RCASTSPEED : Reduces the speed of your skills, it means the cooldown of your skills will be increased. AIFLAG_RHP_REGEN : Reduces the regeneration of your health. AIFLAG_TIMEVIT : <versa> Make your attack damage half, for x seconds. About the vice-versa, those values are imaginable in switched description too. If the reflect is removing your attack damage with the half of it for x seconds then the VIT flags are the transformations. Forexample: the timevit is for tranforming you into monster, or mount for couple of seconds. the vit is for transforming you into a statue until the zodiac floor runs, or until one of your mate hits you. typedef struct SMobSkillLevel { DWORD dwVnum; BYTE bLevel; } TMobSkillLevel; typedef struct SMobTable { DWORD dwVnum; char szName[CHARACTER_NAME_MAX_LEN + 1]; char szLocaleName[CHARACTER_NAME_MAX_LEN + 1]; BYTE bType; BYTE bRank; BYTE bBattleType; BYTE bLevel; BYTE bScale; BYTE bSize; DWORD dwGoldMin; DWORD dwGoldMax; DWORD dwExp; DWORD dwMaxHP; BYTE bRegenCycle; BYTE bRegenPercent; WORD wDef; DWORD dwAIFlag; DWORD dwRaceFlag; DWORD dwImmuneFlag; BYTE bStr, bDex, bCon, bInt; DWORD dwDamageRange[2]; short sAttackSpeed; short sMovingSpeed; BYTE bAggresiveHPPct; WORD wAggressiveSight; WORD wAttackRange; char cEnchants[MOB_ENCHANTS_MAX_NUM]; char cResists[MOB_RESISTS_MAX_NUM]; char cElementalFlags[MOB_ELEMENTAL_MAX_NUM]; char cResistDark, cResistIce, cResistEarth; DWORD dwResurrectionVnum; DWORD dwDropItemVnum; BYTE bMountCapacity; BYTE bOnClickType; BYTE bEmpire; char szFolder[CHARACTER_FOLDER_MAX_LEN + 1]; float fDamMultiply; DWORD dwSummonVnum; DWORD dwDrainSP; DWORD dwMonsterColor; DWORD dwPolymorphItemVnum; TMobSkillLevel Skills[MOB_SKILL_MAX_NUM]; BYTE bBerserkPoint; BYTE bStoneSkinPoint; BYTE bGodSpeedPoint; BYTE bDeathBlowPoint; BYTE bRevivePoint; BYTE bHealPoint; BYTE bRAttSpeedPoint; BYTE bRCastSpeedPoint; BYTE bRHPRegenPoint; FLOAT fHitRange; } TMobTable; bScale: : Scale value between 50 and 200. It will resize the monster. cElementalFlags : So I've told you some info about this, I don't know more. cResistDark : This is a missing elemental resist, they have added it, I just don't really know why even there, not into the resists array, stupid. cResistIce : This is a missing elemental resist, they have added it, I just don't really know why even there, not into the resists array, stupid. cResistEarth : This is a missing elemental resist, they have added it, I just don't really know why even there, not into the resists array, stupid. bHealPoint : Healing percent for the healers. bRAttSpeedPoint : These can be used for what I've named them or the REFLECT or the VIT and TIMEVIT flags too, to give them special value, so it is still a questionmark. bRCastSpeedPoint : These can be used for what I've named them or the REFLECT or the VIT and TIMEVIT flags too, to give them special value, so it is still a questionmark. bRHPRegenPoint : These can be used for what I've named them or the REFLECT or the VIT and TIMEVIT flags too, to give them special value, so it is still a questionmark. fHitRange : Because the client is using its default value to make the checks, this one for sure is on serverside, to check the distance between the character and the monster to validate the attack, skill or the movement of the monsters. But still not 100% I hope it is understandable, my english isn't the best sorry for that. If I missed something let me know in PM.

else if (!m_pPacketInfo->Get(bHeader, &iPacketLen, &c_pszName)) { if (g_bAuthServer) LOG_IP("%s",inet_ntoa(lpDesc->GetAddr().sin_addr)); sys_err("Input: Unknown header:%d, Last header:%d(%d), Remain bytes:%d, fd:%d", bHeader, bLastHeader, iLastPacketLen, m_iBufferLeft, lpDesc->GetSocket()); lpDesc->SetPhase(PHASE_CLOSE); return true; } Or you can save all the ip that send unknown packets to auth/game. After about 1 - 5 minutes you will have all the ips of the attacker and you can block them in the firewall. Or if you use OVH you can use OVH_API to filter IPs through the mitigation system. This is the hotfix I used. ?

Hi! I downloaded the file but no gr2? So i think should use mde right? I had never use them, the process is the same for gr2?

LoadMotion: cannot find accumulation data in file 'data/monster/horse_event1/03.msa' LoadMotion: cannot find accumulation data in file 'data/monster/boar/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/dog_god/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/lion/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/boar/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/dog_god/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/lion/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/boar/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/dog_god/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/lion/run.msa' LoadMotion: cannot find accumulation data in file 'data/monster/horse_event1/03.msa' I will teach you only the rationale and after that you will be able to fix it in whatever file syserr gives. I will teach you only the rationale and after that you will be able to fix it in whatever file syserr gives. As an example, while driving the lion (wild, young, brave) mobs are loading late or never loading npc's / metin's disappears. Follow the steps for solution; Here we download the granny viewer and install it. In the pack folder, we find and opening patch2, eix and epk. We go to \ patch2 \ ymir work \ npc \ lion directory, and find "run.msa" and open it with notepad ++ run.gr2 We open it with granny viewer and go to "Animation List" tab. Right click on the animation file and press "View in detail" button. We click on the "click to view sub-structure" button opposite the void ** TrackGroups that opens. A window opens up and we'll add the value to our work here "granny_real32 Loop Translation" in the run.msa file we opened earlier. Now we go back to the run.ms file and add the following lines; Accumulation 0 -589.625915 0 The value from 0-589 that is written in the opposite direction will change to whatever is in your .gr2 file. We also apply it to the server side, so we go to / usr / game / share / data / monster / lion and change the run.msa to what we had previously done. As shown in the attachment; Explain why we are doing this: Accumulation is the speed value of the model animation. If we assign this value incorrectly or leave it blank, the model and animation will work independently of each other. If the client-side and server-side accumulation values match, you will see the animation at real speed. READY .MSM FILES VIRUSTOTAL GOOGLE TRANSLATE MADE THIS

I just finished a good script or not, that encrypts it's pack "eix, epk" for the official tool MakePack. Here is the Python script: import os import shutil PACK = "uiscript" os.system("_Junction -s "+PACK+" ../_MakePack/pack_source/"+PACK+"") with open(PACK+'.txt' , 'w') as fp: fp.write('FolderName "pack"n') fp.write('PackName "'+PACK+'"nn') fp.write('List ExcludedFolderNameListn{nt".svn"n}nn') fp.write('List ExcludedPathListn{nt"d:/ymir work/bin/"n}nn') fp.write('List ExcludedFileNameListn{nt"_MakePack.exe"n}nn') fp.write('List CSHybridEncryptExeNameListn{nt"py"n}nn') fp.write('List FileListn{n') for root, directories, files in os.walk(""+PACK+""): for filename in files: filepath = os.path.join(root, filename) fp.write('t"'+filepath+'"n') fp.write('}') fp.close() os.system("_MakePack.exe "+PACK+'.txt') os.system("_Junction -d "+PACK+"") source = os.listdir("../_MakePack/") destination = "pack_log/" for files in source: if files.endswith(".log"): shutil.move(files,destination) To succeed has encrypt your pack you must open the python file change this change line 4 PACK = "uiscript" in PACK = "The name of your PACK" Double clic file "_MakePack.py" and now it's over

simple just change size column from type "enum" to "set" I fix my db server just doing this sorry my bad english

Yes, if you walk to where there is no server_attr and you'll get kicked. (So walk around the very edge of the map) It will generate something i beleive "cannot find sectree/coordinates" But if the edges are all mountain so players can't go there, you'll only face by the slided attrs for pvp, water, block zones. (maybe the regen/npc/stone.txt spawns are also slided but i'm not sure)

MMORPG and multikill sounds