Jump to content
metin2dev
Ekstasia2

Vanilla

Developer
  • Content Count

    362
  • Joined

  • Last visited

  • Days Won

    46

Everything posted by Vanilla

  1. 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
  2. I fixed the download link, now you can download the compiled version
  3. @Hik: Please post a backtrace. Otherwise we're unable to help you.
  4. Vanilla

    60 fps cap

    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
  5. 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
  6. 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...
  7. 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.
  8. 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.
  9. 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
  10. fixed the link for source code
  11. Vanilla

    [Solved] Loop in client source

    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.
  12. Vanilla

    crash core.Help please

    warning: `/libexec/ld-elf.so.1': Shared library architecture i386:x86-64 is not compatible with target architecture i386. warning: .dynamic section for "/libexec/ld-elf.so.1" 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.
  13. Vanilla

    -delete-

    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.
  14. Vanilla

    Questdialog doesnt close

    please post the quest (only the whole part where the error occurs) so we can help you. Are there any syserrs? And if you have a snippet of your syslog it'd be helpful.
  15. _types.h isn't missing. It's the DEPEND-file that may be messed up a bit. Try to do the following: mv Depend Depend.bak gmake dep This recreates the Depend-file as long as you have devel/makedepend installed. It automagically creates a new Depend-file with the correct path to _types.h
  16. Vanilla

    Searching : Development [C++]

    Can't we agree to stop discussing about developers and let him search for the one that's fitting for his needs? This is a service searching thread and unless you don't want to offer your services there's literally no reason to post here. Especially not when it comes to discussing about irrelevant and stupid things.
  17. 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.
  18. Vanilla

    Discussion thread about vanilla core

    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.
  19. Vanilla

    [CLIENT] Teleportation memory leak

    Then we'd hurry up and start now
  20. Vanilla

    Discussion thread about vanilla core

    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
  21. Vanilla

    Discussion thread about vanilla core

    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..
  22. Vanilla

    Discussion thread about vanilla core

    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
  23. Vanilla

    Discussion thread about vanilla core

    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.
  24. 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.
  25. Vanilla

    socket_connect error on remote server

    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.
×