Intel

Considering Korea has similar laws (account sharing can be legit identity theft in Korea), then, maybe? I mean let's not forget Korea has the checks for the hours played during the day (even LoL has that shit)

1gb was a lot? Uh.. it was a 999.99€ pre-built PC in 2005 with a Foxconn motherboard and an ATi GPU. 2$ PSU obviously (it fried). Oh I forgot, I remember buying additional 512 MB of ram when DDR3 was already out. I had to go and spend like 70€ for. freaking. 5 1 2. mega. bytes. of ram. I mean, it made my PC survive a little bit more until I had no choice but to upgrade ahah

Looks like a recurring thing.. even I had tried to run an hamachi server on a Pentium 4 HT/1GB DDR1 RAM Suffice to say, it was able to handle only one player online I remember then building for the first time my PC (Asus M4N82 Deluxe/AMD Phenom II X4 955/Corsair Dominator 8GB DDR2 1066 MHz), burning down the older hard disk because I plugged the SATA cable into the PCI-E PSU port..

what if inventory is in the same position as the offline shop preview?

no one's got any problem unless you using leaked files (same rules as m2dev basically)

I cannot replicate it (I should have to either add the new ikarus offline shop to my files since it already has a similar system, I would need to just change the preview with a render target window, or I should add the rendering target to marty sama files ETA: at least two weeks because cba gotta do other stuff) I've tried to mimic it opening my search npc interface (with a render target) when I use an item: else: #### #### ### self.interface.ToggleSearchNpc() ##open search npc self.__SendUseItemPacket(slotIndex) Either your render target window or the system that open that interface has some mistakes.

At this point it's probably just another if (isrendering()){ if(GetPickedSlotPointer()) { } } just somewhere else; I am not sure what's happening on your screen though. It looks like there's another tooltip with just the name of the item. I don't think it's a launcher problem but the system itself in the python code. Something doesn't look quite right.

It's.. the first post of the thread buddy

If the table exists, and it still doesn't start, it's gonna tell you why it's not starting

Table 'account.string' doesn't exist

Maybe, but the idea is to rewrite the networking and I/O threading anyway.. Also, the fact that I can run it locally with docker + debugger + sanitizer, knowing you are debugging the same version you are going to run in production, is miles better (despite visual studio debugger being a great piece of software, but I can use gdb on visual studio code anyway). (Also, everyone and their mothers is removing FreeBSD from their options. Contabo for example wants you to pay to upload the ISO to install a custom image.)

My server is on Debian12 x64 lol

It depends. If you link with -static (so every lib ""is put into the binary""), yes, otherwise you are gonna have to move the libs to the freebsd server you will be running the game on. To see the libs needed you can do: ldd game example: I would specify the libs you have as .a in the makefile (like I did for cryptopp, do it for the devil ones, libmysqlclient, openssl, libmd, libz etc basically all except the ones you compile for the game aka liblua, libgame, libsql, libpoly, libthecore, also remove hackshield, xtrap and gtest from the makefile and possibly the source code) so you would just then need to do this: fetch getlinkfromfreebsd.org: [Hidden Content] ex: [Hidden Content] tar -C / -xpf lib32.txz to install lib32 if not present and then: pkg install compat7x-amd64 compat8x-amd64 compat10x-amd64 compat11x-amd64 compat12x-amd64 (probably on freebsd14 there's also compat13x-amd64, I don't know) No, because the default compiler in freebsd is clang. If you make it that it uses gcc, then, sure (but at that point, it's the same as downloading the repository)

No, it will give you undefined reference (unless you use clang+libc) and probably it won't be a version compatible for Metin2 (as I said, a version greater than 8.4.0 may not work) You can always do: git clone --branch CRYPTOPP_8_4_0 *****@*****.tld:weidai11/cryptopp.git enter folder edit GNUMakeFile (if you use gcc/g++) compile move the lib and header files in your extern folder or change the directories in your makefile for cryptopp obviously, you gonna have to do the same for the client

I was going to say about the header files lol

Looks like you are linking against an old libcryptopp.a lib (or definitely not the one you compiled). After compiling cryptopp, you have to copy the lib to Extern/lib folder

Weird.. although! Did you clean the game project and rebuild it? (gmake clean and then gmake again) Try adding -static-libstdc++ as a CFLAG INCDIR += -I/usr/include/cryptopp this don't make sense Replace this: INCDIR += -I/usr/include/cryptopp INCDIR += -I../../../Extern/include LIBDIR += -L../../../Extern/lib LIBS += -lcryptopp -lgtest with: INCDIR += -I../../../Extern/include LIBDIR += -L../../../Extern/lib LIBS += ../../../Extern/lib/libcryptopp.a (remove gtest and honestly? Also remove HackShield from the makefile) Important note: do not build a cryptopp version greater than 8.4.0

I think it's fixed.. I can reproduce it with the dragon soul window: After: Also, at least on these files, dragon soul window is not as large as it supposed to be: 520 in height should do the trick

I had seen this: but I don't know how to replicate it on my client (even on latest martysama)

This is the problem I am talking about: Basically, when you get down from the mount (or the item slots are refreshed), the tooltip shown does not stay as the one from the item in the inventory's interface on top, but the item in the inventory behind. To fix this behaviour, go on void CSlotWindow::RefreshSlot() and change void CSlotWindow::RefreshSlot() { OnRefreshSlot(); // NOTE : Refresh µÉ¶§ ToolTip µµ °»½Å ÇÕ´Ï´Ù - [levites] if (IsRendering()) { TSlot * pSlot; if (GetPickedSlotPointer(&pSlot)) { OnOverOutItem(); OnOverInItem(pSlot->dwSlotNumber); } } } to: void CSlotWindow::RefreshSlot() { OnRefreshSlot(); if (IsRendering() && UI::CWindowManager::Instance().GetPointWindow() == this) { TSlot * pSlot; if (GetPickedSlotPointer(&pSlot)) { OnOverOutItem(); OnOverInItem(pSlot->dwSlotNumber); } } }

no need to change to clang, just add CXX = g++ CC = gcc on top of GNUMakefile of cryptopp

You have to compile your game and cryptopp with the same compiler. By default, on FreeBSD, everything will compile with clang + libc++ unless specified. You either force cryptopp to compile with gcc (therefore using libstdc++), editing the GNUMakeFile, or compile the game with clang as well (which will use libc++ in FreeBSD)

(didn't wanna make a whole thread for it so let's revive this thread) Prob is always 1 in group_group:

Amun's had enough

ahah I remember I talked with Amun about this and told me that this might happen. I've tested again Amun's way and at the end, it's the same as I had it. It's fine in 99.99% cases but a friend of mine told me the client apparently can't freeze, ever, even if in the background it's still "rendering" (so after the freeze you'll see your actual position), because with that freeze players can get out of the "fly" (with the original client, it can even execute some skills multiple times. Basically, you get stuck with sword hits, then you freeze the client and do like the warrior's three way skill. You'll be "unstuck" from the hits, and that skill might even do double/triple or more damage. I LOVE THIS GAME BTW.).