• Content count

  • Joined

  • Last visited

Everything posted by Vanilla

  1. Greetings! The new beta is finished! I'm proud to present r70140-BETA. This time a few things have changed. And in this revision, we have a lot of new stuff. That's the reason I want to make a BETA so everything's tested. In the following I'll provide the download link along with the things I'd love you to test. *** DISCLAIMER *** I am absolutely not responsible for you replacing your core with a Beta-revision. This is clearly undergoing development and had not enough testing to be labeled as stable. Please do not use it in production envirionments unless you're sure what you're doing (and even so it's madness). It's meant for testing purpose. Our main goal is to achieve a stable core. As soon as patches come in, I'll tidy up the patchlog. 1.) What's new? + Boot-Trigger for quests With this you can execute commands, timers, and all the stuff you'd like to have just on boot-time! * revisioned the unique class and added a ton of possibilities to it! More down below! + Added the functionality to create unique-groups + Temp-Variables for quests * upgraded all libs and moved completely to the newest clang version * fixed some big security issues in the source code * fixed the ingame ban and unban commands * unified tables and gave them a new way: unify! * Revisioned the Makefiles and gave the source a new, easier structure * Removed all external dependencies - you won't need them, just install them by ports. No External-folder necessary! * Partial implementation of the wolfman (claws etc. are added, needs review) - removed boost dependency (no boost lib needed yay) And basically everything that has been offered in the earlier versions of the vanilla core. Nothing should be missing. And if you miss something, just feel free to tell me! 2.) What needs testing? There is a lot of stuff to test! In this earlier BETA-stage I won't give out the source code. I will do so once I've made sure the core runs well enough to be released in public. Though there are few things I'd love you to test out! * Please check if the core is vulnerable to any security breaches you may know (also the public ones, don't know if I missed something) * Please test out the new features! I'd really love to know if the new unique-functions and the boot-trigger does the job. 3.) Explanation to new features * Unique with container support Unique has evolved! This time you have a few new possibilities. Don't know what unique is? Here's a short explanation: With the unique-questfunctions you can spawn or set mobs, npcs and now even players to have a unique name. This name is stored into a unique-container. You can access this container and get all the vid's by their unique name (also called: the key) So for example you can spawn a boss with a key. Later on you can check if this specific mob has been killed or not. Or you can set his hp on-the-fly. There's basically no limits! And now with the revised system you'll have even more options. The new unique system works with containers. By default there are two containers reserved: __DEFAULT__ and __CHARACTER__. The first one is for all the basic stuff. And the second one is reserved for players. Now, as you may have noticed, there's a default one which means that the container-stuff is optional. If you just use the unique-functions without specifying a container, it'll just use the default stuff. But you CAN use your own containers just as you want to. You can create, delete and list all the containers running. There is a list with all the quest-functions down below. * Boot-Trigger This is pretty self-explanatory. With this release you can use "when boot begin" to specify a block of code that will be executed once the core has been booted. * Temp-Variables With the new temp-variables you can set and remove player-specific variables. They are stored in the core and not written to disk or database. So be careful because they might get dropped once the core shutdowns. It's just a quick storage for people who want to have something like a cache for quick access. The new quest functions: nil unique.spawn_unique(string key, int vnum, string pos=unused, string container=optional) nil unique.set_unique(string key, int vid, string container=optional) nil unique.purge_unique(string key, string container=optional) nil unique.kill_unique(string key, string container=optional) bool unique.is_unique_dead(string key, string container=optional) int unique.get_hp_perc(string key, string container=optional) nil unique.set_def_grade(string key, int def, string container=optional) nil unique.set_hp(string key, int hp, string container=optional) nil unique.set_max_hp(string key, int maxhp, string container=optional) int unique.get_vid(string key, string container=optional) bool unique.exists(string key, string container=optional) table unique.get_container_list() --this prints out all the unique containers table unique.get_container_list(string key) --this prints out all the vids in the unique-container "key" nil unique.remove_container(string key) --removes a whole container (flushes it when called on standard containers) nil pc.temp_var_set(string key, string value) string pc.temp_var_get(string key) nil pc.temp_var_delete(string key) Thanks a lot for participating! If there are any questions, this is the topic related to it. Further releases will be made public here too! If you'd like to contribute, just post code additions here. Download: Here Download (source code): Here Password for both archives is: vanilla Libs are included. If you're building your own vanilla binary you'll first have to move into every project of the Internal directory and rebuild the libs. The main Makefile is not adapted yet, I was too lazy Best Regards Vanilla
  2. Nope, the error is not related to the quest at all. You might want to try and reproduce the quest to see which conditions are needed for this bug to trigger. Maybe something in your quest is wrong.
  3. you've built devIL the wrong way. Make sure it's built with clang and 32 bit (it you're running a 64 bit os). The linker found your lib but it can't use it (that's why it's telling you it's skipping the incompatible lib).
  4. simple as that - don't let the bonus overexceed 100 There are some bonuses that do not increase your rates by a certain amount but the chance to actually get a boost. Stacking exp bonuses for example doesn't work like you'd expect it to. The most common exp bonus doesn't add to your exp, but it is chance to get a bonus. If you exceed these bonuses over 100 the server is warning you since.. well, it isn't made for p-servers and their unrealistic high bonuses. So how to fix it? Either disable it via source/dif or simply don't let the people exceed them. The warning even tells you what bonus you're exceeding and how far you're doing that.
  5. But he is absolutely right. The Client normally doesn't handle damage values if there's a critical hit. Though there's still something implemented which you can use for your needs. The client is able to display different styles depending on the damage types. For example poison could possibly be showed in a different style - and critical hits too. He even showed you the line which does that. Normally it's commented so the client doesn't use it. If you remove the comment, the client will use the critical.mse to determine the way it shows critical hits. And in effect\affect\damagevalue you can find everything you need, even the critical.mse with which you can display different colors. In your case that is violet. I think both of you need to calm down a bit... There's no need for insulting each other. We don't need prejudices against romanian people and we also do need to insult others as idiots.. especially when they present you the solution to your problem.
  6. open

    Are there any relevant logs? Check syslog at the time you're opening the cube and place some items. This way we can determine if there's any error or strange behaviour from the server. Not being able to place items could also be related to the clientside part but I wouldn't count on that.
  7. most of the stuff is in the client source as the colors are defined by the damage type. For example if the damage you're dealing is marked as a critical strike, the client chooses different files for displaying the damage. You need to change that in the source, it's not too difficult once you've found it.
  8. you can simply replace the g++ with c++ but if the source isn't adapted you may run into some problems when compiling with clang. You'll have to make some changes to the source.
  9. check your Makefile and change your g++ to a compiler that's actually present in the system. g++ is from older systems where gnu cc was the standard compiler. Now we have clang and there you'd use c++ or install a compiler manually. This way you can also install and use gcc but you shouldn't use "g++" as your compiler in your Makefile.
  10. Regarding "Questions and answers". Wouldn't it be best if you can create a coloured tag [SOLVED] and a red tag [OPEN] so everyone can see if the question is already done or not? Of course this may require some cleanup from mods since users won't always set a thread to solved... But I think this way you have a better overview and if you search the board you can see similar topics which may have been answered.
  11. That's actually a quite good idea. Next vanilla release will have a offline message system based on c++ and txt. Also mail system incoming. With open source you can just get it from the vanilla sources then. No need to pay
  12. if you're force closing your server you'll get serious trouble. You'd check that you're doing a so called grace shutdown. Give your server time to sync the dbcache with your database. Otherwise you'll loose items. That's why companies have a larger span of time for their maintenances.
  13. Thank you everyone for the kind feedback. next build is coming soon. If everything goes as planned we'll hit stable soon. And no, I don't plan on releasing a bin like I do it with the core. Maybe some day in the future but currently there are no plans. I'm also onto the problem with compiling under release mode and I think I found it. Next build should work without any problems in release mode
  14. I fixed the download link, now you can download the compiled version
  15. @Hik: Please post a backtrace. Otherwise we're unable to help you.
  16. Run config.exe and have a look at "frequency". This is the setting where you can change the fps cap. Note that in the default config it's only possible to switch between 30 and 60. You may change that if you're building your own config. The setting is saved in metin2.cfg where you can change it too
  17. Yep, the exact points you mentioned are the reasons I'd consider building them myself instead of using pkg. Though I don't blame people for using pkg, I write my guides like I'd do it and that's the way it worked. If that's too long for you, feel free to use pkg. But in Freebsd < 9.4 you might not have much fun with it. You need clang to be the compiler except you wish to change the compiler for your m2 source to gcc. Older FreeBSD versions don't have packages prebuilt with clang. The project is ongoing and yes, code modernization is a part of the plan. Thanks for your feedback, I'll take that into account when preparing the next versions
  18. Using the pkg system isn't as effective. It's faster but it's not better. You'd compile the ports on your machine. I for myself experienced a lot of trouble especially when installing compilers via pkg. Additionally you don't need everything, just like in devil. And you sure know that we use clang and some ports may or may not use it depending on the system you're using? We don't need to link to gcc-prebuilt packages...
  19. clang-devel should be installed just via ports. It should work in FreeBSD < 10. c++14 needs the newer clang version. If you're on one of the older compilers like gcc 4.2 it most likely won't work. Also you need devel/libc++ and devel/libcxxrt To build you then only need security/googletest, security/cryptopp, graphics/devil (only jpg needed, all else is not needed), devel/gmake, devel/makedepend and database/mariadb101-client (or any other mysql client for the lib). These are all the dependencies. I've gathered them together into a list. Note that every additional port should be compiled with clang instead of gcc! You cannot use gcc-compiled libs in a clang-project. First install: - lang/clang-devel (you don't need to use the devel-version of clang, you can just install one of the most recent versions) - devel/libc++ - devel/libcxxrt - devel/gmake (should already be installed by one of the ports above) - devel/makedepend And then add the following to /etc/make.conf: CC = clang-devel CPP = clang-cpp-devel CXX = clang++-devel CFLAGS += -stdlib=libc++ After that you can start installing the dependencies: - security/googletest - security/cryptopp - graphics/devil (note: Only jpg needed) - databases/mariadb101-client (no server needed, only the client. You can also use mysql if you wish to, we only need the client lib) If everything is installed, make sure you rebuild the Depend-File. For this you can just cd into the source directory and remove it. Then you can just execute the following command: gmake depend After that you'll have everything you need. You can build the sources. gmake debug|release|all Note that you can either choose to compile debug, release or all. You can also use install if you specified a path in your Makefile. This way the created binary will be pushed into a directory once it's finished.
  20. I did not use the BSD-functions. I use c++ standards. Lots of stuff can be handled via std-lib. Since c++11 there's a lot of new features. For example I replaced the boost::unordered_map with std::unordered_map. This also ensures cross-compatibility since you can build libc also on unix-systems. Also the security issues were SQL injections most of the time. For example the auth-messenger. But it's not limited to sql injections since there also were a few things not coded correctly with which you'd possibly crash the core. Most of them is already public so nothing too new. @galet Clientside you can just change the pong like you want to. There's nothing needed, unless you want to change the pong via config files there too (which shouldn't be done). The reason I implement this on the source is for people who just want to change those things on-the-fly and maybe release a updated binary. Or you just want to have the possibilities without messing with the core. It's more simple, the client part should be done too of course but that's not one of those things I'd do. I think I'll write a guide on how to change the encryption, e. g. xtea to AES regarding the client. This way they everyone can implement those things in their own client.
  21. I won't make a big project for the client. But I will do some few things like python 3.6 and I also will release a guide + source download for those things. But nothing like the core^^ Additionally I'm planning on gathering information for the next version of the core. Please share some feedback if you have and tell me what you'd like to see in the next revision. Few things I can already mention: - Option to switch compression algorithms. You'll be able to switch from lzo to lz4 and backwards by CONFIG - Option to switch encryption algorithms. You'll be able to switch from xtea to CAST-128 or AES and vice versa (does only work with enhanced security disabled) - Option to setup pong and other stuff via CONFIG. Of course some stuff does only work with enhanced security disabled. - Option to enable/disable custom MySQL-functions for passwords (so you can use e. g. salt for better security) - Ingame Elevation with a standard passphrase (enabled by default!) The next release focuses on stability and security. The goal is to add more diversity when it comes to encryptions and hardening your server. With custom passphrases and stuff you'll be able to switch to other implementations easily. Also the custom password functions will further protect the passwords even when an attacker gets insight on the database. Of course the core will also be able to use a custom phrase to further lengthen the password and making it more difficult for attackers to retrieve the original strings. Let me hear your thoughts EDIT: Btw. I tried to fix every bug that's been made public. But I'm not 100% sure I got everything. That's why I'm asking you kindly to revise the core and see if there's anything unstable before I brand it as a stable one. That's why It's called a BETA
  22. fixed the link for source code
  23. The error in your first post is pretty much the join-statement. if you use t1.join() then the game will synchronize with the thread meaning it's waiting for the thread to be finished. A thing that will actually never occur since your thread is running into infinity. The precise point where you're using join() is the moment when the game stops executing. Yes, your thread will still run, but the actual game won't because it's always waiting for your thread. At the very moment you're spawning the thread, execution starts. So there's no need for join anyway.
  24. warning: `/libexec/': Shared library architecture i386:x86-64 is not compatible with target architecture i386. warning: .dynamic section for "/libexec/" is not at the expected addr ess (wrong library or version mismatch?) These lines tell you what's wrong. There is clearly a library mismatch and you'd check that you're using the correct libs for your game core.
  25. int dungeon_new_jump(lua_State* L) { if (lua_gettop(L) < 3) { sys_err("not enough argument"); return 0; } if (!lua_isnumber(L, 1) || !lua_isnumber(L, 2) || !lua_isnumber(L, 3)) { sys_err("wrong argument"); return 0; } long lMapIndex = (long)lua_tonumber(L,1); long x = (long)lua_tonumber(L, 2) * 100; long y = (long)lua_tonumber(L, 3) * 100; LPDUNGEON pDungeon = CDungeonManager::instance().Create(lMapIndex); if (!pDungeon) { sys_err("cannot create dungeon %d", lMapIndex); return 0; } LPCHARACTER ch = CQuestManager::instance().GetCurrentCharacterPtr(); ch->WarpSet(x, y, pDungeon->GetMapIndex()); return 0; } should work, I didn't test it though.