Jump to content
  • Create New...

Search the Community

Showing results for tags 'fix'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Metin2 Dev
    • Announcements
    • Discord
    • Pillory
    • Top Metin2
    • Metin2 Dev Wiki
  • Community
    • Member Representations
    • Off Topic
  • Metin2
    • General
    • Private Servers
  • Help Center
    • Questions & Answers
    • File Requests
  • Releases
    • Basic Tutorials / Beginners
    • Guides & HowTo
    • Binaries
    • Programming & Scripts / Systems
    • Web Development & Scripts / Systems
    • Tools & Programs
    • Maps
    • Quests
    • 3D Models
    • 2D Graphics
    • Operating Systems
    • Others
  • Marketplace
    • Join the Marketplace - Sales & Services
    • Searching
  • Miscellaneous
    • Trash
    • Archive
    • Temporary
  • Forum Bureau of Investigation's Forum

Product Groups

  • Header & Footer
  • Topic & Forum
  • Pack


Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



My Message









Found 19 results

  1. This vulnerability should affect every server. You can duplicate item rewards, and also crash the server through dangling pointers. The danger of this bug escalates to how many custom systems, and how many crafting quests (for example, the vitality ore quest, not the cube system) you have in your server. How to trigger it: Any quest that uses select & wait, and the item lua module after that is vulnerable. After the server uses select() or wait(), the player's quest state is suspended. After the player replies using the CG packet, the quest state is recovered. So what's wrong with it? It doesn't verify if the stored quest item ptr expired. You basically need to destroy the selected item ptr in order to dupe the rewards of the quest. After some tries, you may get a core crash in the game. (dangling pointers often cause crashes only after that memory sector has been rewritten) In my files, I've checked (since several years ago) if the quest state was suspended for the the default windows such as exchange, cube, shop. This bug can work very easily on offline shops or other new systems that don't check that. After the select() or wait() is called, you send the selected item to the (e.g.) offlineshop system window. It will delete the item ptr in the game. Now, you can press "Ok" on the quest, and the quest will proceed as if the item still existed. The item still exists in the offlineshop, but not the item ptr anymore. The item won't be deleted by the quest even after item.remove() is called. This is the fix: diff --git a/s3ll_server/Srcs/Server/game/src/char.cpp b/s3ll_server/Srcs/Server/game/src/char.cpp index 0ea307fa..65b1dd65 100644 --- a/s3ll_server/Srcs/Server/game/src/char.cpp +++ b/s3ll_server/Srcs/Server/game/src/char.cpp @@ -303,7 +303,10 @@ void CHARACTER::Initialize() m_dwQuestNPCVID = 0; m_dwQuestByVnum = 0; - m_pQuestItem = NULL; + m_dwQuestItemVID = 0; m_dwUnderGuildWarInfoMessageTime = get_dword_time()-60000; @@ -6123,33 +6126,37 @@ LPCHARACTER CHARACTER::GetQuestNPC() const void CHARACTER::SetQuestItemPtr(LPITEM item) { - m_pQuestItem = item; + m_dwQuestItemVID = (item) ? item->GetVID() : 0; } void CHARACTER::ClearQuestItemPtr() { - m_pQuestItem = NULL; + m_dwQuestItemVID = 0; } LPITEM CHARACTER::GetQuestItemPtr() const { - return m_pQuestItem; + if (!m_dwQuestItemVID) + return nullptr; + return ITEM_MANAGER::Instance().FindByVID(m_dwQuestItemVID); } diff --git a/s3ll_server/Srcs/Server/game/src/char.h b/s3ll_server/Srcs/Server/game/src/char.h index cc4da2bb..74b3470e 100644 --- a/s3ll_server/Srcs/Server/game/src/char.h +++ b/s3ll_server/Srcs/Server/game/src/char.h @@ -1674,9 +1674,9 @@ class CHARACTER : public CEntity, public CFSM, public CHorseRider private: DWORD m_dwQuestNPCVID; DWORD m_dwQuestByVnum; - LPITEM m_pQuestItem; + DWORD m_dwQuestItemVID{}; // @fixme304 (LPITEM -> DWORD) // Events To unlock the client in order to move your windows with a quest open, you edit this from interfacemodule.py: You can even Hide the TopBar and BottomBar from uiQuest.py for a better result. Important: after this fix, the item ptr may be nullptr after they press enter, so you need to check if the item ptr is still valid by using this function: ALUA(item_is_available) { auto item = CQuestManager::instance().GetCurrentItem(); lua_pushboolean(L, item != nullptr); return 1; } ... { "is_available", item_is_available }, // [return lua boolean] By simply doing: when 169.take begin local s1=select("Yes", "No") if s1==2 then return end if not item.is_available() then return end end If you want to tryhard, and be sure that the item ptr didn't get swapped, you can do as following via quest:
  2. Yo! If you have an item with a limit type LIMIT_REAL_TIME_START_FIRST_USE that has been used at one point and put it inside the safe-box, it will not be removed from the game until you pull it out of the safe-box and perform a teleport. item.h // Search: protected: friend class CInputDB; // Add below: friend class CHARACTER; [...] bool OnAfterCreatedItem(); char.cpp // Search: void CHARACTER::LoadSafebox(int iSize, DWORD dwGold, int iItemCount, TPlayerItem * pItems) { [...] if (!m_pkSafebox->Add(pItems->pos, item)) { M2_DESTROY_ITEM(item); } else item->SetSkipSave(false); // Modify to: if (!m_pkSafebox->Add(pItems->pos, item)) { M2_DESTROY_ITEM(item); } else { item->OnAfterCreatedItem(); item->SetSkipSave(false); }
  3. Download Other Mirros Download Here (GitHub) Download Here (Mega) Hey M2Dev, I want to share something small but visually appreciated by players that are paying attention to details. What I'm sharing with you today will solve the issue of item tooltips with large strings, these strings overflow the width of the tooltip causing the text to hang out of the edge, especially when metin stones are attached to your weapon or armor. BEFORE PREVIEW AFTER PREVIEW .
  4. An annoying bug which need a fix. Gif with the problem (from ѕeмa™) : // PythonApplicationProcedure.cpp // After: if (m_isWindowFullScreenEnable) { __MinimizeFullScreenWindow(hWnd, m_dwWidth, m_dwHeight); } // Just add: OnMouseMiddleButtonUp(0, 0);
  5. Hello guys, I am once again coming with a really little fix that is related to rare attribute (6/7 bonuses). This bug is extra rare because to trigger it you must have a way to add 6 and 7 bonuses to an item and you must have an incorrect field or an error in your item_attr_rare table. So this is most likely a code sanitization but it's always good to avoid such errors as I encountered people having this bug. When you add a rare bonus, the game will fill a vector with the bonuses from the table and randomly pick one in the vector. However, if you have an error in the table, this vector will be empty and the randomization will result in doing "number(0, -1)", which is obviously incorrect and your core will crash. For searching purposes (if someone in the future is looking for a fix), the error is this one : The fix is really simple, we must check if the vector is empty and then exit at this moment. In item_attribute.cpp, in the following function: bool CItem::AddRareAttribute() Under this block of code: for (int i = 0; i < MAX_APPLY_NUM; ++i) { const TItemAttrTable& r = g_map_itemRare[i]; if (r.dwApplyIndex != 0 && r.bMaxLevelBySet[nAttrSet] > 0 && HasRareAttr(i) != true) { avail.push_back(i); } } Add the following check: [Hidden Content] And that's pretty much it, pretty straightforward, but instead of crashing, you will have a syserr and you will know what to check next!
  6. M2 Download Center Download Here ( Internal ) Hi devs, today I will release the fix I made for the skill cooldown, already fixed on official servers, this is the bug it self: And this is the fix: Regards! Fix skill cooldown ~ Shang.rar ### root/ui.py ### Search: def SetSlotCoolTimeColor(self, slotIndex, r, g, b, a): wndMgr.SetSlotCoolTimeColor(self.hWnd, slotIndex, r, g, b, a) ### Add after: def StoreSlotCoolTime(self, key, slotIndex, coolTime, elapsedTime = 0.0): wndMgr.StoreSlotCoolTime(self.hWnd, key, slotIndex, coolTime, elapsedTime) def RestoreSlotCoolTime(self, key): wndMgr.RestoreSlotCoolTime(self.hWnd, key) Thanks to @Horinna for report that bug. Here's the fix: """ Find this: elif (not self.__CanUseSkillNow()) or (skillGrade != j): skillPage.SetSlotCount(realSlotIndex, 0) skillPage.DisableCoverButton(realSlotIndex) Add this under:""" skillPage.DeactivateSlot(realSlotIndex) # After the else, paste this: if player.IsSkillActive(slotIndex) and (skillGrade == j): # fix001 skillPage.ActivateSlot(realSlotIndex) # The if should look like this: if (skillGrade == skill.SKILL_GRADE_COUNT) and j == (skill.SKILL_GRADE_COUNT-1): skillPage.SetSlotCountNew(realSlotIndex, skillGrade, skillLevel) elif (not self.__CanUseSkillNow()) or (skillGrade != j): skillPage.SetSlotCount(realSlotIndex, 0) skillPage.DisableCoverButton(realSlotIndex) skillPage.DeactivateSlot(realSlotIndex) # fix else: skillPage.SetSlotCountNew(realSlotIndex, skillGrade, skillLevel) if player.IsSkillActive(slotIndex) and (skillGrade == j): # fix skillPage.ActivateSlot(realSlotIndex)
  7. There is a problem, when you change position of horse riding skill in playersettingsmodule, you cannot use horse skills. For me, the way skills work on the client side of thing is really dumb, but they went even furher. I don't understand why, client checks if player has a horse riding level from the fixed skill slot, not from skill info itself. Without my fix, it goes like this: With fix: Actual fix:
  8. Hello everyone, While working on some clientside thing. I noticed one big exploit that I was able to reproduce. Long story short, I was basically able to extend any collision and be able to reproduce (in a makeshift dirty way) the famous "kill aura" or whatever you call it. Basically allowing you to hit monsters from really far away without any problem. That's one of the most common thing the bots are using. Videos of the bug: Spoiler Videos of the fix: Spoiler The fix Spoiler [Hidden Content] Have a nice day!
  9. Hey guys, I just noticed that the description of leadership skill is not displaying party group bonuses values correctly. [Hidden Content] And you're done. Now you can go into the game and check, if the bonuses values in the leadership skill description are displayed correctly. Good luck!
  10. Download Metin2 Download Hi Guys, I m pretty sure most of you perfectly know what i m meaning for "DEVIL TOWER LAG AFTER WARP", It's a critical FPS Drop which happen very often just after a warp in a dungeon. I ve found the way to definitely fix it with a few lines short change. Just to spend a few words for those who want to understand something before copying and pasting the fix here is the explanation of the bug: Here is the code: DOWNLOAD ZIP
  11. M2 Download Center Download Here ( Internal ) There is a bug about the stealth of the assassin with buffs actived. If the players near the assassin that is using the stealth move the camera zoom , the effects become visible again. here the fix of this problem source : myself Sameone could need to add #include "../UserInterface/Locale_inc.h" at the beginning of the file source/EterBase/StdAfx.h to include the defines in Locale_inc.h
  12. Short back story: I remember long time ago I had a map that had many NPCs on it and I got a problem with the packet that sends the NPCs to the client to be displayed on the big atlas map Fix: input_login.cpp Search: SECTREE_MANAGER::instance().SendNPCPosition(ch); Couple lines under it you should find: d->SetPhase(PHASE_GAME); Put the "d->SetPhase(PHASE_GAME);" before the SendNPCPosition line Like this:
  13. Introduction I think everyone know about this famous bug. I profiled the game and checked granny documentation why it happens because we also faced this on MAP1s since we have a lot of offline shops. Actually the game not even freezes, it runs well and the updates happen. What eventually happens there is just that update time takes too long so it will skip rendering. What makes update times longer? The answer is granny controls. When you minimize your game, the completed controls never get freed. It's because the game frees them in CGrannyModelInstance::UpdateWorldPose which is called from CPythonApplication::RenderGame in a long way. There are just more and more of them that are never freed and that makes GrannySetModelClock take more and more time so when you open up your client from the minimized state it will never finish the update fast enough to call RenderGame in which they would be freed again. [Hidden Content] Thats all, you won't face the "black screen bug" again! Good luck guys!
  14. Sup bois and grils I still see a lot of people not being able to select the character when using a local server for friends or VPS behind a internal router or firewall. Disclaimer: This code wasn't made by me, it was originally posted on the metin2dev's French brother Funky-Emu by @Veltor88. On service.h add this: #define ENABLE_PROXY_IP On char.cpp: After: p.lAddr = lAddr; Add: #ifdef ENABLE_PROXY_IP if (!g_stProxyIP.empty()) p.lAddr = inet_addr(g_stProxyIP.c_str()); #endif Like this: On config.cpp: After (or anywhere within the global variables definition): char g_szInternalIP[16] Add: #ifdef ENABLE_PROXY_IP std::string g_stProxyIP = ""; #endif Like this: Still on config.cpp: After: the last TOKEN Add: #ifdef ENABLE_PROXY_IP TOKEN("proxy_ip") { g_stProxyIP = value_string; } #endif Like this: On config.h: After (or anywhere in the file): extern char g_szInternalIP[16]; Add: #ifdef ENABLE_PROXY_IP extern std::string g_stProxyIP; #endif Like this: On desc.cpp: Within the function: void DESC::SendLoginSuccessPacket() Inside: for (int i = 0; i < PLAYER_PER_ACCOUNT; ++i) Add in the beginning: #ifdef ENABLE_PROXY_IP if (!g_stProxyIP.empty()) rTable.players[i].lAddr=inet_addr(g_stProxyIP.c_str()); #endif Like this: On input_db.cpp: Withing the function: bool GetServerLocation(TAccountTable & rTab, BYTE bEmpire) After: rTab.players[i].szName); Add: #ifdef ENABLE_PROXY_IP if (!g_stProxyIP.empty()) rTab.players[i].lAddr=inet_addr(g_stProxyIP.c_str()); #endif Still on input_db.cpp and within the same function: After: struct in_addr in; Add: #ifdef ENABLE_PROXY_IP if (!g_stProxyIP.empty()) rTab.players[i].lAddr=inet_addr(g_stProxyIP.c_str()); #endif Like this: Still on the same file: Within the function: void CInputDB::PlayerCreateSuccess(LPDESC d, const char * data) After: pack.player = pPacketDB->player; Add: #ifdef ENABLE_PROXY_IP if (!g_stProxyIP.empty()) pack.player.lAddr=inet_addr(g_stProxyIP.c_str()); #endif Like this: Done on the source, you can compile. On every channel config, add this: BIND_IP: <Private IPv4 IP> (it will be something within a private IP class. Check the IP of the machine using the "ifconfig" command) PROXY_IP: <Public IPv4 IP> (check out something like [Hidden Content]) Private IPv4 classes: On some sources (like the one from vanilla, BIND_IP was renamed to PUBLIC_IP, just check which TOKEN is responsible to set the value on the variable g_szPublicIP. You will need to open the ports on your router, even for yourself on localhost with the virtual machine because the game server will try to "proxy" you through the public IP you defined. This wasn't tested using a VPN, like Hamachi or ZeroTier.
  15. Download Metin2 Download I do this topic for those who have a problem with Unknown Header operating server in France with 800-1k player online and it has been working for 5 days without problems and without kick [Hidden Content]- If you have provlem : Open in game.py search and remove: if constInfo.SEQUENCE_PACKET_ENABLE: net.SetPacketSequenceMode() Now open constinfo.py and search and remove SEQUENCE_PACKET_ENABLE = 1 ---------------------------------------------------------------------------------------------- Source Client: Search return SendSequence(); change with // return disable;
  16. Hey m2dev You summon a lot of monsters, they attack your character and then you kill or purge monsters, but the damage still continues to be shown visually. Is this a familiar situation? In addition, the damage is shown visually even after the death of the character... I love this game. I haven't seen a fix for this problem, let's try to fix this sh.. [Hidden Content] I'm not saying that this is an ideal solution. If you have any ideas, please write comments. Best regards, Masha
  17. Hello! Many people complained about a "7 pixel bug" on some clients. For example the client will open a few pixels too far from the left-side of the screen. Usually between 7 and 9 pixel on the right. I still do not know why it happens for some people and not for other. I thought about a visual studio toolset, a screen configuration or whatever but it turns out to be harder to know why it actually happens, I also had only two people talking about this so I cannot get accurate data. Anyway, let's get started it's really easy. The bug looks like this, take from the official client it looks like 1 or 2 pixels only. But it looks almost exactly like it at some moments. First, make sure your metin2.cfg is correct and does not display a weird resolution (like 1913 * 1080). Then just add this small line in PythonApplication.cpp: [Hidden Content] Right after this one: AdjustSize(m_pySystem.GetWidth(), m_pySystem.GetHeight()); EDIT: If you happen to have it on the second window as well, move the line under the bAnotherWindow check. Just like this: And voilà, it's fixed. Don't hesistate to add or remove one pixel if needed. It's really small and looks like a workaround but I did it really quickly. I didn't test this fix on clients / computers not having the actual bug. If it is a client issue it shouldn't cause any problems, if it's a computer issue, I might need more data to fine-tune the fix. Don't forget to share some data if you have.
  18. Version of Files : 40k Source (clean) Hi, There is an old error what i want to solve. In the second/third core of channels, i always get a syserr like this: SYSERR: Apr 29 15:43:59.406352 :: Show: cannot find sectree by 983887x271709 mapindex 41 SYSERR: Apr 29 15:43:59.406359 :: Show: cannot find sectree by 984077x271700 mapindex 41 SYSERR: Apr 29 15:43:59.406365 :: Show: cannot find sectree by 984242x271714 mapindex 41 SYSERR: Apr 29 15:43:59.406377 :: Show: cannot find sectree by 984415x271715 mapindex 41 SYSERR: Apr 29 15:43:59.406383 :: Show: cannot find sectree by 984595x271710 mapindex 41 SYSERR: Apr 29 15:43:59.406390 :: Show: cannot find sectree by 984766x271716 mapindex 41 SYSERR: Apr 29 15:43:59.406396 :: Show: cannot find sectree by 984912x271714 mapindex 41 SYSERR: Apr 29 15:43:59.406403 :: Show: cannot find sectree by 985078x271716 mapindex 41 SYSERR: Apr 29 15:43:59.406409 :: Show: cannot find sectree by 983754x272599 mapindex 41 SYSERR: Apr 29 15:43:59.406416 :: Show: cannot find sectree by 984052x272602 mapindex 41 SYSERR: Apr 29 15:43:59.406423 :: Show: cannot find sectree by 984617x274106 mapindex 41 SYSERR: Apr 29 15:43:59.406441 :: RegenNPC: Cannot create guild npc SYSERR: Apr 29 15:43:59.406456 :: Show: cannot find sectree by 983951x274065 mapindex 41 SYSERR: Apr 29 15:43:59.406470 :: RegenNPC: Cannot create guild npc I'm 99.99% sure it is because of the guild land objects and npcs. I only have a guild land sold in blue map1 (==41, that's why it only say mapindex 41 in syserr) I think you guessed what is the problem here, the mapindex 41 is in the first core, the second core want to load that index and create guild npc + objects there but the index is not there, it is only available in the first core. I think most people say "just ignore this syserr", but i don't want to. Any idea to solve this problem? I dont want to copy mapindex 41 (blue) 1 (red) 21 (yellow) to the second cores since then there can be seperated map1s for cores and that can cause troubles for players. Like 2 people in the same map1 but they may not see each other because one is in first core's map1, other is in second core's map1. Before you start typeing "I don't have this problem" please read the topic. You must have at least one guild land sold! Edit: To be clear, you had to place some object or guild npc to produce that syserr. Thanks, Sincerly, TMP4
  19. In exchange.cpp chage this: if (0 == s_vDSGrid[wBasePos]) to this: if (0 == s_vDSGrid[wPos]) and now you can exchange

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.