Vanilla

Developer
  • Content count

    282
  • Joined

  • Last visited

Everything posted by Vanilla

  1. Hello dear dev's, this thread is created just to suite one specific topic: The vanilla core. I'd like to announce that the new version will be released very soon (this time open source). Meanwhile I'd like you to take part in it! I have some few suggestions that I'd like to commit. But not only this - I want to read your suggestions. What do you think could be part of the new vanilla core versions? The topic is also meant for the future, so when I release the core it's thread is only for troubleshooting and feedback. Features etc. can be discussed here then to give you a better overview about the project. Also I want to note one small thing: I do not recommend anyone to use the older vanilla core distributions! This has one simple reason: They're outdated. New security breaches were discovered and they are not fixed in those binaries. If you're using the source you can fix them by yourself. But I recommend you to wait for the new version. At first I'd like to say that there will be 3 different versions. All have their own codenames and have a different set of features: - STABLE: This branch is only focused on the main goal of the vanilla core - a core that is smooth, stable and fast along with many, many CONFIG-options to choose from so you can suit the core by yourself. Feature changes will be delayed until they're approved by testing on a different branch. Security fixes will be tested directly and pushed to this branch as soon as possible to ensure a secure experience. - BETA: This branch is focused on testing feature changes. They could be unstable, but of course the aim is not to be. It's not recommended to use this on production servers, only for testing purposes. New features will be pushed directly to this branch and a core along with it's source code will be released as soon as possible. - SANDBOX: Yep, I want to create a sandbox. This way I can re-develop features I would've released with my project (damn the HDD crash). In this branch you can suggest features that may not suit everyone. It's mainly for releasing working features and concepts and play a bit with the source. One side note: I won't use git nor svn. I'll develop locally and upload the core along with it's sources accordingly. Everyone is free to implement their own code and send it to me. After I've reviewed it chances are it'll get into the next vanilla version. So, there are the first few things I'd like to ask you. 1.) What do you think about the option to have another compression algorithm? (I'll also release the client part along with an archiver). My choice would be lz4hc instead of lzo and I'd like to give you the option to switch between those two compressions. Of course standard would be lzo to ensure compatibility. 2.) What do you think about new ways of encryption when not defining the advanced security macro? Normally this would lead into a pong being sent and xtea being used for encryption. I'd change xtea with something else - my choice would be AES-256. 3.) What would you think about a new client config? Of course it'd be open source. Let me hear your opinions and please feel free to give me every suggestion you may have.
  2. Development is on halt since rl took over, as many of you may have noticed. I'll continue the developing once I have more time for it. Sorry for the inconvenience, the project of course isn't dead.
  3. Then we'd hurry up and start now
  4. I know it is but using git and svn could be troublesome if it gets closed. And I won't have a server nor do I want to rely on something for this work. I won't publish any branches but that doesn't mean I won't work with revisions locally You're right with the send it to me. I'll change that into "Post it into the release topic". This way everyone can see who posted the code and where it came from. Additionally I can give credit to those wo contributed to the project and add a link to their post in my thread. Thank you! Yep, I already replaced it. It's not that difficult and maybe I'll write a guide to it though everyone will be possible to clearly see it once the project is released. The major reason for the change from lzo to lz4 is the client, not the server. Of course using a ramdisk or ssd will improve loading times by a lot it doesn't mean everyone will do that. If you're on a laptop chances are that you don't have that many RAM nor an ssd to work with (of course you'd possibly upgrade..). But it's just for the broad masses and getting a faster algorithm is always better as long as it's safe, no matter the circumstances
  5. 1.) You're developing for the broad mass of different players. Not everyone has an SSD. Some (like me) are using both SSD and HDD. Also a SSD won't magically fix everything for you since compression/decompression is not only limited to the type of disk you're using. 2.) It's for people who don't want to enable that macro. If you disable it, the server and client will use a combination of lzo and xtea. Also instead of the handshake they'll use the old pong. I never said I'd touch the packet encryption with this macro enabled. 3.) Isn't that a little bit overkill? Thanks for your suggestions! Yes, something like changing all the new to unique_ptr is a lot of work. I changed a few of them but not all at once. I want to make sure I don't make a mistake there and that's why I think I'll first fix the critical stuff and change them with future updates since the main goal was to create a stable binary. But the suggestion is good, I also had the wish to change at least most of the raw pointers into unique_ptr..
  6. Sound great, Socialized. I'd love to! I'm also planning on developing the config with c++. The one I presented earlier was with c# but I want to move to qt and therefore do it in c++. Would love to hear your opinion about the other two points. Also, if anyone has any suggestion, feel free to post them here
  7. 1.) Yes. Compression speed is slower than in lz4, but the decompression speed is very fast. Since the package-files are only compressed once (when you put them together to create an epk and eix archive) it's by far faster than with lzo or lz4. Your users will experience faster loading times. Packets will be compressed too but that's not a problem since they're small enough that the slower compression speed doesn't slow down the connection at all. 2.) Me too. And it's also faster than xtea 3.) Some options will be better adjustable than in the old config. There will also be new options, I've shared some screens before but since my HDD crashed I couldn't release the config. But for more options there is some work on the client that needs to be done. I'd for example add v-sync, anti-aliasing or texture filtering. Especially on the graphics side there's a lot we can improve without much effort.
  8. First there's a problem with textures not being there. CGraphicImage::OnLoad: CreateFromMemoryFile: texture not found(d:\ymir work\effect\monster\yeongi.dds) This clearly states that the client can't find your texture file in the given path. So make sure you packed your client properly. For debugging purpose you may manually copy the yeongi.dss to the path so the client can load it from your disk directly. Then you'd attach the mse files mentioned here. Without them it's not possible to help you fix the problem.
  9. SYSERR: Jul 31 19:15:27 :: InitializeTables: InitializeMobTable FAILEDSYSERR: Jul 31 19:15:27 :: Initialize: Table Initialize FAILED That tells you everything. DB doesn't boot, that's why the cores cannot connect to it and therefore fail to boot too. And the error clearly shows that something is wrong with your item and mob tables.
  10. Hello everyone! I'm currently working on a secret project (yeah, it's a sever. Not so secret anymore, huh). Since there are a few topics in this section regarding team searching I'm going to hop on the train and ride along. I won't go into much detail since you can guess what it will be. What you can expect: - Friendly and serious team (yes, it is. Though I want to create a funny atmosphere I do not wish to have any corruption or something like this. You'll see what plans I have to fight against this when you send me a PM) - Very, very, very customized server (yes, I literally changed almost everything, adapted it and made it hopefully better than before. Even small changes can make a difference) - A lot of features in this server (I bet it won't be boring. Hopefully) - Experienced team (whoever may know me knows that I'm a perfectionist and know a few things) - long-term project aimed to create a better metin2 (pretty self-explanatory) - The server will run at an updated customized vanilla core (for all those who are looking for a new version: It will come. Be patient.) What you'd bring in: - Experience (at least a bit, I don't want to do everything alone. You don't have to be a c++ developer or a big fish in the sea but if you come with literally no experience you won't get in) What I am searching: - literally everything. Except with one thing! I currently do not want to have Moderators, Gamemaster or something alike since the project is currently under development.. And that's it! If you want to join in then feel free to drop me a pm. You don't have to write a whole application (damn we aren't a business here). Just tell me a bit about why you want to join, what you can bring in, who you are (funny, eh? No need to tell me your hobbies, name, and where you live... but knowing your age is important). I do also not care for the age as long as it's not too low (at least 16 years old if you have manners, know your stuff and behave in a correct way). And that's all for now. If you have any questions feel free to ask as long as they're fitting the topic. Best Regards, Vanilla
  11. It really is sad and I wish I could've finished that. Anyways, I think it's a good time to move on to something else. The ideas and concepts are still in my mind and maybe one day I'll have a chance again. Until then I'm gonna write some guides, time to let the game progress a lot. Expect new compression and encryption algorithms, a new packer with sources and of course the beloved python3.
  12. Sadly the project has to be closed. Reason for this is that my drive gave up. I've lost all the files and everything regarding m2. Backups were corrupt so there's no chance to recover from this. Therefore the project is sadly closed. But I won't stop developing on m2 and will soon publish some guides (since everything is still in my brain^^'). But recreating such a big project would take too much time. I'm sorry :/
  13. strlcpy is not reserved to FreeBSD! There is an linux equivalent. http://linux.die.net/man/3/strlcpy 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.
  14. You will. I just not want to reveal everything right now. The project is nearly finished, it just needs some polishing There are a few things I want to disclose. 1.) There will be absolutely no itemshop or anything alike. If you want to show your appreciation you can do it with donations but it won't affect your gaming experience (except for a good conscience ;D). It's a hobby for me to develop and I did sooo many things, tried out a lot of stuff and implemented various features that I think it'd be a great game. 2.) When the project launches major features will be open source. Why? Because the things I do aren't just for myself. It's for making metin2 better and help the community to make bigger progress with working on the source. Of course not everything will be the exact same. For example the server uses an alternative encryption and compression. I won't shout everything out since people would start cracking the client and do bad things with it. But there will be a few guides how to create your own 3.) I mentioned before I want to create a new experience. This means that you will still have the feeling of our good old and loved game but with much greater polishing. For example various people and also I had some thoughts about how to rebalance the game (some people may know my post about recalculating defenses). The thing is - all the great stuff and even more is combined together to rebalance the game and let the players feel what they are. If you're a black mage sura, you want to have those dark balls flying around crushing your enemies. Or an assassin that just wants to sneak or jump in, kill it's target and do everything to get out alive. The old metin2 had those classes and they did work - but not as they should. Also things like mages being able to do their job in PVM. Think about your spells crushing a metinstone! In the past this wasn't even possible that well but with the changes you can also farm with mages. No need to lock down to PVP/PVM anymore, just be good in both ways. 4.) In the project you can do everything alone. Feel free to explore the world, farm and do stuff. But united you'll notice that you're going to be by far stronger. The bosses are rebalanced to be challenging but rewarding. So expect more from bosses in all ways! 5.) Players define the pace and you define if you want to go along. Some big changes are made so smart players can even defeat people with higher levels. Equipment isn't all anymore, it's about your strategy and how you play against your opponent. This means that there's no simple "I smash on my keyboard and win"-situation. If you do that, you'll most likely hit your enemy with everything, yes, but it won't be as effective and his revenge will hit you harder. For example I want to take the warrior class. There's a lot done there, his three-strike ability won't deal as much damage as before - but you can reduce the armor of your opponent if you hit it. There's no stun skill anymore for you, but if you time your skill right, it can boost you to catch up on slippery enemies like assassins who like to jump and blink around. And if you want to carry a bow? Stop thinking about just getting in front of your enemy and unload everything you have. In this project the effects are reversed - the farther you are, the harder you hit. Enemies can react with closing the distance and you can try everything to keep it because if they get too close you're a more vulnerable target then you were in the old metin2. 6.) Rates are an important topic when it comes to servers. This one has mild rates - you won't get tons of money just from killing monsters, but it will be enough for you to get around. Why? Blacksmithing costs no money anymore except for occasions when it's important. For example high rank equipment. Also even the blacksmith learned how to do it right - he won't break your equipment apart anymore... This will rebalance the money and gives you the opportunity to spend it on things you really need (of course there are some more things you can spend it on.. but upgrading low equipment doesn't fall under these things). Also I mentioned before that players will define the pace. And that's literally. There is a special chest you can earn in some occasions (like fishing, mining, daily quests, bosses, metinstones). It's contents depend on your level. If you are above the average level of the server (lv1 characters not included) you will get exp depending on your level until you hit the average level. Then, things change and you will get gold out of the chest - again, depending on your level. The higher you are above the average level the more you'll get. But chests expire so it's not a bight idea to store them for eternity.. And that's all I want to disclose for now. It's a lot of text but you can just read what interests you the most and ignore the rest if you feel like it. I won't be mad if you do
  15. uhm, I don't make money out of it. No itemshop. It's a hobby project for enthusiasts. I can't offer an itemshop for things I didn't do. So the only thing I can get out of it is the fun to create and maybe donations people can give. But there's absolutely nothing you can buy. So yes, I keep my word.
  16. Welcome to the second part of my guide series. This time I'll tell you how you can compile with gcc48 or even gcc49 like it's the case in vanilla and how you can use c++11 which will allow much more and faster instructions than the old one. At first we need to have a look at our Makefile. Make sure you edited the Line SVN_VERSION so you won't receive any errors. Try it e. g. to SVN_VERSION = mt2 Next, you'll have to declare what compiler you want to use. Of course you first need to install the compiler, but I guess it's clear (if you haven't done so, just use cd /usr/ports/lang/gcc49 or even 48 and use make install clean). The line normally say: CC = g++ This is the standard compiler. You may want to change this line to: CC = g++49 Or if you're using 48, change it to CC = g++48 Now before you compile it, you'd recompile all needed libs with gcc48/gcc49 too! So change the compiler in the makefile and recompile the sources in the following directories: libgame/src libpoly libserverkey libsql libthecore/src And then you need to recmopile cryptopp with the newer gcc version too! It's located in the Extern/cryptopp-directory. Now you can compile your game and even your db source with the newer gcc version. You may experience a much smaller file size. The newer compilers will produce an even more faster and smaller gamefile than before. Oh and if you want to carry out the lib-files you're using on your compiling machine (to make sure everything runs smoothly) you may use the following CFLAG: -Wl,-rpath,/usr/local/lib32/metin2 You can change the path to whatever you want! If you specify this, you instruct the linker to use this path so whenever you start your game/dbcache it'll first look in the given directory for the right libs and then, if it can't find the libs there, it'll look elsewhere. Using c++11 is a must-have if you want to make new statements. The source code how to load the database without txt-files needs the newer c++ version, so you'll have to upgrade at least the dbcache for it. But you'll experience even more smaller file sizes with this change so it keeps up with more and more advantages. First you may want to specify the new CFLAG. It's called: -std=c++11 This tells the compiler to use c++11. Keep in mind that not every compiler can use c++11! The newer gcc version can deal with it without any problems. If you compile your source then, you may find a new error occuring! Open every .cpp and .h-file in Notepad++ and do the following things (you can use the mass replacement of Notepad++): replace typeof with __typeof replace auto_ptr with unique_ptr Watch out for the common-directory too! Then you can recompile the source and it's done! Oh and for this you don't need to compile every other sourcecode with c++11. You can e. g. only compile the dbcache with it. Last small hint: You can play with the tuning flags to get even more optimization. -O2 can sometimes be good, but sometimes it's better to use others flags. You can even use -O3 or -Ofast. But be careful with this and consider using -fstrict-aliasing so the compiler won't optimize instructions that'd lead into a crash if it'd optimize them. And always: Pay attention to the warnings your compiler throws at you! They aren't there to just "hang out". They'd lead into crashes, so care about them. Lastly I hope you enjoyed the guide. As in the last one, please tell me if it's good or not and if you have any questions: Feel free to ask.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. First you can use some kind of a pool for your quests. Just write a state for each individual quest you'd like to use, write them into a list. Then you can use a math.random(1, length-of-your-table) to get a random quest out of your list. This is the initial part. To have "a new quest each day" you can use os.date(%d) to get the actual day of month. You can use questfiles to store this information into a persistent variable. That's all With this you can achieve that your players will get a quest each new day.
  22. 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
  23. 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^^
  24. 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.
  25. 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.