Currently translated at 32.1% (242 of 753 strings)

Currently translated at 98.8% (744 of 753 strings)

Currently translated at 56.3% (424 of 753 strings)

Currently translated at 100% (0 of 0 strings)

Created new translation.

Currently translated at 94.1% (709 of 753 strings)

Currently translated at 32.5% (245 of 753 strings)

Currently translated at 94.0% (708 of 753 strings)

Currently translated at 98.1% (739 of 753 strings)

Currently translated at 98.1% (739 of 753 strings)

Currently translated at 98.0% (738 of 753 strings)

Currently translated at 95.4% (719 of 753 strings)

Currently translated at 43.8% (330 of 753 strings)

Currently translated at 75.5% (569 of 753 strings)

Currently translated at 40.2% (303 of 753 strings)

Currently translated at 36.9% (278 of 753 strings)

Currently translated at 61.6% (464 of 753 strings)

Currently translated at 54.1% (408 of 753 strings)

Currently translated at 52.3% (394 of 753 strings)

Currently translated at 35.4% (267 of 753 strings)

Currently translated at 36.2% (273 of 753 strings)

There it isn't needed.

This adds a chat console the server owner can use for administration
or to talk with players.
It runs in its own thread, which makes the user interface immune to
the server's lag, behaving just like a client, except timeout.
As it uses the same console code as the f10 console, things like nick
completion or a scroll buffer basically come for free.
The terminal itself is written in a general way so that adding a
client version later on is just about implementing an interface.

Fatal errors are printed after the console exists and the ncurses
terminal buffer gets cleaned up with endwin(), so that the error still
remains visible.

The server owner can chose their username their entered text will
have in chat and where players can send PMs to.
Once the username is secured with a password to prevent anybody to
take over the server, the owner can execute admin tasks over the
console.

This change includes a contribution by @kahrl who has improved ncurses
library detection.

Fix memory leak in minetest.place_schematic
Slightly refactor Schematic code

Use type 'string' for v3fs and add comments

Before, time progressed wrongly. This was due to a mistake in how m_time_of_day_f was calculated,
and a regression of the last two commits.

The Atomic implementation was only partially correct, and was very complex.
Use locks for sake of simplicity, following KISS principle.
Only remaining atomic operation use is time of day speed, because that
really is only read + written.

Also fixes a bug with m_time_conversion_skew only being decremented, never
incremented (Regresion from previous commit).

atomic.h changes:
	* Add GenericAtomic<T> class for non-integral types like floats.

	* Remove some last remainders from atomic.h of the volatile use.

It isn't possible to use atomic operations for floats, so don't use them there.

Having a lock is good out of other reasons too, because this way the float time
and the integer time both match, and can't get different values in a race,
e.g. when two setTimeofDay() get executed simultaneously.

Cleanup:
	* Remove volatile keyword, it is of no use at all. [1]
	* Remove the enable_if stuff. It had no use either.
	  The most likely explanation why the enable_if stuff was there is that it
	  was used as something like a STATIC_ASSERT to verify that sizeof(T) is not larger
	  than sizeof(void *). This check however is not just misplaced in a place where we
	  already use a lock, it isn't needed at all, as gcc will just generate a call to
	  to the runtime if it compiles for platforms that don't support atomic instructions.
	  The runtime will then most likely use locks.

Code style fixes:
	* Prefix name of the mutex
	* Line everything up nicely, where it makes things look nice
	* Filling \ continuations with spaces is code style rule

Added operations on the atomic var:
	* Compare and swap
	* Swap

The second point of the cleanup also fixes the Android build of the next commit.

[1]: http://stackoverflow.com/q/2484980

On Windows Release x64 bit build this changes:

ProfilerGraph::put
1.68% -> 0.061%

ProfilerGraph::draw
12% -> 17.%

So yes, there is a tradeoff between saving profiling data
(executed always) and drawing the profiler graph (executed very rarely).
But usually you don't have the profiler graph open.

Using logging for these just makes them bloated and hard to read and overally just not neat at all.