Shogun

Here are all the update texts regarding the beta http://games.sina.com.cn/zt/newol_0727metin2/0727_metin2_1871/index.shtml Unfortunately these files seem long lost; http://games.sina.com.cn/newgames/2004/07/072836251.shtml http://games.sina.com.cn/downgames/client/netgames/2004/08/2479022.shtml

Mark the checkbox that says Unsigned there while having applytype0 highlighted as in your picture and Save. The original game won't even run (without crashing) in a modern version of MySQL if that wasn't done already. Besides, that's not the standard location of my.cnf in FreeBSD.

Aren't you supposed to edit this stuff in uiscript?

Why do the screens look like you ran an oil paint filter on them?

Left column is Red, Green and Blue. Left is Alpha. Maximum is 1. With any palette chooser (the one in Paint net, or in Chrome Dev Tools for example, or there's online ones) you should be able to figure out values.

If you only want certain IPs to access those ports then either delete this rule: pass in on $ext_if proto tcp to any port $service_ports flags S/SA keep state (max-src-conn 64, max-src-conn-rate 32/5, overload <abusive_hosts> flush) (Or if you still want some of the service_ports to be publicly accessible just delete the ones you want to restrict from the service_ports list) And then add the IP or IPs you want to allow in the trusted_hosts table. Those IPs are trusted so they can access any port regardless of rules. That said, this is not the best way to secure either ssh or mysql, which should be done with SSH keys (and maybe changing the port to avoid the log spam from bruteforce attempts) and in MySQL, by binding the address to localhost and then using the SSH Tunnel option in Navicat instead of connecting directly to the port.

As long as you're blocking connections by default (block all or block in all should be your first rule) then you can just do this table <trusted_hosts> const { youriphere,anotherip } Pay attention to my example file to see where it's placed.

You cannot unpack them because they are compiled into binary. That's why it's called cython.

You don't see it because it's from the devil library. Maybe you have the wrong version installed, or none at all. Try installing devil from ports or something, though it looks like you are using FreeBSD 7 and it's not going to work.

Yeah, it's called cython.

So yesterday I got a PM asking for help optimizing a MySQL server and I though Icould just as well share what would be my answer with everyone. First of all make sure you are using a recent version of MySQL (5.6 at least) or MariaDB (10.3 or newer) as they generally should perform better than older versions. Upgrading your MySQL is easy - just uninstall the current version (ie: pkg delete mysql55-server) and install the new one (pkg install mysql57-server). You can find what is the currently installed version with pkg info. You may need to also uninstall and install the client separately. Note that when you uninstall MySQL it doesn't delete you data so you should be able to start your upgraded server straight away, unless you're moving to a very different version - in that case you may need to run mysql_upgrade, through newer versions of MySQL and MariaDB will do this themselves. Regardless, it's a good idea to make a backup first: either a physical copy (meaning, just copy the files in /var/db/mysql elsewhere, but stop the mysql service first to avoid table corruption!) - if we are using a still supported version we can install again in case of a problem - or backing up with mysqldump if we aren't. If you have been using your own my.cnf file for a long time, installing a new version will not replace it with fresh defaults, which means you may be using obsolete settings here that will prevent mysql from starting - just check your MySQL log at /var/db/mysql/<yourhostname>.err after starting the service to make sure everything is fine. So now that we are running a recent version, let's get to optimization proper. I am not going to explain how to find yourself what to optimize - that's what Database Administration degrees are for. I will just point you to some useful tools. It is recommended, in the first place, that you migrate as many tables as you can to InnoDB. If you use Navicat, and even if you don't, this is a very trivial task. ZFS tuning for MySQL If you have a good amount of InnoDB tables and you are using the ZFS filesystem (OVH installs ZFS by default for example) you may want to set up specific filesystems for them to match the block size of the InnoDB tables. Caution, this procedure is not advised for begginers: First thing, add these settings to my.cnf under the [mysqld] part (if these settings already exist, change them accordingly) innodb_data_home_dir = /var/db/mysql-innodb innodb_log_group_home_dir = /var/db/mysql-innodb-logs Stop the mysql-server service if it's running and then move your mysql directory: mv /var/db/mysql /var/db/mysql-bak Then in the shell execute these commands to create our custom filesystems for InnoDB: zfs create -o recordsize=16k -o primarycache=metadata zroot/var/db/mysql-innodb zfs create -o recordsize=128k -o primarycache=metadata zroot/var/db/mysql-innodb-logs zfs create -o recordsize=8k zroot/var/db/mysql Now let's copy the following files to their appropiate locations (you may not have all of these - it's ok, just skip it then) cp /var/db/mysql-bak/ib_logfile* /var/db/mysql-innodb-logs/ cp /var/db/mysql-bak/ib_buffer_pool /var/db/mysql-innodb/ cp /var/db/mysql-bak/ibdata* /var/db/mysql-innodb/ cp /var/db/mysql-bak/ibtmp* /var/db/mysql-innodb/ cp -r /var/db/mysql-bak/* /var/db/mysql/ Now start the mysql server and check the logs to make sure there's no errors; then once you're sure you can delete the /var/db/mysql-bak folder. Tuning tools First things first. The easiest way to set the host, user and password for all the MySQL related tools is to create a file named /root/.my.cnf and grant chmod 600 to it so other users can't read our password. [client] user=root password=whatever port=3306 socket=/tmp/mysql.sock This way we will log in automatically without the need to specify the same options over and over. MySQLTuner MySQLTuner is a popular perl script that will give you actionable suggestions to improve performance of your mysql server. Personally I prefer Percona Toolkit but this is a good starting point for beginners nevertheless as it's very easy to read the output. cd /root fetch http://mysqltuner.pl perl mysqltuner.pl After entering user and password of our MySQL server, it will spit a number of statistics and recommendations. For more information and command line options: https://github.com/major/MySQLTuner-perl Percona Toolkit Percona Server is, in fact, a drop in replacement for MySQL, just like MariaDB. Personally, I haven't tested it because their FreeBSD support seems sketchy. Nevertheless, we can find a port of their auxiliary tool package "percona-toolkit", which provides more insightful recommendations that MySQLTuner. Not all the tools in the kit do work, as some rely in linux commands and nobody cared to adapt them to FreeBSD (I said that the support was sketchy!), but some of the most useful ones do: pt-duplicate-key-checker Find duplicate indexes and foreign keys on MySQL tables. pt-index-usage Read queries from a log and analyze how they use indexes pt-query-digest Analyze MySQL queries from logs, processlist or tcpdump pt-table-usage Analyze how queries use tables. pt-variable-advisor Analyze MySQL variables and advise on possible problems (Similar to MySQLTuner suggestions) Usage examples of Percona Toolkit, with the two tools I found the most useful for beginners. Index usage reads a slow query log and suggests indexes to remove, while variable advisor shows suggestions similar to MySQLTuner: pt-index-usage -F /root/.my.cnf /var/db/mysql/slow.log pt-variable-advisor "S=/tmp/mysql.sock" That's all for now. Don't expect miracles for running automated tools - those tools don't know your hardware specs, your goals and needs, or whether you are running other software in the machine. These are all important considerations - giving MySQL all the memory for itself is not a good idea if your Metin server is in the same machine for example. Use them to help you understanding what can be changed and the effect it has, and don't just implement suggestions blindly. And remember some of the settings in MySQL If you have performance problems and can't sort them out, try using a default my.cnf or deleting all the optimizations you made - sometimes reverting to defaults is the best option.

A small update - I decided to revert to using MariaDB 10.4 instead because our Log DB is running on MariaDB and the upgrade to MySQL 8 would involve a full dump and restore which would take hours with the server offline (50 GB of data there) Another reason is neither percona toolkit or xtrabackup, two tools I wanted to try out recently (more on this in a new post) do not have a FreeBSD port that is compatible with MySQL 8.

FreeBSD is the best decission YMIR made. I don't get the obsession with porting it to a system just because it's more popular. There's a reason Netflix, Apple and Sony use it.

Wow where did you find this? That's really early stuff. Too bad the ninja didn't look like that

I had those crashes with skills or mobs which had 0 as damage if I recall correctly, in any case if your syslog has 18k lines and your syserr 2 somethin is seriously wrong. Dump your skill_proto table and paste the SQL here.