Jump to content

Changing guild mark problem (DevIL 1.8.0)


Recommended Posts

  • Contributor

Today someone reported me a crash about guild marks: https://metin2.dev/topic/27610-40250-reference-serverfile-client-src-15-available-languages/page/44/#comment-155036
and while I couldn't reproduce it I found another bug with guild marks.

Basicly the problem is, when I change the guild mark, sometimes it starts filling from the bottom. I attach a picture to explain. Please read by the numbers 1. 2. 3. 4.

K-perny-k-p-2023-02-06-150219.png

I recently changed DevIL to static. But I took 1 years old backup to test and the problem exists there too. So it's probably not about changing DevIL libs from shared object to static.

I'm using this: 

 

This is the hidden content, please

I'm not sure If I fcked up something or it's bad by default.

DevIL version is 1.8.0 from pkg (pkg install devil)

  • Metin2 Dev 23
  • Scream 2
  • Good 3
  • Love 1
  • Love 3
Link to comment
Share on other sites

  • Honorable Member

Maybe you forgot to delete mark/mark_index as well. I'm using libdevil (1.8.0) as static (server-side) for 9 years I guess. Either 32bit or 64bit, c++98 / c++20. Never got a crash about it. 

You can also use IL without dependencies (libpng & co) server-side, because they are not needed.

This is the hidden content, please

Even so, I checked an 8 years old mark_0.tga. The mark_index is incremental for every new guild created. If a guild doesn't upload the flag, it remains black. It never started from the bottom (like in your case).

For the lzo1x_compress crash, I'd check if they uploaded a 0kb logo, or something like that.

 

Edited by martysama0134
  • Metin2 Dev 36
  • Good 3
  • Love 2
  • Love 3
Link to comment
Share on other sites

  • Contributor
3 hours ago, martysama0134 said:

Maybe you forgot to delete mark/mark_index as well. I'm using libdevil (1.8.0) as static (server-side) for 9 years I guess. Either 32bit or 64bit, c++98 / c++20. Never got a crash about it. 

You can also use IL without dependencies (libpng & co) server-side, because they are not needed.

This is the hidden content, please

Even so, I checked an 8 years old mark_0.tga. The mark_index is incremental for every new guild created. If a guild doesn't upload the flag, it remains black. It never started from the bottom (like in your case).

For the lzo1x_compress crash, I'd check if they uploaded a 0kb logo, or something like that.

 

First of all thanks for your answer ?

I did not forget to delete mark_index. I have guild id 1 and 2.
I downloaded and compiled and linked static your libdevil but it's the same.

Here is a video about my bug:

It placed the 1. logo to the last line of the mark tga, and when I uploaded another logo, it moved the previous one to the first line (the right location) and placed the current logo the the last line. Please watch the video because it sound silly but it really does this.

I replaced DevIL libs with older precompiled ones (1.7.8 from Mali's older FreeBSD12.0 VM) and then it works fine, it never places to the last line.
Ofc it's dirty, I just did it for testing.

By knowing that, should the source be modified to be compatible with 1.8.0?

Edited by TMP4
  • Metin2 Dev 1
Link to comment
Share on other sites

  • Honorable Member

In game/src/guild_manager.cpp

// change:
	rkMarkMgr.LoadMarkIndex();
	rkMarkMgr.LoadMarkImages();
	rkMarkMgr.LoadSymbol(GUILD_SYMBOL_FILENAME);

// to:
	if (!rkMarkMgr.LoadMarkIndex())
	{
		rkMarkMgr.SaveMarkIndex();
		rkMarkMgr.SaveMarkImage(0);
	}
	else
		rkMarkMgr.LoadMarkImages();

 

I think if the image .tga is missing, it will glitch it on the top when it gets resized the first time, so I'm regenerating it when it attempts to load it the first time.

i.e. LoadSymbol is unused code.

 

 

In game/src/MarkImage.cpp, if you want to read the correct save position:

// change:
printf("PutMark pos %u %ux%u\n", posMark, colMark * SGuildMark::WIDTH, rowMark * SGuildMark::HEIGHT);
// to:
sys_log(0, "PutMark pos %u %ux%u\n", posMark, colMark * SGuildMark::WIDTH, rowMark * SGuildMark::HEIGHT);

 

Check if it solves the issue.

Edited by martysama0134
Link to comment
Share on other sites

  • Contributor
21 minutes ago, martysama0134 said:

In game/src/guild_manager.cpp

// change:
	rkMarkMgr.LoadMarkIndex();
	rkMarkMgr.LoadMarkImages();
	rkMarkMgr.LoadSymbol(GUILD_SYMBOL_FILENAME);

// to:
	if (!rkMarkMgr.LoadMarkIndex())
	{
		rkMarkMgr.SaveMarkIndex();
		rkMarkMgr.SaveMarkImage(0);
	}
	else
		rkMarkMgr.LoadMarkImages();

 

I think if the image .tga is missing, it will glitch it on the top when it gets resized the first time, so I'm regenerating it when it attempts to load it the first time.

i.e. LoadSymbol is unused code.

 

 

In game/src/MarkImage.cpp, if you want to read the correct save position:

// change:
printf("PutMark pos %u %ux%u\n", posMark, colMark * SGuildMark::WIDTH, rowMark * SGuildMark::HEIGHT);
// to:
sys_log(0, "PutMark pos %u %ux%u\n", posMark, colMark * SGuildMark::WIDTH, rowMark * SGuildMark::HEIGHT);

 

Check if it solves the issue.

It's still the same. It places the uploaded mark to the last line of the tga. Then I restart the server. Then I upload another one, the previous will be moved to the first line (correct location) and after a server restart, it'll show the 1. logo since that is in the correct location.

Just as I showed in the video ?

But in the meantime I recompiled DevIL 1.7.8 to get clean static libs, it works fine. So it's only wrong with DevIL 1.8.0.
If I can't fix it, I'll just use 1.7.8. The newer version doesn't even give any advantage, I only used it because the pkg and ports got updated to that version...

Link to comment
Share on other sites

  • Honorable Member

I found the bug on the v1.8.0:

They save the direction in the .tga:

sjA0DEa.png

When MarkImage.cpp loads the .tga it does ilOriginFunc(IL_ORIGIN_UPPER_LEFT); and it gets flipped.

By commenting these lines directly in the IL src, it gets resolved.

This is the hidden content, please

Edited by Metin2 Dev
Core X - External 2 Internal
  • Metin2 Dev 35
  • Good 5
  • Love 1
  • Love 7
Link to comment
Share on other sites

  • Contributor
13 hours ago, martysama0134 said:

I found the bug on the v1.8.0:

They save the direction in the .tga:

sjA0DEa.png

When MarkImage.cpp loads the .tga it does ilOriginFunc(IL_ORIGIN_UPPER_LEFT); and it gets flipped.

By commenting these lines directly in the IL src, it gets resolved.

This is the hidden content, please

Thank you, it seems now working fine ?Many thanks

---

I have 2 question, 1. related to DevIL, 2. to cryptopp.

1. We don't need to link /usr/lib/liblzma.a with your libdevil, right?
2. I see your patched cryptopp 

This is the hidden content, please
 Is there any reason you chose version 7.0.0? Currently I'm using 8.4.0 (because Mali's clientside have 8.4.0 too) while I'm not experiencing any issue and nobody reported me anything, I just curious to avoid future bugs like this DevIL one.

Edit: We talked in Discord, liblzma.a is not needed unless it asks for it (probably won't) and cryptopp 8.4 is fine if it does not crash at login.

Edited by TMP4
  • Metin2 Dev 24
  • Good 1
  • Love 1
Link to comment
Share on other sites

  • Premium
On 2/7/2023 at 7:19 AM, TMP4 said:

Thank you, it seems now working fine ?Many thanks

---

I have 2 question, 1. related to DevIL, 2. to cryptopp.

1. We don't need to link /usr/lib/liblzma.a with your libdevil, right?
2. I see your patched cryptopp 

This is the hidden content, please
 Is there any reason you chose version 7.0.0? Currently I'm using 8.4.0 (because Mali's clientside have 8.4.0 too) while I'm not experiencing any issue and nobody reported me anything, I just curious to avoid future bugs like this DevIL one.

Edit: We talked in Discord, liblzma.a is not needed unless it asks for it (probably won't) and cryptopp 8.4 is fine if it does not crash at login.

Mh, I don't know on FreeBSD (I am not interesting on upgrading DevIL on there unless I want to build a native 64bit file game), but I was trying to build a Linux version and it asks for lzma. It's from libtiff:

SOyMNYU.png

needed for il_tiff:

98ZUuze.png


 

Spoiler

Also, if anyone is interested, on Linux DevIL has three more dependencies (libmng, libdeflate, libwebp), libjasper has been removed and liblcms upgraded (and there is no static lib from the package, but maybe from sources it works, I cba rn). This devil 1.7.8 btw , I will still have to try from sources.

# DevIL
INCDIR += -I/usr/local/include/IL
LIBS += /usr/lib/x86_64-linux-gnu/libIL.a\
		/usr/lib/x86_64-linux-gnu/libpng.a\
		/usr/lib/x86_64-linux-gnu/libmng.a\
		/usr/lib/x86_64-linux-gnu/libtiff.a\
		/usr/lib/x86_64-linux-gnu/libjbig.a\
		/usr/lib/x86_64-linux-gnu/liblzma.a\
		/usr/lib/x86_64-linux-gnu/libjpeg.a\
		/usr/lib/x86_64-linux-gnu/libdeflate.a\
		/usr/lib/x86_64-linux-gnu/libwebp.a
LIBS += -llcms2

# MySQL
INCDIR += -I/usr/include/mysql
LIBS += /usr/lib/x86_64-linux-gnu/libmysqlclient.a /usr/lib/x86_64-linux-gnu/libz.a
LIBS += -lzstd

CNOWNz7.png

(before anyone asks, I don't even know how much this is broken, I basically have just finished compiling it and I am not sure about the socket/kernel events working properly on libthecore.)

My 2 cents in case someone stumbles upon here trying this metin2 on linux journey.

 

Edited by Metin2 Dev
Core X - External 2 Internal
  • Good 1
Link to comment
Share on other sites

  • Premium
8 minutes ago, TMP4 said:

I'm not using tiff or any other extension since they're completly unused, we only need targa (.tga) which is builtin in DevIL.
Probably that's why I don't need lzma ?

Oh yeah, for sure, but (at least from original sources and package) I guess cmake kept detecting libtiff (and the others) in the system. If marty's version only goes for targa then it's great.

I should definitely retry removing all the useless dependencies

 

EDIT: Ok, I should nuke the useless stuff I guess before compiling DevIL or maybe it's just a Linux thing:

ttVfPO9.png

 

Edited by Metin2 Dev
Core X - External 2 Internal
Link to comment
Share on other sites

  • Forum Moderator
4 hours ago, xXIntelXx said:

Oh yeah, for sure, but (at least from original sources and package) I guess cmake kept detecting libtiff (and the others) in the system. If marty's version only goes for targa then it's great.

I should definitely retry removing all the useless dependencies

 

EDIT: Ok, I should nuke the useless stuff I guess before compiling DevIL or maybe it's just a Linux thing:

ttVfPO9.png

 

I never tried to directly compile LibDevIL on Linux, but I don't have any issue with it on the server. I just used the includes from the 1.7.8 version and on the running machine I installed the apt package "libdevil-dev". On the client I am still on the 1.6.5, but weirdly enough I didn't encounter a single issue with libdevil on the server, neither the order in the mark or the corrupted logo. Maybe I should start to compile it and to link it statically to see if it creates any issue

Gurgarath
coming soon

Link to comment
Share on other sites

  • Premium
6 hours ago, Gurgarath said:

I never tried to directly compile LibDevIL on Linux, but I don't have any issue with it on the server. I just used the includes from the 1.7.8 version and on the running machine I installed the apt package "libdevil-dev". On the client I am still on the 1.6.5, but weirdly enough I didn't encounter a single issue with libdevil on the server, neither the order in the mark or the corrupted logo. Maybe I should start to compile it and to link it statically to see if it creates any issue

Funnily enough, compiling it gave me the shared libs, the package the static libs (linux AND FreeBSD as well when I tried on 64bit)

FreeBSD though gives you the 1.8.0 version if I am not mistaken.

  • Think 1
Link to comment
Share on other sites

  • 2 weeks later...
  • Premium
On 2/7/2023 at 7:19 AM, TMP4 said:

Thank you, it seems now working fine ?Many thanks

---

I have 2 question, 1. related to DevIL, 2. to cryptopp.

1. We don't need to link /usr/lib/liblzma.a with your libdevil, right?
2. I see your patched cryptopp 

This is the hidden content, please
 Is there any reason you chose version 7.0.0? Currently I'm using 8.4.0 (because Mali's clientside have 8.4.0 too) while I'm not experiencing any issue and nobody reported me anything, I just curious to avoid future bugs like this DevIL one.

Edit: We talked in Discord, liblzma.a is not needed unless it asks for it (probably won't) and cryptopp 8.4 is fine if it does not crash at login.

About cryptopp, I've just tested 8.7.0 and it does work as well, if anyone wants to upgrade.

Edited by xXIntelXx
  • Metin2 Dev 1
  • Good 1
Link to comment
Share on other sites

  • Honorable Member
10 hours ago, xXIntelXx said:

About cryptopp, I've just tested 8.7.0 and it does work as well, if anyone wants to upgrade.

You should mention which compiler, os, and arch you used too. Some cryptopp versions have internal crashes for different reasons.

Also, cryptopp 8.7.0 from ports, pkg or from the official website?

Edited by martysama0134
  • Metin2 Dev 2
Link to comment
Share on other sites

  • Premium
2 minutes ago, martysama0134 said:

You should mention which compiler, os, and arch you used too. Some cryptopp versions have internal crashes for different reasons.

Also, cryptopp 8.7.0 from ports, pkg or from the official website?

cryptopp 8.7.0 from github, gcc12 FreeBSD 13.0/13.1 (32 bit of course)

Link to comment
Share on other sites

  • Premium
43 minutes ago, Denizeri24 said:

CryptoPP can be safely updated as long as it is not compiled with -O3 / -Ofast / DEVEL compilers / -march=native (problem about different CPU instruction sets). Metin2 uses certain algorithms;

spacer.png

ndYuQ1V.png

Usually the default GNU-Makefile from their github (branch master) is fine, just select the same compiler as the game to not have undefined references to basic_string and what not.

Also side note, gcc13 on freebsd 13.0/13.1 32bit from packages is utterly broken (at least on the latest ISOs I've tried)

Edited by Metin2 Dev
Core X - External 2 Internal
Link to comment
Share on other sites

18 minutes ago, xXIntelXx said:

Usually the default GNU-Makefile from their github (branch master) is fine, just select the same compiler as the game to not have undefined references to basic_string and what not.

Also side note, gcc13 on freebsd 13.0/13.1 32bit from packages is utterly broken (at least on the latest ISOs I've tried)

gcc13 is devel version, so thats normal. my files give cores sometimes too with clang-devel hehe

Link to comment
Share on other sites

  • Premium
14 minutes ago, Denizeri24 said:

gcc13 is devel version, so thats normal. my files give cores sometimes too with clang-devel hehe

At least they compile ahah mine would print undefined references from libstdc++ (even for a simple hello word program) or verify_cgraph_node failed issues (I wanted to avoid to use fmt as an extern library and use it from the std, but oh well)

Edited by xXIntelXx
Link to comment
Share on other sites

  • 9 months later...
  • Active+ Member
On 2/7/2023 at 2:23 AM, martysama0134 said:

I found the bug on the v1.8.0:

They save the direction in the .tga:

sjA0DEa.png

When MarkImage.cpp loads the .tga it does ilOriginFunc(IL_ORIGIN_UPPER_LEFT); and it gets flipped.

By commenting these lines directly in the IL src, it gets resolved.

This is the hidden content, please

Hello. Can you tell me how to solve this problem? I applied the changes you gave via visual studio and compiled it(32bit). When I tested the resulting dll file, the guild icons in the game became completely invisible. I also uploaded your lib files to the server, but it's still the same. When I select the guild icon, no .tga or anything like that is created on the server side and it does not appear in the game.

 

I'm using bsd 13.0 - 32bit

Edited by blaxis
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now


×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.