EnneGi

Just now, .NyanCat said:

There should be no issue implementing that. The changes are related to the networking layer. The package transport should be untouched.

Thanks sir! I implemented that with no issue.

Thanks OP for this release, i was excited to try it and it just works. Fantastic!

I have a question: i know that for the linux version to work, it was changed the network library to libevent.

I would like to implement in the source the Target Info System; do you know if that could work without problems? Or maybe there are compatibility issues

Thank you in advance

1 hour ago, Amun said:

Apologies for the late reply, I didn't have a lot of time for metin2.

 

Now, in regards to the bug, I remembered about a conversation I had with @MrQuin in Dec 2020 and he said he had a similar problem when running the server in release mode on windows.

 

I've just compiled the server with this and seems like it's fixed now.

In common/tables.h search for:

typedef struct SPlayerSkill

 

And replace it with:

typedef struct SPlayerSkill
{
	BYTE    bMasterType;
	BYTE    bLevel;
#ifdef _WIN32
	DWORD    tNextRead;
#else
	time_t    tNextRead;
#endif
} TPlayerSkill;

 

I'll upload the source with the update when I have a bit of free time.

Thank you for letting us know!

 

For everyone else:

Please don't hesitate to write a comment or shoot me a message if you find any other bugs!

Thank You!

 

Here's a picture of the server running in release:

 

https://metin2.download/picture/Wm8fP1eA7eiz6Q7tbSp17lwWCH097CJL/.png

You are the GOAT, thank you!!
With the help of other guys in the forum, we have also found a solution for the drop bug (excessive drop bug):
Excessive drop - Questions & Answers - Metin2 Dev

If someone is interested, i leave the link shared for anyone  

On 5/3/2020 at 12:08 PM, Hik said:

UP2:

 

if (iPercent >= number(1, iRandRange))

 

iPercent = 100000                      | in mob_drop_item the percentage is set to 10

number = 1, 4000000                | random number between 1 and 4000000

 

I noticed, however, how the random values obtained are very different between the two versions:

 

random = 3894439
random = 229634
random = 1664283
random = 3958197 | BSD VERSION
random = 924476
random = 2193081
random = 181074
-----------------------------------------------------------------------------

random = 12851
random = 10165 | WINDOWS VERSION
random = 23397
random = 12871

I don't enter all the other values because they follow the same trend.
In the first case, having a high random value I will not drop, while having a low one in the second case I will always drop.
Any ideas on this?

Hi Hik, your searching was useful to me, as you said every windows server file is affected by this bug.

I found the root cause. 

File: utils.c in libthecore

DWORD thecore_random()
{
#ifdef __WIN32__
    return rand();
#else
    return random();
#endif

for Windows, it will use rand(). It has limitations for Windows, the maximum range is 32767. That's why the number extraction in Windows is so low.

You have to find another way to random with bigger numbers, or as a workaround you can multiply the rand() value to have a maximum of iRandRange.

You can find the multiplier value by dividing iRandRange / 32767.

It's working, but it's a really bad workaround if you tell me, because we are not get a random result from 1 to iRandRange. 

If you want to try this workaround, find item_manager.cpp and change:

number(1,iRandRange)

To

(rand() % 32767) * iMultiplier)

Before 

while (it != g_vec_pkCommonDropItem[bRank].end()) in CreateDropItem

add this:

int iMultiplier = iRandRange / 32767

Before 

while sys_log(1, "CreateQuestDropItem victim(%s), killer(%s)", pkChr->GetName(), pkKiller->GetName() ); in CreateDropItem

add this:

int iMultiplier = iRandRange / 32767

My advise is to work in a good implementation of random for Windows.

Cheers

1 hour ago, Amun said:

I'm compiling right now. I'll take a look once it's done.

 

Does it happen when both the client and the server are running in release?

Or when only one of them is running in release while the other is in debug?

Client in release/distribution mode, db/game server in release to reproduce the bug.

I tried db/game in debug mode, and client still in release/distribution and it works

Thanks!!

17 hours ago, xTryhard said:

it is always the same you ( client ) want something from the server so for example you press a button now you send a packet to the server he looks what you want and after that he will validate your packet if everything is good you get a callback from the server with the data you want if something is wrong he will not send you anything ( anti cheat )

the best way to debug something is to start at the beginning from the road look what will happen when you press on the button and check everything the way to the server and back to the client

use printf in source to see if you get what you expect or not
 

Really thanks for the tips. I'm working on it, if i found the root cause i will post it.

Meanwhile, i found that this bug happens only in Release mode compilation with Windows. In debug mode, it just works out of the box, Skill points are setted. OBV this bug doesn't happen if you compile TMP4 source in freebsd.

To summarize, it is reproducible only if you compile these source in Windows via Visual Studio in Release Mode - 32 bit.

1 hour ago, xTryhard said:

when you add an item to your inventory with AddToCharacter print the index out and look if you really have the item or not if your console says you have it check if the update packet is sending to the client and check if python update correctly

Really thanks, i solved, items were really in the inventory, i spawned some item in admin account and then all items reappear (magic?)

For OP, i have found another bug, don't know if anyone has the same. Skill points not setting correctly, the abilities stay with 0 points.

Someone know a fix for this? Thanks

Did you edit something about socket count server side?

Cause with the client TMP4 provided i can't see items in my inventory, even if i have them.

In logs i had an error like "Invalid Socket Count 3, set to maximum"

Hi everyone,

I'll try again with a new help request. I did my homework this time, and with search function i did not find anything related with.
I have a very annoying bug where when I drop an object from any mob, it randomly drops with 0,1,2,3 socket, whatever object it is. This gives me problems because I can't stack objects correctly, and some of them are generated with GALL sockets or EMPTY. Can anyone give me an input on where to check in the source?

Itemproto TXT and sql side looks ok, but I accept advice and suggestions.

I have not made any changes to the sources, and since it seems very stable to me (and the only one that I can compile decently for Windows), I would like to fix it.

Can anyone help me?

Thanks in advance for anyone who will help me.

... i already saw that, i didn't resolve. but thanks anyway. Maybe i'll write directly to the owner of the posts.

Hi everyone,

today i compiled binaries and client from this sources:

My client brutally crashed with this error: SYSERR: Unknown packet header: 50, last: 76 1

I checked packet.h client and game but i can't find this packet header as HEADER_GC.

Can someone help me?

Thanks

Hi!

I hope someone can help me. I compiled DB and game without problems.

Then i combined them with DB for mysql and locale from another SF. 

And everything is okay. Then i started my client, login is ok, but when the client go in the screen with the loading bar, a crash happened.

The only syserror i have is "wsagetlasterror returned 10054". I can't find why the client always crash, maybe im using a wrong DB? What can i do?

I used the test client 40k. I tried several other client and the result is the same. Sorry for bad english and thanks for the help.