xP3NG3Rx

Don't you see the problem?

And also in debug. Build in Distribute.

Not everyone have this bug

Hello. I was looking inside the official python files and I found a little fix for this: Let me explain a bit the problem. If you leave open the inventory/dragon soul inventory/expanded taskbar or the affected objects and then you are using quest for teleportation, the windows what you left open will be closed because of the quest and when the quest executed those windows what you left open before would be opened again, but the warp is killing this procedure and that happens what you can see in the video, the windows are there but you cannot see them. Btw you can close them with escape key. The fix is coming from webzen: Simple, just execute a .Hide() function before the Destroy function has been called on that object what is stuck on the main window after teleport and that's it. For example: interfaceModule.py -> Interface class -> Close function: if self.wndInventory: self.wndInventory.Hide()#fix self.wndInventory.Destroy() if self.wndDragonSoul: self.wndDragonSoul.Hide()#fix self.wndDragonSoul.Destroy()

Probably. I think the GUI has fix slots, so if you are trying to open a box which contain more items it will cry. But the idea isn't bad.

Such a good idea

Oh, than I'm really stupid, because I don't know any way from those .

2018 and still python22 gg&wp. btw for the errorlog there is the error_lookup.py

Every patchservers are containing it. They cythonized tho, just packed with wrong script :rofl:

Waow, thanks a lot. Which client?

No, I've tried 100 times to find a couple of functions what have never been changed and the patternfinder doesn't give back any valuable result. This is the reason why I stuck. And the offset of the functions always changed after every start so I can't tell to my tool that this function is on this offset hook it, because at the second start the function is on another offset already. Oh yeah, and I've tried the searching on the .BR binary as well and every single try was successful. So the lueco shell is sucks. Btw should be enough to modify only one byte in the memory and you'll be able to unpack via python. int __cdecl sub_5161660(int a1, int a2) { int v3; // ST14_4 char v4; // [esp+Ch] [ebp-164h] int v5; // [esp+15Ch] [ebp-14h] int v6; // [esp+160h] [ebp-10h] int v7; // [esp+16Ch] [ebp-4h] if ( !PyTuple_GetString(a2, 0, &v6) ) return Py_BuildException(0); if ( packExists(v6) ) { sub_53DA140(&v4); v7 = 0; v5 = 0; if ( sub_5441430(0, (int)&v4, v6, (int)&v5) ) { sub_53DA3D0(&v4); v3 = python27_Py_BuildValue("s#"); v7 = -1; sub_53DA580(&v4); return v3; } v7 = -1; sub_53DA580(&v4); } return Py_BuildException(0); } int __cdecl sub_5161660(int a1, int a2) { int result; // eax int v3; // ST14_4 char v4; // [esp+Ch] [ebp-164h] int v5; // [esp+15Ch] [ebp-14h] int v6; // [esp+160h] [ebp-10h] int v7; // [esp+16Ch] [ebp-4h] if ( !PyTuple_GetString(a2, 0, &v6) ) return Py_BuildException(0); sub_53DA140(&v4); v7 = 0; v5 = 0; if ( sub_5441430(0, (int)&v4, v6, (int)&v5) ) { sub_53DA3D0(&v4); v3 = python27_Py_BuildValue("s#"); v7 = -1; sub_53DA580(&v4); result = v3; } else { v7 = -1; sub_53DA580(&v4); result = Py_BuildException(0); } return result; } metin2client.exe:051616A0 test edx, edx metin2client.exe:051616A2 jnz short loc_51616CA metin2client.exe:051616A4 push 0 metin2client.exe:051616A6 call Py_BuildException metin2client.exe:051616AB add esp, 4 metin2client.exe:051616AE jmp loc_516176A metin2client.exe:051616B3 ; --------------------------------------------------------------------------- metin2client.exe:051616B3 mov eax, [ebp+var_10] metin2client.exe:051616B6 push eax metin2client.exe:051616B7 call packExists metin2client.exe:051616BC add esp, 4 FROM: 85 D2 75 0F 6A 00 E8 45 58 28 00 83 C4 04 E9 B7 00 00 00 8B 45 F0 50 E8 D4 FE FF FF 83 C4 04 TO: 85 D2 75 26 6A 00 E8 45 58 28 00 83 C4 04 E9 B7 00 00 00 8B 45 F0 50 E8 D4 FE FF FF 83 C4 04 "75 0F" is a short jump at 0x51616A2 Sig: (85 D2 75 0F 6A 00 E8 ?? ?? ?? ?? 83 C4 04 E9 ?? ?? ?? ?? 8B 45 F0 50 E8 ?? ?? ?? ?? 83 C4 04) + 3 The 26 instead of 0F will skip the dot and the extension check if-statement. So after the patch the packGet would looks like this: PyObject * packGet(PyObject * poSelf, PyObject * poArgs) { char * strFileName; if (!PyTuple_GetString(poArgs, 0, &strFileName)) return Py_BuildException(); CMappedFile file; const void * pData = NULL; if (CEterPackManager::Instance().Get(file, strFileName, &pData)) return Py_BuildValue("s#", pData, file.Size()); return Py_BuildException(); }

The source of the foxpack isn't usefull?

Since the source is public, also everyone can write an unpacker tool.

Eine kebab mit alles und scharf.

What is the general foreign language in the Turkish schools? I'm 100% sure it isn't english.

Reup: [Hidden Content] The password is the same.

Here is the code for old compilers: struct s_sort { bool operator() (LPITEM src, LPITEM dst) { return (src->GetVnum()<dst->GetVnum()); } } _sort; ACMD(do_sort_inventory) { std::vector<LPITEM> collectItems; std::vector<WORD> oldCells; int totalSize = 0; for (WORD i = 0; i < INVENTORY_MAX_NUM; ++i) { LPITEM item = ch->GetInventoryItem(i); if (item) { totalSize += item->GetSize(); oldCells.push_back(item->GetCell()); collectItems.push_back(item); } } if (totalSize - 3 >= INVENTORY_MAX_NUM) { ch->ChatPacket(CHAT_TYPE_INFO, LC_TEXT("INVENTORY_FULL_CANNOT_SORT")); return; } std::vector<LPITEM>::iterator it = collectItems.begin(), end = collectItems.end(); for (; it != end; ++it) ((LPITEM)*it)->RemoveFromCharacter(); std::sort(collectItems.begin(), collectItems.end(), _sort); std::vector<LPITEM>::iterator it1 = collectItems.begin(), end1 = collectItems.end(); for (; it1 != end1; ++it1) { WORD cell = ch->GetEmptyInventory(((LPITEM)*it1)->GetSize()); ((LPITEM)*it1)->AddToCharacter(ch, TItemPos(INVENTORY, cell)/*, isNew=false*/); } }

Go back to turkmmo and never come back.

Google it.

Pink dew, White dew, Yellow dew, Green dew, Blue dew, Red dew. - The potions with custome effects from flowers and empty bottles.