Unfortunately memory databases are not supported yet... basically it does work, but what's currently missing is a mechanic to store the world on the hard drive periodically. The setting in the server.properties is ignored atm 
About getting stuck at 10%: at this stage the client is fully connected (authenticated etc) and waits for the world data (the remaining 10-100% solely depend on how many chunks were already loaded). But the server also sends all other relevant data to the client at this stage, e.g. poster images, plugin assets (3d models, UI images), map tiles etc. It's possible that the client is too busy downloading these files (so it does not receive any world data). And if the player has a high ping, for example, or an unstable internet connection (high packet loss etc), the troughput can be very low...
Another direct problem is that the client sometimes no longer receives other data from the server (world data, chat messages etc) while being busy downloading large files - and if the client doesn't receive any world data (while still in the loading screen) for a given amount of time, it will close the connection.
Before the recent update, this timeout for this was somewhere between 15 and 20 seconds, but we increased it to 40 seconds - and if a packet was received in the meantime, the game even increases this limit to 120 seconds. This means in the worst case, the client gets stuck at 10% for up to 2 minutes before getting a timeout (and if throughput is too low, the client possibly still did not receive the necessary data).
Some data (like poster images, plugin assets etc) are cached clientside, so once a player has downloaded these files, he usually has less trouble joining the server the next time.
One possible solution that we can implement is to use a webserver to download large files. The dedicated server already has a built-in webserver (used for queries for the server list, but later this will also be used for the RCON tool). File transfer could be a bit faster (using TCP instead of UDP), but more importantly it would not interfere with receiving other data from the server (world data, chat messages etc). This could possibly solve the getting-stuck-at-10%-issue (unless there is another issue causing this) 
Working with it could then look like this, for example:
The problem is that we do not clear the memory when creating the array for the getItems() method, we just fill it with the items in the furnace. But if one item is missing (i.e. one entry is null), the array index is not explicitly set to a null ptr - and in JNI, this array index will then just contain a random memory address (and accessing it results in a fatal error). We will fix that with the next update 
Ich habe da definitiv nichts gemacht, warum sollte ich auch.
Das Problem dabei ist, dass so ein Feature leider einen gewissen Rattenschwanz hinter sich herzieht und dadurch nicht ganz so trivial umsetzbar ist... alle Bautexturen sind quasi zu einer einzelnen Textur zusammengepackt (einem sog. Texturen-Array) - denn wenn die Texturen einzeln vorliegen würden (über 200 Stück), wäre der Zugriff der Grafikkarte bzw. des Shaders darauf viel zu langsam (und auch die Bauelemente könnten nicht so effizient mit versch. Texturen gerendert werden).
"Klein" eher im Sinne der vorgenommenen Änderungen und Fixes 
Daher das Beispiel mit den 45° Gebäude
