Lead0b110010100

I mean it works, but at what cost..? That's the worst tutorial / not tutorial / patch file I have seen in my life. If you want it to work: - Take your time - Follow the diff file - Only use the tutorial, if its missing in the diff file - Pray. Pray a lot that it works. - Debug if it doesn't. Besides that: Thanks for the release, it's clearly partly generated by AI. So if you do care about code quality, you will need to rewrite some parts (Like calling Python by importing module and then executing func in C++, gosh. Our integration goes the other way, calling C++ from Python ).

Great job!

Caution: The following text was translated with DeepL from German to English. Not because I don't know English, but I am way too lazy to translate this. It's been copied from my thread from another competitor board in the german m2 scene, because I thought it could help more people. --------------------------------------------------- Hello everyone, Today, it was brought to my attention that there is an ancient bug in Metin2 that we have simply accepted until now. Introduction: Our mouse is on an item (Unknown Dagger), we click on it and... oops? An Unidentified Robe has been picked up. Why on earth...? Before (the item is green, which is not picked up because there is a bag with the robe behind it): Afterwards (The item is green, which you will actually pick up, i.e., the bag behind the text, in this case the earrings): Description: There are two different methods in Metin2 for finding the “item to be picked up.” Both are called “Pick,” item.Pick() and textTail.Pick(). One applies to the text tail, i.e., the pure text. The other applies to the model (i.e., when you go over the bag model). However, only the former is marked in green, i.e., the item on whose text tail I am currently standing. In this case, the dagger. The client source has the following order for which item it picks up: 1) Is my mouse over a model? -> Pick up 2) Is my mouse over text? -> Pick up Well, who noticed? Only case 2 is marked in green, even if case 1 would be picked up. This is due to an incorrect implementation in the client (game.py). This causes us to click on the dagger and still pick up a robe. To fix this: With this fix, we solve this visual problem and fix the feedback for the user. Client 1) Search in game.py if -1 != self.PickingItemIndex: textTail.SelectItemName(self.PickingItemIndex) 2) Replace with picked_item_vid = item.Pick() if -1 != picked_item_vid: textTail.SelectItemName(picked_item_vid) Notes: Apart from this bug, there are other things that go wrong when picking up an item with the mouse, in my opinion. However, these would all be separate releases, which I could release if there were enough requests. The following would be examples: 1) Why can I pick up an item by clicking on a model? Isn't that counterintuitive? It would be better if you could only pick up items via the model if “Show item names” is set to “Limited.” In other words, if you can't always see the item names. 2) The distance calculation on the client is always 150 for picking up items, but on the server it is higher. The consequence is that the character has to walk up to almost every item to pick it up. Even though the server would allow picking up items from further away. 3) Even if an item is within this range of 150, the player makes a rotational movement on the spot. They “twitch.” Hope this helps and have a wonderful weekend ~Lead

Others speak english and this man speaks in facts. This way of communicating feels like reading a bitch slap. GJ!

Thanks

Isn't it better to add this code to the QuestionDialog class directly?

Oh wow, my comment got more backlash than I thought it would. I was like "Why should someone put such a crazy value there, that's stupid as hell. But someone did, so did you find a fix for it." The problem we are trying to solve here is not a new one, try entering 9000000000 as a value for the width parameter for example. It will also overflow, resulting in a 'random' value of m_Config.width or a crash. We can't really 'fix' the underlying problem here, which is that serialization of numbers can result in overflows. If you take a 8 bit data type like 'long long' instead of the 4 bit 'int' for m_Config.width, someone could still write a bigger number. What I wan't to say is: This check might result in randomly true or false, regarding the value after the overflow in the config parameter. if (m_Config.width >= screen_width_1) Sorry if my first comment sounded rude or offensive, it was definitely not meant like that.

But... why should someone do that xDD And why should a server admin care hahahha

Thank you very much Ikarus. Not only that you fixxed it, I love how you explain the bug and your solution. I knew one more developer in this board that did that some time ago (Vanilla) and I missed such posts. I even learned something, thank you.

You ware totally right, I replaced std::map with std::unordered_map here.

Okay? No problem:

I tested it and got like 44% RAM usage reduction. But I had to do some changes in order to not get exceptions when running the server on windows. (Due to unintialized usage of map) + I changed way more lines of code to do that, but the idea is absolutely correct.

Add a way to contact you, maybe discord?

I do have a fix for that actually. But I don't know if I want to sell / release it. Maybe in some months in my own shop.

That comment is dumb af. You can't secure your self against sql injections by just disallowing people from using special characters. That's not the point of cyber defence.