Jump to content
metin2dev
Vanilla

[SRC] Vanilla Core [latest: r70220]

Recommended Posts

vor 20 Stunden schrieb .NyanCat:

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!

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:

	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);
				it = m_mapServerTimer.erase(it);
			}
		}
	}

 

Regards

  • Like 2

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

Hey everybody! I've got some news on the upcoming release.

Thanks to people sending me code snippets I'm able to crush some bugs that I wasn't able to notice (due to not using the functions as my daily driver).

Additionally further vanilla revs will no longer use different locale-files depending on the country. What I mean with this is that it will always read locale.lua in your quest-folder instead of anything else. Though the countries still does count, since it will still be used when moving to the quest directory (for example locale/de or locale/gb). Only the locale.lua is a unified way of reading this file.

Next is a total conversion into utf8. This means that also the database will be read with utf8 encoding. If you go ahead and convert your client to utf8 too, you'll be able to send and receive messages with characters you may not be able to use before. utf8 is a unified way of handling charsets and the future vanilla revs will only run with this charset.

Of course this may or may not break backwards compatibility. I've chosen to go this route since it fixes a few things I'm also planning for the future and is less error-prone if you only have to deal with one charset. Also it's more simple since the database can (and should!!!) be changed to utf8 and this way represent all the needed characters. Ultimately, if you want to upgrade to higher python versions, utf8 will be needed since it's the only charset more recent python versions will use. And thus, having a server set up for exactly this charset is just perfect.

 

One important note on this - I will not break the easiness of installing the core. This means that I don't want you to have to follow steps just to use the core. I will only turn these features on when you specify it in your CONFIG file. So expect a new option. But I will print a warning if you don't activate the option since it's more or less the future and some day I will just merge in the changes and remove the ability to opt-out.

  • Like 4

Share this post


Link to post
Share on other sites
On 31.07.2017 at 10:17 PM, Vanilla said:

Hey everybody! I've got some news on the upcoming release.

Thanks to people sending me code snippets I'm able to crush some bugs that I wasn't able to notice (due to not using the functions as my daily driver).

Additionally further vanilla revs will no longer use different locale-files depending on the country. What I mean with this is that it will always read locale.lua in your quest-folder instead of anything else. Though the countries still does count, since it will still be used when moving to the quest directory (for example locale/de or locale/gb). Only the locale.lua is a unified way of reading this file.

Next is a total conversion into utf8. This means that also the database will be read with utf8 encoding. If you go ahead and convert your client to utf8 too, you'll be able to send and receive messages with characters you may not be able to use before. utf8 is a unified way of handling charsets and the future vanilla revs will only run with this charset.

Of course this may or may not break backwards compatibility. I've chosen to go this route since it fixes a few things I'm also planning for the future and is less error-prone if you only have to deal with one charset. Also it's more simple since the database can (and should!!!) be changed to utf8 and this way represent all the needed characters. Ultimately, if you want to upgrade to higher python versions, utf8 will be needed since it's the only charset more recent python versions will use. And thus, having a server set up for exactly this charset is just perfect.

 

One important note on this - I will not break the easiness of installing the core. This means that I don't want you to have to follow steps just to use the core. I will only turn these features on when you specify it in your CONFIG file. So expect a new option. But I will print a warning if you don't activate the option since it's more or less the future and some day I will just merge in the changes and remove the ability to opt-out.

need client+sf also need game and db compile with windows for windows server files

Share this post


Link to post
Share on other sites
11 hours ago, scrabbyyy said:

need client+sf also need game and db compile with windows for windows server files

Anything else? Maybe we should also pay for your server? Get real mate and do some work yourself. :mellow:

Share this post


Link to post
Share on other sites
On 31.07.2017 at 10:17 PM, Vanilla said:

Hey everybody! I've got some news on the upcoming release.

Thanks to people sending me code snippets I'm able to crush some bugs that I wasn't able to notice (due to not using the functions as my daily driver).

Additionally further vanilla revs will no longer use different locale-files depending on the country. What I mean with this is that it will always read locale.lua in your quest-folder instead of anything else. Though the countries still does count, since it will still be used when moving to the quest directory (for example locale/de or locale/gb). Only the locale.lua is a unified way of reading this file.

Next is a total conversion into utf8. This means that also the database will be read with utf8 encoding. If you go ahead and convert your client to utf8 too, you'll be able to send and receive messages with characters you may not be able to use before. utf8 is a unified way of handling charsets and the future vanilla revs will only run with this charset.

Of course this may or may not break backwards compatibility. I've chosen to go this route since it fixes a few things I'm also planning for the future and is less error-prone if you only have to deal with one charset. Also it's more simple since the database can (and should!!!) be changed to utf8 and this way represent all the needed characters. Ultimately, if you want to upgrade to higher python versions, utf8 will be needed since it's the only charset more recent python versions will use. And thus, having a server set up for exactly this charset is just perfect.

 

One important note on this - I will not break the easiness of installing the core. This means that I don't want you to have to follow steps just to use the core. I will only turn these features on when you specify it in your CONFIG file. So expect a new option. But I will print a warning if you don't activate the option since it's more or less the future and some day I will just merge in the changes and remove the ability to opt-out.

need client+sf also need game and db compile with windows for windows server files

Share this post


Link to post
Share on other sites
Spoiler

 

char_item.cpp

 

Search


bool CHARACTER::DoRefine(LPITEM item, bool bMoneyOnly)


In my source I have this check


		if (true == item->isLocked())		
	{		
		ChatPacket(CHAT_TYPE_INFO, "Bu iteme artı basamazsın.");		
		return false;		
	}

Maybe someone will find this helpfull


 

How can we install devel/libcxxrt and /devel/libc++ now ?

https://www.freshports.org/devel/libc++

No installation instructions: this port has been deleted.

The package name of this deleted port was:

PKGNAME: libc++

https://www.freshports.org/devel/libcxxrt

No installation instructions: this port has been deleted.

The package name of this deleted port was:

PKGNAME: libcxxrt

 

Best Regards,

Undyne

Share this post


Link to post
Share on other sites
Am 6.8.2017 um 19:28 schrieb Undyne:
  Unsichtbaren Inhalt anzeigen

 

char_item.cpp

 

Search



bool CHARACTER::DoRefine(LPITEM item, bool bMoneyOnly)


In my source I have this check



		if (true == item->isLocked())		
	{		
		ChatPacket(CHAT_TYPE_INFO, "Bu iteme artı basamazsın.");		
		return false;		
	}

Maybe someone will find this helpfull

 

 

 

 

How can we install devel/libcxxrt and /devel/libc++ now ?

https://www.freshports.org/devel/libc++


No installation instructions: this port has been deleted.

The package name of this deleted port was:

PKGNAME: libc++

https://www.freshports.org/devel/libcxxrt


No installation instructions: this port has been deleted.

The package name of this deleted port was:

PKGNAME: libcxxrt

 

Best Regards,

Undyne

There's no need to install libcxxrt and libc++ in recent FreeBSD distributions since it's now part of the base system and already included. You don't need to install it manually.

  • Like 1

Share this post


Link to post
Share on other sites
On 8/7/2017 at 9:00 PM, Vanilla said:

There's no need to install libcxxrt and libc++ in recent FreeBSD distributions since it's now part of the base system and already included. You don't need to install it manually.

Dear Vanilla,

 

I must start with saying that I'm sorry that I have to ask you something long (and probably boring to read) like this.

How can I compile your source ?

 

Let me tell you what I did and what's not working.

I installed FreeBSD 11.0 (i386) from the official FreeBSD website

Installed pkg:

/usr/sbin/pkg

pkg2ng

echo 'WITH_PKGNG=yes' >> /etc/make.conf

Installed  clang:

cd /usr/ports/lang/clang-devel/ && make install clean

Installed makedepend:

cd /usr/ports/devel/makedepend/ && make install clean

Added in make.conf

CC = clang-devel
CPP = clang-cpp-devel
CXX = clang++-devel
CFLAGS += -stdlib=libc++

Installed googletest:

cd /usr/ports/devel/googletest/ && make install clean

Installed cryptopp:

cd /usr/ports/security/cryptopp/ && make install clean

Installed devil:

cd /usr/ports/graphics/devil/ && make install clean

But I've got this problem

tMg5XEly.png

Then I used 'make DISABLE_VULNERABILITIES=yes' and in the end it successfully installed ( I guess )

 

Installed mariadb101-client

cd /usr/ports/databases/mariadb101-client/ && make install clean

 

 

I must say that while the ports were being installed i spotted this warning (multiple times and on different ports )

vswf8VS.png

I know that you told me that there's no need to install libcxxrt and libc++, but I found them in usr/src/lib and tried to install them.

CdyUbQP.png

I haven't found libc++.ld on my system

 

 

 

Anyway, that's all I did with the installation thing. Now when I try to use gmake depend this error shows:

3sEVGby.png

Sorry again for the long message. I hope you can and want to help me.

 

Best Regards,

Undyne

Share this post


Link to post
Share on other sites

at first

CFLAGS += -stdlib=libc++

is not needed anymore since FreeBSD already uses libc++ with the most recent versions since.. well, clang is the default compiler and libc++ is now a part of the base system :)
There's no need in adding this variable.

 

Next you need makedepend. It'd be located in devel in the portstree.

Also you'd check if your portstree is up to date. To do so, try portsnap fetch update. If this doesn't work (which mostly happens if you install a clean freeBSD [and it's not a wonder ;D]) then just go ahead and use portsnap fetch extract.
I recommend rebuilding every port after updating the ports tree. Your warnings were because you used an outdated portstree and the ports are marked as a security risk since.. yeah, they're outdated and maybe have security flaws.

After all this you'd be ready to go. Ah, and don't use gmake depend. The instruction is declared as gmake dep and not gmake depend :)

  • Like 1

Share this post


Link to post
Share on other sites
13 hours ago, Vanilla said:

at first


CFLAGS += -stdlib=libc++

is not needed anymore since FreeBSD already uses libc++ with the most recent versions since.. well, clang is the default compiler and libc++ is now a part of the base system :)
There's no need in adding this variable.

 

Next you need makedepend. It'd be located in devel in the portstree.

Also you'd check if your portstree is up to date. To do so, try portsnap fetch update. If this doesn't work (which mostly happens if you install a clean freeBSD [and it's not a wonder ;D]) then just go ahead and use portsnap fetch extract.
I recommend rebuilding every port after updating the ports tree. Your warnings were because you used an outdated portstree and the ports are marked as a security risk since.. yeah, they're outdated and maybe have security flaws.

After all this you'd be ready to go. Ah, and don't use gmake depend. The instruction is declared as gmake dep and not gmake depend :)

Thank you ! I'll try and come back with an edit.

 

Edit:

HxmIjRV.jpg

 

Working perfectly with debug game and db files, but when I try to start the server with release files this error pops up:

MQlSXNu.png

 

Also I removed the highlighted text in makefile (from game)

2h0rvl4.png

because when I tried to compile game i had this problem

QuSLmss.png

I guess it's ok since I have all the needed libs.

I'm looking forward for your replay !

 

Best Regards,

Undyne

Edited by Undyne

Share this post


Link to post
Share on other sites

The error appears when you compile with -Ofast. Try lowering it to -O3 and if that doesn't hit it, then go with -O2. IT happens only on game, not db :)

I recommend not removing -Wl,-rpath,/usr/local/lib32/metin2 since this specifies the path where libraries are loaded. Of course, that's a typo of mine in the public release (which will be fixed in next version too). It'd be -rpath and not just rpath, which is why you get the error.

  • Like 1

Share this post


Link to post
Share on other sites
vor 16 Minuten schrieb Vanilla:

The error appears when you compile with -Ofast. Try lowering it to -O3 and if that doesn't hit it, then go with -O2. IT happens only on game, not db :)

I recommend not removing -Wl,-rpath,/usr/local/lib32/metin2 since this specifies the path where libraries are loaded. Of course, that's a typo of mine in the public release (which will be fixed in next version too). It'd be -rpath and not just rpath, which is why you get the error.

Hey Vanilla,

thanks for your answer, unfortunately -o3 and -o2 doesnt solve the problem. Do you have any other ideas ?

Share this post


Link to post
Share on other sites
6 minutes ago, Aliano said:

Hey Vanilla,

thanks for your answer, unfortunately -o3 and -o2 doesnt solve the problem. Do you have any other ideas ?

 

22 minutes ago, Vanilla said:

The error appears when you compile with -Ofast. Try lowering it to -O3 and if that doesn't hit it, then go with -O2. IT happens only on game, not db :)

I recommend not removing -Wl,-rpath,/usr/local/lib32/metin2 since this specifies the path where libraries are loaded. Of course, that's a typo of mine in the public release (which will be fixed in next version too). It'd be -rpath and not just rpath, which is why you get the error.

Can confirm that -O1 is not working either.

Share this post


Link to post
Share on other sites
11 minutes ago, Damn said:

its the -DNDEBUG with it it works

Thanks man, it's working. I tried first with -ggdb, but you overcame me.

47 minutes ago, Vanilla said:

The error appears when you compile with -Ofast. Try lowering it to -O3 and if that doesn't hit it, then go with -O2. IT happens only on game, not db :)

And I really want to thank you too, you helped me a lot: really appreciate it ^_^ Keep up the good work !

Share this post


Link to post
Share on other sites
16 minutes ago, Optimus said:

Hey! what version of visual studio I need for this source?

You need to compile the source with FreeBSD.

Share this post


Link to post
Share on other sites

Hello,

always when i try to create a guild. the Server goes down. channel Syserr:

socket_connect: HOST localhost:15000, could not connect.

 

all syserr the same. the db syserr:

SYSERR: Aug 22 22:22:31 :: pid_init: 
Start of pid: 8523

SYSERR: Aug 22 22:22:31 :: Start: TABLE_POSTFIX not configured use default

 

Terminal:

connect: Connection refused

 

mysql is still running

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×