Mafuyu

after over and over granting and revoking the same bonus, it destorys your character. first of all, it stacks over time more and more, by also bringing other stats to negativ.

pretty lit

please post your full function void CParty::ComputeRolePoint(LPCHARACTER ch, BYTE bRole, bool bAdd)

edit: your second option works perfectly fine. Your first option is bugged af, dunno. duping every attribute while bringing others to negativ, dunno whats broken there

shorter text would be better, like DEV instead of developer, SA instead of Server Admin, it kinda ruins the look of it when theres nearly a written book above your name

thanks anyway

found it few years ago, sometimes real_time items could disappear in nemeres watchtower. never found any solution or even a topic about it. maybe a year later i found something in the patchnotes from another big server like "fixed a bug causing items disappear in nemeres tower", couldnt really ask anyone about it and i just removed the dungeon. Now 2 weeks ago i found something in the informations from the lungsam server source:

"- fix real_time in Nemere's Watchtower"

now i know, its a common problem and not only for me. Did someone else found this somehow? or did someone have a fix for this?

everything in spanish dude cmon

dunno why, for me neither detachment nor tuning will work after splitting it up. And yeah, its not that much of changing code but it literally doesnt work anymore. Even with debug outputs, none of the 2 functions gets triggered after splitting it up. Any idea?

					case USE_TUNING:
						{
							LPITEM item2 = nullptr;

							if (!IsValidItemPosition(DestCell) || !(item2 = GetItem(DestCell)))
								return false;

							if (item2->IsExchanging() || item2->IsEquipped());
								return false;

#ifdef __STONE_REFINE_FIX__
							if (item->GetVnum() >= 28330 && item->GetVnum() <= 28643) // fix
							{
								ch->ChatPacket(CHAT_TYPE_INFO, LC_TEXT("Du kannst Steine nur bei Seon-Pyeong verbessern."));
								return false;
							}
#endif
#ifdef __RITUAL_STONE__
							if (item->GetValue(0) == RITUALS_SCROLL)
							{
								if (item2->GetLevelLimit() < item->GetValue(1))
								{
									ChatPacket(CHAT_TYPE_INFO, LC_TEXT("Du kannst nur Items über Lv. 80 verbessern."));
									return false;
								}
								else
									RefineItem(item, item2);
							}
#endif
							else
							{
								RefineItem(item, item2);
							}
						}
						break;
					// DETACH_METIN_REFACTORING //trennung von USE_DETACHMENT und USE_TUNING in 2 funktionen
					case USE_DETACHMENT:
						{
							LPITEM item2 = nullptr;
							if (!IsValidItemPosition(DestCell) || !(item2 = GetItem(DestCell)))
								return false;

							if (item2->IsExchanging() || item2->IsEquipped());
								return false;
							
							ChatPacket(CHAT_TYPE_INFO, "test 3");
								
#ifdef ENABLE_SOULBIND_SYSTEM	
							if (item2->IsBind() || item2->IsUntilBind())
							{
								ChatPacket(CHAT_TYPE_INFO, LC_TEXT("Du kannst keine Steine aus seelengebundenen Items entfernen."));
								return false;
							}
#endif
#ifdef __SASH_SYSTEM__
							if (item->GetValue(0) == SASH_CLEAN_ATTR_VALUE0)
							{
								if (!CleanSashAttr(item, item2))
									return false;
								
								return true;
							}
#endif
							DetachMetin(item, item2);
						}
						break;
					// END_OF_DETACH_METIN_REFACTORING
                              
                              
   ------------------------------
                              
bool CHARACTER::RefineItem(LPITEM pkItem, LPITEM pkTarget)
{
	if (!CanHandleItem())
		return false;

#ifdef ENABLE_AURA_SYSTEM
	if (pkTarget->GetType() == ITEM_COSTUME && pkTarget->GetSubType() == COSTUME_AURA) 
	{
		ChatPacket(CHAT_TYPE_INFO, LC_TEXT("AURA_ITEM_CANNOT_BE_REFINED_THIS_WAY"));
		return false;
	}
#endif
	ChatPacket(CHAT_TYPE_INFO, "test 5");

#ifdef ENABLE_REFINE_FAILSTACK
	int failstacks = DBManager::Instance().GetFailStacks(this);
#endif
	// MUSIN_SCROLL
	if (pkItem->GetValue(0) == MUSIN_SCROLL)
#ifdef ENABLE_REFINE_FAILSTACK
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_MUSIN, pkItem->GetCell(), failstacks, failstacks / 100);
#else
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_MUSIN, pkItem->GetCell());
#endif
	// END_OF_MUSIN_SCROLL
#ifdef ENABLE_CAN_USE_SCROLL_FOR_501_REFINESET
	else if (pkItem->GetValue(0) == CHUKBOK_SCROLL)
#ifdef ENABLE_REFINE_FAILSTACK
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_SCROLL, pkItem->GetCell(), failstacks, failstacks / 100);
#else
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_SCROLL, pkItem->GetCell());
#endif
#endif
	else if (pkItem->GetValue(0) == HYUNIRON_CHN)
#ifdef ENABLE_REFINE_FAILSTACK
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_HYUNIRON, pkItem->GetCell(), failstacks, failstacks / 100);
#else
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_HYUNIRON, pkItem->GetCell());
#endif
	else if (pkItem->GetValue(0) == BDRAGON_SCROLL)
	{
		if (pkTarget->GetRefineSet() != 702) return false;
#ifdef ENABLE_REFINE_FAILSTACK
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_BDRAGON, pkItem->GetCell(), failstacks, failstacks / 100);
#else
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_BDRAGON, pkItem->GetCell());
#endif
	}
#ifdef __RITUAL_STONE__
	else if (pkItem->GetValue(0) == RITUALS_SCROLL)
	{
		if(pkTarget->GetLevelLimit() <= pkItem->GetValue(1)) return false;
#ifdef ENABLE_REFINE_FAILSTACK
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_RITUALS_SCROLL, pkItem->GetCell(), failstacks, failstacks / 100);
#else
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_RITUALS_SCROLL, pkItem->GetCell());
#endif
	}
#endif
	else
	{
		if (pkTarget->GetRefineSet() == 501) return false;
#ifdef ENABLE_REFINE_FAILSTACK
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_SCROLL, pkItem->GetCell(), failstacks, failstacks / 100);
#else
		RefineInformation(pkTarget->GetCell(), REFINE_TYPE_SCROLL, pkItem->GetCell());
#endif
	}
	return false;
}

bool CHARACTER::DetachMetin(LPITEM pkItem, LPITEM pkTarget)
{
	//if (!(pkItem || pkTarget))
	//	return false; //deactivated just for testing
	ChatPacket(CHAT_TYPE_INFO, "test 123");
	LogManager::instance().ItemLog(this, pkTarget, "USE_DETACHMENT", pkTarget->GetName());

	bool bHasMetinStone = false;

#ifdef ENABLE_EXTENDED_SOCKETS
	for (int i = 0; i < ITEM_STONES_MAX_NUM; i++)
#else
	for (int i = 0; i < ITEM_SOCKET_MAX_NUM; i++)
#endif
	{
		long socket = pkTarget->GetSocket(i);
		if (socket > 2 && (DWORD)socket != ITEM_BROKEN_METIN_VNUM)
		{
			bHasMetinStone = true;
			break;
		}
	}
	
	if (bHasMetinStone)
	{
#ifdef ENABLE_EXTENDED_SOCKETS
		for (int i = 0; i < ITEM_STONES_MAX_NUM; i++)
#else
		for (int i = 0; i < ITEM_SOCKET_MAX_NUM; i++)
#endif
		{
			long socket = pkTarget->GetSocket(i);
			if (socket > 2 && (DWORD)socket != ITEM_BROKEN_METIN_VNUM)
			{
				ChatPacket(CHAT_TYPE_INFO, "test 2");
				AutoGiveItem(socket);
#ifdef ENABLE_BROKEN_METIN_ITEM
				pkTarget->SetSocket(i, ITEM_BROKEN_METIN_VNUM);
#endif
				pkTarget->SetSocket(i, 1);
			}
		}
		
		pkItem->SetCount(pkItem->GetCount() - 1);
		ChatPacket(CHAT_TYPE_INFO, "successfull 1");
		return true;
	}
	else
	{
		ChatPacket(CHAT_TYPE_INFO, LC_TEXT("Es gibt keinen Stein zum Herausnehmen. "));
		return false;
	}
}                         

refine window wont open up again, stone detachment opens the yes/no dialog window but doesnt do anything after pressing yes. No crash, no syserr

dunno why i cant just fkn edit my comment and need to double post (thanks metin2dev) but you fked up your tut with wrong ;'s

					case USE_TUNING:
						{
							LPITEM item2 = nullptr;
							if (!IsValidItemPosition(DestCell) || !(item2 = GetItem(DestCell)))
								return false;

							if (item2->IsExchanging() || item2->IsEquipped()); <--- ???
								return false;

							RefineItem(item, item2);
						}
						break;

					// DETACH_METIN_REFACTORING
					case USE_DETACHMENT:
						{
							LPITEM item2 = nullptr;
							if (!IsValidItemPosition(DestCell) || !(item2 = GetItem(DestCell)))
								return false;

							if (item2->IsExchanging() || item2->IsEquipped()); <---- ???
								return false;

							DetachMetin(item, item2);
						}
						break;
					// END_OF_DETACH_METIN_REFACTORING

wont work this way

shouldnt it be enough if you have clientversion implemented, to use this in input_main: 

        case HEADER_CG_MOVE:
            Move(ch, c_pData);

            if (g_bCheckClientVersion)
            {
                if (0 != g_stClientVersion.compare(d->GetClientVersion())) // @fixme103 (version > date)
                {
                    ch->ChatPacket(CHAT_TYPE_NOTICE, LC_TEXT("clientversion wrong!"));
                    d->DelayedDisconnect(1); // @fixme103 (10);
                }
            }
            break;

? let them login with a different client, as soon as they tried to move ingame, they get kicked

my "fix" is more like a workaround which is not the best solution for the 5% on every server which uses a old toshiba notebook from 2006. But there are no better solutions out (yet!). Would be interesting if someone with more knowledge will get into the problem and may find a better solution without breaking the rest of the game and without more complicated workarounds

but as far as i can say, on my last 3 projects, i had never any issues with my fix and no users complaining about heavy gpu/cpu usages in background or heavy lags after minimizing the client. i would say my "fix" can be used without any worries.

On 11/8/2022 at 1:00 AM, Gurgarath said:

Hello,

Sorry for the late answer, I had to sort out other things before going back to this issue. I checked everything and the only time it occured so far with me was with the "Red Dryads". The maximum distance recorded was "8.60". It can also be related to the motion itself. So cranking it up to 9 should reduce most of the issues. I updated the tutorial and I will keep my informations like that to eventually make some fine-tune and publish it. Thank you for your report!

even with 9.0f we get false positives^^ way less but still few 

i get ranges over 13 with 2hand weapons sometimes^^

dunno, somehow only on few maps. guess have to crank it even higher

its already public. Dont know where it was but i have something like that already implemented month ago. i guess it was here on metin2dev

9 hours ago, Gurgarath said:

Can you tell me the steps to reproduce please, with a gif eventually?

It's possible that false positive occurs and it's very easy to fine-tune the detection based on specific cases. I personally just tried to exp 30 minutes in the redwood in multiple spots and with multiple mobs, even destroyed a stone and spawned two hundred monsters of different kind and I didn't manage to get a single report (until I fought the redwood boss, in which I got two reports during all the fight that I couldn't reproduce).

I have had a few false positives so far, that I am logging and investigating, but please, note that for this fix to work, you must have correct server data for monsters (with correct accumulations and so on). Every fix on the server that relies on sectree (speedhack etc.) must have correct data for the server to correctly process what is going on. It is slightly prone to lags and you must be careful of your server's data.

  Reveal hidden contents

A mismatch will occur if your client have different data than the server, for example on the client you will see a monster that is in your vicinity and attack it, while based on the server data, notably motion accumulation, this mob is 7 meters behind because on his motion data, he cannot travel the distance it does on the client, and the "fix" (as you call it) is rightfully telling you that you cannot attack a monster that is this far (because for the server, he is far).

 

I do not say that the fix is perfect, far from that, but if your server data are correct, you are not supposed to get spammed like this and the amount of false positive is relatively small. The goal of the system is not to ban players, but to mitigate obvious abuse. If you are getting spammed ONLY in specific places, then it is more your fault than the system's fault. I would however gladfully fix the system if you provide me with enough informations, but so far, I only had a small amount of false positive, nothing that hinders the gameplay (I didn't notice once that I was flagged and that my hit was cancelled) and I log every single one of them to make sure they won't happen twice.

I am genuinely interested on the issue, thank you for your report.

 

dunno how i should post a gif for it, we are simply using bravery cape at the end of red forest and we get hundreds of spam messages in chat from the fix. The thing is, i didnt removed the return in the function so the outranged mobs should still gets "ignored" but for us, every mob dies fine. Its not like we are hitting 20 times on specific mobs and they wont die because of desync so they should be all in range but i dont know why we then get all those false positives. Can you give me your red forst mob folders so i can check their accumulation and compare with mine. 

Also we have this issue with the red forest boss as you mentioned.

Bugged bro. Pulling mobs on maps with many mobs gets always detected. For us, red forest every pull with bravery cape triggers the "fix".

On 7/10/2022 at 11:45 PM, Kafa said:

Nice bro, could u tell for others how exactly you fixed it ? 

on the git page theres a "fixxed" files for "more safebox pages", check it out. This fix is the new way he handle the grids in his fixxed safebox.cpp. Adapt it to your file and u good2go

4 hours ago, Kafa said:

You have 5 safebox pages and you say its still byte? 

This is the hidden content, please

• Sign In
• or
• Sign Up

 just increase the byte here is a tutorial

yeah because its absolutly not necessary to extend it to dword or int because im only using 225 length, not even close to 255 so this could not be the problem

edit: i now implemented your tut for 6 pages and DWORD but still have the absolute same problem:

edit: the problem was safebox.cpp the grids. Fixxed

10 minutes ago, Kafa said:

I had the same issue, check your code again with visual studio maybe there is something byte. i forget how i fixed it.

the whole storage data type is byte, i didnt extended my safebox size over 255 so i didnt had to change byte to dword or int.

any ideas? someone has the same problem? giving 2 size items in last slot will made it look like this. Same with 3 size items with only 2 slots left on one side.

@ Maliany idea?

---- solved

if anyone has problem with size 2 and 3 items in shopex with 80 slot npcs, change

CGrid grid(5, 9); in shop_manager.cpp to:

CGrid grid(10, 9);

--fixxed--

can someone post the "old" fix again so i can remove the old one? added it years ago and the TE was so smart to remove the old code so we cant remove it??

how do i have to understand? sash scales from lvl 4 sashes are 11-25%, so how can i add this properly?

lVal = number(SASH_GRADE_4_ABS_MIN, SASH_GRADE_4_ABS_MAX_COMB);

did i miss something? xD

edit: interesting, it only gives the correct absorption when i use the npc to refine them, when i create them with command, it gives low values on it. Is this changeable? like i have higher sashes in chests and they get low values

any idea? just remove? 

btw:

Real Server Log OffAsyncSQL: connected to localhost (reconnect 1) FATAL ERROR!! mysql client library was not compiled with thread safety failed, retrying in 5 seconds

? you have full source from libmysql? i cannot change the thread_safe option because its missing

Just now, JorJe3 said:

I don't have them

scroll to the right, they are default 

use the szpointPoly2 and szPointOn2 you have by default in your skill proto?

On 5/22/2021 at 8:00 PM, Ikarus_ said:

Added an important disclaimer at the beginning!

for your disclaimer, should it not be enough if you check the CanWarp directly at the pc_warp function in questlua_pc? so you dont need to add the check to EVERY quest

like this

		if (!ch->CanWarp())
		{
			ch->ChatPacket(CHAT_TYPE_INFO, LC_TEXT("CANNOT_WARP_AFTER_TRADING"));
			lua_pushboolean(L, false);
			return 1;
		}

after the message "the event starts in 10 seconds with 2 characters" nothing happend. The questions wont show up ? any idea? 

we tested this now, with a small penetration tool and this fix does literally nothing. It wont handle the handshakes better in anyway. 1 second after i start my pen tool (the source code for this is public on a microsoft website for testing, its not even a "hard" program, it only sends 14 bytes per second) the auth server will not take any other handshake. nothing will happen. The false handshakes will not getting rejected, they wont get cleared, it only handles one by one so as long as the tool sends simple handshake requests, no one else can connect. This "fix" or "improvement" does literally nothing to your server. 

just install an pf on your freebsd and the false handshakes are getting blocked after maybe 3 seconds and than you are absolutly fine. But do not install this here and think you have a much better auth server now. The "fix" / "improvement" just didnt do anything.