Vanilla

strlcpy is not reserved to FreeBSD! There is an linux equivalent. [Hidden Content] Also, you don't even need strlcpy since c++ provides you with everything you need. If you need those size-bound functions you can just use the native c++ ones. strncpy would be the right choice for this case. And this belongs to the std library, not any os-implementations. So you don't need to worry about compiling on bsd, linux or even windows.

you'd have a look at auto_ptr or better unique_ptr (which you'd use instead of auto_ptr) The first one executes an Async-Query. As stated in db.h it does not return a value at all. So it makes absolutely no sense to store it's result anywhere. The second one is meant to be used when you want to store the results inside a variable. It's a direct query which means it'll be executed and the rest of the code will only continue when the query has finished and returned a value. You can later use it to e. g. check if the query was successful or not. In this case it's best to wrap it inside a unique_ptr (or in your case you mentioned auto_ptr which I do not recommend to use). So, if you do not need to check the queries results (as mysql errors will be displayed anyway) and you do not need a returned value for proceeding, you can just use a Async Query. If you do need the results, then wrap it inside a auto_ptr and use a DirectQuery.

Okay you can change locale_game.txt but what if a user changes it back? c++ > txt files With his fix the server won't respond with an accurate message. Next thing is that people could write a tool to connect with the server and start the bruteforce - this way they won't even need the locale_game.txt and just fetch the result packet the server sends them. Telling people to consider changing a simple text file on a local client instead of a serverside source isn't really that secure^^' It's easier, yes. But comfortability sacrifices security. Therefore: Thanks, I for myself didn't see it. Should be in the next vanilla core release with an option to change it (of course on by default so make sure it's secure)

I did not mean to insult you. That's why I said there was no offense intented. You're free to do what you want except for scamming. 500€ for fixing a problem must either mean it's a very difficult one or that you have a lot of money. I believe you're keeping your words. But I recommend no one to pay 500€ for a fix unless he wants to. That's why I said I'd help you for free^^ By the way: The backtrace is too less information. We need more in order to help you. The backtrace has to be deeper than just #4. We need that in order to determine what's causing the crash.

First it's a decision everyone makes for him- herself. Then: You don't really believe he'd pay 500€ for a fix? Come on, that's just ridiculous. I replied because I liked the idea behind it (of course I don't think he'd really pay at least half of it, no offense meant) and if it is a difficult task, I'd like to give my thoughts about it. For free. I don't know what's the problem about it.

Feel free to pm me with the exact error and as much information as possible. You don't need to pay, I'll solve the error for free.

Great idea! You've done well especially for the first quest. Here are some general tips though I'm really not a questing professional: 1.) I recommend you to use quest states. It's more readable and you can set states for each part of your quest. You can then also skip the server_timer part. I recommend the same structure that YMIR used for their quests: One for beginning the quest, one for completing each task and one for the finished part. You can set a questflag with the actual time and date to make sure you can kick yourself back to the beginning of the quest if you want to make it a daily one. 2.) Similar to 1, there's a problem with your server_timer. I'm not really familiar how mt2 handles multiple instances of the same server_timer. For example when players relog. 3.) server_timer does not use the player as an instance who created it. In fact it has no player instance at all. Using pc-functions won't work. One way to get around this problem is by passing the current vid to the server_timer function and use pc.select to fix this. But then there's another problem: If the player isn't online, it won't work. 4.) You'd have a look on your indentation. It's best to make sure the quest has a clear structure so you can always have a new look at your script and know in which segment your is. 5.) elseif tasks == 4 then is unnecessary since you return a finishing when-segment. You can just leave that part out and nothing would happen. If you want to add some code after that, I recommend you putting this case to the top of your if-segment, so you make sure you don't miss it and have a clear look at the script structure. 6.) if playerlevel +1 then won't work there. This is not a valid if expression as far as I know^^' It's a good beginning but I recommend you to compile the quest with your qc to make sure you don't have syntax errors. Keep up the good progress

Didn't know it had so many bugs. I haven't tried it yet. Making it compatible with VS 2015 clang is the last thing I planned to do. Anway, you can still compile it with the VS compiler. so nothing to worry^^

When is a good question. I want to spend more time developing and refining the source instead of pushing one release after another. This means it'll take a little bit more time but I'm working on it for a while now. The new source will drop gcc in favour of clang. It will be compatible with VS 2015, I recommend using clang as the compiler which is possible since VS 2015.

It's public but clearly outdated. A rework is in process and I will publish the cleaned, up-to-date source soon. I recommend not to use the old source because since the release of this source there are multiple vulnerabilities discovered which of course aren't fixed.

the vanilla core and it's source is outdated. It's not maintained for a long while. I've also improved on c++ since I clearly lacked skills. A new version is in development but unfortunately it's hard for me to release it. Also you've sent me a pm which I already answered. If there are any issues or bugs, just send them to me and I'll have a look if it isn't already fixed in my new version.

It's a matter of both. Length and complexity. A simple password consisting of 4 simple letters will be hard to crack with a bruteforce but not when you're using dictionary attacks. This is why both should be regarded. Telling people that a password consisting of 8 characters should be enough is just wrong. Larger passwords, better yet passphrases, with less complexity (but not none!) is the key to achieve good passwords. Everything else can be cracked easily with modern computers under some circumstances. Also tricks like replacing e with 3 is old and most bruteforce attacks know those patterns. Still the attacker won't know your pattern. Easiest way to get safe passwords is putting random words together (which have no relation at all), remove some letters or substitute them with something else and you're done. Easy to remember, hard to crack. Hackers won't know your pattern. As long as they don't know, their attack will be by far less efficient.

Source: http://xkcd.com/936

#pragma code_page() is changed now too! Thanks The case is already replaced. It will always use UTF-8. Also the GetCodePageFromLang got replaced to use UTF-8 too. I've made some research and it seems I was quite right about what I said, and not. The input the binary receives is not UTF-8 like I wanted it to be. Instead, it's WINDOWS-1252. The encoding procedure was wrong too. In the first step when the client receives input, it encodes it from multibyte to widechar (wchar_t). In this case it's imporant not to give it the encoding I wish to have but the encoding in which it's written! Because this step already encodes it to UTF-16, which is the standard encoding for wide chars. I had it to utf-8 which meant that every ö, ä, ü I received was getting mangled to 65535 code: Replacement character for invalid codes. I fixed it and changed it to LATIN first, it seemed to work fine. I tracked what happened with the variable. The conversion down back to a multibyte happens in the IME.cpp. It mangled with my code again because there was a length issue and maybe the decoding provided by WidecharToMultibyte is just worse. I replaced it and returned a widechar to the PythonIME function. I used boost::locale to convert it manually into utf-8. This was the point where I found out the input was WINDOWS-1252 and not LATIN-1, because it also didn't work with LATIN-encoding to utf-8. Only when I used the windows-encoding, it worked without flaws. And yes, even in the console it does work now. I can see the ö. But in the client there's still a weird sign but it's by far different than what I got before. It's not more than one sign and it looks like a typical case of "ö from latin/windows to utf-8". Now I only need to let the client display it like the console. Python does not raise any errors anymore.

Is your database capable of storing higher values? Please check if you can manually alter a table entry and set it's level to e. g. 300. Also make sure you have a look on syslog, maybe there's a query error there. Most likely you missed a step from the guide.

I guess the problem is located in the IME part. I mean, every ö, ä, ü, etc works fine when I read it from documents (.py for example). But they won't work when I use them inside input elemts. IME is the part that controls this. And have a look at the function PyObject* imeGetText(PyObject* poSelf, PyObject* poArgs) which only calls an IME function to retreive the string. After this very function call the text already got mangled with. I can't read it neither as LATIN nor UTF-8 properly. The whole IME uses only UTF-8 anymore, I changed the encoding completely there. I didn't even hand it to python and the text still doesn't work as intended. The console shows this. The output there is made before Py_BuildValue is even called. So it should print out the text fine but it doesn't. @Ken, your function does work, but it has no effect. I changed it back to the original one. The problem isn't located there I guess. Also this is supported due to Py_BuildValue calls an internal conversion from python, not the one provided by PyString_AsString. So this function won't be called anyway in this case. Elsewhere it just works as intended. The fact that the name already got mangled before it even reaches python makes me believe that it's not a python problem anymore. Still I need to know where I can make sure IME gets the right encoding and the input I make actually uses UTF-8 and not anything else. The whole client has UTF-8 as it's encoding specified. So normally there should be no problems.

In this case I guess chardet won't help me. I wanted to know what happened to the string itself. When I check the python object I will always get the same result. Every string in python is a unicode string. Checking them isn't necessary, it's necessary for files etc.. So my python code is actually only capable of creating unicode characters. The problem must be in the binary part :/ If I change the encoding in CIME::GetText to CP_LATIN (which is capable of using ö, ä, ü) the output is always ? for these characters. It won't raise an error. Also the characters ß and ´ are gone though + and ` do work as intended. When I change back to CP_UTF8 those characters also produce weird results.

I did. Every string gets encoded. These are the functions I use for string encoding: Maybe I should change the ignore flag to strict and see if errors occur :/

Already had a check on that. It's changed. locale.cpp int MULTI_LOCALE_CODE = CP_UTF8;

Hello metin2dev, I wanted to ask for help regarding encodings. There's a lot of trouble and one big thing when I migrated to python 3.5 on the client is the encoding. I managed to make all the ui files etc. work with utf-8. The results are clear. You can see everything, even characters like ö, ä, ü. In German language, they're very important. So what's the big deal? The problem is the input. Everytime I tried to input such characters, the text box stopped working. The reason for this is an encoding error python responds with. It tells me that utf-8 can't decode these bytes. I checked the IME part on the client source after that. I've made some research and soon I changed the whole encoding in the source to UTF-8, except for the WebBrowser project which still sticks to CP_ACP. But that doesn't make a difference anyway here. The textbox started working and there are no encoding errors more. Instead, as you can see in the picture, the following weird result shows up. As you can see I'm debugging the client and added a line to make sure it prints the GetText results from IME before handing them over to python. This symbol happens to be there when I try to type an ö character. I guess there's some messing up with encodings and therefore this weird symbol appears. Maybe you have an idea what could've caused the error. As already stated the whole client should use UTF-8 now. Thank you for your time! Best regards, Vanilla

Update FreeBSD. It's the best way to handle this error.

To be honest, shogun. You were hiding important things from me and that's something that's a fact and you know that.I do not holde a grudge against you and the reason I've moved has nothing to do with you. Am I not allowed to leave this board if I want to or do I have to tell you within details why I want to? Unlike you I'm not telling the story between us everyone to the broad mass. Please refrain from posting non-related content. Your personal issues with me has nothing to do with this. Oh, and I don't think I have a personality issue. But that's somethin I need to know by myself, I have nothing to do with you, so please stop interfering with thins that are none of your business. I'm still not hating you, you'd think about if you're the one with the personality issues here..? And I've talked with the staff of epvp. As you can see. The thread is still up. It's alright, so don't worry about that. @Ridleypr: Check your quest-table. There the last switch time is stored. Remove it and start your server again. There you go!^^

vanilla is now released on epvp. I hope this way it'll reach more people and I can publish further versions there.

execute got removed since it causes crashes when the quest you're calling doesn't exist. It's a work for 2.5, not 2.4.1 If you're brave enugh you may remove the return at the beginning of the function when you're working with IDA. But I don't recommend it.

There'll still be updates. I've managed to fix the drophack for example. But they won't be released here. The only reason I kept on this board was a agreement I've made. The other side didn't want to keep their words so now I'm gone. Maybe I'll find a place to distribute it in a safe environment for me. Stay tuned, I'll tell you if I've got new information.