Search the Community

INTRODUCTION & PROBLEM Hello, today we will fix a few errors, especially the error that caused the core down by giving an unexpected negative (-) arg (number) in the commands (Example; /mob 101 -1), and we will also regulate the use of "ChatPacket" in this functions. WHY ? GMs are already part of the team, you may ask why we need this, you are right, but do not forget that a GM who does not have coding knowledge may accidentally trigger this, let's not leave it to chance. SOLUTION The process we will do is simple, it will be enough to make sure that the given arg value is within the range we want, let's get started. [Hidden Content]

I recently came across this issue when updating some things on the party (group) system and I realized that this problem was present on all the branches of the source. Although I've seen certain topics with some solutions, they don't provide much information and, in my opinion, a good solution. So, I'll share mine with you and you can use it if you're happy with the results. The Bug When you set a role to a member as a leader, it will give the member a certain bonus according to the role, this bonus is given if the leadership skill is high. Now, if you decide to remove the members role, in theory the bonus should be removed. However, when this happens, it will only compute the battle points of the player which will make some bonuses of certain roles the same until the character computes all his points again. For example, if you set a member with the tanker role, which grants a bonus of additional health points and then remove the role from the member, the bonus will not be removed until the character computes his points again. It doesn't remove the bonus because the function by default only computes the battle points, this relates to roles like, attacker and defender. Realization So far, we realized a possible solution, which is replacing the ComputeBattlePoints with ComputePoints, well sure, and I've seen this solution on this forum in some help request topics but this comes to a major cost in performance since the role computation function CParty::ComputeRolePoint is frequently called. The Solution What we really want to do is check if the member has any bonus assigned to a role, remove the bonus and finally compute the character's points appropriately, avoiding constant updates to the ComputePoints function. If the member doesn't have any bonus given from a role, there will be no need to calculate the points.

See this error on client 'syserr'? ResourceManager::GetResourcePointer: NOT SUPPORT FILE d:\project\metin2\main\assets\npc\lion\lion.psd I faced this problem using UltharV2 SF How to fix it? 1. Download "Granny Texture Path Changer" by Helia01: 2. Unpack your 'npc' folder that contains 'lion' folder inside and search for: "combo_attack1.gr2" 3. Open Granny Texture Path Changer and change the .PSD texture to: "D:\Ymir Work\npc\lion\lion.dds" 4. Pack your files And done! Sorry if someone has already posted this before, I didn't find a solution on the forum.

This is the problem I am talking about: Basically, when you get down from the mount (or the item slots are refreshed), the tooltip shown does not stay as the one from the item in the inventory's interface on top, but the item in the inventory behind. To fix this behaviour, go on void CSlotWindow::RefreshSlot() and change void CSlotWindow::RefreshSlot() { OnRefreshSlot(); // NOTE : Refresh µÉ¶§ ToolTip µµ °»½Å ÇÕ´Ï´Ù - [levites] if (IsRendering()) { TSlot * pSlot; if (GetPickedSlotPointer(&pSlot)) { OnOverOutItem(); OnOverInItem(pSlot->dwSlotNumber); } } } to: void CSlotWindow::RefreshSlot() { OnRefreshSlot(); if (IsRendering() && UI::CWindowManager::Instance().GetPointWindow() == this) { TSlot * pSlot; if (GetPickedSlotPointer(&pSlot)) { OnOverOutItem(); OnOverInItem(pSlot->dwSlotNumber); } } }

Hello! Today I found that in lua the modification of item.set_socket(0, value) does not work. Fixed: int item_set_socket(lua_State* L) { CQuestManager& q = CQuestManager::instance(); if (q.GetCurrentItem() && lua_isnumber(L, 1) && lua_isnumber(L, 2)) { int idx = (int)lua_tonumber(L, 1); int value = (int)lua_tonumber(L, 2); if (idx >= 0 && idx < ITEM_SOCKET_MAX_NUM) q.GetCurrentItem()->SetSocket(idx, value); } return 0; } Original: int item_set_socket(lua_State* L) { CQuestManager& q = CQuestManager::instance(); if (&q == NULL) return 0; LPITEM item = q.GetCurrentItem(); if (item == NULL) return 0; if (item && lua_isnumber(L, 1) && lua_isnumber(L, 2)) { int idx = (int) lua_tonumber(L, 1); int value = (int) lua_tonumber(L, 2); if (idx == NULL) return 0; if (value == NULL) return 0; if (idx >=0 && idx < ITEM_SOCKET_MAX_NUM) item->SetSocket(idx, value); } return 0; } Explanation: If the socket index is 0, it returns and does not run the code... fck logic. if (idx == NULL) return 0;

Hello community ! I found an issue when i was checking ShopEx system. If your pack_tab size is bigger than default m2 / SHOP_HOST_ITEM_MAX_NUM is bigger than default this overflow occurs. This causes a core crash as seen in the screenshot below: [Hidden Content] Solution I use temp buffer for handle better but you can change 8096 too. To solve this problem, you can follow these steps: // In shopEx.cpp -------------------------------------------------------------- // Search char temp[8096]; char* buf = &temp[0]; size_t size = 0; // Change like this TEMP_BUFFER buf(16 * 1024); -------------------------------------------------------------- // Search memcpy(buf, &pack_tab, sizeof(pack_tab)); buf += sizeof(pack_tab); size += sizeof(pack_tab); // Change like this buf.write(&pack_tab, sizeof(pack_tab)); -------------------------------------------------------------- // Search pack.size = sizeof(pack) + sizeof(pack2) + size; // Change like this pack.size = sizeof(pack) + sizeof(pack2) + buf.size(); -------------------------------------------------------------- // Search ch->GetDesc()->Packet(temp, size); // Change like this ch->GetDesc()->Packet(buf.read_peek(), buf.size()); After following these steps, you should have overcome this problem in the ShopEx system. If you have any problems, please leave a comment. Kind regards, Luigina

Hi, I don't know if you've noticed, but every time you open a shop or want to add a stone to an item, the window inexplicably opens somewhere on the right at the top near the inventory. It bothered me for quite a while, so I looked into the code, and the fix is very easy. I'm sharing it with you, and I would appreciate it if you let me know if any other window does the same, as I've only noticed these two so far. Open uiattachmetin.py and search in def Open(self, metinItemPos, targetItemPos): self.UpdateDialog() Add under: self.SetCenterPosition() ############################ Open uishop.py and search in def Open(self, vid): self.Refresh() Add under: self.SetCenterPosition() Thats all :D

This video was presented to me yesterday and vietnam flashbacks came back to me to the first time I found out about this. Three years ago I thought it was just my client, maybe this part was deleted when it was not supposed to, but I guess it's not. Why does this work, I have absolutely no clue but it's amazing that it behaves like that. Let's get to fixing it. Open PythonPlayerSkill.cpp and add: DWORD dwMotionIndex = pSkillData->GetSkillMotionIndex(rkSkillInst.iGrade); DWORD dwLoopCount = pSkillData->GetMotionLoopCount(rkSkillInst.fcurEfficientPercentage); if (!pkInstMain->NEW_UseSkill(rkSkillInst.dwIndex, dwMotionIndex, dwLoopCount, pSkillData->IsMovingSkill() ? true : false)) { //Tracenf("CPythonPlayer::__UseSkill(%d) - pkInstMain->NEW_UseSkill - ERROR", dwSlotIndex); return false; } after: if (pSkillData->IsFanRange()) { if (pkInstMain->NEW_GetInstanceVectorInFanRange(float(dwRange), *pkInstTarget, &kVct_pkInstTarget)) { It should look like this: Literally the end.

Hi Bug fix by me Before fix: [Hidden Content] After fix: [Hidden Content] Fix: char_state.cpp Comment this line: f.m_pkChrFind->AddAffect(AFFECT_WAR_FLAG, POINT_MOV_SPEED, 50 - f.m_pkChrFind->GetPoint(POINT_MOV_SPEED), 0, INFINITE_AFFECT_DURATION, 0, false); Add below: f.m_pkChrFind->UpdatePacket(); Like this: if (!pMap->GetTeamIndex(GetPoint(POINT_STAT), idx)) return; f.m_pkChrFind->AddAffect(AFFECT_WAR_FLAG, POINT_NONE, GetPoint(POINT_STAT), idx == 0 ? AFF_WAR_FLAG1 : AFF_WAR_FLAG2, INFINITE_AFFECT_DURATION, 0, false); //f.m_pkChrFind->AddAffect(AFFECT_WAR_FLAG, POINT_MOV_SPEED, 50 - f.m_pkChrFind->GetPoint(POINT_MOV_SPEED), 0, INFINITE_AFFECT_DURATION, 0, false); //fix f.m_pkChrFind->UpdatePacket(); //fix pMap->RemoveFlag(idx); char.cpp Find: case POINT_MOV_SPEED: min_limit = 0; if (IsPC()) limit = 200; else limit = 250; Add below: if (FindAffect(AFFECT_WAR_FLAG)) limit = 50; Like this: case POINT_MOV_SPEED: min_limit = 0; if (IsPC()) limit = 200; else limit = 250; if (FindAffect(AFFECT_WAR_FLAG)) limit = 50; break;

#Solution 1: [Hidden Content] #Solution 2: [Hidden Content]

So, @ Syreldar was making a quest for a server I am working on and, he noticed that after the value 255, the direction set was not working properly. For some reason, dir is an int almost everywhere, except his declaration in the struct and the two lua functions. I understand the int in the spawnmob function as a parameter, for the -1 thing to decide to make it random, but then, it should be a number between 0 and 359 but somehow they decided to go with an 8bits representation number (BYTE) So here we are fixing another korean mistake.. Go to regen.h, and replace: BYTE direction; with uint16_t direction; Go to questlua_dungeon.cpp, replace: BYTE dir = (int) lua_tonumber(L, 4); with uint16_t dir = static_cast<uint16_t>(lua_tonumber(L, 4)); both in dungeon_spawn_mob_dir_ac and dungeon_spawn_mob_dir (not needed but for consistency at this point..) Go to char_manager.cpp in: LPCHARACTER CHARACTER_MANAGER::SpawnMob(DWORD dwVnum, long lMapIndex, long x, long y, long z, bool bSpawnMotion, int iRot, bool bShow) add: if(iRot > 359){ iRot = 359; } before if (iRot == -1) iRot = number(0, 360); and that's it.

Hello I found a base bug and I have found its solution. I share it with you with tests. Bug 1: Many times when attacking with Sword Strike the damage fails and this damage behavior varies very strange. Fix: Remove CRUSH flag from skill_proto (index 20) Bug 2: The damage of Sword Strike is too low compared to the other skills of your group. Fix: Change eSkillType from MELEE to RANGE in skill_proto (index 20) Testing bug 1: [Hidden Content]

Hey there! I've come across this bug where the female Ninja attacks with the bow much more faster than the male Ninja. I did not find the fix anywhere on this forum, so I decided to write the actual FIX for this issue. What's the cause of this BUG? The issue is with the duration of the animation file (attack.gr2), where the male Ninja's animation takes 1.5 seconds, while the female Ninja's takes 1 second. Ymir basically did not verify the duration of the anim for both femal and male So, let's fix this bug once and for all. I found the corrected attack.gr2 animation file, with both genders now having the attack set to 1 second. By replacing the files in your client with the ones from the archive, you will resolve this issue. Before the FIX (gif): [Hidden Content] After the FIX (gif): [Hidden Content] Download:

1) my msm gr2 server_client all ready good working 2) data/client msm/gr2/etc all ready good working i have this bug on 2023 again and again on my pc with anydesk 5 develope from france for see this problem We fixed it (temporarily) My server working BEST without bug mount (temporarily for find an even better fix) 1) OPEN INPUT_MAIN 2) SEARCH: const float fDist = DISTANCE_SQRT ((ch->GetX() - pinfo->lX) / 100, (ch->GetY() - pinfo->lY) / 100); if (((false == ch->IsRiding() && fDist > 750) || fDist > 999) && OXEVENT_MAP_INDEX != ch->GetMapIndex()) { sys_log (0, "MOVE: %s trying to move too far (dist: %.1fm) Riding(%d)", ch->GetName(), fDist, ch->IsRiding()); ch->Show (ch->GetMapIndex(), ch->GetX(), ch->GetY(), ch->GetZ()); ch->Stop(); return; } 3) ADD AFTER if (true == ch->IsRiding()) { ch->UpdateSectree(); }

Hi, I will share with you the solution of a general problem that occurs in infrastructures such as MartySama that use an account recording system over REGISTRY. When you save your account, the data is saved in the Windows Registry, as shown in the example below. Everything is great, the system is exactly what we wanted. Account information is no longer saved in files in the client. However, there is a problem. Players have this problem. If you save your character information using Turkish characters, the client does not open and gives an error. It states that you have a problem with characters used on a system that supports ASCII encoding. Check This ; LoginWindow.__LoadScript.BindObject - <type 'exceptions.UnicodeEncodeError'>:'ascii' codec can't encode character u'\xe7' in position 8: ordinal not in range(128) To resolve this, follow the steps below. Root/Intrologin.py find in "def SAB_Click_Save(self, slot):" if len(id) == 0: self.PopupNotifyMessage(localeInfo.LOGIN_INPUT_ID, self.SetIDEditLineFocus) return Add this just above the code if any(ord(char) > 127 for char in id + pwd): self.PopupNotifyMessage(localeInfo.TURKISH_WORDS) return It will be enough to add the following message anywhere in locale_game.txt TURKISH_WORDS Please do not use Turkish characters when registering your account! It's done! A few things I want to point out. 1. I am not a perfect developer, I have Python knowledge and this is how I found a solution. It's short and it works. 2. If you have a better solution suggestion, please specify. Instead of making fun of me, I ask you to respect the way I try to be useful to the community. 3. I had another account on Metin2.dev but I forgot the information so I created a new account. Moderators please understand me ^^ Kind Regards.

Hi there devs, Its been a while since my last topic, and the reason for waking up from my eternal hyper dream is no less significant than a small possible item dupe exploit that is present in the original leaked source, and therefore very likely still present on most of the active servers including the official. I've seen topics from late 2021 where this bug was abused on prestigious international servers, so its for sure known by some people for a long time, moreover even a related partial fix for the exploit is already present on the board: How does it work? How to fix it? I think I filled my quota of talking in the how does it work section above, so without further ado:

Download Center Github or Internal Link With this 'system' you will be able to open the PM Window just by clicking on the Player Name on any Chat Category not only on Global (normal, group, guild...) I use martysama so if you use anything else you need to edit it for your sources. Because i did not found an full tutorial here it is, is not perfect i know. Preview: [Hidden Content] Bellow is just an example, follow the tutorial on github or download it from dev. Pack Search inside interfacemodule.py and edit it like bellow: def MakeHyperlinkTooltip(self, hyperlink): tokens = hyperlink.split(":") if tokens and len(tokens): type = tokens[0] if "item" == type: self.hyperlinkItemTooltip.SetHyperlinkItem(tokens) # Add this under like here elif "msg" == type and str(tokens[1]) != player.GetMainCharacterName(): self.OpenWhisperDialog(str(tokens[1])) Server Srcs Search inside input_main.cpp and make the changes like bellow: // With Chat Color #ifdef ENABLE_CHAT_COLOR_SYSTEM static const char* colorbuf[] = {"|cFFffa200|H|h[Staff]|h|r", "|cFFff0000|H|h[Shinsoo]|h|r", "|cFFffc700|H|h[Chunjo]|h|r", "|cFF000bff|H|h[Jinno]|h|r"}; int len = snprintf(chatbuf, sizeof(chatbuf), "%s |Hmsg:%s|h%s|h|r : %s", (ch->IsGM()?colorbuf[0]:colorbuf[MINMAX(0, ch->GetEmpire(), 3)]), ch->GetName(), ch->GetName(), buf); #endif // Without Chat Color just change it like this int len = snprintf(chatbuf, sizeof(chatbuf), "|Hmsg:%s|h%s|h|r : %s", ch->GetName(), ch->GetName(), buf); Source @ Sanchez Client Srcs Search inside PythonNetworkStreamPhaseGame.cpp bool CPythonNetworkStream::RecvChatPacket() { .. // Search this like case CHAT_TYPE_WHISPER: { .. } .. } And add this inside the case, like this:

Disable loading BGM music/sounds when the player has the Volume set on 0.0 I speak about this ones when you open the client, login, select character, loading. 0706 17:55:00831 :: BGM/login_window.mp3 > 304 kb 0706 17:55:08657 :: BGM/characterselect.mp3 > 472 kb 0706 17:55:19083 :: BGM/enter_the_east.mp3 > 3.14 mb But you can add the maps with specific songs to the list... 0706 18:26:21453 :: BGM/desert.mp3 > 3.61 mb 0706 18:36:17583 :: BGM/follow_war_god.mp3 > 4.63 mb 0706 18:38:00674 :: BGM/save_me.mp3 > 2.90 mb ... and more Inside the Client Srcs file: SoundManager.cpp (MilesLib) Search for the function and make the changes like bellow: void CSoundManager::PlayMusic(DWORD dwIndex, const char * c_szFileName, float fVolume, float fVolumeSpeed) { # add this if (GetMusicVolume() == 0.0) return; # add this if (dwIndex >= CSoundManagerStream::MUSIC_INSTANCE_MAX_NUM) return; ... } The only one bug problem is that when an player changes an song with the volume 0 it will not load (ty @ Karbust) this can be fixed from python (root/uisystemoption.py) When the player is choosing any song set the volume to 5/10% then load the mp3 file. def __OnChangeMusic(self, fileName): # you can try snd.SetMusicVolume(0.1 * net.GetFieldMusicVolume()) systemSetting.SetMusicVolume(0.1) Sorry if it did not help you, and however to see the files loading without any use... It bothers me. If you have an better way post it bellow and i will update the topic.

For all the years I had been actively dismissing the problem of the misaligned cursor in the text edit box when centred. The day finally came that I fixed it. Broken Fixed [Hidden Content]

This is a nasty bug where a boss can throw you inside a wall if he hits you with a skill that has SKILL_FLAG_CRUSH or SKILL_FLAG_CRUSH_LONG. // char_skill.cpp // Search: if (IS_SET(m_pkSk->dwFlag, SKILL_FLAG_CRUSH | SKILL_FLAG_CRUSH_LONG) && !IS_SET(pkChrVictim->GetAIFlag(), AIFLAG_NOMOVE)) { ... } // Replace the if with: if (IS_SET(m_pkSk->dwFlag, SKILL_FLAG_CRUSH | SKILL_FLAG_CRUSH_LONG) && !IS_SET(pkChrVictim->GetAIFlag(), AIFLAG_NOMOVE)) { float fCrushSlidingLength = 200; if (m_pkChr->IsNPC()) fCrushSlidingLength = 400; if (IS_SET(m_pkSk->dwFlag, SKILL_FLAG_CRUSH_LONG)) fCrushSlidingLength *= 2; float fx, fy; float degree = GetDegreeFromPositionXY(m_pkChr->GetX(), m_pkChr->GetY(), pkChrVictim->GetX(), pkChrVictim->GetY()); if (m_pkSk->dwVnum == SKILL_HORSE_WILDATTACK) { degree -= m_pkChr->GetRotation(); degree = fmod(degree, 360.0f) - 180.0f; if (degree > 0) degree = m_pkChr->GetRotation() + 90.0f; else degree = m_pkChr->GetRotation() - 90.0f; } GetDeltaByDegree(degree, fCrushSlidingLength, &fx, &fy); long startX = (long)(pkChrVictim->GetX()); long startY = (long)(pkChrVictim->GetY()); long endX = (long)(pkChrVictim->GetX() + fx); long endY = (long)(pkChrVictim->GetY() + fy); // We asume all positions between the start and end point are movable bool allPositionsMovable = true; // Calculate the distance between the start and end points double distance = std::sqrt((endX - startX) * (endX - startX) + (endY - startY) * (endY - startY)); // Calculate the step size for each coordinate double stepX = (endX - startX) / distance; double stepY = (endY - startY) / distance; // Check if all points on the trajectory between startX, startY and endX, endY are movable for (double i = 0; i <= distance; ++i) { double currentX = startX + i * stepX; double currentY = startY + i * stepY; long roundedX = static_cast<long>(std::round(currentX)); long roundedY = static_cast<long>(std::round(currentY)); if (!SECTREE_MANAGER::instance().IsMovablePosition(pkChrVictim->GetMapIndex(), roundedX, roundedY)) { allPositionsMovable = false; break; } } if (allPositionsMovable) { sys_log(0, "CRUSH SUCCESS! %s -> %s (%d %d) -> (%d %d)", m_pkChr->GetName(), pkChrVictim->GetName(), pkChrVictim->GetX(), pkChrVictim->GetY(), (long)(pkChrVictim->GetX()+fx), (long)(pkChrVictim->GetY()+fy)); pkChrVictim->Sync(endX, endY); pkChrVictim->Goto(endX, endY); pkChrVictim->CalculateMoveDuration(); } else { sys_log(0, "CRUSH FAIL! %s -> %s (%d %d) -> (%d %d)", m_pkChr->GetName(), pkChrVictim->GetName(), pkChrVictim->GetX(), pkChrVictim->GetY(), (long)(pkChrVictim->GetX()+fx), (long)(pkChrVictim->GetY()+fy)); } if (m_pkChr->IsPC() && m_pkChr->m_SkillUseInfo[m_pkSk->dwVnum].GetMainTargetVID() == (DWORD) pkChrVictim->GetVID()) { SkillAttackAffect(pkChrVictim, 1000, IMMUNE_STUN, m_pkSk->dwVnum, POINT_NONE, 0, AFF_STUN, 4, m_pkSk->szName); } else { if (allPositionsMovable) pkChrVictim->SyncPacket(); } }

There is a nasty bug where sometimes some items are not loaded in the safebox. This problem occurs because the function that interprets the data from the set packet (RecvSafeBoxSetPacket) is called too early. Fix: // PythonNetworkStream.cpp // 1. Search: Set(HEADER_GC_SAFEBOX_SET, CNetworkPacketHeaderMap::TPacketType(sizeof(TPacketGCItemSet), STATIC_SIZE_PACKET)); // 1. Replace with: Set(HEADER_GC_SAFEBOX_SET, CNetworkPacketHeaderMap::TPacketType(sizeof(TPacketGCItemSet2), STATIC_SIZE_PACKET));

Hello, In this I fixed several problems Now with the new method the problems have all been solved [Please it has been tested before publishing] 1) OPEN char_affect.cpp search: void CHARACTER::RemoveBadAffect() { .......... } Change with: void CHARACTER::RemoveBadAffect() { for (auto it = 0; it < SKILL_MAX_NUM; it++) { const CAffect * pkAff = FindAffect(it); if (pkAff) { switch (it) { case AFFECT_FIRE: { RemoveAffect (AFFECT_FIRE); event_cancel(&m_pkFireEvent); break; } case AFFECT_POISON: { RemoveAffect (AFFECT_POISON); event_cancel(&m_pkPoisonEvent); break; } case AFFECT_STUN: case AFFECT_SLOW: case SKILL_TUSOK: { RemoveAffect (it); break; } } } } ComputePoints(); UpdatePacket(); } -------------------- ---------- 2. search: void CHARACTER::RemoveGoodAffect() { .......... } change with: void CHARACTER::RemoveGoodAffect() { for (auto it = 0; it < SKILL_MAX_NUM; it++) { const CAffect * pkAff = FindAffect(it); if (pkAff) { switch (it) { case AFFECT_MOV_SPEED: case AFFECT_ATT_SPEED: case AFFECT_STR: case AFFECT_DEX: case AFFECT_INT: case AFFECT_CON: case AFFECT_CHINA_FIREWORK: case SKILL_JEONGWI: case SKILL_GEOMKYUNG: case SKILL_CHUNKEON: case SKILL_EUNHYUNG: case SKILL_GYEONGGONG: case SKILL_GWIGEOM: case SKILL_TERROR: case SKILL_JUMAGAP: case SKILL_MANASHILED: case SKILL_HOSIN: case SKILL_REFLECT: case SKILL_GICHEON: case SKILL_KWAESOK: case SKILL_JEUNGRYEOK: { RemoveAffect (it); break; } } } } ComputePoints(); UpdatePacket(); } (If you haven't solved the UpdatePacket and ComputePoints issues please don't use this method) (90% people have martysama and owsap serverfiles there is no problem) I worked many hours to fix all the problems from the fix @ Syreldar it has been tested before I publish it (I Have test and in martysama serverfiles and in Owsap to be sure it will work properly) thanks you.

Ayo, recently I've come across an issue with a customer who had item proto entries all over the place and when the database tried to sort that mess, it messed it up even more, eventually, it messed up this very Monday for me as I spent hours debugging this. Long story short: It first inserts key-value to map m_map_itemTableByVnum where the key was an integer (item vnum) and the value was a pointer that pointed to an item table object at position X in m_vec_itemTable but at the end, it sorted this very vector while values in map still pointed to the same positions in the vector. Guessed what happened? An item with vnum 19709 had an item table of the item with vnum 20009 because you donkey were too lazy to put new proto entries in the correct order. Go over to server source, database/ClientManagerBoot.cpp, at the end of the following function: bool CClientManager::InitializeItemTable() { [...] m_map_itemTableByVnum.clear(); auto it = m_vec_itemTable.begin(); while (it != m_vec_itemTable.end()) { TItemTable * item_table = &(*(it++)); sys_log(1, "ITEM: #%-5lu %-24s %-24s VAL: %ld %ld %ld %ld %ld %ld WEAR %lu ANTI %lu IMMUNE %lu REFINE %lu REFINE_SET %u MAGIC_PCT %u", item_table->dwVnum, item_table->szName, item_table->szLocaleName, item_table->alValues[0], item_table->alValues[1], item_table->alValues[2], item_table->alValues[3], item_table->alValues[4], item_table->alValues[5], item_table->dwWearFlags, item_table->dwAntiFlags, item_table->dwImmuneFlag, item_table->dwRefinedVnum, item_table->wRefineSet, item_table->bAlterToMagicItemPct); m_map_itemTableByVnum.insert(std::map<DWORD, TItemTable *>::value_type(item_table->dwVnum, item_table)); } sort(m_vec_itemTable.begin(), m_vec_itemTable.end(), FCompareVnum()); return true; Now we'll do some dark magic, we'll move the sort function at the beginning of previously shown code, like so: bool CClientManager::InitializeItemTable() { [...] m_map_itemTableByVnum.clear(); // -------------------------------------------------------------> Wohoo I am here now! sort(m_vec_itemTable.begin(), m_vec_itemTable.end(), FCompareVnum()); auto it = m_vec_itemTable.begin(); while (it != m_vec_itemTable.end()) { TItemTable * item_table = &(*(it++)); sys_log(1, "ITEM: #%-5lu %-24s %-24s VAL: %ld %ld %ld %ld %ld %ld WEAR %lu ANTI %lu IMMUNE %lu REFINE %lu REFINE_SET %u MAGIC_PCT %u", item_table->dwVnum, item_table->szName, item_table->szLocaleName, item_table->alValues[0], item_table->alValues[1], item_table->alValues[2], item_table->alValues[3], item_table->alValues[4], item_table->alValues[5], item_table->dwWearFlags, item_table->dwAntiFlags, item_table->dwImmuneFlag, item_table->dwRefinedVnum, item_table->wRefineSet, item_table->bAlterToMagicItemPct); m_map_itemTableByVnum.insert(std::map<DWORD, TItemTable *>::value_type(item_table->dwVnum, item_table)); } return true;

When you set a text in a textline and then change font name, text disappear. Before fix: With fix: [Hidden Content]

Download Alternative download links → Version1 or Version2 or Version3 Changelogs Version 3. Fix quest pick in quest Fix delayed desc kick Now it works stable without problems in version 3 Version 2. Now, the players cannot delete messange other people's In 4 failures the server kick you @ TMP4 @ Abel(Tiger) Version 1. Normal fix guild comment