Gurgarath

1 hour ago, Skaira said:

Nahhh, you still need to fix SyncHack  

for example;

-> sync packet to x,y

-> attack packet;

and say bb fix

Where you are right is that SyncHack isn't working, distances aren't remotely good, checks will never trigger. You can fix the SyncPosition function, but it would still be called during ownership and SyncPackets. I preferred to make the check directly into the Attack function so that it doesn't process dirty packets further.

Hello everyone,

While working on some clientside thing. I noticed one big exploit that I was able to reproduce. Long story short, I was basically able to extend any collision and be able to reproduce (in a makeshift dirty way) the famous "kill aura" or whatever you call it. Basically allowing you to hit monsters from really far away without any problem. That's one of the most common thing the bots are using.

Videos of the bug:

Videos of the fix:

The fix

Have a nice day!

Thank you for sharing! Note that you do not need this fix if you use the method below, which remove the need of a server -> client packet which sends NPC informations.

Love me such details. Good job Toki!

4 hours ago, Lead0b110010100 said:

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.

Don't worry, mine wasn't supposed to sound harsh as well. It's just funny because this kind of comment is a bit of a meme on the community. However, regarding your message I wasn't able to reproduce it at all. I however managed to trigger the bug by putting negative value.

Here is the proper fix for both, I included the theoric fix about what you said, you can "merge" the fixes to make it look more compact but for learning purposes I made it longer. The bug still occured (so still occurs on official binaries) if you add a negative value in fullscreen mode. Which doesn't occur in Windowed mode.

3 hours ago, Lead0b110010100 said:

But... why should someone do that xDD

And why should a server admin care hahahha

That's a reversed fix. Most likely they fixed it because they got aware of this and decided to fix it. Of course it is very rare, I didn't even know you could abuse it in fullscreen before "reading" the assembly. I would say any server adming caring about things like this and details is a good admin, but that's my two cents on the question. It's a small and free fix anyway, you're free to use it or not

Hello,

As a certain someone pointed out with pseudo code, a new fix has made its way onto the official binaries. This fix is really small and specific as it would almost never be triggered, unless you specifically trigger it yourself.

How to reproduce?

Basically, edit the file metin2.cfg and replace the resolution (WIDTH / HEIGHT) with those three lines.

WIDTH 32767
HEIGHT 32767
WINDOWED 0

Unless you have a very unusual and gigantic screen and resolution, it will basically crash, saying that your game doesn't support DirectX, stuff like that.

How to fix?

Edit:

Additional fix for overflow and negatives values here:

Have a nice day!

Metin2 Steam Cards - Can be used as Wallpaper or Loading screens as well (1920*1080)

Hello, do you have a gif or a video trying to reproduce this bug please?

7 hours ago, karona200 said:

 

That's how the game works. That's common_drop_item.txt

1 hour ago, SCOOB said:

Another common bug, the tooltip of the objects sometimes stick to the cursor.

 

https://metin2.download/picture/2UWntujr827gvqVERGcI9cE5ZiRc43kj/.gif

As far as I remember, it's when OnOverOut / MouseOverOut cannot be called because another action is pending or the piece of UI you are hovering does not support it. It's a very common bug, indeed! 

4)

5) It's by default on every server, it's splash damage, works with all kind of skills

Hi,

It's as simple as "a protection is released so it has flaws". Staying with the usual pack method will allow for some minor tweaks and is easy to use. Pretty much everything is designed around it, packers as well as unpackers. FoxFS is pretty good and allows for a little bit more speed, but is a bit harder to use and set-up. Also, if you do not make some modifications here and there it will be easy to unpack for pretty much anyone. Keep in mind that the best is always what you do yourself anyway, so if you want security, plan on modifying some stuff, or go for a paid solution, but I cannot vouch for any of them in the market currently.

Hi,

A small suggestion would be to allow to switch the selection of nearby objects (can be done within the same square) using tab to quickly select a nearby object. It would come in handy when multiple objectifs are actually inbricked one within another. Only workaround I found was to move all the objects away, to finally reassemble them again.

On 3/23/2022 at 11:45 PM, Tekanse said:

I really dont like when someone says something like this. Friendly reminder, that in 2009 most players had under 5Mb/s connection, and devs had to make sacrafices.

For example, you made TPacketGCAttack bigger about 32 bytes, back then it was significant. 

 

Also, you really shouldnt send floats, eventually you will run into conversion problems, there is a reason why YMIR never put any into packets (well, with one excpetion).

You are completely right on this. Metin2 movement and PvP was done in pre-2002 actually and worked super well for the limitations at the time (thinking bandwith and usual internet connection outside of Korea) and it gave that fast paced pvp with only very few packets and server usage. It was however reworked in 2013 for the new maps (Level 90 maps) to introduce fall and stuff like this and it ended up creating this issue. The fly problem was not a thing until their "New__" movement and new ownership functions that they made in 2013-2014.

13 hours ago, filipw1 said:

Source was first leaked at the end of 2013 so your point is only partially correct. YMIR did things as small, unexperienced business do, which is: not keeping track of problems, solving critical errors with minimal effort and developing new ideas ignoring limitations they have. In one of branches you can actually see their attempt to boost::asio implementation, I guess that was before _IMPROVED_PACKET_ENCRYPTION_ but they abandoned that idea for something easier. What I mean here is, they should have note somewhere problems of the game and as the hardware, software, networking and so on developed, solved this problems. They didn't and they still don't, only when it appears in game and is dangerous for players. For the float thing, you are right, but I think that's a right place for CLang both in server and client.

This topic is a golden one, thanks for publishing it.

Yes and no. They do not bother to update things unless they need it or are "forced" to. The boost::asio implementation was from the same upgraded packet system as Metin2, but was intended for Inferna, not for Metin, at least at that time.

About the original topic, that's a good summary and it gives an interesting paths and hint, that is overall a really smart and interesting topic on this! Good job and thank you for sharing!

7 minutes ago, Thorek said:

Solved.

Hello, how did you?

iSkillBonus = MINMAX(-30, (int) (gauss_random(0, 5) + 0.5f), 30);

if (abs(iSkillBonus) <= 20)
    iNormalHitBonus = -2 * iSkillBonus + abs(number(-8, 8) + number(-8, 8)) + number(1, 4);
else
    iNormalHitBonus = -2 * iSkillBonus + number(1, 5);

Most likely it's skillBonus being calculated first, then we have average damage. It mostly focuses on lower values so it's most likely:

- Average damage mostly within the -5 / 30% range. Getting 40, then 50 is significantly harder. Getting more than 60 is considered nearly impossible.

- Getting 30% skill damage is possible, but still pretty rare.

On 1/19/2022 at 11:00 PM, TonisBoss said:

I have problem with this fix. Shaman can dmg from far or they do double damage. If you could help me please.

I have actually went back a couple of days ago to porting my skills to the latest patch. Technically, it just gave me an insight on how messed up some skills are in the game. For example, some Mental warrior skills, or horse skills will trigger the damage BEFORE the actual animation and effect (notably) because of the splash not being correctly used, but this is another topic.

Well, back on your question, if you have these issues, you should not follow this fix, the skill is working great by itself, this "fix" is pretty much useless for most people as it will most likely make you double compute the skill (because of the hittingspheres as OtherChoice explained). The explaination I can find is that I probably had a mismatch between the client and the server, or the skilltable and the actual PC files, the latter would be the most realistic explanation on why I did not check and why I ended up with mismatching files considering on what I worked back then.

Anyway, if your skill is working great by itself, you should not follow this guide because it can make it worse because it will compute when you launch it and when the hitting spheres will actually hit.

Hope I was clear enough, because this post has created confusion

You can use the preprocessor to do so. However enlarging models for the sake of enlarging is commonly a bad practice. The best is to dynamicaly (so c++) adjust it and adjust the bounding sphere / hitbox as well. xP3NG3R and Maso worked on it, maybe it is for sale now I am not sure.

Either fix it yourself (Client time exhauster, dirty division, specific time specifier and so on) or wait for an update

Cryptex is right, it is not properly working on FreeBSD, it is working perfectly fine on Windows though. He will have 225 seconds displayed but the item will vanish after 5. You can also see it above in the thread. It's most likely a time_t mismatch

True, I've completely forgot about this box (that I used to trigger by mistake). Thanks for clarifying it!

I think a good feature would be to add shadowmap exclusion. For example a list of objects that doesn't cast shadow when you regenerate the shadowmap. I am currently thinking about grass, as we do not always want grass to cast any shadow.

1 hour ago, granpa123 said:

any chance of getting the whole lot for all characters sit down etc this late if anyone still got them

 

Granpa123

We had quite a few other animations like these, however, they were only made for the warrior. So you (or we) need someone to adapt all of them for every race and gender

2 hours ago, arom224 said:

didn't work for me

 

This is an old error we used to fix by typing: fsck -y

Also, do as TMP4 said, those are 2009 (with mostly 2008 files) serverfiles. We usually call them 2008 because the game.core is r808 (iirc) which is a 2008 revision. But I didn't check in details.