Think

Sounds like you added extra "}"
 
Did you take a look over at this thread?

std::string strMapName = CPythonBackground::Instance().GetWarpMapName();     if (strMapName == "metin2_map_oxevent")     {         //BlockMovement();         return TRUE;     } Transform this into
return false; //(i.e return always false) If you still collide on any map at all... that's magic or you are not updating your binary or something, because that really works (this is the only place where these collisions are checked). If in fact you do not collide, then go back and make sure that your map is called metin2_map_oxevent (which, yeah, if you didn't change anything... that should be it).

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.

For a first post it's very well laid out, so don't worry! To the point...:
 
1. The quest seems fine. If it compiles, then it's probably double fine!
2. The gamecore source is a bit buggy, but in general - In this specific case, you could say it's just not implemented thoroughly. Possibly YMIR made the change before implementing this dungeon (I can imagine how, but I refuse to implement the crappy solution anyway) to allow server_timers on other states.
 
The thing is that because server_timers are not associated to any player, they are attempted to be ran from the start state, because they don't save which state they were called at. If you want to solve the problem in source, you only need to associate the quest npc created for the timers to the state. I know it probably sounds weird but if you take the time to understand how timers go in Metin2 you'll understand.
 
Solution #2 and much simpler would be to move all your when xxx.server_timer handlers to the start state. You'll still be able to start them normally from any other state. Also, I don't quite recall atm if the functions are state-bound (i.e you can't call a function from another state), but if the functions are throwing errors because they don't exist or something, create a new state called state __FUNC__ and paste all of them there. I usually use a __FUNC__ state when I need shared functions between states (Looks more organized to me, and I forgot already if there was a forced reason to do it).
 
 

Toxic, what you did is not helpful. Well, it is, but just partially.
It's pointless to give a solution without explaining why it is a solution! That way next time the person will probably have to ask again. And if someone finds this thread and has the same doubt as the OP, the thread is way less useful.
 
Okay, so, thread-related, and for the sake of completeness, you have two easy solutions:
 
Add a quest flag
You can set a quest flag with
pc.setqf("name_of_flag", value_of_flag) In this case, you could use something like pc.setqf("done", 1) at the end of the quest, and then a check for it at the start (right after the when)
if pc.getqf("done") != 0 then return end That way the quest would go "player logins -> the quest flag is 0, continue -> give all -> set quest flag to 1", and the next time the player logins, it will do
"player logins -> the quest flag is NOT 0, stop (return)".
 
---
Now, solution 2 (The one Toxic did), which is better, because it does not involve a quest flag.
 
Change state
Quests can have several states. State "start" is the default, which is the one you have on your quest. And when a quest is on a state, it only executes the code on that particular state.
So... if you just want for a quest to stop doing anything (and never come back), all you need is to redirect it to an empty state!
 
That's why Toxic added
state __complete begin end To jump to a state you have to use the set_state function, so instead of setting a flag like on the other solution, you can just do set_state("__complete")
 
Hope it's understandable enough.
Regards!

You can freely remove it.
 
 
I assume it refers to a CVS database: http://en.wikipedia.org/wiki/Revision_control
 
 
No, it does not.