TMP4

If thats false then he missed the locale_inc.h, not?

"And if you ask, metin2.cfg nor config.exe are not in the autopatcher." Just to make sure, start your client directly without patcher and see result.

Did u installed that hp showing system or it comed with your serverfiles? If u installed then you should have the tutorial, and then there you can check where the types are declared and are they int. Also: If one is int, other is long / long long then it could make this bug too. Some public source have long long hp like gold. I do not have your source and i do not have that system, so i can't tell more.

Check if the HP itself (should be int in clean source!), and that HP showing system's datatype is int or greater.

Edit: Solved, i just made another board for hp at left bottom

There are several sash system out, everyone should check if it's ok there too. Mine looks ok by default: #ifdef __SASH_SYSTEM__ if (pSash) { const char * itemName = pSash->GetName(); ch->ChatPacket(CHAT_TYPE_INFO, " SASH: %s", itemName); for (int i = 0; i < pSash->GetAttributeCount(); ++i) { const TPlayerItemAttribute& attr = pSash->GetAttribute(i); if (attr.bType > 0) { const char * pAttrName = FN_point_string(attr.bType); if (pAttrName == NULL) continue; snprintf(buf, sizeof(buf), FN_point_string(attr.bType), attr.sValue); ch->ChatPacket(CHAT_TYPE_INFO, " %s", buf); } } if (pSash->IsEquipped() && arg1[0] == 's') ch->UnequipItem(pSash); } #endif Also it can be a positive thing to set the command's minimum requirements to implementor in cmd.cpp: { "costume", do_costume, 0, POS_DEAD, GM_IMPLEMENTOR }, Since player's don't need this command, it is only for debug as VegaS said. Edit: Also check costume_weapon, but mine doesn't iterate through attrs so it's ok.

No idea then sorry.

Yes

uiInventory.py __init__() takes exactly 2 arguments (1 given) Good luck

And if you try to set it? (with 0)

Maybe your CONFIG files overwrite it. I have this in config files: empire_whisper: 0 And every non gm player can see the other kingdom's whisper/chat.

Type it in google: [Release] 2010 / 2011 MC "sura" V2 100% Working all servers I can't provide direct link because of the rules but it will be the first hit in google.

Ah bro... My problem with that tutorial is that the server get instabil, because it will communicate with public ip inside too while it have internal ip. (So the internal communications will flow to the router and flow back) But when it starts, it works, no kicks. But since we can make the changes in clientside too (like the old "sura head mc" starter did) it would be a better solution for me. I only need these changes temporary while i run it in virtualbox. After these changes not needed. Hope you now understand me. Also i think it's just one line modificaiton in clientside But i can't remember where.

"I edited the sv side to get the right ip, that's all." So you did something similar to that tutorial i mentioned. But the ip can set in the client side too somewhere and then the server can work with his internal ip. I want to leave the svside alone with his internal ip, i just want to set in clientside since it's just a test server. The live server will not have internal ip so it will work without any modification, that's why i want to set in clientside until it's a test.

Please read the topic again, there is no problem actually, it's a normal behavior on home-root test servers since the server have an internal ip. But if the client connects to the public ip, it can work. That is what that sura starter did, and that is what i'm looking for.

Version of Files : 40k source Hi! So if a metin2 server's machine have an internal ip like 192.168... or 10.x... (so it is behind a router) anyone outside that local network will be "kicked" after selecting the character. (Why? because the server will give his internal ip to the client instead of his public ip.) There is this tutorial: Does it works? I rather say it work -ish The game acts very weird, sometimes doesn't works at all, sometimes works after it push some "connection refused". So what i want to do instead is, to make the changes at clientside (source) like the old "Sura head MC starter" did. About 5 years ago a guy gave me a client modification tutorial at skype, what worked. It was short but i can't remember where and what, and since it was in skype, i can't see it anymore. So if someone know the modification, can you please share with me? Thank you in advance

First of all thanks @Shogun for the release and @-YC- for the regens. I think the sound files are missing, can somebody upload it for me please?

The system works fine thanks @.ZeNu You should mention in the thread that there are more pages, not static anymore so it is not a problem if a chest contains a lots of item. Btw did anyone managed to set a tooltip to the chest icon in the drop window? Tried many ways but not succed yet.

So i installed the system from: [Hidden Content] View Drop 0.1 And i can't reproduce your error. I checked the files. There's no lock and there's no need for any, since it just send the open command for the item, cannot really dupe anything. I can only reccomend you to check if you have an older version installed, or if you screwed anything. (Most likely in Python)

So basicly the problem is that system lock the inventory as you open the chest, but not unlock it after the chest system closed. To Def Close / Def Destroy or the def when closing... write the xy.Unlock() Can't be more precisely without the code. BTW it is a free-released system? I do want to try if so, and then i can tell you the exact unlocking method.

If you check for implementor it's as good as set the minimum to implementor at cmd.cpp like everyone do. I just don't understand why do you need to log everyone who try /shutdown. There will be always someone to try, even normal players. If you want to ban them, it's not a good idea.

Just think a little. If you set the minimum for GM_IMPLEMENTOR then the if (!ch->IsGM()) LogManager [...] will never ever triggered since only an implementor character can go throguh the ACMD(do_shutdown) in cmd_gm.cpp. So you should set it to GM_PLAYER and keep that if above. But then every GM can use shutdown command so maybe it would be nice to edit to check the gm level too there, if possible. I don't know if you can check the gm level by default in 40k source. Edit: I quickly searched and you can, there is an ch->GetGMLevel() == GM_IMPLEMENTOR what you can use.

Why don't just set shutdown's minimum gm level in cmd.cpp? Then if a player will try it will get "command not exist" or something, i'm not using english files.

@WeedHex Sorry but now i gonna be honest with you! Your're so dumb when understanding the problem. The game want to load guild npcs and objects to every core. But that is not needed, map1 (index 41) is only at core 1. That's why it's cannot find the sectree at core 2, because it only exists in core1. I can't exlain you more There's no problem with the sectrees or server_attrs. The syserr only appears in core 2. @ElRenardo thanks i gonna test it soon! Working, thanks!

Do you have a localhost server with more then 1 core/ch? Buy a guild land, place some object and a guild npc, and go to the second core's syserr. If your map1 is in core1, go to core2's syserr and vica versa. Then you can see with your eyes