Jump to content
metin2dev

Leaderboard


Popular Content

Showing most liked content on 01/07/2017 in all areas

  1. 3 points
    An annoying bug which need a fix. #PythonApplicationProcedure.cpp //Search this function: void CPythonApplication::__MinimizeFullScreenWindow(HWND hWnd, DWORD dwWidth, DWORD dwHeight) { ChangeDisplaySettings(0, 0); SetWindowPos(hWnd, 0, 0, 0, dwWidth, dwHeight, SWP_SHOWWINDOW); ShowWindow(hWnd, SW_MINIMIZE); } //Add after: void CPythonApplication::__ResetCameraWhenMinimize() { CCameraManager& rkCmrMgr=CCameraManager::Instance(); CCamera* pkCmrCur=rkCmrMgr.GetCurrentCamera(); if (pkCmrCur) { pkCmrCur->EndDrag(); } SetCursorNum(NORMAL); if ( CURSOR_MODE_HARDWARE == GetCursorMode()) SetCursorVisible(TRUE); } //Search: if (m_isWindowFullScreenEnable) { __MinimizeFullScreenWindow(hWnd, m_dwWidth, m_dwHeight); } //Replace with: if (m_isWindowFullScreenEnable) { __MinimizeFullScreenWindow(hWnd, m_dwWidth, m_dwHeight); __ResetCameraWhenMinimize(); } else { __ResetCameraWhenMinimize(); } #PythonApplication.h //Search: void __MinimizeFullScreenWindow(HWND hWnd, DWORD dwWidth, DWORD dwHeight); //Add after: void __ResetCameraWhenMinimize();
  2. 1 point
    Pictures: https://www.assetstore.unity3d.com/en/#!/content/30892 Link: https://mega.nz/#!9p1U1YZC!GQ9qwf7nmMoPqJ0u7mB76dmbR9pN24oaV3IJuFD3reg
  3. 1 point
    if you need just need the lightning effect here is a tut: http://board.metin2downloads.info/index.php?thread/810-how-2-115er-rüstungen-mit-blitzeffekt/&postID=7080#post7080
  4. 1 point
    maybe if you would properly speak english someone could help you
  5. 1 point
  6. 1 point
    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.
  7. 1 point
    Lzo is a data compression algorithm. It compress data and there are no "lzo keys". On the other hand, XTEA is a block cipher which uses a 8 byte key to encrypt/decrypt data. static DWORD s_adwEterPackKey[] = { 45129401, 92367215, 681285731, 1710201, }; static DWORD s_adwEterPackSecurityKey[] = { 78952482, 527348324, 1632942, 486274726, }; I've made a converter in python: (as requested by someone via PM) >>> from struct import pack as spack >>> a1=spack("LLLL", 45129401,92367215,681285731,1710201) >>> a1.encode('hex') 'b99eb0026f69810563989b2879181a00' >>> >>> a2=a1.encode('hex') >>> a2 'b99eb0026f69810563989b2879181a00' >>> a3=a2.decode('hex') >>> from struct import unpack as sunpack >>> sunpack("LLLL", a3) (45129401L, 92367215L, 681285731L, 1710201L) >>>
×