Damage Print Improve (v26.0.5) - REVERSED

[Metin2 Dev 12291]

This is the hidden content, please

• Sign In
• or
• Sign Up

Alternative download links →

This is the hidden content, please

• Sign In
• or
• Sign Up

Features:
- When you recieve damage and is 0 it will print MISS
- New icons for critical/penetrate/crit+pene mix/block/dodge  
- All damage is rendered last in the pipeline so it's printed above all other game objects (before interface)

All python changes are made on the 2018 leaked root.

Notes:
- inside the .mse there is a new (to me) variable called "StaticRotation" that I didn't reverse yet
- the "EnableFrustum" variable I think it was added some versions ago so I didn't place it under this feature flag
- the "RecvDamageInfoPacket" have more info in the official binary (auto attack system). I only kept the relevant parts for these changes

If I missed something please tell me and I will fix it as soon as posible!

[Apex01 4]

Hey Abel, great work on the reverse engineering. However, there's a small but critical logic flaw in your C++ implementation for the 'enablefrustum' flag that will cause massive FPS drops.

I've been reversing the same binary, and comparing your code with the Assembly dump reveals a crucial missing detail: the exclamation mark (!).

In your code:

if (!rTextFileLoader.GetTokenBoolean("enablefrustum", &m_ParticleProperty.m_bEnableFrustum))

Your logic means: If the flag is NOT found, disable Frustum Culling (FALSE).
However, the official Assembly (see my screenshot below) explicitly checks if (v66) without the NOT operator. The official logic is: If the flag IS found, disable it.

The Performance Impact:
Because 99% of old Metin2 .mse files do not contain the enablefrustum string, your code effectively disables Frustum Culling for almost every particle in the game. The GPU will be forced to render thousands of unseen particles (like foot dust or basic attacks) even when they are behind the camera. This overdraw will completely destroy performance in crowded areas like guild wars.

To replicate the official behavior and save your users' FPS, you just need to remove the ! from your condition.



Best regards,
- aki

Edited April 29 by Apex01
Core X - External 2 Internal

[Metin2 Dev 12291]

Hello. Now I see what you are talking about. The wz developers are just idiots, as always. 
I am pretty sure the logic was meant to be like I made it because they added this EnableFrustum to over 200 effects, some having 0 and some having 1. The mistake was that I set m_bEnableFrustum to False in ::Clear which was supose to be True (my bad).


After looking again the final code in official will be:

// Change inside ParticleProperty.cpp:
void CParticleProperty::Clear()
{
	...

	m_bEnableFrustum = TRUE;
}


// Change inside ParticleSystemData.cpp
        if (rTextFileLoader.GetTokenBoolean("enablefrustum", &m_ParticleProperty.m_bEnableFrustum))
        {
            m_ParticleProperty.m_bEnableFrustum = FALSE;
        }

With this it will work exactly like on official, meaning if the variable "enablefrustum" exist in the mse (the value doesn't matter) => the frustum check will be disabled (yeah, no logic). 
 

 

My recomandation (NOT OFFICIAL):

// Change inside ParticleProperty.cpp:
void CParticleProperty::Clear()
{
	...

	m_bEnableFrustum = TRUE;
}


// Change inside ParticleSystemData.cpp
        if (!rTextFileLoader.GetTokenBoolean("enablefrustum", &m_ParticleProperty.m_bEnableFrustum))
        {
            m_ParticleProperty.m_bEnableFrustum = TRUE;
        }

This code will work like this: 
1. If the variable exist in the file: m_bEnableFrustum will take the value from the file
2. If the variable does not exist in the file: m_bEnableFrustum will be True


 

[Apex01 4]

Glad we figured it out! And yes, your "NOT OFFICIAL" recommendation is exactly how it should have been written in the first place. It makes perfect logical sense.

It's actually hilarious when you think about why the wz developers wrote it that way. Instead of fixing the core issue-which is the flawed bounding sphere/radius math that causes large effects to disappear when the camera pans-they just slapped a band-aid on it to "save the day". They essentially hardcoded a hack: "If an effect is broken, just throw this keyword into the file to bypass the math completely so players won't complain." Classic technical debt!

Thanks for taking the time to update the thread so quickly and for sharing your work with everyone.

Best regards,
- aki

[stivencortez655 0]

top