.NyanCat

On 4/24/2024 at 11:00 AM, EnneGi said:

Thanks OP for this release, i was excited to try it and it just works. Fantastic!

I have a question: i know that for the linux version to work, it was changed the network library to libevent.

I would like to implement in the source the Target Info System; do you know if that could work without problems? Or maybe there are compatibility issues

 

Thank you in advance

There should be no issue implementing that. The changes are related to the networking layer. The package transport should be untouched.

On 2/17/2024 at 9:04 PM, Hyu said:

Just wondering, does this have all the latest fixes from TPM like the item duplication fix?

No currently there are no fixes inclued.

I just learned that on most modern ARM cpus char is unsigned.
X86 cpus handle the char as signed in most cases.
I guess thats the problem with those strange behaviors on my M1-Mac.

I will test the -fsigned-char compiler flag and let you know if that helps.

The strange problems are different from arm to x86. On arm the items disappear and some other things are broken.
Running the deployment on windows, those bugs are not available but you are not able to connect after several minutes and the same happens on arm as well.(Wrong password message)
Starting the auth over helps but the problem continues.

What a wonderful project! 
Thanks for the effort!

The source compiles and runs natively on my m1 mac as well! (Without any vm)
Next is tryin to connect with the client.

Gonna keep you updated...

@ TMP4?

On 11/22/2021 at 8:47 PM, TMP4 said:

Well I just went for https://cryptopp.com/cryptopp840.zip (8.5.0 works too but I have 8.4.0 in the clientside so I choose that)

Unzip it in your freebsd then cd there then gmake then gmake install or point to that directory in your MakeFIle.
(Be sure to remove cryptopp before if you have already installed via pkg or from ports)

Still don't know why the pkg and the port version not working tho, but honestly I don't care at this point,
at least the downloadable version works

How do you build the shared lib (.so)?
If i run "gmake static dynamic" i get the error 

"ld: error: relocation R_386_32 cannot be used against local symbol; recompile with -fPIC"

I experienced that exact samr peoblem as well yesterday

On login. Auth crashes.

Hello, i do have the same problem as well.

Anyone here that can help?

Okay. No one can help me so far...

Still having this bug. I started to compare with other db sources (popular ones) and compared makefiles etc.

There is no difference in these parts! It needs to be something regarding compiler or i dont know...

I also switched root server. Same problem.

Here is my latest error:

https://metin2.download/picture/xXjn60jMVFBJ2mv7e2R1NvG1h9xAtFiV/.png

cache.h:

#ifndef __INC_COMMON_CACHE_H__
#define __INC_COMMON_CACHE_H__

template <typename T> class cache
{
	public:
		cache()
			: m_bNeedQuery(false), m_expireTime(600), m_lastUpdateTime(0)
		{
			m_lastFlushTime = time(0);

			memset( &m_data, 0, sizeof(m_data) );
		}

		T * Get(bool bUpdateTime = true)
		{
			if (bUpdateTime)
				m_lastUpdateTime = time(0);

			return &m_data;
		}

		void Put(T * pNew, bool bSkipQuery = false)
		{
			thecore_memcpy(&m_data, pNew, sizeof(T));
			m_lastUpdateTime = time(0);

			if (!bSkipQuery)
				m_bNeedQuery = true;
		}

		bool CheckFlushTimeout()
		{
			if (m_bNeedQuery && time(0) - m_lastFlushTime > m_expireTime)
				return true;

			return false;
		}

		bool CheckTimeout()
		{
			if (time(0) - m_lastUpdateTime > m_expireTime)
				return true;

			return false;
		}

		void Flush()
		{
			if (!m_bNeedQuery)
				return;

			OnFlush();
			m_bNeedQuery = false;
			m_lastFlushTime = time(0);
		}

		virtual void OnFlush() = 0;


	protected:
		T       m_data;
		bool    m_bNeedQuery;
		time_t  m_expireTime;
		time_t	m_lastUpdateTime;
		time_t	m_lastFlushTime;
};

#endif

Compiled with -std=c++2a 

As i said befor. I cant trigger that crash. It just randomly appears.

I realy need help with that one. Please help me.

@Vanilla any idea what might be the problem?

Can anyone reupload this code please?

@Vanilla

void CClientManager::FlushItemCacheSet(DWORD pid)
{
	TItemCacheSetPtrMap::iterator it = m_map_pkItemCacheSetPtr.find(pid);

	if (it == m_map_pkItemCacheSetPtr.end())
	{
		sys_log(0, "FLUSH_ITEMCACHESET : No ItemCacheSet pid(%d)", pid);
		return;
	}

	TItemCacheSet * pSet = it->second;
	TItemCacheSet::iterator it_set = pSet->begin();

	while (it_set != pSet->end())
	{
		CItemCache * c = *it_set++;

		c->Flush();
		m_map_itemCache.erase(c->Get()->id);
	
		delete c; // This is line 1408
	}

	pSet->clear();
	delete pSet;

	m_map_pkItemCacheSetPtr.erase(it);

	if (g_log)
		sys_log(0, "FLUSH_ITEMCACHESET : Deleted pid(%d)", pid);
}

void CClientManager::UpdateLogoutPlayer()
{
	time_t now = time(0);

	TLogoutPlayerMap::iterator it = m_map_logout.begin();

	while (it != m_map_logout.end())
	{
		TLogoutPlayer* pLogout = it->second;

		if (now - g_iLogoutSeconds > pLogout->time)
		{
			FlushItemCacheSet(pLogout->pid);	// This is line 1335
			FlushPlayerCacheSet(pLogout->pid);

			delete pLogout;
			m_map_logout.erase(it++);
		}
		else
			++it;
	}
}

void emergency_sig(int sig)
{
	if (sig == SIGSEGV)
		sys_log(0, "SIGNAL: SIGSEGV");
	else if (sig == SIGUSR1)
		sys_log(0, "SIGNAL: SIGUSR1");

	if (sig == SIGSEGV)
		abort();		// Main.cpp Line 58
}

@Vanilla those files are still 90 % same as your last source release r71480. The lines might vary maybe between 1-3 lines according to includes and minor changes.

I will provide the functions as fast as possible. Im not at home during the weekend so please stay tuned.

Thanks for the suggestion with ports tree. I will change my compile environment. Do i need to change the root as well? 

And again. I always relied on your source. It worked best for me and you always did a great job with tutorials and help. You are indeed one of the reasons i learn with that mt2 scene for years now (10 years now).

1 hour ago, Vanilla said:

Downgrading FreeBSD version only masks the problem.

Are you running it on the same machine as you're building it? If no, what version does the target system and the building system have?

Can you call ldd db?

What compiler are you using?

Im actually still using your source with some minor changes  thank you for your great work btw!

No i build it locally and run it on a root server. Both are latest FreeBSD 12.0 p11. All ports are up to date as well. Same.

ldd db (on root):

libc++.so.1 => /usr/lib/libc++.so.1 (0x204bd000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x20581000)
libm.so.5 => /lib/libm.so.5 (0x2059e000)
libmd.so.6 => /lib/libmd.so.6 (0x205cd000)
libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x205f1000)
libz.so.6 => /lib/libz.so.6 (0x20911000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x20929000)
libthr.so.3 => /lib/libthr.so.3 (0x20941000)
libc.so.7 => /lib/libc.so.7 (0x20969000)
libssl.so.111 => /usr/lib/libssl.so.111 (0x20b12000)
libcrypto.so.111 => /lib/libcrypto.so.111 (0x20b90000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x20de0000)
libelf.so.2 => /lib/libelf.so.2 (0x20de4000)

I use clang.

Thanks a lot for your help!

# Edit:

Ah i installed most ports over pkg and upgraded everything to the latest with pkg as well while tryin to get rid of those crashes.

I also installed same mysql versions on both.

The compilation works flawless

#Edit 2:

gdb offers a bit more information then lldb:

#0  0x20ae1f73 in thr_kill () from /lib/libc.so.7
#1  0x20ae01b1 in raise () from /lib/libc.so.7
#2  0x20a53353 in abort () from /lib/libc.so.7
#3  0x004603f7 in emergency_sig (sig=11) at Main.cpp:58
#4  0x20953408 in ?? () from /lib/libthr.so.3
#5  0x2095283b in ?? () from /lib/libthr.so.3
#6  <signal handler called>
#7  0x00446040 in CClientManager::FlushItemCacheSet (this=0xffbfe910, pid=792) at ClientManager.cpp:1408
#8  0x0043c308 in CClientManager::UpdateLogoutPlayer (this=0xffbfe910) at ClientManagerPlayer.cpp:1335
#9  0x00440a03 in CClientManager::Process (this=0xffbfe910) at ClientManager.cpp:3089
#10 0x00440040 in CClientManager::MainLoop (this=0xffbfe910) at ClientManager.cpp:191
#11 0x00460537 in main () at Main.cpp:93

Yes thats what i actually did as well! I will try that. Thank you so much!

Btw. do you have any idea why that happens? @Tunga

Hey Guys,

i hope anybody can help me

i followed this guide to upgrade my source code. 

I dont know if my following problem comes from upgrading it but i do have the following very annoying problem:

I suffer database crashes including core dumps from time to time. I cant reproduce it. It just happens suddely.

https://metin2.download/picture/SnL5RPGPO38LXzO76bDhROmsvH0ypZ7v/.png

The error log does not say anything. The source parts that are mentioned in this dump are not touched and same as original source.

Maybe you have an idea?

Thanks in advance!

Searching as well

I tried everything out now and both wait and pro damage are fixed. Moblock as well!

Nice!

Is there a solution for move speedhack?

vor 19 Minuten schrieb Kori:

The public hidden fixx is buggy and give random Bann 

Look here this is the released version but Bann random members who not use a hidden hack 

 

 

Can you send me the link to the fix?

Maybe instead of banning just kick the players? 

Can you create a guide for all types of cheats?

What about Pro/Wait Damage? Speedhacks? Wallhack?

Any updates?

There is a core down in the uniqueKill Funktion which is called in char_battle.cpp.

The down appears on very heavy loads with many plaeyrs.

Greets

Same here

vor einer Stunde schrieb Yiv:

Both solutions should work fine. I think the solution posted by Socialized using the returned iterator by the erase method should be better. I at least would change my code posted above to this:

 

Regards

vor 3 Stunden schrieb Socialized:

 

Yes you should be able just push it to a live server, as it just cleans&fixes code.
Here another example, that we had running on Zentoria, as we were struggling with similar problems:

map::erase invalidates the current iterator, but returns the one of the next element in the container.

Wow thanks guys for your help!

@Yiv: With your first solution the core crashed after about 22 hours. But without generating the .core file so i cant backtrace the error...

@Socialized Im gonna try the modification now and tell you if the crashes are gone.

Thanks again!

vor 3 Stunden schrieb Yiv:

Try to replace the CQuestManager::CancelServerTimers method in questmanager.cpp with this one:

	void CQuestManager::CancelServerTimers(DWORD arg)
	{
		for (auto it = m_mapServerTimer.begin(); it != m_mapServerTimer.end(); /**/)
		{
			if (it->first.second != arg)
			{
				++it;
			}
			else
			{
				auto event = it->second;
				event_cancel(&event);
				m_mapServerTimer.erase(it++);
			}
		}
	}

 

Regards

Hey thanks for your help!

Do you think that i can implement it right into the live system?
The problem is that it only occures on the live server. The test server does not have this problems. The files are 1:1 the same except the database (much more players on live)

I cant figure out the excact problem are these timers saved somewhere in the database?

Greetings and thanks for your help!