masodikbela

I think noone ever did anything like that in the mt2 scene what you are looking for right now. As others said probably the best way to start is to start analysing and understanding other already finished stuff, and modifying things inside them, what will happen, etc... Yes sometimes you will learn bad things or wrong things with this method, but if you do it long enough you will recognize them sooner or later. If you are looking for some other type of information, like how does this or that works (mostly in theory, so you need those type of information like I usually write in my comments) I'm your type of guy, so feel free to ask me, and if I have the time and mental power I won't hesitate to write long long explanations.

However I can't blame gameforge because of everything. They are only a publisher of the game. So we have webzen as the developer, they decide what to code and what patch to give for the publishers. Publishers don't even have a say about it. So if webzen gives a patch with 6th 7th bonus, publishers can decide if they put the patch to live, or no. They can't undo this. They don't even have source or anything. I was doing a research some weeks ago if its possible to get a license from webzen, and if so will you have the right to change the game the way you would like to, and (I didn't talk to anybody nor contacted anybody, only read the available documents and stuff) I realized that no, its not possible. So currently we have 2 companies with license to metin according to webzen's homepage: Ongame (in brazil) and Gameforge (in europe). Yes, thats true that gameforge is still full of crap, and they are doing questionable things like this copyright strike, but still I can't blame them for everything. Not sure if they do or do not care about the feedbacks, or just webzen pisses off the players needs.

Okay, it feels like now you think I'm the bad ugly dev here, because I refused to share or sell this stuff here despite I having it for more than a year. Moreover you took my detailed review about this fix as a personal attack. Let me clear some stuff here (I hope you manage to chill by the time you are reading this). I wrote my answer without any hate or anything. Yes, like I said it felt a bit bad for not leaving any credit for the idea at least with a 1pt textsize that nobody can see but still there. My goal was to tell you the technical problems with your changes. I wrote nothing but the truth. Its always sad to see when someone ignores my technical advises but its more sad when someone misunderstands my intent. Truth sometimes painful but its always necessary. I could have write that "ahh man its even better than my solution, thank you very much, sorry for not telling you and releasing my version". Would it help? Not sure. Did the stuff I do help? In long term I'm sure, but even in short term you changed that now all the motions load correctly, so I guess it did worth. You were asking in the first comment for help and discussion, to improve your solution. I was hoping that my comment will serve this purpose. I wrote even more detailed in some topics there because you said that you are not a programmer. (I would have wrote it anyway because I know that there are not much people out there knowing about pooling and stuff.) I've stopped releasing stuff long time ago, because it felt like giving fully ready stuff under people butts are moving the community and the devs in the wrong way. I've realized that there are no or not much professional devs out there because they are not trying to dive into deep inside stuff and they are doing it because of the money only. So I was thinking what could I do for this community to change this, or help changing this so we could get other more professional devs, and making some competition for the other pros out there. I came to this conclusion that if I explain stuff like this or stuff like the rect clippin would probably impel others to get some experience. There is another reason why I didn't published this particular one is that I made this for a server as a freelancer under a contract, which says I can't share or sell stuff I made for them. Also (and I'm writing this only to inform you, so no hate or anything still) that removing contents are forbidden on this forum.

Not sure if you guys noticed, but its not only private servers. Its all type of content related to "Metin2". You cant upload video even from official servers if you are not an approved youtuber by GF. https://corporate.gameforge.com/games/letsplay/?lang=en I just simply don't understand the logic behind it...

The original topic got updated/changed over time but I will not update this comment, so its normal to feel confused while reading it. I've run through the method you chose, and I have some notes about them. c_Reference_Decrease_Wait_Time is unused right now, because the client is not using other thread for background loading by default, so m_RequestMap will be empty always, so ms_loadingThread.Fetch(&pData) will return false always. Moreover, the whole ProcessBackgroundLoading function is unused right now, since it only do things if the mentioned background stuff is enabled. Editing g_iLoadingDelayTime in that file is probably pointless, since it will be overwritten by the config file. You should remove that option from the metin2.cfg. Editing __DestroyCacheMap is pointless aswell, since it will only run when you close the client. Also I would put a very very big red exclamation mark here, since you commented out m_pCacheMap.clear(). In theory (ofc it will never happen because the function runs only when you close the client so nobody will give a fck about that cache map anymore) this could lead to huge crashes since in CReferenceObject::Release a deallocation could happen (its possible that it won't, because its possible that at that point something is using that actual file for some reason, so the reference count will still be higher than 1). And after that since you don't clear the cache map, the next time when the system would try to use the cache map, it would receive a corrupt memory address, since we deallocated the object from that address. So anyway if you still want to make sure that nothing will call that function, just put a return to its beginning. About the last edit: I would put an even bigger red exclamation mark there. This requires some further explanation tho, so get ready for it. So first of all, let me talk about memory pools. So as you may know, our processors work better (talking about performance) if the memory addresses are close to each other. Also it works even better, if the affected memory block it needs to read is inside its cache. Also, allocating/deallocating memory runtime is an expensive operation. So long ago programmers came up with an idea: Lets allocate a big chunk of memory when we start our program, so we can put our instances inside it, so the data will be in one place close to each other, and we don't even have to bother with allocation and deallocation. So memory pooling was born. Now that we know this, lets talk about the implementation of CDynamicPool. So as you can see, we have 2 vectors inside it. m_kVct_pkData and m_kVct_pkFree. The first one contains all the ADDRESSES of the given object's instances (even if they are not used at the moment). The second one contains ADDRESSES of those objects that are no longer in use. (As you can see it contains ADDRESSES, so this type of implementation does not solve the problem with the "data in one place" problem, because its possible that we will get an address far far away from the previous one, but its irrelevant right now.) If you take a closer look, you will see new operator, but you won't see delete operator. (This is a possible memory leak factor tho, but since you don't remove those memory addresses from the union of those two vectors, its not the case in reality.) Moreover, if you check the Free function, you will only see that we just simply put an address to the pkFree vector. It means, that the destructor of the given object will not get called. (This could and probably do (in some cases) lead some actual memory leaks, but again, this is not what I want to talk about right now.) Okay, now lets say that we have 2 allocated instances, so we have 2 already-in-use addresses in pkData vector. Lets say that one of them gets "deleted". The Free function will put its address to the pkFree vector. Then, we say that uhhhh ummmmm wait wait, I need a new instance. Okay, we call Alloc. Lets see what will happen: pkFree is not empty, so it will not allocate a new instance, just simply gives the last free address back from pkFree. Looks safe and simple right? Yes, thats the case if you are aware that NO CONSTRUCTOR WILL BE CALLED THERE. Whats the problem with it you may ask... The problem is that we didn't change the content of that instance during this Free and Alloc call. (Sure if we've called some cleanup function outside of the CDynamicCache this is not the case like I said, but then it means you were aware of this problem.) So what you did when you commented out that pMotionModeData->MotionVectorMap.clear(); part was removing this correct cleanup. So what could happen (at least in theory)? Lets say we have a male warrior. This male warrior go away and all the data gets deleted after 4 hours, and you just simply stand still and no other characters appear. The game will remove the unused motions from the CDynamicCache. Then suddenly out of nowhere someone summons a wild dog. It will receive the same exact stuff from the pkFree vector that we just removed. So that wild dog will have 240+ motions loaded instead of 4 or something like that. Sadly we can state that our new wild dog won't run with the male warrior's animation, since in NEW_RegisterMotion that animation will be overwritten, so there will be no visual defects. I'm not sure about the chrmgrRegisterMotionData changes, but probably those don't add much to the final result. My opinion is that changing c_Deleting_Wait_Time to a much higher value was the only thing you did and actually helps in this problem. So basically what you did was: You changed that the unused files don't get deleted over time (or just after 4 hours), which means that in this specific case if you go to somewhere alone, and no other player appears for 4 hours (instead of the original 30 second) and after that someone with other type of character (so you are a warrior and the other player is not a warrior) appears, you will still have the same lag like before. Conclusion: Disregarding the wrong/useless parts, it doesn't solve the main problem. In the gif you shared its clearly visible, that not all the motions load during the loading screen. Example (what you should see) for female assassin (241 motions in total): Because of this, when you login the first time, and you meet a different type of character, you will still have the same lag as before. (The first time I had some doubts in myself tho, so I tested this one to be sure, and I was right, so this is the case.)

Its a built-in feature for clang, and if you are using clang you just have to pass a few more arguments for the build. (I think its working/integrated with gcc too, but I'm totally not sure about this since I always used clang and barely worked with gcc) I'm using a very default settings for ASAN, the related arguments are: CFLAGS += -fsanitize=address -fsanitize-recover=address -fno-omit-frame-pointer If you have ASAN enabled you must note that it will use much much more memory (like 2-3 times as much as usually) the program will always abort/crash on the first anomaly. Its necessary since if it continues there would be a chance that it would produce false results... this could be annoying sometimes if there are more bad parts in your code, cous it could happen that you want to fix x, but you have to fix y, z, i, j, k before, even if they are not related to your main problem. the program will not generate core dump, instead it will write the result to the stderr, so you might want to run the program without vrunner and detour the output to a file (instead of writing it to the console) I can't help with valgrind since this is the first time I heard about it. @Sherer Thats not true for the affect pool. Its enabled by default, because its #ifndef DEBUG_ALLOC not #ifdef DEBUG_ALLOC.

I would recommend you to try building your cores with ASAN (address sanitizer) enabled. I can't promise anything, but it can help you in desperate times... I remember having the weirdest crashes when AE opened. There was some heap-use-after-free error related to our multilanguage and battlepass systems that we would never been able to find without ASAN. (I don't think this is the case right here, just wanted to mention it as an example.) I think its worth a try. There are some nice article about it on the internet so I'm sure you can manage it, but if you have some questions about it I will try to answer them (despite I'm not an expert user of it).

I guess this is what you are searching for. I recently used this technique in my new wiki (ignore the cursor, its position is fucked up in the gif): [Hidden Content] The trick is exactly what you were thinking in your post above: First, you need a main window. We set this window's size to exactly as big as we need. Then lets make another window inside it, and make it as big as we need to store all elements we need in it. Then when you scroll we just have to move this inner window. But... you have to create a function (obviously this is the hard part of it) that handles the inner window. So basically it hides those parts of the window that is outside of the main window. I've seen some different implementation already, where they did this python side using the SetRenderingRect function, but I would avoid that (like I did) cus it would make the whole code a mess. Instead, I would recommend you to modify the render functions directly. What I did was: created a new bool "isInsideRender" which I can set if the window need to check if its outside from its parent created a RECT "render box" where I store how much is the current window is outside from its parent window modified the necessary functions like set size, set position, etc, where I update the render box if the isInsideRender is set modified the necessary windows (image box, textline) renders to render only the visible parts of the window according to the stored data in the render box Obviously I won't release it (sadly) like I didn't do it in the past ~1 year, but if you have some more questions about it (which is not like "can you show me the exact code") I'm here to help.

Ahh was a bit late yesterday and somehow I missed it totally ? sorry you are right...

You should check if the thread is already joined, or just simply check if you already called Quit, cus db is crashing at the very end of the process, because quit is called from the db too (and also from the destructor of CAsyncSQL).

You can't. Originally it was made this way because using sql queries in quest was too expensive... This whole thing is outdated right now so it would be better to refactor this system.

You can disable the shadows cus as far as I saw that consumes the most... however the whole rendering thing is old and not well optimized, also it could be that I made mistakes in this solution and it could be improved too, but I think the real problem is the rendering itself... Btw the fps in metin is capped at 60 and I had somewhere between 40 and 60 with this on the original map1s(cus the map can also be the problem for your low fps). So in short: no I don't plan to improve it...

Because of obvious reasons I described at the beginning of the topic... Like rendering everything would use more resources than rendering things around your character...

Did you enabled it here?

Maybe I forgot to mention that you have to change the foglevel in the constinfo... For me:

Well if you do the first step, the client will load the whole map into the memory. This would increase the memory usage a little bit but would increase the performance too. Ofc even if the full render is disabled, this can't be disable because like you said I erased the garbage collector. But I think its not that big change, should not cause any problem even on low spec PCs, no need to worry about it.

I haven't thinking about it before so no, but I guess it has a purpose, for example rendering static shadows is way more easier and costs less processing time than rendering dynamic shadows...

The loaded terrains and objects should be cleared when the bool CMapOutdoor::Destroy() is called, which should happen every time when you change map. If you want to make sure if its working as its intended, you can put a MessageBoxA into that function, and it will appear when its called.

Here you are @alondark @K3zX:

Hi there devs, Okay, so after reading the title you may (or may not) have some thougts/questions like "Hollllllllly sh..", "Oooookay..." or just "?". About one or two years ago a mapper questioned me: "Is this possible, to make the whole map visible? Like in normal games? This fog is sooo disgusting, I've could create more beautiful view with a normal fog..." I've tried to do it many ways until finally after some sleepless night I've made it about a year ago. Once it was done I didn't know what to do with it. It was pretty good (I think) but since I'm not a mapper I can't do anything with it. I could have sell it, but since there is no way to protect this code its not an option for me, so I've decided to share it with the public. This TuT gonna be a bit long and there are several things to discuss but FIRST lets watch this video (in the first part I disabled the fog). "Wow, thats actually not bad" this was my first reaction when I first saw this view. BUT enough from me, lets talk about more important things... So I decided to create stages for this tutorial (4 stages actually). Its a normal down-top thing, so it means that you can do stage 1, 2 and then you can stop, but can't do stage 2 without 1, 3 without 2 and 4 without 3... it will help you to customize these modifications. Also I may write some "interesting" (at least for me) notes/thoughts for each stages. However, as you will see the last 2 stages are not ready at the moment, so I would rather say its an experimental release... Anyway, before we start to implement this lets talk about the tests, performance and other more or less important things. Table of content: Stage 1: Removing garbage collectors, loading all map related things into memory ("chunks", objects, etc...) Stage 2: Rendering full terrain Stage 3: Rendering all objects on map [NOT READY YET] Stage 4: Create config for players [NOT READY YET] Performance One of the most important questions about a game: will I be able to play it with my spec? Well of course this depends on much things. Using high poly objects, large maps, HD textures, lots of trees, effects can highly impact the performance/rendering time. So all I can say about it in a nutshell: its really depends on your maps (and of course the player's machine). Until now this old buddy could be ran on almost every computer but with this could change things so this is why I created config for it, enabling or disabling this feature. About my experiences/tests Well the memory usage increased, from the default ~270 MB to ~300 MB (see the explanations later), the processor usage didn't change (~5-10%). About my video card usage I can't tell nothing since I can't monitor it, but I'm sure its usage (both video memory and processing) increased too... You maybe noticed some lag in the video but its not the case, its only because of my recorder, the game is still runs smoothly (remember, its depends on the computer and the map...) If it helps I have a Lenovo U41-70 notebook (Intel i7 5500U, 8GB DDR3 and GeForce 920M) and I used the "(old) wom2 maps". However, I noticed some fps drop with all shadows enabled, and also couldn't test it with many characters (cus the character render consumes so much processing time without this too), so I recommend to disable it by default and if the player decides to use it, he will be able to turn it on. Stage 1 Stage 2 Stage 3 Stage 4 So yeah this is it so far, if you have problem with the code (not compiling, etc) is probably because you did something wrong, I made these steps too on a full untouched client source so it should work for you too... (So pls don't ask me to help with this ) However, if something is not clear in the tutorial you can ask me for pictures or clarification. I didn't test it in dungeons (indoor maps) so there could be problems... Also if you made this and you have some nice maps or you find some great spots for some ingame pictures or videos, feel free to post them here

I think its hard to compare, the build time depends on the computer: Mostly processor and ssd/hdd write time. Also if you have large libs or large object files that the linker have to put into the binary its even takes more time, for example if you have static python lib or cythonized root it takes so much time, for me sometimes ~10min Btw the difference between Distribute and Release is that there are some #ifdefs that are using distribute's macro, and if its compiled in release some part of the code will work like if it would be in debug (for example the debug strings in the client) because of the mentioned ifdefs check... And yeah also can be some configuration difference too but its vary too...

The view distance only modifies the range for the broadcast packet (I mean with larger viewdistance you will see more players). For the terrain you will need something like this: I made this about a year ago and I wanted to release it a few times before, maybe I will do it sometimes soon, but the best solution for this if it would be disabled by default, and players would have the option to turn it on, cus the "engine" itself can't render much objects, so on low spec pcs it would be an instakill. However, while I was testing it the only mentionable difference I found was with the shadows, if I disabled it the performance was near the same, but I never had the chance to test it on a live server with large amount of players/shops.

In Hungary players sometimes complaining about that they cant start their clients on WinXP

Also note that on freebsd 64 bit with gcc the long's length is 64 bit, which is quite irritating when you want to send packets from the client to the server containing long (because they are 32 bits long) so therefore you have to replace the longs on serverside to int or replace the longs on clientside to long longs to match the packets size (only in the packets ofc).

You can give it int, or you can change the column name in the system, if you use different column for coins in your website.