fdb_

I made a few changes to handle the movespeed changes. Might need some improvements, but for now it's handling things well.

Also moved SendMonsterMoveByPath out of the Unit header. Got really tired of recompiling everything because I added or changed some debug output in that function.

Have you tried ccache ?

Hi,

Am I the only one wanted to browse over the forums using https ?

If yes this is too bad

Anyway, it seems that when you direct access to the forum with https it works fine except that any links are written with http, so you left the secure browsing as soon as you click a link....

TheLuda can you check this ?

Kind regards,

fdb.

hehe you right

Maybe moving it to unit to also handle vehicles power types in future ?

.rename DasBlub Undertaker

I fully agree with DasBlub.

But I am affraid to use a poor (even if it is practical) bugtracker. In my mind a bugtracker will ease a lot of work but many of public facilities giving access to a bugtracker does not implement workflows, categorization or a good search engine...

The lack of those features can be a pain to comunicate, exchange and find the right information for most of people.

My 2 cents.

That's what you advised

I know this, but why there is no permanent semaphore at all in my other system ?

Seems that some semaphore can become residual almost like zombie processes (I cannot confirm btw).

In sysctl -p

error: "kernel.semmsl" is an unknown key

error: "kernel.semmns" is an unknown key

error: "kernel.semopm" is an unknown key

error: "kernel.semni" is an unknown key

Yeah you are right I write this and it is totally wrong

In fact all these params are in one kernel config named "kernel.sem".

List current semaphore values:

# ipcs -ls

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

You can also use the following command:

# cat /proc/sys/kernel/sem
250     32000   32      128

Here are the information I found from the Oracle recommendations (should work for any other hungry systems):

SEMMSL

The SEMMSL kernel parameter is used to control the maximum number of semaphores per semaphore set.

Oracle recommends setting SEMMSL to the largest PROCESS instance parameter setting in the init.ora file for all databases hosted on the Linux system plus 10. Also, Oracle recommends setting the SEMMSL to a value of no less than 100.

SEMMNI

The SEMMNI kernel parameter is used to control the maximum number of semaphore sets on the entire Linux system.

Oracle recommends setting the SEMMNI to a value of no less than 100.

SEMMNS

The SEMMNS kernel parameter is used to control the maximum number of semaphores (not semaphore sets) on the entire Linux system.

Oracle recommends setting the SEMMNS to the sum of the PROCESSES instance parameter setting for each database on the system, adding the largest PROCESSES twice, and then finally adding 10 for each Oracle database on the system. To summarize:

SEMMNS = sum of PROCESSES setting for each database on the system

+ ( 2 * [largest PROCESSES setting])

+ (10 * [number of databases on system]

To determine the maximum number of semaphores that can be allocated on a Linux system, use the following calculation. It will be the lesser of:

SEMMNS -or- (SEMMSL * SEMMNI)

SEMOPM

The SEMOPM kernel parameter is used to control the number of semaphore operations that can be performed per semop system call.

The semop system call (function) provides the ability to do operations for multiple semaphores with one semop system call. A semaphore set can have the maximum number of SEMMSL semaphores per semaphore set and is therefore recommended to set SEMOPM equal to SEMMSL.

Oracle recommends setting the SEMOPM to a value of no less than 100.

Dynamic setting:

# echo "250 32000 100 128" > /proc/sys/kernel/sem

Persistant settings:

# echo "kernel.sem=250 32000 100 128" >> /etc/sysctl.conf

I hope this one will work

I think this is related to mangos and not to system.

When I spoke about Oracle I did not mean that it came from the SQL server. But I was refering to some Linux system requirements for a medium loaded Oracle on Linux (some system tuning - including semaphores - have to be set).

In some case mangos can be very greedy. So some system tuning can be mandatory.

BTW, I think you set the number of allowable semaphores far too high, something like 1K seems already very high to me and should be fine for most of the mangos servers.

Thank you, but the thing is that with another mangos rev in another server, there is no semaphore att all ! (and I use MySQL, that's weird)

EDIT : done this, but still the same error. I'll kill myself

I also have those error on a test server but I did not think it was a problem.

I will try to find a workaround but I cannot promise to do it quick.

Meanwhile you can try to put these lines in your sysctl config file (in fact, that are the tests I will do on my test server):

kernel.semmsl = original value * 4 (or * 8)
kernel.semmns = original value * 4 (or * 8)
kernel.semopm = original value * 4 (or * 8)
kernel.semmni = original value * 4 (or * 8)

Of course, still use

sysctl -a

to find the current system values.

NB: The sysctl config file need to be reloaded to apply the changes (or reboot your server).

Also, I have heard from a Veritas engineer that some kind of semaphores can only be cleaned with a system reboot (I doubt that this is the only solution but it worth a try to have a clean system before reproducing the error).

You can try to list the semaphores with

ipcs -a

And to delete semaphore

ipcrm -s [i]id[/i]

Be gentle because some semaphores does not belong to mangos but to other system processes.

Good luck.

Try this:

echo 134217728 >/proc/sys/kernel/shmall
echo 134217728 >/proc/sys/kernel/shmmax

Or put in your sysctl config file (to have the settings kept after a reboot):

kernel.shmall = 134217728
kernel.shmmax = 134217728

There are the descriptions of the semaphore kernel params:

SEMMSL: maximum number of semaphores per id

SEMMNS: maximum number of semaphores, system wide.

SEMOPM: maximum number of operations in one semop call.

SEMMNI: number of semaphore identifiers (or arrays), system wide.

You can also tune the semaphore max numbers to avoid these messages. For example Oracle needs value larger than 100 in semaphore kernel params.

To list all the system params:

sysctl -a

(use grep to find the one you want)

Also try to use google to find system kernel config for Oracle, perhaps it will help.

Good luck and keep us updated.

BEware of the white rabbit !!! This one is awesome

'Cause you look more like a super genius if you have your own core with its own name

I think it was good to mention the copyrights issue and al that's around it but now I think that focusing on the main thread subject will be more constructive.

Please good forward guys, this is not a forum where it is good to flame

When you do that, maybe you could add a suffix such as "11293_mangos_command_WARNING.sql" or something you want. Do the sql updates need to have exactly the same file name form?

Yes something like that will permit to handle special cases and also to automate the updates.

Nice patch

Not all sql updates safe apply without reading notes. Some weeks ago have some that specially notes check DB name compatibility before apply.

So you anyway need read related commit notes before apply sql update

Yes that's true, for example sometimes the databse name is hardly coded in the script, if you have changed the default db names you can run in deep trauma...

The following is a try to revamp the old ticket engine in a new fashion manner.

It is deeply inspired by laise and Janu work.

Let's go with some specs:

In game commands:

Deleting tickets:

.ticket del all $Char_name (Delete all the tickets created by $Char_name)

.ticket del all (Delete all the tickets in the database !!!)

.ticket del all opened (Delete all open tickets)

.ticket del all closed (Delete all closed tickets)

.ticket del $Ticket_id (Delete ticket $Ticket_id)

.ticket del before $date (Delete tickets before the given date...)

Used to clean the ticket from database.

Delete a ticket (or many tickets) without checking their status, neither if they are assigned.

Deleting tickets commands should be configured as level 3.

Special behaviour:

When the GM select a player, .ticket del all will delete all the tickets opened by this player (including opened/closed/pending tickets)

Closing tickets:

.ticket close all $Char_name (Close all the tickets opened by $Char_name)

.ticket close all (Close all the tickets opened)

.ticket close $Ticket_id (Close the ticket $Ticket_id)

.ticket close $Ticket_id $Reason (Close the ticket $Ticket_id with $Reason)

Closing a ticket (or many tickets) will flag the ticket as closed, without deleting it from the database.

A GM can only close the tickets that are assigned to him or assigned to GM's with lower access rights.

Only assigned tickets can be closed.

Example:

GM_lvl3 can close all the tickets opened by the player JDoe (command: ".ticket close all JDoe") even if the tickets are handled by different GM (GM_lvl1_A and GM_lvl1_B ), but GM_lvl1_A using the same command (".ticket close all JDoe") will result in only closing the tickets he is handling.

Same behavior applies to every commands.

Assigning tickets:

.ticket assign (Assign the current tickets of the selected player to the GM who is writing this command)

.ticket assign $Ticket_id (Assign the $Ticket_id to the GM who is writing the command)

.ticket assign $Ticket_id $GM_Name (Assign the $Ticket_id to $GM_Name)

.ticket assign level $Ticket_Id $level (Set the ticket to be handled by a $level GM)

.ticket assign level $Ticket_Id $level $Reason (Set the ticket to be handled by a $level GM with $Reason)

A GM assigns the tickets with those commands.

A GM can assign a ticket to himself or to lower level GM only.

Requeing tickets:

.ticket requeue $Ticket_id (Requeue the ticket $Ticket_id)

.ticket requeue $Ticket_id $Reason (Requeue the ticket $Ticket_id with $Reason)

Tickets history:

.ticket history $Ticket_id (Show the ticket history)

Basically unassign the ticket.

Additional information:

- Every command should check the GM level to avoid assiging/closing/requeuing/deleting tickets that are handled by higher level GM's.

- $Reason field can be handled as an history field, text format can be discussed later (something like :timestamp: text msg\\n\\r:timestamp: msg2....).

Update of this field occurs:

-- when an escalation is requested,

-- when a requeue is requested,

-- when the ticket is closed.

- The use of SOAP can help to handle almost all the ticketing system from an external adm website.

This is a pretty complete ticket system.

Development start: on-hold.

Due date: to be defined.

If this project has a dev planned I will make a dedicated thread.

Any comments are welcome.

Keeping the number of cleared ticket per GM seems also a good idea.

Current ticket handling is very basic, so this modification is very very useful.

Tested on [10392] and does not disappear.

Certainly moving hosting to http://kpsn.net/

It seems interesting to have this kind of patch.

With the lastest RPS and RFS linux kernel patches (included in mainstream from the last kernel 2.6.35) it can be a very efficient way to handle massive amount of clients.

More information:

- Receive Packet Steering (RPS) http://lwn.net/Articles/328339/

- Receive Flow Steering (RFS) http://lwn.net/Articles/382428/

Well, first, it's a comparison against glibc 2.3 from 2002-2003, current glibc is 2.9 (2009-2010). Second - using LD_PRELOAD is not "compilation". It's just a dynamic linking.

Hehe, that's right I just forgot "or fully..."

Another way to improve mysql seems to use thread cached mallocs developped by google.

Install and add "LD_PRELOAD="/usr/lib/libtcmalloc.so"" in your mysqld_safe (or fully recompile mysql with this new malloc).

http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html

Hi DaViper,

I fully agree with you for the convenient purpose of combining patch Managing an high amout of diff file and handling conflicts is a 24/7 work without a good planning.

But on the dev side I prefer to see atomic commits on my own repository (even on outside repo's).

I do not have a crash using YTDB.

Peerhaps it is related only to a DB issue, in that case report the problem on the DB forums.