Leaderboard

M2 Download Center Download Here ( Internal ) Download Here ( GitHub ) Based idea: [Hidden Content] [Hidden Content] You can add control for specific skill ids ----------- Not tested very well. Let me know, if you found a bug.

SetEnemyVID --> if not chr.GetInstanceType(self.vid) == chr.INSTANCE_TYPE_PLAYER:

I actually think it's not, I am doing all the tests on a small VPS and I don't have this bug, I will do further investigations because it seems easy to reproduce but in fact I didn't manage to. However it's interesting me because it seems to be a common bug

M2 Download Center Download Here ( Internal )

M2 Download Center Download Here ( Internal ) Hi, here I publish my edit of the public Render Target System. I hate it, when people earn money with public systems. Preview: [Hidden Content] DL: [Hidden Content] Original Thread [Hidden Content]

M2 Download Center Download Here ( Internal ) Hi, As requested by some users i have you a VM with FreeBSD 9.2 32bit, novaline source and pre installed Ports so you can compile the game. It was like 10 minutes of work to enter the commands so no thanks needed. Link: HerpDerp Login: root Pw: dev To compile the game: cd /usr/src/novaline/Srcs/Server/game/src gmake clean gmake -j20 If there are any Problems or questsions you can add me in Skype(l337-5p34k) or Message me here i'll always give you support. Kind regards TheGame €: There are no Serverfiles on this VM because i dont have test serverfiles. If someone have Serverfiles for me i'll implement them and upload an updated version of this VM. €: Updated Link: Thanks to Da'Real Pain

Hi there devs, Its been a while since my last release and probably this will not change, but I had this guide in my head for like a year now. In my last ~2 years while I was working in the AE team various devs came and go, and this kind of guideline would have been a huge help and could prevent lots of errors. I have been in the dev scene for more than 10 years now and (as some of you may already noticed) one of my main interest has always been making more and more user friendly and complex UI objects/interfaces and along the road gathered tons of experience. You won't end up with another shiny system that you can use in your server this time by reading this article, but instead maybe I can prevent you from making windows that stays in the memory forever, opens infinite times, prevents other window's destruction, and many more. Who knows, maybe you will leave with some brand new never ever seen tricks that you can use in your future UIs. But first of all lets talk about some good2know stuff. UI layers Layers are root "windows", their purpose to hold all kind of interface windows while managing the z order of the windows (z order = depth level of the windows, which one is "above" the other). By default there are 5 layers (from bottom to top): "GAME": this is only used for the game window (game.py), and when you click on it the game will translate the click position to the map "UI_BOTTOM": this is used for shop titles "UI": this is the default layer, we would like to put most of our windows into this layer, like inventory, character window, messenger, pms, etc, so they can overlap each other "TOP_MOST": every window, that should always be in front of the player, so other windows would not overlap them from the lower layers, so for example the taskbar is placed in this layer "CURTAIN": this is for the curtain window, which is actually a black as a pit window, that is used to smooth the change from different introXX windows (like between login and charselect) This is the outest layer and goes before the other 4. So when the render happens, the 1st layer and its childs will be rendered first, then the 2nd layer, then the 3rd, etc, so by this we will get our comfy usual client layout. In the other hand, when we click, everything goes in reverse order, first the client will try to "pick" from the curtain layer's child windows (also in reverse order), then the top_most layer, etc. Ofc there is no layers beyond the game layer, so usually the "pick" will succeed there, and we will end up clicking on the map. UI windows Now lets talk a little bit about the parts of an UI window. It has a python object part and a c++ object part. When you create a basic Window (from the ui.py) basically 2 things happen: a python Window object is created first, then through the wndMgr.Register call a c++ CWindow object is created. These 2 objects are linked, in python the handle for the CWindow is saved in the self.hWnd variable, while in the CWindow the python object handle would be stored in the m_poHandler. What are these handles for? If you want to call a method on a window from python, you have to specify which window you want to perform that action on. Remember, the python part is just a "frontend" for the UI, the actual magic happens in the cpp part. Without python, its possible to create windows, but without the cpp part there is no windows at all. On the cpp part, we need the python object handle to perform callbacks, like notifying the python class when we press a key, or pressing our left mouse button. By default the newly created window will take a seat in one of the layers (if provided through the register method, otherwise it goes to the UI layer). In a healthy client we only put useful windows directly into a layer. For example you want to put your brand new won exchange window into the UI layer, but you don't want to put all parts of a window into the UI layer (for example putting the base window into the root layer then putting the buttons on it to the root layer too, then somehow using global coordinates to make it work). Instead, you want to "group" your objects, using the SetParent function. You may say that "yeah yeah who doesn't know this?", but do you know what actually happens in the background? The current window will be removed from its current parent's child list (which is almost never null, cus when you create it its in the UI layer, so the parent is the UI layer) and will be put into the end of the new parent window's child list. Why is it important, that it will be put into the end? Because it will determine the Z order of the childs of the window. For example if I create 2 ImageBox with the same size of image on the same position and then I set ImageBox1's parent before ImageBox2's parent, then I will only see ImageBox2, because that will be rendered after ImageBox1, because its position in the childList is lower than ImageBox2's. For normal window elements (like buttons) its very important, because after you set the parent of a window, you can't alter the z order (or rather the position in the childList) unless you use the SetParent again. No, you can't use SetTop, because its only for windows with "float" flags on it, which you only want to use on the base of your window (the root window that you put your stuff on it and use it as parent for most of the time). Window picking "Picking" is performed when we move the cursor. This is an important method, because this will determine the result of various events, for example the OnMouseOverIn, OnMouseOverOut, OnMouseRightButtonDown, etc. To fully understand it, you must keep in mind that every window is a square. Do you have a perfect circle image for a button? No you don't, its a square. Do you have the most abstract future window board design with full star wars going on the background? No, you DON'T. ITS A SQUARE. By default, a window is picked if: the mouse is over the window AND the window is visible (Shown) AND the window doesn't have "not_pick" flag set AND the window is "inside its parent's square" on the current mouse position, which means if the parent's position is 0,0 and it has a size of 10x10 and the window's position is 11, 0, the window is outside of its parent's square. This is really important to understand, lots of UI has fully bugged part because of ignoring this fact. I think every one of you already experienced it on some bad illumina design implementation, when you click on a picture, and your character will start to run around like a madman, because the game says that A-a-aaaaa! There is NO WINDOW ON THAT POSITION It is useful to use the not_pick flag whenever you can, for example on pure design elements, like lines and flowers and ofc the spaceships on the background. Lets say you have a size of 10x10 image that has a tooltip, and you have a window on it that has a size of 5x5. When the mouse is over the image, the tooltip will be shown, but if its over the 5x5 window, the tooltip won't appear, unless you set it to the 5x5 window too. But if you use the not_pick flag on the 5x5 window, the 5x5 window won't be picked and the tooltip would be shown even if the mouse is over the 5x5 window. Window deletion, reference counting, garbage collector, proxying The window deletion procedure starts on the python side, first the destructor of the python object will be called, then it will call the wndMgr.Destroy that deletes the c++ object. By default, we have to store our python object, or this time our python window, to make sour it doesn't vanish. Usually we do this via the interface module, like "self.wndRandomThing = myModule.RandomWindow()". But what is this? What is in the background? Python objects has reference count. Let me present it with the following example: a = ui.Window() # a new python object is created, and its reference count is 1 b = a # no new python object is created, but now b is refering to the same object as 'a', so that object has a refence count of 2 del b # b is no longer exists, so its no longer referencing to the newly created window object, so its reference count will be 1 del a # the newly created window object's reference count now 0, so it will be deleted, calling the __del__ method To be more accurate, del-ing something doesn't mean that it will be deleted immediately. If the reference count hits 0 the garbage collector (btw there is garbage collector in python if you didn't know) will delete it, and that moment the __del__ will be called. It sounds very handy isn't it? Yeeeeah its easyyyy the coder don't have to manage object deletion its sooo simple.... Yeah... But lets do the following: class stuff(object): def __del__(self): print "del" def doStuff(self): self.something = self.__del__ # here we could just simply do self.something = self too, doesnt matter a = stuff() a.doStuff() # and now you just cut your leg del a #you are expecting the "del" print, but that will never happen You may say " ? oh please who tf does something stupid like this? It SO OBVIOUS that its wrong whaaaaaaat????" But in reality, I could count on only one of my hand how many devs don't make this mistake. Even my codes from the past decade are bad according to this aspect, since I only realized this problem about a year ago, when I was working on the AE wiki. Even the yimir codes contain tons of this kind of errors, however there was definitely a smart man, who implemented the __mem_func__. Okay, I see that you still don't understand how is this possible to make this kind of mistake, so let me show you a real example: class myBoard(ui.Board): def __init__(self): super(myBoard, self).__init__() self.makeItRain() def __del__(self): super(myBoard, self).__del__() print "I want to break free. I want to breeaaaaaak freeeeeeeeeeee" def doNothing(self): pass def makeItRain(self): self.btn = ui.Button() self.btn.SetParent(self) self.btn.SetEvent(self.doNothing) #boom a = myBoard() del a # but where is the print? Thats not that obvious now right? What happens here? We create a myBoard object, which in the __init__ calls to the makeItRain func, which stores an ui.Button object, and sets the button to call for the myBoard class's doNothing function with the self object pointer in the OnLeftMouseButtonDown function, which means that the reference count will never be zero, because the btn referenced in the myBoard but myBoard is referenced in the btn but the btn is referenced in the.... so you know, its a spiral of death, that our best friend garbage collector can't resolve. Okay, but how to do it correctly? Lets talk about proxying. In python, proxies are weak references, which means that they don't increase reference count of an object, which is exactly what we need. #let me show this time the console output too class stuff(object): def __del__(self): print "del" >>> from weakref import proxy >>> a = stuff() #newly created object >>> b = proxy(a) #create weak reference to the new object (note that the weak reference object is also an object that stores the weak reference) >>> b #what is b? <weakproxy at 02DB0F60 to stuff at 02DBFB50> # b is a weakproxy object that refers to a which is a "stuff object" >>> del b # what if we delete b? # no "del" message, the stuff object is not deleted, because its reference count is still 1, because its stored in a >>> b = proxy(a) # lets recreate b >>> del a # now we delete the only one reference of the stuff object del # and here we go, we got the del message from __del__ >>> b # okay but whats up with b? <weakproxy at 02DB0F60 to NoneType at 7C2DFB7C> # because b is a weakproxy object, it won't be deleted out of nowhere, but it refers to a NoneType right now, because the stuff object is deleted (also note here that NoneType is also a python object :D) >>> if b: #what if I want to use b? ... print "a" ... Traceback (most recent call last): File "<stdin>", line 1, in <module> ReferenceError: weakly-referenced object no longer exists # in normal cases no need to trycatch this exception, because if we do everything right, we will never run into a deleted weakly-referenced object But how do we proxy something like self.doNothing? Actually, what is self.doNothing? self.doNothing has 3 parts: The first part is not that obvious, it has a base class pointer, which is points to myBoard. It has a class object pointer, that is basically "self". It refers to the current instance of myBoard. It has a function object pointer, called doNothing, which is located inside the myBoard class. And now we can understand ymir's ui.__mem_func__ class, which is exactly meant to be used for proxying class member functions: # allow me to reverse the order of the definitions inside the __mem_func__ so it will be more understandable class __mem_func__: def __init__(self, mfunc): #this happens when we write ui.__mem_func__(self.doSomething) if mfunc.im_func.func_code.co_argcount>1: # if the doSomething takes more than one argument (which is not the case right now, because it only needs the class obj pointer (which is the 'self' in the 'self.doSomething')) self.call=__mem_func__.__arg_call__(mfunc.im_class, mfunc.im_self, mfunc.im_func) #lets unfold the python object to the mentioned 3 parts else: self.call=__mem_func__.__noarg_call__(mfunc.im_class, mfunc.im_self, mfunc.im_func) #this will be called for the 'self.doSomething' def __call__(self, *arg): # this line runs whenever we call apply(storedfunc, args) or storedfunc() return self.call(*arg) class __noarg_call__: # this class is used whever the python object we want to proxy only takes one argument def __init__(self, cls, obj, func): self.cls=cls # this one I don't really get, we won't need the class object later also its not proxied, so its probably here to prevent delete the base class in rare cases self.obj=proxy(obj) # here we proxy the object pointer which is what really matters self.func=proxy(func) # and then we proxy the class func pointer def __call__(self, *arg): return self.func(self.obj) # here we just simply call the class function with the object pointer class __arg_call__: def __init__(self, cls, obj, func): self.cls=cls self.obj=proxy(obj) self.func=proxy(func) def __call__(self, *arg): return self.func(self.obj, *arg) # here we just simply call the class function with the object pointer and additional arguments Pros, cons, when to, when not to, why? Now you may ask that "Okay okay that sounds good, but why? What can this cause, how big the impact could be, is it worth to even bother with it?" First of all, you must understand that this is kinda equal to a memory leak. I would actually call these non-deleted windows as "leaking windows". Every time you warp, new and new instances will be generated from those objects, and ofc, one instance of a window means like about +50/100 instances, depending on the window complexity, how much childs it has. Usually these windows are at least remain in a Hide state, and hidden windows don't affect update and render time, but they will remain in the root layer, and may stack up depending on how much time the player warp. Still, the number of leaking root windows / warp is around 50-100, which is really not much for a linked list (the type of the childList). However, the memory consumption is much greater. One year ago AE had 10k leaking windows growth / warp. One base class (CWindow)'s size is 140 bytes, which means the memory growth is at least 1,3MB/warp and it does not contain the size of the python objects size for those windows, the linked_list headers and other necessary stuffs. After some hour of playing this can easily reach 100+MB of leaking memory. On worse cases the old windows are not even hidden, and on rewarp players may see multiple instances of the mentioned windows, like double inventory, double messenger window, etc. In this cases those windows can affect the render and update times too. Pros: your code will now work correctly regarding to this topic you may gain some performance boost you may find stuff in your client that even you don't know about you may find enough kebab for a whole week you can save kittens by removing leaking windows and proxying objects you can build my respect towards you and your code and you can even calculate the actual number using the following formula: totalRespect = proxysUsed * 2 + ui.__mem_func__sUsed - proxysMisused * 3.511769 - ui.__mem_func__sMisused * pi - 666 * ui.__mem_func__sNotUsed Cons: depending on how bad the situation is and how skilled you are, the time needed to find and fix everything could be vary, from few hours to several days if you are satisfied with your client as it is right now there is not that huge benefit regarding how much time it could take to fix all the windows Detecting leaking windows DON'T BLOCK THE BACKEND!! At first glance python code looks like you are invincible, you can do whatever you want, you are not responsible for the performance because python has a bottomless bucket full of update/render time and if the game freeze sometimes its definitely not your fault, the game is just BAD. Lets talk about OnUpdate and OnRender, whats the difference, when they are called, what to and what not to put in there. So as their name implies, they are called from the binary every time it performs an Update or Render action. In Update, the binary performs non-rendering actions, like updating the positions of walking characters, updating window positions, and every kind of calculation that is necessary for a render action, to make every kind of data up to date, reducing the cpu operations required for render as much as possible while keeping track of the time. In Render, the binary performs non-updating actions, calling only directx device rendering methods that builds up a picture of the current world, including the UI, using the current, up to date positions. If you try to count the number of stars in our galaxy to accurately simulate your star wars going on in the background of your inventory window, no matter where you do it, (render or update) you will start hurting the game. For example if you have an ui with tons of elements, generating all the elements under one tick can cause HUGE client lag. In my AE wiki, I only load one or two entity for the current page under an update tick, so it will still load quickly, but won't block the game. Notice that doing something like this is an UPDATE operation. Lets be nice and don't interrupt our rendering whit this kind of stuff. You should only use calls to render functions inside the OnRender, for example like in the ui.ListBox class, where we actually ask the binary to render a bar into our screen. Around 20% of time spent in an Update tick was consumed by the UI update (calling to a python object through the api is kinda slow by default) in the AE client one year ago. Removing the rendering and updating of the gui for testing purposes actually gave a huge boost to the client, so who knows, maybe one day someone will make a great client that runs smooth on low end pcs too. Answer the api calls if expected! Some calls from the binary like OnPressEscapeKey expects a return value. Of course if no return value is provided the binary won't crash, but can lead to weird problems and malfunctions. For example, the OnPressEscapeKey expects non-false (non-null) if the call was successful on the window, so it will stop the iteration from calling to lower level windows. So if you expect from the game to close only one window per esc push, you have to return True (or at least not False or nothing). There was a crash problem related to this in one of my friend's client recently. In his ui.EditLine class the OnPressEscapeKey looked something like this: def OnPressEscapeKey(self): if self.eventEscape(): return True return False In the original version it just return True unrelated to the eventEscape's return value. This looks fine at first glance, but if for some reason the self.eventEscape doesn't return anything and if (like the garbage collector decides to run or its disabled) the layer's or the parent's child lists changes in the binary because one or more windows are destroyed under the OnPressEscapeKey procedure and the iteration trough the child list is not interrupted, the binary will start to call invalid addresses thinking that they are existing windows, calling OnPressEscapeKey on them, resulting hardly backtraceable crashes. Closing words I can't highlight out enough times how much I like and enjoy creating new kind of UI stuff, (like animating windows that you may saw on my profile recently (click for the gif)) and because of this if you want to discuss a theory about new UI stuffs or mechanics of already existing UI stuffs feel free to do it in the comment section instead of writing me a pm to help others. Also this time (unlike for my other topics) I would like to keep this guideline up to date and maybe adding new paragraphs if I find out another common mistake/misunderstanding. DEATH TO ALL LEAKING WINDOW!!!!!4444four

M2 Download Center Download Here ( Internal ) VirusTotal: [Hidden Content] Hi ! Today ThunderCore Society will offer you a special tool for Granny3D Models. Note: That tool isn't for begginers and we don't offer suport for that. We hereby inform you that we take the copyrights file and his contents because ThunderCore Society has paid to perform this work. Attention: NonCommercial — You may not use the material for commercial purposes. NoDerivatives — If you transform, or build upon the material, you may not distribute the modified material. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits. Kind Regards - Johnny White

M2 Download Center Download Here ( Internal ) [Hidden Content] Enjoy.

M2 Download Center Download Here ( Internal ) Hi there. While cleaning out "my closet", I found this thing I developed between 2014-2015 - maybe(?) - for my, at that moment, server. Since it's now closed, and I won't use it, I'm sharing it with you guys. Note: Didn't do the scrollbar, wasn't needed for me, so yeah. Now, let's start with opening your locale_game.txt and adding these lines: QUESTCATEGORY_0 Main Quests QUESTCATEGORY_1 Sub Quests QUESTCATEGORY_2 Collect Quests QUESTCATEGORY_3 Levelup Quests QUESTCATEGORY_4 Scroll Quests QUESTCATEGORY_5 System Quests Alright, now find your characterwindow.py (uiscript?) and you can either comment Quest_Page children or simply remove them all. Moving on to your interfaceModule.py find this line self.BINARY_RecvQuest(index, name, "file", localeInfo.GetLetterImageName()) and replace it with self.wndCharacter.questCategory.RecvQuest(self.BINARY_RecvQuest, index, name) Ok, then we are at the most, let's say, difficult part of this. Open your uiCharacter.py and just as you did in your characterwindow.py, remove or simply comment any single line related to quests. You can just search for these vars: self.questShowingStartIndex self.questScrollBar self.questSlot self.questNameList self.questLastTimeList self.questLastCountList Once you did that, you just: # Find these lines self.soloEmotionSlot = self.GetChild("SoloEmotionSlot") self.dualEmotionSlot = self.GetChild("DualEmotionSlot") self.__SetEmotionSlot() # And add the following import uiQuestCategory self.questCategory = uiQuestCategory.QuestCategoryWindow(self.pageDict["QUEST"]) # Find this def OnUpdate(self): self.__UpdateQuestClock() # Replace it with def OnUpdate(self): self.questCategory.OnUpdate() And we're done with the client-side. I attached some extra elements needed (such as the main python file (uiQuestCategory.py) and some image resources). Remember to edit the path linked to these images in that file. For the server-side... Well, screw it, uploaded it too. Too lazy to write. It has only a new quest function (q.getcurrentquestname()) and a few things to add in your questlib.lua. Btw, not sure if you have it, but if not, just add this extra function in ui.Button() (ui.py - class Button). def SetTextAlignLeft(self, text, height = 4): if not self.ButtonText: textLine = TextLine() textLine.SetParent(self) textLine.SetPosition(27, self.GetHeight()/2) textLine.SetVerticalAlignCenter() textLine.SetHorizontalAlignLeft() textLine.Show() self.ButtonText = textLine #Äù½ºÆ® ¸®½ºÆ® UI¿¡ ¸ÂÃç À§Ä¡ ÀâÀ½ self.ButtonText.SetText(text) self.ButtonText.SetPosition(27, self.GetHeight()/2) self.ButtonText.SetVerticalAlignCenter() self.ButtonText.SetHorizontalAlignLeft() Forgot the source part, fml, here it is. Add it to your questlua_quest.cpp. int quest_get_current_quest_name(lua_State* L) { CQuestManager& q = CQuestManager::instance(); PC* pPC = q.GetCurrentPC(); lua_pushstring(L, pPC->GetCurrentQuestName().c_str()); return 1; } void RegisterQuestFunctionTable() { luaL_reg quest_functions[] = { { "getcurrentquestname", quest_get_current_quest_name}, { NULL, NULL } }; CQuestManager::instance().AddLuaFunctionTable("q", quest_functions); } Now, finally, have fun and bye!

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.

Problem solved There're a few bool functions that weren't returning anything, neither false or true. But since their value was never used, they were only called outside of if's I passed them all to void and the few return false changed to return. My compiler wasn't giving error about bool functions not returning a value. About this, anyone has any idea? EDIT: Added this to my CFLAGS: -Werror=return-type

Sure. [Hidden Content] ymir work\effect\etc\soul\

For me it is a waste of time, at the moment I will ignore this problem .. I will look for a solution in the near future if there will be .. Until then, thank you all for your contribution. Good luck to everyone!

Check again

[Hidden Content]

NextUpdate will include Hair [Hidden Content] UiToolTip-Fix_2.0.txt UiToolTip-Fix_3.0.txt 2.0 -> Rüstung Costüme/Waffen 3.0 -> Hair bug Fix + On/Off Render Target on Gameoptions

M2 Download Center Download Here ( Internal ) Hi everyone! So, after serveral days of searching a tool that could change the texture path of a .gr2 file, I found the tool(probably all of you know it, the texture changer by marv). After that I tried to change the texture paths of some gr2 models of a weapon, and guess what, it didn't work. I'm gonna reupload the file, because I didn't seen it on metin2dev, and I'm gonna teach you how to use it. First of all, I don't know about others, but for me it didn't work to change anything with this (I'm running windows 7 x64 bit). Some of guys told me that this "texture changer" works only on windows 7 x86 bit, so I reinstalled my windows(I really needed that tool), of course, it didn't work either way. So, go in Start and search cmd, and run it. After the cmd started you'll see a path right there C:\Users\Name (Instead of Name you'll have your username of computer administrator, or the account you're logged in), now that's the path where we can work with the tool. PAY ATTENTION!!! IF YOU START THE TOOL IN OTHER FOLDER INSTEAD OF C:\Users\Name THE TOOL WILL NOT WORK, AND YOU WILL NOT BE ABLE TO SAVE THE NEW MODEL. Exctract all the files from the archive(I'll post it below), and start Metin2TextureChanger.exe. Now click "Load" to choose a gr2 file you want to change texture path, BUT, the model name can't have spaces in name(devil sword.gr2 for example, it's wrong, the tool won't read it, and you'll not be able to save your new gr2 model), so if you want to change for example devil sword.gr2 you need to rename it into devil_sword.gr2 or devilsword.gr2 or any other name without spaces betwen. Where is "Neuer Texturpfad" we will chose the new path for texture, for example d:\ymir work\test\devil_sword_blue.dds , there you can choose any other path, but you can't modify "d:\ymir work" or you won't be able to see the weapon/armour in-game. Now we save the file wherever we want, it doesn't matter, this way must work for everybody. AGAIN, THIS TOOL WASN'T MADE BY ME. And I made this post because I've searched many days a tool that would work, but neither didn't work, and this tool didn't work for me either just when I used this method. So, this post is for guys who had the same problem like me (they had the tool, but couldn't save the new model) that's why I wanted to help them, and any other people who weren't been able to use it. And about the other tool I've found on this forum, the tool "made" by thunder-core, I didn't find that tool satisfying, it worked, but after the new model was made, I wasn't been able to import it in 3d max, or to convert the model from file format revision 7 to 6. So you were basicaly forced to upgrade your client to granny 2.9, and I found that inconvenient, because, I don't know about others, but I don't use source for binary, and because of that it's imposible to see the model in-game. And of course, the new model you've created, with the tool in attachement, is revision 7, so you need the new granny if you want to see it in-game, but you can use the converter from archive to convert from revision 7, to revision 6 (old), and you'll be able to see it in-game. If you already see it in-game, you don't need to use the converter. If you found this post helpful I'm glad I could help you.

M2 Download Center Download Here ( Internal ) Hello There. I publish here this system i hope that this help you a bit with this you can hide your costume if you dont like it (if I forgot something just say it ) (this system is not complete yet you can hide only your costume no hairstyle,sash,weapon) (This system is not mine! i just found the source function and made the python codes and quest)

M2 Download Center Download Here ( Internal ) Download scan granny 2.9 video(before n after):

Thx, but check this [Hidden Content] and scroll?

delete your player_deleted table,copy structure of player table and remane it to player_deleted

M2 Download Center Download Here ( Internal )

Your base source is mainline from kraizy.tgz? So that we can use it as research

Version of Files : XXX Hello I would like to build (just for fun) a Metin2 GF bot/hack. But I don't have any kind of experience with these kind of things (metin2 client injection... etc.). So I would need some guidance. First of all, if there is any forum posts about this, I'm sorry but I couldn't find it, so please share it with me. I will try to ask some question, and hopefully the answers can put me on the right track. 1. how can you inject or manipulate the values from the metin2 client ? 2. there is any library/framework already made, that can help me with this? 3. for what kind of stuff is the Metin2 Cheat Blocker looking for while the game is running? Thanks