Think

The main problem is that you should not be having a game.core - That means the game crashed. The size of the game.core is relative to the information contained on it, it's sort of a crash dump.

Definitely try the game.core analysis if you have a core file like Night says, but I have my doubts that there will be anything in the syslog if it's segfaulting right on boot without outputting anything else. Did you make changes to the code before you compiled it? Segfaults are very common in C++ and can mean pretty much anything. Even a core file analysis can be misleading because the crash might be ocurring on an unrelated part of your code. Since you are compiling it yourself, you could try the good old cout spam to see where it starts failing (cout in main, cout in boot, etc).

Yes, that column holds the player's delete code for their characters.

What are you asking about exactly?

Don't waste your time with silly protections like that one. In general, don't waste your time protecting your server binary from use (it's just going to bite you back at some point). Protect the server its stored at! If it's interesting enough that people will want to steal it, anyone can easily bypass stuff like this. And no, the != 0 is not going to change a lot besides removing a warning if you have them on a high level. Nevertheless, the problem is that you are placing the code in the wrong place. It has to be at any point after GetIPInfo().

I suppose you don't have an user called metin2, otherwise that should be fine.

Even if he did, disregarding criticsm like you did (as long as its constructive as it was his) is dumb. He pointed out major flaws in this, I don't see why you dismiss them. But well, I'd like to point out another two things (minor) - Your ban script just does some empty selects... and most certainly does not ban anyone D: - You should indicate that half of your "bonus protections" have very poor cross-pc compatibility and will be empty (or FFFF-FFFF-FFFF-FFFF) a large part of the times. Also, serializing the username or the computer name is just a bad practice, at least in my opinion, because its the opposite of flexible (and terrible if you plan to ban using it). But well, to each with their own, and you just added it as a possiblity, so I'm not complaining about that

How is a quest involved in players being able to run commands? xD

Just passing by to point out this is most likely vulnerable to SQL injection (depends on the implementation of the query function). mysql_direct_query("INSERT INTO `pet_system` (`id`, `pet_name`) VALUES ('"..pc.get_player_id().."', '"..NewPetNm.."');") 19 chars is all it takes. ';DROP TABLE item--

Being smart, some tools to help you, and restricting access to people you trust... mostly. If my "mysql attacks" you mean SQL injection or something of the sort, that's just programming your website or whatever connects to DB correctly. This that you ask is in general a very broad subject (it's pointless to protect the database from outside access if you don't also protect your server where the db is), any answer you'll get will either be biased to one option you can use, or incomplete, because, well, this is broad. Also, there's a subtle balance in whether the protections you end up setting into place are worth the annoying it might get to use whatever you are protecting, so in the end, it should be your informed choice. However the fact that you ask how to protect Navicat might indicate that you didn't really search up how can your security be vulnerable... I think one of the best defenses is common sense, knowing common pitfalls (in configuring stuff mostly) and avoiding them, as well as general security recommendations. I suggest you look about the subject in google if you are really interested in it.

As you correctly identified, the speedhack control that there's in the server has nothing to do with actual move speed, just attack speed. There is not any kind of built-in measure against speedhack (and you can go at 500 speed without any setback issues). What you describe sounds like the position syncing is not being ran properly, either too slowly (and by the time the server tries to sync you, you are in already another position and it sets you back... but I never saw this happen), or too fast (and server receives many syncs together and decides you are hacking - this is to prevent movement by teleporting though, not speedhacking). Which mount are you using? Or well, which mob you poly to? Which is your base speed (w/out mount) and which is the bonus speed (w/ mount)? Maybe we could try to reproduce the error.

Deprecated doesn't mean removed though...

We are still looking for a Game Designer! If you would like to apply, though, please send an email to [email protected] instead of the outdated email address in the post.

And you added your new quest to locale_list?

So 80% of wom's players are romanians, but you don't accept romanian youtubers. Nice! Well, i guess you have some kind of strategy, and want more players from other countries too, but i can guarantee that many romanians won't think like that:D Or maybe you alredy have romanian youtubers, and i that case i'm sorry for opening my mouth xD You are correct, we have romanian youtubers, and anyway, we are an international server! It's good to have players from all over the world not just a specific region

Yes. CInstanceBase::CheckAdvancing() is your friend. There you have to check for OX map, make it ignore a certain set of collisions and allow the player to advance. Speaking of which, computing collisions is one of the most complex things in the game. Don't go deeper than this function, it's not worth it, and a bit of tweaking here should be enough. Don't be discouraged by all that weird code and DX vectors and give it a try!

Are you getting any particular error?

First of all, I clearly did. I would ask you to please check the code. Second, you guessed wrong? Recheck how bits are set and how the bit logic works! To reassure you, this fix has been running on WoM since March and all immunes worked fine. And I don't really understand what you mean about the work you did on your computer. @metin2team: no, else if does not need to be if. Each attribute can only be one type of immune at the same time!

So the problem before was not initialization. Now? What's the backtrace? Where does it get to with syslogs?

You cannot do this: std::string = "asd" You need to set a variable name (I don't know if you meant that). Regardless, it might be a library error, but that doesn't sound so likely. Can you post the rest of your code, at least Initialize()? Also, are you calling Initialize? This is a very pretty nullpointer you have there: Achievement::Login (this=0x0)

if (m_set_loginAccount.find(name) != m_set_loginAccount.end()) sys_log(0, "Thats weird "); return; Take a closer look there. You are always returning from your function! This is most likely not the problem, but it's worth noting that it is probably the reason why it doesn't go any further.

Well, I've been meaning to share an actual fix after seeing different attempts at it (one or two which were totally off and decided to remove some code, and the other which recalculated the flag on each check), so here it goes: The bug: If you equip an item without immune after equipping another one with immune, you lose your immune. Internally, the problem is that your immune flag gets recalculated every time you equip an item, but it bases off the proto immunes, forgetting completely about the actual bonuses on the item. The solution itself is rather short! In the functions CItem::EquipTo and CItem::Unequip (in item.cpp) Find: SET_BIT(dwImmuneFlag, m_pOwner->GetWear(i)->m_pProto->dwImmuneFlag); Replace with: SET_BIT(dwImmuneFlag, m_pOwner->GetWear(i)->GetRealImmuneFlag()); Then add the function referred up there to item.cpp: DWORD CItem::GetRealImmuneFlag() { DWORD dwImmuneFlag = m_pProto->dwImmuneFlag; for (int i = 0; i < ITEM_ATTRIBUTE_MAX_NUM; ++i) { if (GetAttributeType(i)) { const TPlayerItemAttribute& ia = GetAttribute(i); if (ia.bType == APPLY_IMMUNE_STUN && !IS_SET(dwImmuneFlag, IMMUNE_STUN)) SET_BIT(dwImmuneFlag, IMMUNE_STUN); else if (ia.bType == APPLY_IMMUNE_FALL && !IS_SET(dwImmuneFlag, IMMUNE_FALL)) SET_BIT(dwImmuneFlag, IMMUNE_FALL); else if (ia.bType == APPLY_IMMUNE_SLOW && !IS_SET(dwImmuneFlag, IMMUNE_SLOW)) SET_BIT(dwImmuneFlag, IMMUNE_SLOW); } } return dwImmuneFlag; } As a new function, it also needs to have an entry on item.h, so find: long GetLimitValue(DWORD idx) const { return m_pProto ? m_pProto->aLimits[idx].lValue : 0; } And add afterwards: DWORD GetRealImmuneFlag(); That's about it. I hope I am not missing anything, as we no longer have the original commit history anymore. If this is not enough, please tell me in the comments, I'll recheck again. Now, as a final note, since I criticized the other solutions (Though only one actually works) I will also go a bit against mine: Is this the best solution possible? It's probable that the answer is no, and that the really best solution involves changes in the point system as a whole. That is however more messy and error prone, so I stayed out of it for the time being. Anyway, hope it helps. Regards!

Add a syschat to the quest and see if shows up. Are you sure you compiled the quest? Does it throw out any errors?

Well I don't know if someone will have stomped with this already, but this is not an everyone-has-mostly-the-same-issues kind of thing anymore. You cannot expect to create threads with little information and get help. As I said, this info might be enough for someone, but chances are your bug is more or less unique, so...: Have you tried to undo the modification you last did? What changes/mods/tutorials did you apply to source? Did you change something about the (internal) point system? Which line did you take for the source? ...etc.

What did you do/which tutorial did you follow? What's the code? Did you check the error? (That you are using "self.inventoryPageIndex" when inventoryPageIndex is not defined). It's hard to help you without info...