Think

if vnum != 71124 and vnum != 7500 and vnum != 7501 and vnum vnum != 7502 and vnum != 7503 and vnum != 7504 and vnum != 7505 and vnum != 7506 and vnum != 7507 and vnum != 7508 and vnum != 7509 and vnum != 7510 and vnum != 7511 and vnum != 7512 and vnum != 7513 and vnum != 7514 and vnum != 7515 and vnum != 7516 and vnum != 7517 and vnum != 7518 and vnum != 7519 and vnum != 7520 and vnum != 7521 and vnum != 7522 and vnum != 7523 and vnum != 7524 and vnum != 7525 and vnum != 7526 and vnum != 7527 and vnum != 7528 and vnum != 7529 and vnum != 7530 and vnum != 7531 and vnum != 7532 and vnum != 7533 and vnum != 7534 and vnum != 7535 and vnum != 7536 and vnum != 7537 vnum != 7538 and and != 71125 and vnum != 71126 and vnum != 71127 and vnum != 71128 and vnum != 71137 and vnum != 71138 and vnum !=71139 and vnum !=71140 and vnum !=71141 and vnum !=71142 then This is the problematic line. Please read it, and you'll see where the error is (There are two, one is the one PACI pointed out, the other one, the one that's currently breaking the compilation is "vnum vnum") And thing two: This is the problem of huge lines. You can't easily see little typos. Why don't you use ranges? Less error-prone, shorter, everyone understands it. if not (vnum >= 7500 and vnum <= 7538) and not (vnum >= 71125 and vnum <= 71128) and not (vnum >= 71137 and vnum <= 71142) then return end

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: [Hidden Content] No, it does not.

What do you mean? Which bonuses are not showing up?

You can allow for functions or variables on chat by tweaking the qc.cc file - Did it first day with source to allow precisely that. Fair warning, though. As with any parser, at first it's confusing to look at the source xD You want to change before here: current_when_argument += os.str(); And what I did was implement a recursive check for parenthesis to allow arguments on said function call (The parenthesis for the func call are the only real problem that needs to be changed). It's not very tested since we didn't end up using it, but I can confirm that my initial tests worked, compiled and displayed ingame. This is what I added if I recall correctly: //Accept functions as valid arguments const char TK_OPEN_PARENTHESIS = '(', TK_CLOSE_PARENTHESIS = ')'; if (lexstate.lookahead.token == TK_OPEN_PARENTHESIS) { int depth = 0; while(lexstate.lookahead.token != TK_CLOSE_PARENTHESIS || depth > 1) { if(lexstate.lookahead.token == TK_OPEN_PARENTHESIS) //allow function calls inside as well depth++; else if(lexstate.lookahead.token == TK_CLOSE_PARENTHESIS) depth--; next(&lexstate); t = lexstate.t; os << t; lookahead(&lexstate); } os << TK_CLOSE_PARENTHESIS; lookahead(&lexstate); } May require another change somewhere, but doesn't look like it atm. I don't really remember the original state of the file so I can't say for sure.

If you have source, input_main.cpp is the one which takes care of this.

As said, the map you are trying to create the dungeon at must be at the same core your current map is at (i.e in the same MAP_ALLOW). Are you sure you are putting BOTH in the same map allow?

No need. Not everything that goes to syserr is an error. It's just information more important than all the crap that goes to syslog (Useful crap sometimes, don't get me wrong, but searching through it is hell)

We didn't see any performance downgrade no. Probably having many loops executed every second can be problematic, but if you space them enough, say 1 minute, the server usually handles them good enough (Although of course it depends on what you are doing when the timer is ran, and if it has a high server load, but well, that's unlikely. The timers running by theirselves don't present any special load, that's what I meant).

MySQL is usually the bottleneck, but in your case, the problem is in neither. First: is it better to use setqf or mysql_query? setqf, no doubt. It's cached from the server side. But in the case of a complex pet system, it's probably easier to use mysql_query. You may lose performance using mysql_query, but it also may be easier to understand and develop than tons quest flags (For example, with a pet table). You decide what you think is better, I don't think using mysql_query is a bad idea here. But as I tell you, it's not your problem. Where's the delay then? a ) 50% In your quest receiving mount/dismount commands. b ) 50% In YMIR's terrible pet mounts implementation. And sadly you can't fix a ) nor b ) unless you compile your own core (and do the appropiate changes).

The format of your code paste is completely screwed up it's impossible that anyone will help you with that code. Try to edit your message with proper indentation, line breaks, and no html.

Now, xCPx, if I recall correctly that's worse than an actual mysql_real_escape_string. According to the docs FILTER_SANITIZE_MAGIC_QUOTES does the following: Apply addslashes(). And the documentation for addslashes says: "Please note that use of addslashes() for database parameter escaping can be cause of security issues on most databases." The preferred funciton is always mysql_real_escape_string, because mysql knows more about your connection character set and what character needs to be scaped better than addslashes (addslashes can be easily bypassed with multibytes: [Hidden Content]). And even then, mysql_real_escape_string won't magically fix your SQL injection problems either (Read [Hidden Content] ). The only real solution to SQL Injection is the proper use of prepared statements (or well, other filters like intval for things that would have to be a integer). Escaping whole post/whole get calls is nonsense and adds useless overhead at the risk of devs still misusing it. Also, I'm sorry to say that you are wrong in both points No, and no. mysql_real_escape_string calls the mysql library doesn't call the mysql server. And well, because of that, that's certainly not why sanitize filters were created. Edit: Wow had to get my facts straight. I originally thought there was one vulnerability on addslashes but that may have been fixed now - Since I'm not sure I won't talk about it. Edit2: There still seems to be. Added back.

If it's not the affect nor part_hair it's the item. Why don't you unequip them all from db?

Your changes to part_hair on player shouldn't change much, I guess what's messing in here is the old affect, or the items itselves. The affects are stored at the affect table. With server off, try the following query: DELETE FROM affect WHERE bType = 514 (although by this logic, that'd mean that affect.remove_hair is not really working... which I guess can be but it may not be this and you'd need to unequip the items that are equipped)

You can probably replicate the libs effect in no time with source. It's true you must know C++ but if you do, and want to learn more, it's definitely better.

Ah, sorry for not understanding then. Right click on the file > Open with. You'll see something like After clicking on the desired one and hitting ok, you will get prompted for the encoding. Auto detect doesn't work. You want either Korean EUC or Korean ISO, one of the two worked, the other didn't (If I remember correctly Korean (949) was not working properly).

Using a timer is a bad idea. With some good timing one can block the quest from actually running by starting another quest and leaving it be on a wait state.

I already said that, and he said he does. "limit" is perfectly valid. That doesn't matter it's a parse error. SirGath, if all the tabs are correct, are you sure that's the problematic group? The error you receive is because it doesn't find the second component of a line, so it must be that you are missing a tab somewhere. If you don't find it, I suggest that you copy the whole text and make spaces/tabs visible and paste it someplace where you can clearly see the tabs like on Sublime (I'm not sure if it's configurable in Notepad++, I'd guess so, but I don't remember anymore). This is what I mean: (note the dots, which are spaces, vs the ---, which are tabs)

Are you sure you want to import _socket and not socket? Maybe try from socket import _socket; or directly import socket;

The main disadvantage I see is harder testing (the generated modules take a bit to compile) and the increased binary file size, which players will have to download every time you want to change anything on python. Besides that, well, you gain (a little) in speed and in protection. The harder testing can be countered by keeping separate binaries and just making normal root packs for testing, and the increased size can be largely reduced by packing the executable, to around 3 MB. So I'd say it's a win.

If GetChild is failing I would say that you have not updated uiscript.

There's your issue - You have to tab the mob too. ([TAB]mob[TAB]636)

It's an interesting way of allowing more gold trade without source. Clean, and well thought of!

What did you try? StartDestroyEvent takes a seconds parameter, so this should do: pkItemToDrop->StartDestroyEvent(5);

You didn't change it to the right encoding. Try with the korean ones, I don't recall which one was it but one works